Hi Qin, Many thanks for the review and comments. An updated version that takes into account your inputs can be seen at: https://tinyurl.com/l3nm-latest Please see inline for more context. Cheers, Med > -----Message d'origine----- > De : Qin Wu via Datatracker [mailto:noreply@xxxxxxxx] > Envoyé : mardi 3 août 2021 10:19 > À : ops-dir@xxxxxxxx > Cc : draft-ietf-opsawg-l3sm-l3nm.all@xxxxxxxx; last-call@xxxxxxxx; > opsawg@xxxxxxxx > Objet : Opsdir last call review of draft-ietf-opsawg-l3sm-l3nm-10 > > Reviewer: Qin Wu > Review result: Has Nits > > I have reviewed this document as part of the Operational > directorate's ongoing effort to review all IETF documents being > processed by the IESG. These comments were written with the intent > of improving the operational aspects of the IETF drafts. Comments > that are not addressed in last call may be included in AD reviews > during the IESG review. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Summary: > This document defines L3VPN network model for provisioning L3VPN > service within service provider network. It provides network centric > view of L3VPN service. I think this document is well written and > ready for publication. However I have a few editorial comments I > want like authors to consider. > > Major issue: None > Nits: > 1. Section 1, Paragraph 6 > Is correspondence referred to corresponding relation or correlation? > If they are equivalent, I am okay with the current wording. [Med] Changed to "correlation" for clarity. > > 2. Section 5, Network topology module bullet s/using the network > topology module in [RFC8345] /using the network topology module in > [RFC8345] Or its extension module such as UNI topology module [I- > D.ogondio-opsawg-uni-topology] [Med] Went with your proposal but listed the I-D as an example to model UNI: "(e.g., [I-D.ogondio-opsawg-uni-topology])". > > 3.Section 6.1 Paragraph 1 > The last sentence describes Causal relationship between template and > batch process and abstracting the parameter into upper SDN layer, it > is not very clear to me that which one is cause? Which one is > effect? Maybe I am wrong. [Med] Agree with your comment. This one will be reworded. Thanks. > > 4.Section 6.1 Paragraph 2 > Customer sites are not modelled in the L3NM any more How about s/ > the addition or removal of customer sites / the addition or removal > of VPN nodes [Med] ACK > > 5.Section 6.1 Paragraph 2 > Is RT/RD synchronization mechanism between Pes in the scope of > document? If none, please make this clear. [Med] 6.1 is about a deployment with as single administrative domain. Not sure there is a need to talk about sync, which is more a concern for the multi-domain case. > > 6.Section 6.2, Paragraph 2 > s/service model/network model [Med] ACK > > 7.Section 6.3 Paragraph 2 > Is MPLS P2MP the only transport for multicast traffic in this case > or just an example transport? [Med] This is an example in reference to this scenario. The text says: "In this scenario, ..." > > 8.Section 7.4 'rd'definition > s/ these RD/the following RD [Med] ACK > > 9. Section 7.6 'connection' definition > s/from where/from which [Med] Left the OLD wording. > > 10. Section 7.6.3 said: > "The L3NM supports the configuration of one or more IPv4/IPv6 static > routes. Since the same structure is used for both IPv4 and IPv6, > it > was considered to have one single container to group both static > entries independently of their address family, but that design > was > abandoned to ease the mapping with the structure in [RFC8299]. > " > I think you emphasize that the L2NM and L3NM to follow the similar > structure to ease the mapping. [Med] Yes. > > 11.Section 7.6.3, 'status' definition > s/ is used to control the (de)activation/can also be used to control > the (de)activation [Med] ACK > > 12. Section 7.6.3 'ipv6-site-of-origin' definition > s/IPv6 Address Specific BGP Extended/IPv6 Address Specific BGP > Extended Community [Med] Fixed. Thanks. > > 13. Section 7.6.3 'authentition' definition under BGP I think we > support different authentication modes such as TCP AO support, IPSEC > support, TLS support. I am not sure that TCP MD5 should be supported > as an option since it has break many protocols. [Med] This is mainly to accommodate the installed base. We added a new text to remind the MD5 weakness. > > 14. Section 7.6.6 'Layer 4' definition > s/data node under ‘l3’ (Figure 25)/data node under ‘l4’ (Figure 26) > I didn’t check other figure number consistency. [Med] The OLD txt is correct. The "protocol" is an L3 field. > > 15. Section 8 > s/RFC UUU/RFC XXX > [Med] That OLD one is correct as we are referring to the common model, not the L3NM. We have this note in the document: Please update "RFC UUUU" to the RFC number to be assigned to I- D.ietf-opsawg-vpn-common. _________________________________________________________________________________________________________________________ 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
