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%7C59bc7fddac014518488008db0b76fb95%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638116377898936638%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0fgFYpM5Wp6C0oYLCbyj7jNiHSnGDjFTg8RzkFnQ8Mw%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 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%7C59bc7fddac014518488008db0b76fb95%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638116377898936638%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0fgFYpM5Wp6C0oYLCbyj7jNiHSnGDjFTg8RzkFnQ8Mw%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. Thanks! Jim From: spring <spring-boun...@ietf.org> On Behalf Of Xiejingrong (Jingrong) Sent: Friday, February 10, 2023 9:55 AM To: bruno.decra...@orange.com; Rishabh Parekh <risha...@gmail.com> Cc: SPRING WG <spring@ietf.org> Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment Hi WG, I don’t agree with Bruno’s point that “this draft could be better restricted to the SR-replication segment itself, leaving any application/VPN specifics outside the scope of this SPRING document”. As I commented in [8] to the same point, the backing solution of this document is tightly related the SR-Rep Segment and the VPN identifier. The SR-Rep Segment provides the semantics/context for the many conflicting behaviors ---- the behavior of the {SR-Rep Segment + VPN Segment} together, and the behavior of normal SRv6. If it is claimed that this draft is only about SR-rep segment itself, I don’t think it is toward to answer the “breaking SRv6 architecture” question. For the point that “For the SRv6 dataplane, as the IPv6 destination address is modified en route …” I have some similar comments previously, and I still have more comments on this topic but they are queued for the “breaking SRv6 architecture” comment above to be solved. Thanks, Jingrong [8] 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%7C59bc7fddac014518488008db0b76fb95%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638116377898936638%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0fgFYpM5Wp6C0oYLCbyj7jNiHSnGDjFTg8RzkFnQ8Mw%3D&reserved=0> 本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ 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 bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> Sent: Friday, February 10, 2023 5:28 PM To: Rishabh Parekh <risha...@gmail.com<mailto:risha...@gmail.com>> Cc: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>> Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment 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. -- 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. -- 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 -- 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%7C59bc7fddac014518488008db0b76fb95%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638116377898936638%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QhmU8ZZCzycpGTNEbVNUV7oygTsT196ShDhB0GYtyd4%3D&reserved=0> Probably, it would be useful to cover this in the document. 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%7C59bc7fddac014518488008db0b76fb95%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638116377898936638%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hMN8Q50SRhD8RoJTdJzdC%2Bdi5q0DESr1gr5XdZxWBjI%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
