Hi Jingrong, Rishabh, For the case where a tunnel is used for multiple VPNs, how to demultiplex traffic at a tunnel leaf is totally independent of replication SID. It's actually outside the scope of this draft in WGLC.
It's true that we want to make sure that the replication SID will work with demultiplexing method. So far, I've see three proposals in this thread and in discussions before: 1. Using a service SID as the source IP address - discussed in BIER WG two years ago. 2. Using a service SID after the replication SID, whose locator is a well-known value meaning "local" and FUNCT bits identify the service (e.g., VPN). The concept was also discussed before in BIER WG. 3. Like #2, though the locator is the ingress PE's locator. All these could potentially work with the replication segment as specified in this draft. We don't have to debate here which one is better and should be chosen. Here I'm using "service SID" instead of "context SID" to avoid ambiguity. In all cases, the FUNCT bits in the service SID are just the equivalent of an MPLS service label. As such, it can be from the ingress PE's local space, a "global" space like SRGB or a "Domain-wide Common Block" (DCB) - a concept introduced in draft-ietf-bess-mvpn-evpn-aggregation-label as mentioned below. Jeffrey How a Juniper Business Use Only From: spring <spring-boun...@ietf.org> On Behalf Of Rishabh Parekh Sent: Wednesday, December 21, 2022 1:00 PM To: Xiejingrong (Jingrong) <xiejingrong=40huawei....@dmarc.ietf.org> Cc: SPRING WG <spring@ietf.org>; spring-cha...@ietf.org Subject: Re: [spring] Issue #1: VPN SID in Multicast //RE: WGLC for draft-ietf-spring-sr-replication-segment [External Email. Be cautious of content] Xingrong, Replies inline @ [RP2] On Sat, Dec 17, 2022 at 1:34 AM Xiejingrong (Jingrong) <xiejingrong=40huawei....@dmarc.ietf.org<mailto:40huawei....@dmarc.ietf.org>> wrote: Why SRv6 is broken in current proposal IMO: 1. PE1 allocate VPN SID 1/2/3 from its Locator for each MVPN (say MVPN 1/2/3) that want to share a single replication tree. 2. PE1 encapsulate the received packet in an outer IPv6 header with SRH, as I assuming it, where IPv6 {DA = P1.Replicate}, SRH {SL=1, VPNSID1, P1.Replicate} so the VPNSID1 is after the Rep SID. 3. P1 receives the packet, with the destination address being P1.End.Replicate, replicates the packet and sends to PE2 and PE3, with the destination address changed to PE2.End.Replicate and PE3.End.Replicate respectively. //Look, the active SID is P1.End.Replicate, and the packet of the received packet with SRH is meaning, by its semantics in current SRv6 architecture, that the packet should then be proceeded to the Next SID (VPN SID1). The Locator of the VPN SID1 is PE1, and the packet should go to PE1. Correct ? [RP2] SRv6 architecture does not mandate SRH processing for a local SID. From RFC 8986: Section 1 Introduction: A function is locally defined on the node where it is executed and may range from simply moving forward in the segment list to any complex user-defined behavior Section 4 SR Endpoint Behaviors The list is not exhaustive. In practice, any behavior can be attached to a local SID; for example, a node N can bind a SID to a local Virtual Machine (VM) or container that can apply any complex processing on the packet, provided there is an SRv6 Endpoint Behavior codepoint allocated for the processing. P1 is a pure Replication Node, it will just replicate incoming packet as (SA=PE1, DA=PE2.Replicate){SL=1, VPNSID1} and {SA=PE1, DA=PE3.Replicate){SL=1, VPNSID1} to PE2 and PE3 respectively. PE2 and PE3 as Leaf nodes will process the SRH and the upper layer header. //Or maybe one may say, the SRH in step 2 is {SL=0, VPNSID1, P1.Replicate}. Then why "hiding" the VPNSID1 in the SRH that is determined not to use (SL=0) ? IMO It is breaking SRv6 by the "hiding" things that is not semantically suitable in SRv6 SRH. DOH is a much better choice if, for any reason, the source address as I suggested above is not the taste. [RP2] There is no "hiding" as explained above. //Or maybe one may say, the VPN SID is allocated from an "Global unique" space named "DCB". I would request the authors and WG to define that since I really don't understand it. Let me cite RFC8986 section 3.2: "Assign a unique B:N::/64 block to each SRv6-enabled node in the domain". [RP2] draft-ietf-bess-mvpn-evpn-aggregation-label describes the concept of DCB. But again why does it matter how the FUNCT bits (corresponding to VPN context) are allocated - upstream on PE1 or from globally unique space? [RP] It is natural to extend the concept of Replication SID as SR-MPLS label to a SRv6 Endpoint behavior represented by FUNCT bits of SRv6 SID. I don't think this "... break[s] SRv6 architecture, scope and restrictions in many aspects". First of this document does not mandate the "context" SID following the SRv6 Replication SID; it just lays down the purpose and restriction on SIDs following the Replication SID. Second, this draft makes it clear that the scope of this "context" SID is local to a Leaf node. [XJR] A proposal that is not mandatory should not break SRv6 either IMO. [RP2] As explained above, optional context SID does not "break" SRv6 architecture. How does the "ICMPv6 error message MUST NOT be originated as a result of receiving ... a packet destined to an IPv6 multicast address" may be considered ? 1. "ICMPv6 error message MUST NOT be originated as a result of receiving ... a packet destined to an IPv6 multicast address" is from RFC4443, to prevent a reflection amplification DDoS attack in my understanding. [RP] Replication SID is not an IPv6 multicast address, but what is your specific concern with ICMPv6 error messages? Note RFC 4443 does allow some ICMPv6 error messages for IPv6 multicast packets (Section 2.4 (e.3)) and acknowledges this exception can be used for DoS attack (Section 5.2 bullet 5). [XJR] How if a packet is replicated to 100 branch nodes, and each branch node found that the HopLimit of the packet is 1. [RP2] I see. We can add a section in the draft about not originating ICMPv6 errors for Replication SID except for exceptions allowed by RFC 4443 for IPv6 multicast groups. We can also add a security note documenting potential security concerns as described in Section 5.2 bullet 5. -Rishabh
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
