Draft: draft-ietf-opsawg-l3sm-l3nm

Commentary: Reviewer :    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 , Paragraph 6 Is correspondence referred to corresponding relation or correlation ? If they are equivalent , I am okay with the current wording . 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  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 7.6 ' connection ' definition s / from where / from which 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  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 7.6.3 ' ipv6 - site - of - origin ' definition s / IPv6 Address Specific BGP Extended / IPv6 Address Specific BGP Extended Community 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 . 7.6.6 ' Layer 4 ' definition s / data node under ‘ l3 ’ ( Figure 25)/data node under ‘ l4 ’ ( Figure 26 ) I did n’t check other figure number consistency . 8 s / RFC UUU / RFC XXX
Paragraph (version A):
Some information captured in the L3SM can be passed by the
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
orchestrator; which is in charge of maintaining the correspondence
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
handling, and thus the L3SM.
Paragraph (version B):
Some information captured in the L3SM can be passed by the
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
orchestrator; which is in charge of maintaining the correlation
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
handling, and thus the L3SM.
Paragraph (version A):
An L3VPN involves nodes that are part of a topology managed by the
service provider network.  Such topology can be represented using
the network topology module in RFC8345.
Paragraph (version B):
An L3VPN involves nodes that are part of a topology managed by the
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).
Paragraph (version A):
A common function that is supported by VPNs is the addition or
removal of customer sites.  Workflows can use the L3NM in these
scenarios to add or prune nodes from the network data model as
required.
Paragraph (version B):
A common function that is supported by VPNs is the addition or
removal of VPN nodes.  Workflows can use the L3NM in these scenarios
to add or prune nodes from the network data model as required.
Paragraph (version A):
For example, route targets (RTs) shall be synchronized between PEs.
When all PEs are controlled by the same management system, RT
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,
the service model must provide a way to specify RTs.  In addition,
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
exported by different PEs.
Paragraph (version B):
For example, route targets (RTs) shall be synchronized between PEs.
When all PEs are controlled by the same management system, RT
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,
the network model must provide a way to specify RTs.  In addition,
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
exported by different PEs.
Paragraph (version A):
Represents and groups the set of Layer 2 connectivity from where
the traffic of the L3VPN in a particular VPN Network access is
coming.  See connection.
Paragraph (version B):
Represents and groups the set of Layer 2 connectivity from which
the traffic of the L3VPN in a particular VPN Network access is
coming.  See connection.
Paragraph (version A):
Used to convey the status of a static route entry.  This data node
is used to control the (de)activation of individual static route
entries.
Paragraph (version B):
Used to convey the status of a static route entry.  This data node
can also be used to control the (de)activation of individual
static route entries.
Paragraph (version A):
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.
Paragraph (version B):
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.