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> 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] *On Behalf Of *Rishabh > Parekh > *Sent:* Tuesday, February 28, 2023 3:57 AM > *To:* SPRING WG List <spring@ietf.org> > *Cc:* 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> 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> 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> > *Sent:* Thursday, February 16, 2023 12:37 AM > *To:* James Guichard <james.n.guich...@futurewei.com> > *Cc:* Xiejingrong (Jingrong) <xiejingrong=40huawei....@dmarc.ietf.org>; > bruno.decra...@orange.com; SPRING WG <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> 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
