Original text:
orchestrator in the L3NM (e.g., customer) or be used to feed some L3NM attributes (e.g., actual forwarding policies).  Also, some information captured in the L3SM may be maintained locally within the <del> orchestrator; which is in charge of maintaining the correspondence </del>  between a customer view and its network instantiation.  Likewise, some information captured and exposed using the L3NM can feed the service layer (e.g., capabilities) to drive VPN service order automated VPN service provisioning and delivery. An L3VPN involves nodes that are part of a topology managed by the <del> service provider network.  Such topology can be represented using the network topology module in RFC8345. </del>  L3NM is not a device model. will still be required. A common function that is supported by VPNs is the addition or <del> removal of customer sites.  Workflows can use the L3NM in these scenarios to add or prune nodes from the network data model as required. </del>  6.2. allocation can be performed by that management system.  In cases where the service spans across multiple management systems, the task of allocating RTs has to be aligned across the domains, therefore, <del> the service model must provide a way to specify RTs.  In addition, </del>  route distinguishers (RDs) must also be synchronized to avoid collisions in RD allocation between separate management systems.  An incorrect allocation might lead to the same RD and IP prefixes being Indicates the Autonomous System Number (ASN) that is configured for the VPN node. <del> As defined in I-D.ietf-opsawg-vpn-common, these RD assignment modes are supported: direct assignment, automatic assignment from a given pool, automatic assignment, and no assignment.  For illustration purposes, the following modes can be used in the deployment cases: </del>  The VPN service provider (service orchestrator) assigns explicitly RDs.  This case will fit with a brownfield scenario Indicates both operational and administrative status of a VPN network access. <del> Represents and groups the set of Layer 2 connectivity from where </del>  the traffic of the L3VPN in a particular VPN Network access is coming.  See connection. routes to the same destination prefix. Used to convey the status of a static route entry.  This data node <del> is used to control the (de)activation of individual static route entries. </del>  In addition, the L3NM supports the following CE-PE routing protocols: routing loops (Section 7 of RFC4364).  The Site of Origin attribute is encoded as a Route Origin Extended Community. <del> Carries an IPv6 Address Specific BGP Extended that is used to indicate the Site of Origin for VRF information RFC5701.  It is used to prevent routing loops. </del>  Controls whether the PE-CE link is advertised to other PEs.

Reviewer comments:
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: Section 1, Paragraph 6 Is correspondence referred to corresponding relation or correlation? If they are equivalent, I am okay with the current wording. 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] 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. 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 6.1 Paragraph 2 Is RT/RD synchronization mechanism between Pes in the scope of document? If none, please make this clear. 6.2, Paragraph 2 s/service model/network model 6.3 Paragraph 2 Is MPLS P2MP the only transport for multicast traffic in this case or just an example transport? 7.4 'rd'definition s/ these RD/the following RD Section 7.6 'connection' definition s/from where/from which 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. 7.6.3, 'status' definition s/ is used to control the (de)activation/can also be used to control the (de)activation Section 7.6.3 'ipv6-site-of-origin' definition s/IPv6 Address Specific BGP Extended/IPv6 Address Specific BGP Extended Community 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. 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. Section 8 s/RFC UUU/RFC XXX

Revised text:
orchestrator in the L3NM (e.g., customer) or be used to feed some L3NM attributes (e.g., actual forwarding policies).  Also, some information captured in the L3SM may be maintained locally within the  <ins> orchestrator; which is in charge of maintaining the correlation </ins> between a customer view and its network instantiation.  Likewise, some information captured and exposed using the L3NM can feed the service layer (e.g., capabilities) to drive VPN service order automated VPN service provisioning and delivery. An L3VPN involves nodes that are part of a topology managed by the  <ins> service provider network.  Such The topology can be represented using the network topology YANG module defined in RFC8345 or its extension such as a User-Network Interface (UNI) topology module (e.g., I-D.ogondio-opsawg-uni-topology). </ins> L3NM is not a device model. will still be required. A common function that is supported by VPNs is the addition or  <ins> removal of VPN nodes.  Workflows can use the L3NM in these scenarios to add or prune nodes from the network data model as required. </ins> 6.2. allocation can be performed by that management system.  In cases where the service spans across multiple management systems, the task of allocating RTs has to be aligned across the domains, therefore,  <ins> the network model must provide a way to specify RTs.  In addition, </ins> route distinguishers (RDs) must also be synchronized to avoid collisions in RD allocation between separate management systems.  An incorrect allocation might lead to the same RD and IP prefixes being Indicates the Autonomous System Number (ASN) that is configured for the VPN node.  <ins> As defined in I-D.ietf-opsawg-vpn-common, the following RD assignment modes are supported: direct assignment, automatic assignment from a given pool, automatic assignment, and no assignment.  For illustration purposes, the following modes can be used in the deployment cases: </ins> The VPN service provider (service orchestrator) assigns explicitly RDs.  This case will fit with a brownfield scenario Indicates both operational and administrative status of a VPN network access.  <ins> Represents and groups the set of Layer 2 connectivity from which </ins> the traffic of the L3VPN in a particular VPN Network access is coming.  See connection. routes to the same destination prefix. Used to convey the status of a static route entry.  This data node  <ins> can also be used to control the (de)activation of individual static route entries. </ins> In addition, the L3NM supports the following CE-PE routing protocols: routing loops (Section 7 of RFC4364).  The Site of Origin attribute is encoded as a Route Origin Extended Community.  <ins> Carries an IPv6 Address Specific BGP Extended Community that is used to indicate the Site of Origin for VRF information RFC5701.  It is used to prevent routing loops. </ins> Controls whether the PE-CE link is advertised to other PEs.