A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery
RFC 8466

Note: This ballot was opened for revision 08 and is now closed.

(Ignas Bagdonas) Yes

Comment (2018-04-03 for -09)
No email
send info
Authors, thank you for the detailed and thorough service model, especially for sections 6 and 7, it shows a good example to follow for model development. 

A few comments and nits: 

References to NMDA (8342) and tree diagrams (8340).

s2: VPWS definition seems to have a missing word - established as a logical [connection?] through a PSN.

s2: B-U-M vs BUM abbreviation, BUM seems to be more widely used in VPLS and EVPN references.

s3.1: IPLS reference RFC 7436.

s/VxLAN/VXLAN throughout the document.

s5.2.1: s/leave/leaf.
s5.2.1: references to E-Line and E-LAN would be good to have, MEF 6.

s5.2.2.4: MAC-VRF, s/arerequired/are required

s5.2.2.4: H&S disjoint topology would require more than two RTs in total, one per hub and at least one for sites. 

s5.2.5: first paragraph: three frame types are supported - could you clarify? Did you mean three frame types need to be supported? 

s5.3: Terminology - exterior interfaces vs ACs.

s5.3: last paragraph: the site may support single homed or multi-homed [access?] - seems to be a word missing. 

s5. s/802.1AH/802.1ah, a reference would be good. 

s5. Micro-BFD reference RFC7130.

s5. cfp-802.1-ag vs cfm-8021-ag

s5.6.2: s/ALPHA-2/ISO 3166.

s5.10.1: s/dot1p/802.1p (or 802.1D).

s5.10.3: CE to CE frame modification - why SHOULD NOT form is used? What would happen if it  gets modified - as there is a common practice of not trusting customer CoS marking. 


s5.16.1, 5.16.2, 5.16.3: the use of EBGP, MP-BGP terms - it is just BGP, does it need to be emphasized? 

s6: s/operatorpolicy/operator policy

s6: s/itscontrol/its control

s6: NETCONF/YANG ecosystem - maybe just YANG based ecosystem?

s7: s/Netconf/NETCONF

(Benoît Claise) Yes

(Deborah Brungard) No Objection

(Ben Campbell) No Objection

Comment (2018-04-03 for -09)
No email
send info
Just a few editorial comments:

Abstract: The abstract seems overly long and detailed. In particular, the 2nd paragraph is not very meaningful without the elaborations later in the body of the document. It should probably be removed from the abstract, or at least reduced to the last two sentences.

§1: Paragraph 1 needs elaboration. Paragraph 4 provides that elaboration. I suggest keeping them together rather than separate them with other paragraphs that are only loosely related.  (If it were me, I would remove all but the first sentence of the first paragraph to just before paragraph 4.)

§3.1, 2nd bullet s/psedowires/pseudowires  (2 times)

