Hi Rishabh: For your statement “disallow any SIDs after Replication SID in SRH and break the MVPN use case”, I understand it that, the “SIDs after Replication SID in SRH” is intended for “MVPN use case”. Therefore I think that is exactly in Bruno’s comment “leaving any application/VPN specifics outside the scope of this SPRING document”.
You said previously that aggregation of multiple MVPN is optional for this document, therefore I assume “to disallow any SIDs after Replication SID in SRH” may not be a big problem for your solution as it is optional. Further, to “disallow any SIDs after Replication SID in SRH”, there are still many possible ways to solve the “MVPN use case” outside the SPRING wg, do you agree with that ? So why need to insist on keeping “SIDs after Replication SID in SRH” in the SPRING document but is really a solution IMO for “MVPN use case” ? I don’t think the use of ambiguous terms like “context” instead of MVPN or VPN-SID does really “leave the application/VPN specifics outside the scope of this SPRING document”. Please remember my previous questions about VPN-SID like SRv6 Upstream-assigned SID or SRv6 DCB SID that are still pending, and that have been understood by Gyan. But I think they can be all solved if it is to “disallow any SIDs after Replication SID in SRH”. And further, I assume “to disallow any SIDs after Replication SID in SRH” is the original and correct design in rev-05 and previous versions. For example In Rev-05 the text below shows a very clear design with careful consideration IMO: An End.Replicate SID MUST only appear as the ultimate SID in a SID- list. An implementation that receives a packet destined to a locally instantiated End.Replicate SID that is not the ultimate segment SHOULD reply with ICMP Parameter Problem error (Erroneous header field encountered) and discard the packet. There MUST not be any topological SID after a Replication SID in a packet. Otherwise, the behavior at Downstream nodes of a Replication segment is undefined and outside the scope of this document. Thanks, Jingrong 本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments may 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: Wednesday, March 1, 2023 5:38 AM To: Xiejingrong (Jingrong) <xiejingr...@huawei.com> Cc: SPRING WG List <spring@ietf.org>; spring-cha...@ietf.org Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment Jingrong, Your suggestion, especially the proposed SRv6 pseudo-code changes, would completely disallow any SIDs after Replication SID in SRH and break the MVPN use case! When Bruno mentioned " leaving any application/VPN specifics outside the scope of this SPRING document", I think he meant to keep the details of the "context" (VPN-SID) out of the SPRING draft, not discard it altogether. With the clarifications and caveats in text and pseudo-code of the latest version about SRH processing on Replication nodes, use of a SID in SRH to provide context for packet processing packets on Leaf/Bud node is clear and valid according to chairs and WG. Thanks, -Rishabh On Tue, Feb 28, 2023 at 1:50 AM Xiejingrong (Jingrong) <xiejingr...@huawei.com<mailto:xiejingr...@huawei.com>> wrote: Hi, WG chairs, authors, and all: Thanks the authors firstly for positively work on this document and update the draft. To be clear, I am not blocking the WGLC. Instead, I am willing to see the technical concerns could be solved, and I would like to give my suggestions based on your latest rev-12. I noticed that: Jim had required the document to provide SRv6 pseudo-code for the accurate behavior defining. Joel had commented/questioned that “the replication behavior does under soem circumstances result in a packet with a partially processed segment list in an SRH and a destination address that does not appear explicitly or by mechanical manipulation in the SRH”. Bruno had suggested that “leaving any application/VPN specifics outside the scope of this SPRING document. This may help with the resolution of some WGLC comments”. To better understand all these comments about application/VPN/MVPN, I have carefully checked all the diffs from rev-00 to rev-12. I feel that, the question may had been brought to the document unintentionally in rev-06, because there was no “application/VPN/MVPN for SRv6 data plane” problem in rev-05 and the definition of SRv6 Replication SID to be the ultimate SID in rev-05 is correct IMO. https://author-tools.ietf.org/iddiff?url1=draft-ietf-spring-sr-replication-segment-06<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl1%3Ddraft-ietf-spring-sr-replication-segment-06&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7C86c4ad95812d4bf6b00e08db14c7a362%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638126619933889962%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oSmaUByvH01KKEKqUWPzqHYVVkxK4Ouv49hPZysv%2FUc%3D&reserved=0> I also feel that, based on the current rev-12, it is not so hard to solve the question about application/VPN/MVPN ---- that is to use the original design of rev-05 and have all VPN references removed outside the scope of this document. Here is my suggestions based on the rev-12 for your reference, and I would like very much to listen to the chairs and authors if the suggestions are helpful: The document says the following notes, and I understand it as “Warning of Misunderstanding it may cause”: Notes: * The IPv6 destination address in the copy of a packet is set from local state and not from SRH I would suggest: The above “Warning of Misunderstanding” text is no longer needed since these will be misunderstanding (see below). The document says: When N receives a packet whose IPv6 DA is S and S is a local End.Replicate SID, N does: S01. Lookup FUNCT portion of S to get Replication State RS S02. If (IPv6 Hop Limit <= 1) { S03. Discard the packet S04. # ICMP Time Exceeded is not permitted (Section 2.2.3 below) S05. } S06. If RS is not found { S07. Discard the packet S08. } S09. Decrement IPv6 Hop Limit by 1 S10. Call Replicate(RS, packet) S11. If (RS.Node-Role == Leaf or RS.Node-Role == Bud) { S12. If (IPv6 NH == SRH and Segments Left > 0) { S13. Derive packet processing context(PPC) from Segment List[Segments Left - 1] S14. } Else { S15. Derive packet processing context(PPC) from FUNCT of Replication SID S16. } S17. Remove the outer IPv6 header with all its extension headers S18. Process the packet in context of PPC S19. } I would suggest the following pseudo code from S08a to S08c is added before S09, and S11a is used to replace S12 to S18: S08a. If (IPv6 NH == SRH and Segments Left > 0) { S08b. Discard the packet S08c. } S11. If (RS.Node-Role == Leaf or RS.Node-Role == Bud) { S11a. Process the packet that is outside the scope of this document. E.g, in MVPN/EVPN document. S19. } The document says the following notes, and I understand it as “Warning of Operation Errors/Exceptions it may cause”: Notes: * The behavior above MAY result in a packet with partially processed segment list in SRH under some circumstances * The packet processing context usually is a FIB table T I would suggest: The above “Warning of Operation” text is no longer needed according to the suggestions above. Thanks, Jingrong 本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments may 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: spring [mailto:spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>] On Behalf Of Rishabh Parekh Sent: Tuesday, February 28, 2023 3:57 AM To: SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>> Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment We have published revision 12 of the draft. Main changes include: - Pseudo-code for SRv6 End.Replicate - Description and example of ping to a Replication SID - Changes to text to address comments from Bruno, Jim and Joel Please review. Thanks, -Rishabh On Fri, Feb 24, 2023 at 4:06 PM Rishabh Parekh <risha...@gmail.com<mailto:risha...@gmail.com>> wrote: Jim, The text you refer to in Section 2.1 and .2.2 has changed after addressing comments since the last revision, but we will try to incorporate the suggested change. Thanks, -Rishabh On Mon, Feb 20, 2023 at 8:06 AM James Guichard <james.n.guich...@futurewei.com<mailto:james.n.guich...@futurewei.com>> wrote: Hi Rishabh & authors, To close out this discussion, in sections 2.1 and 2.2 we have: There MAY be SIDs after the Replication SID in the segment list of a packet. These SIDs are used to provide additional context for processing a packet locally at the node where the Replication SID is the Active Segment. The processing of SIDs following the Replication SID MUST NOT forward the SR-MPLS packet to another node. The chairs believe it would be helpful to add a sentence to clarity the scope and offer the following text "Coordination regarding the absence or presence and value of context information for replication leaves is outside the scope of this document.". Thanks! Jim, Joel & Bruno From: Rishabh Parekh <risha...@gmail.com<mailto:risha...@gmail.com>> Sent: Thursday, February 16, 2023 12:37 AM To: James Guichard <james.n.guich...@futurewei.com<mailto:james.n.guich...@futurewei.com>> Cc: Xiejingrong (Jingrong) <xiejingrong=40huawei....@dmarc.ietf.org<mailto:40huawei....@dmarc.ietf.org>>; bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>> Subject: Re: WGLC for draft-ietf-spring-sr-replication-segment James, On Wed, Feb 15, 2023 at 8:05 AM James Guichard <james.n.guich...@futurewei.com<mailto:james.n.guich...@futurewei.com>> wrote: Hi Jingrong & document authors, I would like for now to leave aside the issue of whether or not application/VPN specifics should be outside the scope of this SPRING document (I will however be revisiting this point in subsequent emails) and focus on bringing closure to the technical comments detailed in https://mailarchive.ietf.org/arch/msg/spring/_1sSZCfCZWlHwXvYpfOtDZZ9M3g/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2F_1sSZCfCZWlHwXvYpfOtDZZ9M3g%2F&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7Cdb56daac0d014f3482a208db0fdfde76%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638121226437340003%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xMx%2BHL31Nq%2FdqZZOXZf9ZEkPD5dptGq7Tsdp7mwieiU%3D&reserved=0>. As I read through your comments Jingrong I think I can summarize your objection to be that you believe the proposal breaks the SRv6 architecture as the forwarding relies upon local state rather than state carried within the SRH. Do I have that right? If this is the case then you need to be specific in terms of which text/sentences in the document are in conflict with which text/sentences of existing RFCs. As written I think Rishabh’s forwarding example is accurate as he describes a lookup on the Replication SID and the action is to either update the outer IPv6 address with the downstream nodes address, or re-encapsulate the packet with a new IPv6 header and SRH. I might draw your attention to https://www.rfc-editor.org/rfc/rfc8754.html#name-fib-entry-is-a-locally-inst<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8754.html%23name-fib-entry-is-a-locally-inst&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7Cdb56daac0d014f3482a208db0fdfde76%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638121226437340003%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=q56RV5lZ8B6B%2F43YzGfa1LyhHu3l1JZbK9M%2Byx3hDvk%3D&reserved=0> which talks about the definition of future SIDs and their behaviors. Further your comments appear to me to suggest that the VPN identification encapsulated at PE1 acts like a normal VPN SID in the sense that forwarding is based upon that IPv6 address. I don’t think that is the intent here; I think the SID is used as an identifier for the VPN itself so that the downstream nodes are given the correct VPN forwarding context i.e. they are not supposed to use that SID to forward the packets back to PE1. Perhaps the authors could clarify this point further? Hi Rishabh, it would be helpful if you could review the comments in https://mailarchive.ietf.org/arch/msg/spring/_1sSZCfCZWlHwXvYpfOtDZZ9M3g/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2F_1sSZCfCZWlHwXvYpfOtDZZ9M3g%2F&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7Cdb56daac0d014f3482a208db0fdfde76%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638121226437340003%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xMx%2BHL31Nq%2FdqZZOXZf9ZEkPD5dptGq7Tsdp7mwieiU%3D&reserved=0> again and perhaps provide more clarity on the expected behavior as there seems to be a difference in understanding of the actual operation. [RP] Exactly, the only purpose of VPN SID is to provide a VPN context at Leaf/Bud nodes to forward the inner packet (encapsulated at ingress PE). I have removed most of the text related to VPN (in yet unpublished next revision) based on Bruno's earlier, but this has been explained earlier in the thread. -Rishabh
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
