Xingrong, Replies inline @ [RP2]
On Sat, Dec 17, 2022 at 1:34 AM Xiejingrong (Jingrong) <xiejingrong= [email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/spring