§4: This section would benefit from a definition (or citation to a definition) of "orchestration", especially to distinguish between "service orchestration" and "network orchestration". (It may be that the target audience all knows the terms, but it's been my experience that everyone thinks they know what "orchestration" means, but they often do not agree on the definition. )

(Alissa Cooper) (was Discuss) No Objection

Comment (2018-04-13)
No email
send info
Thanks for addressing my DISCUSS and COMMENT. I still find it odd that the text talks about configuring access to "the" cloud when really it's about configuring access to one or more specific cloud providers.

(Spencer Dawkins) No Objection

Benjamin Kaduk No Objection

Comment (2018-04-04 for -09)
No email
send info
I support Alissa's DISCUSS.

Please be consistent about BUM vs. B-U-M and what it expands to.  (This is probably a symptom of a more
general issue for documents this long with multiple contributors, where it's easy to lose a common
editorial style.)  NNI and potentially other acronyms should be expanded, as well.

In Section 1

   This version of L2VPN service model supports the Network Management
   Datastore Architecture (NMDA) [I-D.ietf-netmod-revised-datastores].

is ambiguous, being readable either as "NMDA is an optional features
of this version of (the) L2VPM service model" or "(the) L2VPN
service model works in support of the NMDA".

Section 5.3.2

   This site-network-access type may have an impact on the parameters
   offered to the customer, e.g., an SP might not offer encryption for
   multipoint accesses

I'm reluctant to document in 2018 something as a "VPN" that does not
offer encryption, given the term's slight redefinition in the
public's eye.  Maybe a different example could be used?

Section 5.6.4

   For an already-configured site-network-access, each constraint MUST
   be expressed against a targeted set of site-network-accesses.  This
   site-network-access MUST never be taken into account in the targeted
   set -- for example, "My site-network-access S must not be connected
   on the same POP as the site-network-accesses that are part of Group

I'm confused by this statement.  Possibly just by the pronoun "This
site-network-access", but maybe more.

Section 5.10.3

   The whole Layer-2 multicast frame (whether for data or control)
   SHOULD NOT be altered from CE to CEs except that the VLAN ID field
   may be modified, ensuring that it is transparently transported.  If
   VLAN IDs are assigned by the SP, they can also be altered.

I assume that "from CE to CEs" means when spanning the SP network,

But I'm still confused by the "SHOULD NOT ... except that the VLAN
ID field" combined with "If VLAN IDs are...they can also be
altered".  Is this redundant or in need of rephrasing, or am I
misreading something?

In Section 5.16, why would someone pick option A, B, or C over the others -- in which case(s) are
they better or worse?

In the security considerations (Section 9), I see the standard YANG boilerplate is in use.
In some ways this document's use of YANG is non-standard, though, since it's instantiated
at a management system and not used for configuration directly.  So I'd be open to modifying
the boilerplate if that seems appropriate.

The document also covers situations where shared tenancy is possible, both on hardware and on links.
Do we want to list some of the potential risks of such shared tenancy in the security considerations,
or is that too far afield?

One last note on the security considerations -- are sections 5.12 and 5.13 really the only points for
extension via augmentation?  Perhaps I misunderstand the intended semantics of the statement.

(Suresh Krishnan) No Objection

Comment (2018-04-03 for -09)
No email
send info
Any reason this has to refer to the old Netconf Access Control Model [RFC6536] instead of the new one [RFC8341] ?

(Mirja Kühlewind) No Objection

(Alexey Melnikov) No Objection

(Adam Roach) No Objection

Comment (2018-04-04 for -09)
No email
send info
Thanks to everyone who worked on this document. I have a handful of comments.



>    +--rw sites
>    +--rw site* [site-id]
>    +--rw site-id                                string

It's possible that I don't understand the intended structure here, or that I'm
misreading the tree diagram, but it seems to me that this should be represented

     +--rw sites
     |  +--rw site* [site-id]
     |     +--rw site-id                          string



>  Example of generated PE configuration:
>  !
>  bridge-domain 1
>   member Ethernet0/0 service-instance 100
>   member vsi one
>  !
>  l2 router-id
>  !
>  interface Ethernet0/0
>   no ip address
>   service instance 100 ethernet
>  encapsulation dot1q 100
>   !
>  !
>  router bgp 1
>   bgp log-neighbor-changes
>   neighbor remote-as 1
>   neighbor update-source Loopback0
>   !
>   address-family l2vpn vpls
>    neighbor activate
>    neighbor send-community extended
>    neighbor suppress-signaling-protocol ldp
>   exit-address-family
>  !
>  interface vlan 100 <-- Associating the Attachment
>    no ip address       Circuit with the MAC-VRF at the PE
>    xconnect vsi PE1-VPLS-A
>  !
>  vlan 100
>    state active

Please update this example to use IPv6 (or a mix of IPv4 and IPv6). See
https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ for guidance.



> feature lacp {
>   description
>     " Enables LACP capability in a VPN. ";
> }

Nit: the spacing around the description here seems odd.

> identity pwe3 {
>   base service-type;
>   description
>     "Pseudo-Wire Emulation Edge to
>      Edge(PWE3)Service type. .";
> }

Nit: the punctuation here seems odd. Add spaces around "(PWE3)", and eliminate
the trailing period.

>     leaf bum-overall-rate {
>       type uint32;
>       units "bps";
>       description
>         "overall rate for BUM.";
>     }

Given bandwidth trends, limiting this value to 4 Gbps seems to be potentially
problematic. Consider a larger integer type.

Martin Vigoureux No Objection