James, We have published the next revision of the draft addressing your comments and fixing the typos.
- Added SRH TLV processing to pseudo-code - Added description of mutable and immutable fields of SRH as mandated by Section 2 of RFC 8754 - Added description change for HMAC TLV processing as mandated by Section 2 of RFC 8754 Thanks, -Rishabh On Tue, Feb 28, 2023 at 1:51 PM Rishabh Parekh <risha...@gmail.com> wrote: > Jim, > Fine. Will add SRH TLV processing to pseudo-code in next revision. > > -Rishabh > > On Tue, Feb 28, 2023 at 1:49 PM James Guichard < > james.n.guich...@futurewei.com> wrote: > >> Hi Rishabh, >> >> >> >> Thanks. Adding where in the processing logic TLVs are processed (if >> locally configured) I think is a worthwhile update. >> >> >> >> Jim >> >> >> >> *From:* Rishabh Parekh <risha...@gmail.com> >> *Sent:* Tuesday, February 28, 2023 4:48 PM >> *To:* James Guichard <james.n.guich...@futurewei.com> >> *Cc:* SPRING WG List <spring@ietf.org>; spring-cha...@ietf.org >> *Subject:* Re: WGLC for draft-ietf-spring-sr-replication-segment >> >> >> >> Jim, >> >> Thanks for diligently catching the typos in the document :) Will fix them >> in the next revision. >> >> >> >> As for SRH TLVs, they can be processed at Replication Node, if allowed by >> local configuration, before an incoming packet is replicated. I see RFC >> 8754 Section 4.3.1.1 SRH processing pseudo-code does not explicitly mention >> SRH TLV processing, but we can add to SRv6 End.Replication pseudo-code if >> you think it is necessary. >> >> >> >> Thanks, >> >> -Rishabh >> >> >> >> On Tue, Feb 28, 2023 at 6:11 AM James Guichard < >> james.n.guich...@futurewei.com> wrote: >> >> 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”. >> >> >> - Perhaps change to -> ““A SR Replication segment allows a packet to >> be replicated from a Replication Node to *one or more* Downstream >> nodes”. >> >> >> - 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 >> >> >> - *[Jim] r/as/a* >> >> >> - A Replication segment can replicate packet to directly connected >> nodes or to downstream nodes >> >> >> - *[Jim] r/packet/packets* >> >> >> - Section 2.2.1 >> >> >> - *[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 >> >> >> - * 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 >> >> >> - the Leaf/Bud bud node which responds with an ICMPv6 Echo >> >> >> - *[Jim] remove “bud” typo* >> >> >> >> Thanks! >> >> >> >> Jim >> >> >> >> >> >> *From:* Rishabh Parekh <risha...@gmail.com> >> *Sent:* Monday, February 27, 2023 2:57 PM >> *To:* SPRING WG List <spring@ietf.org> >> *Cc:* 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> >> 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%7Cec7c7bfd25414bf59a2608db19d57c6b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638132176954671077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UA2ybryYZzAO3sRzkNu4QijmMM8IX4ZgDSWLig6ajfk%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%7Cec7c7bfd25414bf59a2608db19d57c6b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638132176954827289%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CAnVac8VQPxeUl7RzXCacXTZQMCdd3LDcRFsWl%2BAu3M%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%7Cec7c7bfd25414bf59a2608db19d57c6b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638132176954827289%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yPkmHH%2FEz8yKMOmQw9N1LkvaEWxZrmwRPAUp6ovG03Y%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
