A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery
draft-ietf-l2sm-l2vpn-service-model-10
Yes
(Benoît Claise)
No Objection
(Alexey Melnikov)
(Deborah Brungard)
(Martin Vigoureux)
(Mirja Kühlewind)
(Spencer Dawkins)
Note: This ballot was opened for revision 08 and is now closed.
Benoît Claise Former IESG member
Yes
Yes
(for -08)
Unknown
Ignas Bagdonas Former IESG member
Yes
Yes
(2018-04-03 for -09)
Unknown
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.3.2.2.1: s/802.1AH/802.1ah, a reference would be good. s5.3.2.2.3: Micro-BFD reference RFC7130. s5.3.2.2.6: 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.15: s/REST/RESTCONF 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
Adam Roach Former IESG member
No Objection
No Objection
(2018-04-04 for -09)
Unknown
Thanks to everyone who worked on this document. I have a handful of comments. --------------------------------------------------------------------------- §5: > +--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 as: +--rw sites | +--rw site* [site-id] | +--rw site-id string --------------------------------------------------------------------------- §7: > Example of generated PE configuration: > > ! > bridge-domain 1 > member Ethernet0/0 service-instance 100 > member vsi one > > ! > l2 router-id 198.51.100.1 > ! > > interface Ethernet0/0 > no ip address > service instance 100 ethernet > encapsulation dot1q 100 > ! > > ! > router bgp 1 > bgp log-neighbor-changes > neighbor 198.51.100.4 remote-as 1 > neighbor 198.51.100.4 update-source Loopback0 > ! > address-family l2vpn vpls > neighbor 198.51.100.4 activate > neighbor 198.51.100.4 send-community extended > neighbor 198.51.100.4 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. --------------------------------------------------------------------------- §8: > 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.
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -09)
Unknown
Alissa Cooper Former IESG member
(was Discuss)
No Objection
No Objection
(2018-04-13)
Unknown
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.
Ben Campbell Former IESG member
No Objection
No Objection
(2018-04-03 for -09)
Unknown
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. )
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2018-04-04 for -09)
Unknown
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 10." 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, right? 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.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -09)
Unknown
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -09)
Unknown
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -09)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -08)
Unknown
Suresh Krishnan Former IESG member
No Objection