Hi WG, It seems like the technical concerns raised in my previous mails are not fully understood, or taken seriously toward solving them, as I understand the reply. To make my comments clear, please allow me to make them one by one, toward solving it collaboratively by giving my opinion on each one, and explain why I think SRv6 is broken by current proposal. Thank you Rishabh, and please see my reply to each of your points in the mail inline below with [XJR]. Don’t worry if they are not clear, as said they will be brought up one by one like below the issue #1.
Issue #1: VPN SID in Multicast. Topology: Src1----PE1----P1----PE2/PE3----Rcv2/Rcv3(connected to PE2/PE3 respectively) My Opinion toward solving the technical issue: 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, and advertise them to PE2 and PE3. 2. PE1 encapsulates the received packet in an outer IPv6 header, where the destination address is P1.End.Replicate, and the source address is the VPN SID 1, 2 or 3, determined by the VRF the received packet belonging to. 3. P1 receive the packet, with the destination address being P1.End.Replicate, the packet is replicated and sent to PE2 and PE3, with the destination address changed to PE2.End.Replicate and PE3.End.Replicate respectively. 4. PE2/PE3 use this VPN SID 1, as in the source address of the packet, to determine the VPN of the packet, and do the table lookup in the VPN for the decapsulated (inner) packet. 5. PE2/PE3 can ping/traceroute this VPN SID 1/2/3 using RFC9259, or send ICMPv6 error message back to this VPN SID as a result of an exceptional condition of above 3 to 4. 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 ? //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. //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”. Thanks, Jingrong 本邮件及其附件含有华为公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件! This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! From: Rishabh Parekh [mailto:risha...@gmail.com] Sent: Saturday, December 17, 2022 6:21 AM To: Xiejingrong (Jingrong) <xiejingr...@huawei.com> Cc: SPRING WG <spring@ietf.org>; spring-cha...@ietf.org Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment Jingrong, Replies @ [RP] Thanks, -Rishabh. On Sat, Dec 10, 2022 at 5:22 PM Xiejingrong (Jingrong) <xiejingrong=40huawei....@dmarc.ietf.org<mailto:40huawei....@dmarc.ietf.org>> wrote: Hi WG and chairs, I would like to draw your attention that, the SRv6 Replication SID will break SRv6 architecture, scope and restrictions in many aspects. Though it is still not defined what is the scope of “context”, leaving a big “hole” to explain in the future. [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. But through the past discussions we have known a little about it, for example, used as a VPN identifier in multicast scenario. [RP] VPN context has been specified in the BESS MVPN/EVPN SR-P2MP draft for quite some time now. And it is only required when a SR P2MP tree is shared across MVPNs. [XJR] obviously I am talking about SRv6. However, I think the Upstream-assigned SID or “DCB” SID in SRv6 for “context” need to be carefully evaluated by the WG. Firstly, there is no definition of “Upstream-assigned SID” or “DCB” in SRv6. [RP] Just because something has not been defined yet, does not mean it can never be defined ☺. How does a PE assigning a SID and advertising to all other PEs break SRv6 architecture? [XJR] I have explained the technical concerns in detail in my mail I think, which led to the “break” I used. Also I will explain it explicitly as above. Secondly, suppose an Ingress PE allocated an “Upstream-assigned SID” from its locator, and put the SID into the SID list after the Replication SID, what is expected to behave on every replication node to this Upstream-assigned SID ? make it an active SID, and then take it as a context ? or send it back to the Ingress PE ? [RP] This draft restricts a Leaf/Bud node using a “context” SID, if present, just for local processing of a packet; the node MUST NOT forward the packet as a result of using context SID. [XJR] We have talked about “context”, and I have explained the technical concerns in detail. 3. Suppose a DCB SRv6 SID, what is the 128bit DCB SRv6 SID looks like ? ffff:ffff:x:x:x:x:x:x? ff00:x:x:x:x:x:x:x? fe08:x:x:x:x:x:x:x? ::127.x.x.x ? [RP] The locator of "context" SID is not relevant since the packet will not be re-forwarded. The FUNCT "context" bits are significant and the egress PE/Leaf knows where this value is present in the SID based on SID structure information from BGP Prefix SID attribute sent along with MVPN A-D routes. [XJR] So why not tell me what is the 128bit DCB SRv6 SID looks like ? I still don’t understand it with your explanation. Further, I think there are many other differences between SRv6 data plane and MPLS data plane for a “Replication SID” to work in its multicast scenario context. For example, how is the “host originating an IPv6 packet” scenario (RFC8754,8986) supported ? [RP] If a host originates a packet with a locator of Replication Node with appropriate Replication SID, it will be replicated as long as security allows it. This is no different that a host originating a SRv6 packet with any other SRv6 Endpoint behavior SID. [XJR] A host originating (SA=h1, DA=End.Replicate)(UDP/ICMPv6,checksum)(payload), and how the checksum will be processed. 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. Also note that, the implementations disclosed in section 4.1 and 4.2 only include MPLS data plane. I assume they reflect the fact that Replication SID for SRv6 data plane is far from mature. Therefore I request the WG to first exclude SRv6 data plane of this draft from the WGLC scope. Then we can focus on the MPLS data plane part (Hopefully I can move from SRv6 problems if they are noted already, and then I can provide some comments on MPLS soon). [RP] SRv6 Replication SID is an essential part of this document. Section 2.2 and the corresponding example illustrated in Appendix A.2 illustrates how SRv6 Replication SID operates within the overall framework of SRv6 architecture. [XJR] See above. Thanks, Jingrong 本邮件及其附件含有华为公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件! This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! From: Rishabh Parekh [mailto:risha...@gmail.com<mailto:risha...@gmail.com>] Sent: Thursday, December 8, 2022 6:52 AM To: Xiejingrong (Jingrong) <xiejingr...@huawei.com<mailto:xiejingr...@huawei.com>> Cc: James Guichard <james.n.guich...@futurewei.com<mailto:james.n.guich...@futurewei.com>>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>; spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment Jingrong, For the second one regarding the SID after the replication SID, I still have some further question when considering it a “VPN SID”: In MPLS data plane, Is the SID an Upstream-assigned Label ? Or an SRGB label (though may be a more strictly unique number than SRGB that is a relatively unique index/offset ) ? In SRv6 data plane, is the SID an “Upstream-assigned SRv6 SID”, which is allocated on Ingress PE and put in the SID list after the replication SID ? The VPN SID is only required when SR P2MP trees are shared across VPNs. It can be upstream assigned or globally assigned (from DCB) as described in SR P2MP MVPN<https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-sr-p2mp/> draft. If present, the VPN SID is after the Replication SID. For SR-MPLS, the VPN SID SHOULD NOT be assigned from SRGB or SRLB since it is an overlay context, -Rishabh _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring