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%7C60f2bcc04ef24f5ec5b908db0ee6f572%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638120157363761147%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uCFEzdCq5sYQCRvqLbpb%2Bcd6DJK5WXyNBHLutSDLPXc%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.
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. Thanks! Jim From: spring <spring-boun...@ietf.org> On Behalf Of Rishabh Parekh Sent: Friday, February 10, 2023 1:07 PM To: bruno.decra...@orange.com Cc: SPRING WG <spring@ietf.org> Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment Thanks for the review Bruno. Responses inline @ [RP] -Rishabh On Fri, Feb 10, 2023 at 1:27 AM <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> wrote: Hi Rishabh, authors Speaking as an individual contributor. Following a request, I've done a review of the latest version of the draft. Please find below some proposed comments. -- As a general comment, may be this draft could be better restricted to the SR-replication segment itself, leaving any application/VPN specifics outside the scope of this SPRING document. This may help with the resolution of some WGLC comments. [RP] The VPN text was introduced when we were asked to add some description of which SIDs are allowed before and after the Replication SID. Let me see if we can re-word the text so VPN details are kept out of scope. -- Ideally, SR Replication and SRv6 compression would be orthogonal hence SRv6 compression would not need to be referenced, not to mention recommended ("SHOULD use a Compressed SID (C-SID) container with Downstream Replication SID as the Last uSID"). If you chose to keep recommending or even proposing uSID, you would need a normative reference to the SRv6 compression document, which may delay the RFC publication of this document. Also, depending on your choices, a uSID End.Replicate Endpoint behavior may be needed to be allocated by the IANA. [RP] On further thought I agree, the Replication SID would work identically with or without compression. I shall remove the compression text. -- In general, there are two replication SIDs/nodes: the one instantiating the replication SID and the downstream one. In order to help the reader, making this explicit in some sentences could be useful. e.g. ยง2.1 SR-MPLS OLD: There MAY be SIDs preceding the SR-MPLS Replication SID NEW: SIDs MAY be added before the downstream SR-MPLS Replication SID [RP] Will do. -- For the SRv6 dataplane, as the IPv6 destination address is modified en route, there seem to be some impact for the ICMP ping checksum. cf https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression-03#section-10.2<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-spring-srv6-srh-compression-03%23section-10.2&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7C7efa65a2df1942ebde0a08db0b91bb13%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638116492786636358%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dHFb24Jq33shKhs6i%2FY33znMRUUN1B4Vpqv1t%2B9YRq8%3D&reserved=0> Probably, it would be useful to cover this in the document. [RP] Will take a look and see what we can cover. Hope this helps. Regards, --Bruno Orange Restricted From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> On Behalf Of James Guichard Sent: Tuesday, January 10, 2023 5:04 PM To: SPRING WG <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 Hi WG: Just a quick update on the status of this WGLC. The authors are working on the various comments received so far on the list and will also most likely publish a new version of the document once all comments have been addressed. For this reason the chairs will keep this WGLC open until those actions have taken place and commenters have confirmed that their comments have been addressed. Thanks! Jim, Joel & Bruno From: James Guichard Sent: Monday, November 28, 2022 10:10 AM To: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>> Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> Subject: WGLC for draft-ietf-spring-sr-replication-segment Dear WG: This email starts a 2-week Working Group Last Call for 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%7C7efa65a2df1942ebde0a08db0b91bb13%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638116492786636358%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uo5xupW7QgrfVSl%2FCev%2BhQ7YmDULGlcInRSDbLVWIjg%3D&reserved=0> Please read the updated document if you haven't already and send your comments to the SPRING WG list no later than December 12th 2022. If you are raising a point which you expect will be specifically debated on the mailing list, consider using a specific email/thread for this point. Lastly, if you are an author or contributor please respond to indicate whether you know of any undisclosed IPR related to this document. Thanks! Jim, Joel & Bruno _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
