Hi Rishabh, Please see inline [Jim]
On Wed, Feb 15, 2023 at 6:58 AM James Guichard <james.n.guich...@futurewei.com<mailto:james.n.guich...@futurewei.com>> wrote: Hi Rishabh, Authors, & WG: Having reviewed the latest version of https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-spring-sr-replication-segment%2F&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7Cbdcb0e652a84487b56d008db0fdedb81%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638121222064204376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jc%2FjseIG6xUGJ37UWvP0x8QYl027YZMOojcWM7pbt%2BA%3D&reserved=0> I would appreciate some clarification from the authors on the specifics of packet replication and forwarding between the replication point and downstream nodes. The draft as I read it bases forwarding at a replication point on the combination of a replication SID which triggers and selects the behavior and the replication state held at that node. The replication state indicates which downstream nodes the packet should be replicated to and those nodes may or may not be adjacent to the replication node. In the non-adjacent case my understanding is that the replication state may include an additional segment-list and this seems to be what the text in section 2.2. is saying by referencing H.Encaps.Red to re-encapsulate the packet with a new SRH and outer IPv6 header. If this is correct could it be made more explicit; at a minimum I would expect to see a reference to RFC 8986 section 5.2. [RP] Your understanding is correct. We can add a reference to RFC 8986 Section 5.2 as you suggest, but you say "... could it be made more explicit ..". Do you mean the current text is not clear about this? [Jim] thank you the addition of the reference is helpful. [Jim] I think the document could be more explicit by adding pseudo-code which shows the actual processing logic of the newly defined SID. RFC 8754 section 4.3.1 is very clear on this point. Please review https://www.rfc-editor.org/rfc/rfc8754.html#name-fib-entry-is-a-locally-inst You will see that the RFC says "This document and section define a single SRv6 SID. Future documents may define additional SRv6 SIDs. In such a case, the entire content of this section will be defined in that document". It is clear that your document is defining a new SID, the Replication SID, and the processing logic of that SID is different to the SRv6 SID as defined in RFC 8754. Showing in your document the processing logic pseudo-code will make this clearer and will also follow the guidelines from RFC 8754. In addition to this I would like to clarify the case where re-encapsulation is not needed i.e. when an explicit path to a downstream node is not necessary and best path forwarding suffices. The text says that in this case the outer IPv6 header is re-used and the downstream replication SID is written into the IPv6 header destination address. This address is most likely NOT contained within the SRH which is a detachment from the normal SRv6 forwarding case and I would like to hear the authors and WGs opinions on this. [RP] Yes, an encapsulation is not needed when a Downstream node is adjacent or best path forwarding to a non-adjacent node is sufficient. The downstream node's Replication SID (from Replication State) is written in outer IPv6 DA and packet is forwarded based on the locator of the downstream node. Our (i.e. authors) opinion is that is permissible within the SRv6 architecture by new End.Replication behavior (associated with incoming local Replication SID) defined in the draft. [Jim] Section 4.3.1 of RFC 8754 would appear to agree with you but I welcome the WGs comments on this if there is disagreement. Jim Furthermore, there is already precedence in SRv6 architecture to process an incoming packet based on local state and forward the modified packet. RFC 8986 defines End.B6.Encaps and End.B6.Encaps.Red (and End.BM) functions that rely on local SR policy state to modify an incoming packet. Thanks, -Rishabh
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
