Draft: draft-ietf-opsawg-l2nm

Commentary: We created a placeholder for items that seem to overlap . reconsider if access - diversity makes sense in the l2 nm . 
 Certainly ethernet - segment - identifier is needed somewhere . But it could go directly under vpn - network - access . I do n't think we need group - id and constraints in the l2 nm , do you know a use - case for it ? 
 Update Ethernet segment identifier to cover explicit generated and auto - asign according to the rules of section 5 of RFC 7432 
 Include DF election method ( see draft - ietf - bess - evpn - pref - df-06 ) 
 This part of the module makes sense in the service module as it may impact how to attach a site . at the network level , these constraints are supposed to be taken into account ( selection of PE , interfaces , etc . ) . I suggest we remove this from the L2NM . 
 This part is redundant with " esi - redundancy - mode " for the evpn case . 
 I lost the context about these two . What is the purpose of these two and how this is used to infer the underlying config ? 
 The description refers to primary and secondary " L2VPN " . That 's vague . 
 The use case for the precedence is the following : ! The group - id combined with the precedence serves to model the primary and backup on the same vpn - node . So we agree to improve the description of the Leaf and Identities to reflect the use case usage and make it more clear . The figure for the usage must be inlcuded in the draft
Paragraph (version A):
Represents the point to which sites are connected.
Paragraph (version A):
Note that, unlike in L2SM, the L2NM does not need to model the
customer site, only the points where the traffic from the site are
received (i.e., the PE side of PE-CE connections).  Hence, the VPN
network access contains the connectivity information between the
provider's network and the customer premises.  The VPN profiles
('vpn-profiles') have a set of routing policies that can be
applied during the service creation.
Paragraph (version A):
See sna for more details.
Paragraph (version A):
Refers to the BGP control plane as described in RFC4761 and
RFC6624.
Paragraph (version A):
Refers to the BGP control plane as described in RFC7432 and
RFC7209.
Paragraph (version A):
Refers to LDP-signaled pseudowires RFC6074.
Paragraph (version A):
Refers to L2TP-signaled pseudowires RFC6074.
Paragraph (version A):
A 'vpn-network-access' represents an entry point to a VPN service .
In other words, this container encloses the parameters that describe
the access information for the traffic that belongs to a particular
L2VPN.  As such, every 'vpn-network-access' MUST belong to one and
only one 'vpn-node'.
Paragraph (version A):
A 'vpn-network-access' includes information such as the connection on
which the access is defined , the specific layer 2 service
requirements, etc.
Paragraph (version A):
Identifier of the VPN network access.
Paragraph (version A):
Text describing the VPN network access.
Paragraph (version A):
Administrative and operational status of the service.
Paragraph (version A):
Carries information about the service OAM.
Paragraph (version A):
The connection container is used to configure the relevant properties
of the interface that is attached to the VPN, for example the
encapsulation type, the physical interface or creating a lag.
Paragraph (version A):
This container is used to indicate the details of the ethernet
service such as bandwidth or qos.