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. 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] 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. 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 5.Section 6.1 Paragraph 2 Is RT/RD synchronization mechanism between Pes in the scope of document? If none, please make this clear. 6.Section 6.2, Paragraph 2 s/service model/network model 7.Section 6.3 Paragraph 2 Is MPLS P2MP the only transport for multicast traffic in this case or just an example transport? 8.Section 7.4 'rd'definition s/ these RD/the following RD 9. Section 7.6 'connection' definition s/from where/from which 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. 11.Section 7.6.3, 'status' definition s/ is used to control the (de)activation/can also be used to control the (de)activation 12. Section 7.6.3 'ipv6-site-of-origin' definition s/IPv6 Address Specific BGP Extended/IPv6 Address Specific BGP Extended Community 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. 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. 15. Section 8 s/RFC UUU/RFC XXX -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
