Hi Bruno and all, I read the draft and support it's adoption because it is obviously very important work for practical SRv6 migrations or introduction/co-existence with MPLS/SR-MPLS technologies. It is worth to continue this work from my (customer) point of view to have practical, deployable and standard MPLS/SR-MPLS<-> SRv6 interworking.
Here are the few minor (more cosmetic) points which I want to mention after reviewing the draft: 1) Section 4. SRv6 SID behavior. 1.1) 4.1 End.DTM .... S03. Set the packet's associated FIB table to T ... I would like to see some clarification, what is T here? 2) Section 6. Interconnecting Binding SID. I would add here the reference for RFC 9256 Section 6 that have a lot of information about BSID usage so will be quite helpful here too. 3) I think it will be worth to move section 2 Interworking (IW) scenarios with Fig.1 Close to section 7, currently it is hard to jump back and worth while reading the text in section 7 Interworking procedures. 4) 7.1 Transport IW This sentence: " An SR-PCE [RFC8664] multi-domain On Demand Next-hop (ODN) SR policy [RFC9256] stitching end to end across different data plane domains using interconnecting binding SIDs. " sounds too complicated and confusing IMO and also does not mention additional scenarios which can accomplish the same goal as PCECC. I would re-phrase, for example, like this: "An SR-PCE [RFC8664] based architecture with additional functionality such as SR policy [RFC9256] or PCECC [RFC8283] with corresponding PCEP extensions and feature like On Demand Next-hop (ODN) can provide end to end stitching across different data plane domains using interconnecting binding SIDs" 5) 7.1.2.1 6oM It is almost impossible to get the Control Plane example without any diagram there. 6) Same as above for 7.1.2.2.1 I understand that making such ASCII-art is a tough task but it will make reading much easier. 7) 7.2.1 Gateway interworking I would re-phrase two last paragraphs (Prefix learned...) they are very complicated for reading. SY, Boris On Thursday, July 11, 2024 at 04:28:19 PM GMT+3, <bruno.decra...@orange.com> wrote: Dear WG: This message starts a three-week adoption call for draft-agrawal-spring-srv6-mpls-interworking, ending on August/1rst. (The third week is to account for the busy IETF week.) >From the Abstract: This document describes SRv6 and MPLS/SR-MPLS interworking and co- existence procedures. Please review the draft and consider whether you support its adoption by the WG. Please share any thoughts with the list to indicate support or opposition -- this is not a vote. If you are willing to provide a more in-depth review, please state it explicitly to give the chairs an indication of the energy level in the working group willing to work on the document. WG adoption is the start of the process. The fundamental question is whether you agree the proposal is worth the WG's time to work on and whether this draft represents a good starting point. The chairs are particularly interested in hearing the opinions of people who are not authors of the document. Draft: https://datatracker.ietf.org/doc/html/draft-agrawal-spring-srv6-mpls-interworking List discussion: https://mailarchive.ietf.org/arch/browse/spring/?q=subject%3A%20draft-agrawal-spring-srv6-mpls-interworking Thanks! Bruno (for the Chairs) _________________ ______________________________ ______________________________ ______________________________ _ 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 To unsubscribe send an email to spring-le...@ietf.org _______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
