Hi Sasha, Yes, fair point. In light of this Rishabh please ignore my first comment đ
Jim From: Alexander Vainshtein <alexander.vainsht...@rbbn.com> Sent: Tuesday, February 28, 2023 9:30 AM To: James Guichard <james.n.guich...@futurewei.com>; Rishabh Parekh <risha...@gmail.com> Cc: spring-cha...@ietf.org; SPRING WG List <spring@ietf.org> Subject: RE: WGLC for draft-ietf-spring-sr-replication-segment James, Rishabh and all, A short comment inline below. Regards, Sasha From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> On Behalf Of James Guichard Sent: Tuesday, February 28, 2023 4:11 PM To: Rishabh Parekh <risha...@gmail.com<mailto:risha...@gmail.com>>; SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>> Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> Subject: [EXTERNAL] Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment Hi Rishabh, Thank you for the new version. A few nits/comments: - Text in the abstract currently says âA SR Replication segment allows a packet to be replicated from a Replication Node to Downstream nodesâ. o Perhaps change to -> ââA SR Replication segment allows a packet to be replicated from a Replication Node to one or more Downstream nodesâ. [[Sasha]] The definition of the replication state of the Replication Segment in section 1.1 states that this state âconceptually a list of replication branches to Downstream nodes. The list can be emptyâ. I.e., the list of Downstream nodes of a Replication segment can be empty. Therefore, I think that âone or more Downstream nodesâ could be misleading. - Couple of typos in the Introduction: - Replication segment is a new type of segment for Segment Routing [RFC8402], which allows a node (henceforth called as Replication o [Jim] r/as/a - A Replication segment can replicate packet to directly connected nodes or to downstream nodes o [Jim] r/packet/packets - Section 2.2.1 o [Jim] I do not see any mention of TLV processing. If local configuration requires TLV processing where in the pseudo code does this fit? Are there circumstances where TLV processing is prohibited if using a Replication SID? Please add this. - Section 2.2.1 o * The behavior above MAY result in a packet with partially processed segment list in SRH under some circumstances § [Jim] It would be helpful to provide an example of such a circumstance here. - Section 2.2.2 o the Leaf/Bud bud node which responds with an ICMPv6 Echo § [Jim] remove âbudâ typo Thanks! Jim From: Rishabh Parekh <risha...@gmail.com<mailto:risha...@gmail.com>> Sent: Monday, February 27, 2023 2:57 PM To: SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>> Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> Subject: Re: 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%2Fclicktime.symantec.com%2F15t5ZsiB4YuXNfPN9HJhV%3Fh%3DdGeCJtk3CMy8Rkrzlbeu8dOoYbx1qaAt1FX07q1NycQ%3D%26u%3Dhttps%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%253Dhttps%25253A%25252F%25252Fmailarchive.ietf.org%25252Farch%25252Fmsg%25252Fspring%25252F_1sSZCfCZWlHwXvYpfOtDZZ9M3g%25252F%2526data%253D05%25257C01%25257Cjames.n.guichard%252540futurewei.com%25257C0f53b811f0f64a03c35f08db18fcc74b%25257C0fee8ff2a3b240189c753a1d5591fedc%25257C1%25257C0%25257C638131246229097081%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%25257C%25257C%25257C%2526sdata%253DsfowbGiy1sECaY%25252FsX6ZjpNy%25252F5ITjL%25252BlLR6Z06oT%25252B3CY%25253D%2526reserved%253D0&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7C6b2a9ecae04c438848a408db19984971%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638131914096530431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fYQLfnHWGwz%2BHDPJWhNaLVwpV32d1qMFnEVMGCeV9A0%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%2Fclicktime.symantec.com%2F15t5ehuTXAb7ncDHgqhr7%3Fh%3D1YW4zn6qWx-vE8uLZfAz2DtpRC8zT91X-SIjiaRyX-A%3D%26u%3Dhttps%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%253Dhttps%25253A%25252F%25252Fwww.rfc-editor.org%25252Frfc%25252Frfc8754.html%252523name-fib-entry-is-a-locally-inst%2526data%253D05%25257C01%25257Cjames.n.guichard%252540futurewei.com%25257C0f53b811f0f64a03c35f08db18fcc74b%25257C0fee8ff2a3b240189c753a1d5591fedc%25257C1%25257C0%25257C638131246229097081%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%25257C%25257C%25257C%2526sdata%253DQsObo6dul7WYDfY9JSwmXse50GtOQ030LQ8z5ylbdFw%25253D%2526reserved%253D0&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7C6b2a9ecae04c438848a408db19984971%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638131914096530431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3eTM6CLlv243qhW8yct2g%2BD7DvttCQx3b%2B0E8dICnx0%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%2Fclicktime.symantec.com%2F15t5ZsiB4YuXNfPN9HJhV%3Fh%3DdGeCJtk3CMy8Rkrzlbeu8dOoYbx1qaAt1FX07q1NycQ%3D%26u%3Dhttps%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%253Dhttps%25253A%25252F%25252Fmailarchive.ietf.org%25252Farch%25252Fmsg%25252Fspring%25252F_1sSZCfCZWlHwXvYpfOtDZZ9M3g%25252F%2526data%253D05%25257C01%25257Cjames.n.guichard%252540futurewei.com%25257C0f53b811f0f64a03c35f08db18fcc74b%25257C0fee8ff2a3b240189c753a1d5591fedc%25257C1%25257C0%25257C638131246229097081%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%25257C%25257C%25257C%2526sdata%253DsfowbGiy1sECaY%25252FsX6ZjpNy%25252F5ITjL%25252BlLR6Z06oT%25252B3CY%25253D%2526reserved%253D0&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7C6b2a9ecae04c438848a408db19984971%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638131914096530431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fYQLfnHWGwz%2BHDPJWhNaLVwpV32d1qMFnEVMGCeV9A0%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 Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
