Skip to main content

A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery
draft-ietf-l2sm-l2vpn-service-model-10

Revision differences

Document history

Date Rev. By Action
2018-10-09
10 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2018-09-17
10 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2018-09-04
10 (System) RFC Editor state changed to RFC-EDITOR from AUTH
2018-08-31
10 (System) RFC Editor state changed to AUTH from EDIT
2018-06-29
10 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2018-06-28
10 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2018-06-28
10 (System) IANA Action state changed to In Progress from Waiting on Authors
2018-06-27
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-06-25
10 (System) RFC Editor state changed to EDIT
2018-06-25
10 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2018-06-25
10 (System) Announcement was received by RFC Editor
2018-06-25
10 (System) IANA Action state changed to In Progress
2018-06-25
10 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2018-06-25
10 Amy Vezza IESG has approved the document
2018-06-25
10 Amy Vezza Closed "Approve" ballot
2018-06-25
10 Amy Vezza Ballot approval text was generated
2018-06-25
10 Amy Vezza Ballot writeup was changed
2018-06-24
10 Ignas Bagdonas IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2018-05-07
10 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2018-04-19
10 Tero Kivinen Closed request for Telechat review by SECDIR with state 'No Response'
2018-04-13
10 Alissa Cooper
[Ballot comment]
Thanks for addressing my DISCUSS and COMMENT. I still find it odd that the text talks about configuring access to "the" cloud when …
[Ballot comment]
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.
2018-04-13
10 Alissa Cooper [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss
2018-04-11
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-04-11
10 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2018-04-11
10 Giuseppe Fioccola New version available: draft-ietf-l2sm-l2vpn-service-model-10.txt
2018-04-11
10 (System) New version approved
2018-04-11
10 (System) Request for posting confirmation emailed to previous authors: Luay Jalil , Chongfeng Xie , Giuseppe Fioccola , Bin Wen
2018-04-11
10 Giuseppe Fioccola Uploaded new revision
2018-04-05
09 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2018-04-05
09 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2018-04-04
09 Adam Roach
[Ballot comment]
Thanks to everyone who worked on this document. I have a handful of comments.

---------------------------------------------------------------------------

§5:

>    +--rw sites
>    +--rw …
[Ballot comment]
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.
2018-04-04
09 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2018-04-04
09 Amanda Baber IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2018-04-04
09 Benjamin Kaduk
[Ballot comment]
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 …
[Ballot comment]
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.
2018-04-04
09 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2018-04-04
09 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2018-04-04
09 Alissa Cooper
[Ballot discuss]
Sec 5.2 says:

"Cloud Access (cloud-access):  All sites in the L2VPN MUST be
      authorized to access to the cloud.  The …
[Ballot discuss]
Sec 5.2 says:

"Cloud Access (cloud-access):  All sites in the L2VPN MUST be
      authorized to access to the cloud.  The cloud-access container
      provides parameters for authorization rules.  A cloud identifier
      is used to reference the target service.  Th"

But Sec 5.2.3 says:

"By default, all sites in the L2VPN SHOULD be authorized to access the
  cloud.  If restrictions are required, a user MAY configure the
  "permit-site" or "deny-site" leaf-list.  The permit-site leaf-list
  defines the list of sites authorized for cloud access.  The deny-site
  leaf-list defines the list of sites denied for cloud access.  The
  model supports both "deny-any-except" and "permit-any-except"
  authorization."

These seem to be conflicting normative requirements. At a minimum, they need to be aligned (presumably to the formulation in 5.2.3, given the existence of permit-site and deny-site). But more generally, why does the model need to normatively require nodes to have a certain kind of access? As the Gen-ART reviewer pointed out, this doesn't seem necessary. And given that the cloud-access configuration requires the specification of a specific cloud-access identifier, what does it even mean that nodes should be authorized to access "the" cloud?
2018-04-04
09 Alissa Cooper
[Ballot comment]
This comment from the Gen-ART reviewer has not been addressed and I think it should be: "I would have expected some reference to …
[Ballot comment]
This comment from the Gen-ART reviewer has not been addressed and I think it should be: "I would have expected some reference to the MEF Ethernet service
  definitions and MEF defined parameters of interest, as industry usage seems
  to reflect those as the common basis for L2 services.  I udnerstand that
  this model is not mandated to conform to the MEF Forum work.  I would
  expect some discussion of the relationship."

Sec 5.2.3:

"The usage of cloud-access is targeted for public
  cloud and for Internet access.
  ...
 
 
     
          INTERNET
     
      "
     
From the perspective of the output of the IETF overall, the above phrasing gives me pause. The notion that the Internet is just one cloud among many seems out of sync with how we would typically talk about the Internet in the IETF, and with RFC 4084 (and perhaps RFC 1958). I realize this is basically a labeling issue, but if the cloud-access element stays in the model, would it be possible to use a different label for configuration of Internet service other than "cloud-access"? This potentially gets back to the point from the Gen-ART reviewer about the necessity of having these different identifiers not being obvious.

Sec 8:

Regarding the location element, if you want the address information to be usable globally (which presumably you do), you will want to consider profiling the address elements in RFC 4119 and/or RFC 5139. At a minimum, jurisdiction-specific identifiers like ZIP code, which only exist in the US, should be replaced by generic address field types.

Nits:

Sec 5.15:

s/remote-carrrier-name/remote-carrier-name/

Sec 5.10.3:

s/broadcast-unknowunicast-multicast/broadcast-unknown-unicast-multicast/
2018-04-04
09 Alissa Cooper [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper
2018-04-03
09 Suresh Krishnan
[Ballot comment]
Any reason this has to refer to the old Netconf Access Control Model [RFC6536] instead of the new one [RFC8341 …
[Ballot comment]
Any reason this has to refer to the old Netconf Access Control Model [RFC6536] instead of the new one [RFC8341] ?
2018-04-03
09 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-04-03
09 Ben Campbell
[Ballot comment]
Just a few editorial comments:

Abstract: The abstract seems overly long and detailed. In particular, the 2nd paragraph is not very meaningful without …
[Ballot comment]
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. )
2018-04-03
09 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2018-04-03
09 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-04-03
09 Ignas Bagdonas
[Ballot comment]
Authors, thank you for the detailed and thorough service model, especially for sections 6 and 7, it shows a good example to follow …
[Ballot comment]
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
2018-04-03
09 Ignas Bagdonas Ballot comment text updated for Ignas Bagdonas
2018-04-03
09 Ignas Bagdonas
[Ballot comment]
Authors, thank you for the detailed and thorough service model, especially for sections 6 and 7, it shows a good example to follow …
[Ballot comment]
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.
2018-04-03
09 Ignas Bagdonas [Ballot Position Update] New position, Yes, has been recorded for Ignas Bagdonas
2018-04-03
09 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2018-04-03
09 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2018-04-03
09 Giuseppe Fioccola New version available: draft-ietf-l2sm-l2vpn-service-model-09.txt
2018-04-03
09 (System) New version approved
2018-04-03
09 (System) Request for posting confirmation emailed to previous authors: Luay Jalil , Chongfeng Xie , Giuseppe Fioccola , Bin Wen
2018-04-03
09 Giuseppe Fioccola Uploaded new revision
2018-03-30
08 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2018-03-21
08 Cindy Morgan Shepherding AD changed to Ignas Bagdonas
2018-03-20
08 (System) IANA Review state changed to IANA - Not OK from IANA OK - Actions Needed
2018-03-14
08 Benoît Claise Ballot has been issued
2018-03-14
08 Benoît Claise [Ballot Position Update] New position, Yes, has been recorded for Benoit Claise
2018-03-14
08 Benoît Claise Created "Approve" ballot
2018-03-14
08 Benoît Claise Ballot writeup was changed
2018-03-14
08 Benoît Claise IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2018-03-14
08 Benoît Claise IESG state changed to Waiting for AD Go-Ahead from In Last Call
2018-03-07
08 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2018-03-07
08 Amanda Baber
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-l2sm-l2vpn-service-model-08. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-l2sm-l2vpn-service-model-08. If any part of this review is inaccurate, please let us know.

We understand that upon approval of this document, we need to perform two actions. Please see our question about the first action.

First, the following entry will be added to the IETF XML ns registry at https://www.iana.org/assignments/xml-registry:

ID: yang:ietf-l2vpn-svc
URI: urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc
File: [template from document]
Reference: [this document]

QUESTION: the template states that the contact should be the WG, but RFC 3688 states, "In the  case of IETF developed standards, the Registrant will be the IESG." Should this be changed in the document?

Second, the following entry will be added to the YANG Module Names registry at https://www.iana.org/assignments/yang-parameters. Please note that the module file will not be posted in the registry until the document has been published. If this module will in fact be maintained by IANA, please contact us:

Name: ietf-l2vpn-svc
Maintained by IANA: N
Namespace: urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc
Prefix: l2vpn-svc
Reference: [this document]

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Amanda Baber
Lead IANA Services Specialist
2018-02-26
08 Ladislav Lhotka Request for Early review by YANGDOCTORS Completed: Ready with Issues. Reviewer: Ladislav Lhotka. Sent review to list.
2018-02-24
08 Joel Halpern Request for Telechat review by GENART Completed: On the Right Track. Reviewer: Joel Halpern. Sent review to list.
2018-02-23
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Fred Baker
2018-02-23
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Fred Baker
2018-02-23
08 Amy Vezza
The following Last Call announcement was sent out (ends 2018-03-26):

From: The IESG
To: IETF-Announce
CC: l2sm-chairs@ietf.org, l2sm@ietf.org, Adrian Farrel , bclaise@cisco.com, …
The following Last Call announcement was sent out (ends 2018-03-26):

From: The IESG
To: IETF-Announce
CC: l2sm-chairs@ietf.org, l2sm@ietf.org, Adrian Farrel , bclaise@cisco.com, adrian@olddog.co.uk, draft-ietf-l2sm-l2vpn-service-model@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: UPDATED Last Call:  (A YANG Data Model for L2VPN Service Delivery) to Proposed Standard


The IESG has received a request from the L2VPN Service Model WG (l2sm) to
consider the following document: - 'A YANG Data Model for L2VPN Service
Delivery'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-03-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document defines a YANG data model that can be used to configure
  a Layer 2 Provider Provisioned VPN service.

  This model is intended to be instantiated at management system to
  deliver the overall service.  This model is not a configuration model
  to be used directly on network elements, but provides an abstracted
  view of the Layer 2 VPN service configuration components.  It is up
  to a management system to take this as an input and generate specific
  configurations models to configure the different network elements to
  deliver the service.  How configuration of network elements is done
  is out of scope of the document.

  The YANG model in this document includes support for point-to-point
  Virtual Private Wire Services (VPWS) and multipoint Virtual Private
  LAN services (VPLS) that use Pseudowires signaled using the Label
  Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as
  described in RFC4761 and RFC6624.

  The YANG model in this document conforms to the Network Management
  Datastore Architecture defined in I-D.ietf-netmod-revised-datastores.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/ballot/


No IPR declarations have been submitted directly on this I-D.




2018-02-23
08 Amy Vezza Last call announcement was changed
2018-02-23
08 Amy Vezza Last call announcement was changed
2018-02-23
08 Benoît Claise Telechat date has been changed to 2018-04-05 from 2018-03-08
2018-02-22
08 Jean Mahoney Request for Telechat review by GENART is assigned to Joel Halpern
2018-02-22
08 Jean Mahoney Request for Telechat review by GENART is assigned to Joel Halpern
2018-02-22
08 Tero Kivinen Request for Telechat review by SECDIR is assigned to Daniel Gillmor
2018-02-22
08 Tero Kivinen Request for Telechat review by SECDIR is assigned to Daniel Gillmor
2018-02-22
08 Cindy Morgan IANA Review state changed to IANA - Review Needed
2018-02-22
08 Cindy Morgan
The following Last Call announcement was sent out (ends 2018-03-08):

From: The IESG
To: IETF-Announce
CC: l2sm-chairs@ietf.org, l2sm@ietf.org, Adrian Farrel , bclaise@cisco.com, …
The following Last Call announcement was sent out (ends 2018-03-08):

From: The IESG
To: IETF-Announce
CC: l2sm-chairs@ietf.org, l2sm@ietf.org, Adrian Farrel , bclaise@cisco.com, adrian@olddog.co.uk, draft-ietf-l2sm-l2vpn-service-model@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A YANG Data Model for L2VPN Service Delivery) to Proposed Standard


The IESG has received a request from the L2VPN Service Model WG (l2sm) to
consider the following document: - 'A YANG Data Model for L2VPN Service
Delivery'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-03-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document defines a YANG data model that can be used to configure
  a Layer 2 Provider Provisioned VPN service.

  This model is intended to be instantiated at management system to
  deliver the overall service.  This model is not a configuration model
  to be used directly on network elements, but provides an abstracted
  view of the Layer 2 VPN service configuration components.  It is up
  to a management system to take this as an input and generate specific
  configurations models to configure the different network elements to
  deliver the service.  How configuration of network elements is done
  is out of scope of the document.

  The YANG model in this document includes support for point-to-point
  Virtual Private Wire Services (VPWS) and multipoint Virtual Private
  LAN services (VPLS) that use Pseudowires signaled using the Label
  Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as
  described in RFC4761 and RFC6624.

  The YANG model in this document conforms to the Network Management
  Datastore Architecture defined in I-D.ietf-netmod-revised-datastores.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/ballot/


No IPR declarations have been submitted directly on this I-D.




2018-02-22
08 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2018-02-22
08 Cindy Morgan Last call announcement was generated
2018-02-22
08 Giuseppe Fioccola New version available: draft-ietf-l2sm-l2vpn-service-model-08.txt
2018-02-22
08 (System) New version approved
2018-02-22
08 (System) Request for posting confirmation emailed to previous authors: Luay Jalil , Chongfeng Xie , Giuseppe Fioccola , Bin Wen
2018-02-22
08 Giuseppe Fioccola Uploaded new revision
2018-02-21
07 Benoît Claise Placed on agenda for telechat - 2018-03-08
2018-02-21
07 Benoît Claise Last call was requested
2018-02-21
07 Benoît Claise Ballot approval text was generated
2018-02-21
07 Benoît Claise Ballot writeup was generated
2018-02-21
07 Benoît Claise IESG state changed to Last Call Requested from AD Evaluation
2018-02-21
07 Benoît Claise Last call announcement was generated
2018-02-21
07 Benoît Claise IESG state changed to AD Evaluation from Publication Requested
2018-02-20
07 Adrian Farrel
Shepherd write-up : draft-ietf-l2sm-l2vpn-service-model

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)?
    …
Shepherd write-up : draft-ietf-l2sm-l2vpn-service-model

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)?
    Why is this the proper type of RFC? Is this type of RFC
    indicated in the title page header?

Standards Track
This is an implementable YANG model
This is correctly indicated on the title page.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up. Please provide such a Document Announcement Write-Up.

Technical Summary:

This document defines a YANG data model that can be used to configure
a Layer 2 Provider Provisioned VPN service.

This model is intended to be instantiated at management system to
deliver the overall service.  This model is not a configuration model
to be used directly on network elements, but provides an abstracted
view of the Layer 2 VPN service configuration components.  It is up
to a management system to take this as an input and generate specific
configurations models to configure the different network elements to
deliver the service.  How configuration of network elements is done
is out of scope of the document.

The data model in this document includes support for point-to-point
Virtual Private Wire Services (VPWS) and multipoint Virtual Private
LAN services (VPLS) that use Pseudowires signaled using the Label
Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as
described in RFC4761 and RFC6624.

Working Group Summary:

This has been a relatively quiet WG, but there has been useful and
technical discussion on the list. WG meetings have brought in a few
additional voices raising valuablee points. The WG has also held
virtual interim meetings to dig into the open technical issues.

Document Quality:

There is one known implementation in progress.
The document received a thorough review from Jan Lindblad as a YANG
expert. Jan was very familiar with the L3SM work and able to carry
this review across.

Personnel:

Adrian Farrel (adrian@olddog.co.uk) is the document shepherd
Benoit Claise (bclaise@cisco.com)is the Responsible AD

(3) Briefly describe the review of this document that was
    performed by the Document Shepherd. If this version of
    the document is not ready for publication, please
    explain why the document is being forwarded to the IESG.

This version of the document is ready for publication.
The document shepherd reviewed the previous version in detail
especially for English and clarity. The updates have significantly
improved the document.

(4) Does the document Shepherd have any concerns about the depth
    or breadth of the reviews that have been performed?

No concerns.
WG last call was echoes to BESS, PALS, RTGWG, and NETMOD

(5) Do portions of the document need review from a particular or
    from broader perspective, e.g., security, operational complexity,
    AAA, DNS, DHCP, XML, or internationalization? If so, describe the
    review that took place.

The big requirements were for YANG review and for input from operators
who offer L2VPN services. Jan satisfied the first. The author team
themselves satisfy the second.

(6) Describe any specific concerns or issues that the Document
    Shepherd has with this document that the Responsible Area
    Director and/or the IESG should be aware of? For example,
    perhaps he or she is uncomfortable with certain parts of
    the document, or has concerns whether there really is a
    need for it. In any event, if the WG has discussed those
    issues and has indicated that it still wishes to advance
    the document, detail those concerns here.

No concerns.
There ws debate (several times) about how this work rslates to
similar work being done by the MEF. This was discussed at WG
meetings and on the mailing list and the document shepherd is
comfortable that the work represents different approaches to
related topics rather than a competitive situation.

(7) Has each author confirmed that any and all appropriate
    IPR disclosures required for full conformance with the
    provisions of BCP 78 and BCP 79 have already been filed.
    If not, explain why?

All authors except have so confirmed.

(8) Has an IPR disclosure been filed that references this
    document? If so, summarize any WG discussion and conclusion
    regarding the IPR disclosures.

No IPR disclosures.

(9) How solid is the WG consensus behind this document? Does
    it represent the strong concurrence of a few individuals,
    with others being silent, or does the WG as a whole
    understand and agree with it?

L2SM is a small WG.
The consensus is solid but there are only a few voices to be
raised. There has been no objection.

(10) Has anyone threatened an appeal or otherwise indicated
    extreme discontent?

No.

(11) Identify any ID nits the Document Shepherd has found in
    this document.

There are no valid nits in revision -07

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type
    reviews.

None

(13) Have all references within this document been identified as
    either normative or informative?

Yes

(14) Are there normative references to documents that are not
    ready for advancement or are otherwise in an unclear state?
    If such normative references exist, what is the plan for
    their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
    If so, list these downward references to support the Area Director
    in the Last Call procedure.

RFC 4664
RFC 7348

(16) Will publication of this document change the status of any existing
    RFC?

No

(17) Describe the Document Shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of
    the document. Confirm that all protocol extensions that the document
    makes are associated with the appropriate reservations in IANA
    registries. Confirm that any referenced IANA registries have been
    clearly identified. Confirm that newly created IANA registries include
    a detailed specification of the initial contents for the registry,
    that allocations procedures for future registrations are defined,
    and a reasonable name for the new registry has been suggested (see
    RFC 5226).

IANA considerations are good.

(18) List any new IANA registries that require Expert Review for future
    allocations. Provide any public guidance that the IESG would find
    useful in selecting the IANA Experts for these new registries.

No new registries

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

YANG compilation checks have been performed.

2018-02-20
07 Adrian Farrel
Shepherd write-up : draft-ietf-l2sm-l2vpn-service-model

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)?
    …
Shepherd write-up : draft-ietf-l2sm-l2vpn-service-model

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)?
    Why is this the proper type of RFC? Is this type of RFC
    indicated in the title page header?

Standards Track
This is an implementable YANG model
This is correctly indicated on the title page.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up. Please provide such a Document Announcement Write-Up.

Technical Summary:

This document defines a YANG data model that can be used to configure
a Layer 2 Provider Provisioned VPN service.

This model is intended to be instantiated at management system to
deliver the overall service.  This model is not a configuration model
to be used directly on network elements, but provides an abstracted
view of the Layer 2 VPN service configuration components.  It is up
to a management system to take this as an input and generate specific
configurations models to configure the different network elements to
deliver the service.  How configuration of network elements is done
is out of scope of the document.

The data model in this document includes support for point-to-point
Virtual Private Wire Services (VPWS) and multipoint Virtual Private
LAN services (VPLS) that use Pseudowires signaled using the Label
Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as
described in RFC4761 and RFC6624.

Working Group Summary:

This has been a relatively quiet WG, but there has been useful and
technical discussion on the list. WG meetings have brought in a few
additional voices raising valuablee points. The WG has also held
virtual interim meetings to dig into the open technical issues.

Document Quality:

There is one known implementation in progress.
The document received a thorough review from Jan Lindblad as a YANG
expert. Jan was very familiar with the L3SM work and able to carry
this review across.

Personnel:

Adrian Farrel (adrian@olddog.co.uk) is the document shepherd
Benoit Claise (bclaise@cisco.com)is the Responsible AD

(3) Briefly describe the review of this document that was
    performed by the Document Shepherd. If this version of
    the document is not ready for publication, please
    explain why the document is being forwarded to the IESG.

This version of the document is ready for publication.
The document shepherd reviewed the previous version in detail
especially for English and clarity. The updates have significantly
improved the document.

(4) Does the document Shepherd have any concerns about the depth
    or breadth of the reviews that have been performed?

No concerns.
WG last call was echoes to BESS, PALS, RTGWG, and NETMOD

(5) Do portions of the document need review from a particular or
    from broader perspective, e.g., security, operational complexity,
    AAA, DNS, DHCP, XML, or internationalization? If so, describe the
    review that took place.

The big requirements were for YANG review and for input from operators
who offer L2VPN services. Jan satisfied the first. The author team
themselves satisfy the second.

(6) Describe any specific concerns or issues that the Document
    Shepherd has with this document that the Responsible Area
    Director and/or the IESG should be aware of? For example,
    perhaps he or she is uncomfortable with certain parts of
    the document, or has concerns whether there really is a
    need for it. In any event, if the WG has discussed those
    issues and has indicated that it still wishes to advance
    the document, detail those concerns here.

No concerns.
There ws debate (several times) about how this work rslates to
similar work being done by the MEF. This was discussed at WG
meetings and on the mailing list and the document shepherd is
comfortable that the work represents different approaches to
related topics rather than a competitive situation.

(7) Has each author confirmed that any and all appropriate
    IPR disclosures required for full conformance with the
    provisions of BCP 78 and BCP 79 have already been filed.
    If not, explain why?

All authors except Chongfeng Xie have so confirmed. The
Chinese New Year celebrations mean that he is away from his
desk, but we expect a confirmatin soon.

(8) Has an IPR disclosure been filed that references this
    document? If so, summarize any WG discussion and conclusion
    regarding the IPR disclosures.

No IPR disclosures.

(9) How solid is the WG consensus behind this document? Does
    it represent the strong concurrence of a few individuals,
    with others being silent, or does the WG as a whole
    understand and agree with it?

L2SM is a small WG.
The consensus is solid but there are only a few voices to be
raised. There has been no objection.

(10) Has anyone threatened an appeal or otherwise indicated
    extreme discontent?

No.

(11) Identify any ID nits the Document Shepherd has found in
    this document.

There are no valid nits in revision -07

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type
    reviews.

None

(13) Have all references within this document been identified as
    either normative or informative?

Yes

(14) Are there normative references to documents that are not
    ready for advancement or are otherwise in an unclear state?
    If such normative references exist, what is the plan for
    their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
    If so, list these downward references to support the Area Director
    in the Last Call procedure.

RFC 4664
RFC 7348

(16) Will publication of this document change the status of any existing
    RFC?

No

(17) Describe the Document Shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of
    the document. Confirm that all protocol extensions that the document
    makes are associated with the appropriate reservations in IANA
    registries. Confirm that any referenced IANA registries have been
    clearly identified. Confirm that newly created IANA registries include
    a detailed specification of the initial contents for the registry,
    that allocations procedures for future registrations are defined,
    and a reasonable name for the new registry has been suggested (see
    RFC 5226).

IANA considerations are good.

(18) List any new IANA registries that require Expert Review for future
    allocations. Provide any public guidance that the IESG would find
    useful in selecting the IANA Experts for these new registries.

No new registries

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

YANG compilation checks have been performed.

2018-02-20
07 Adrian Farrel Responsible AD changed to Benoit Claise
2018-02-20
07 Adrian Farrel IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2018-02-20
07 Adrian Farrel IESG state changed to Publication Requested
2018-02-20
07 Adrian Farrel IESG process started in state Publication Requested
2018-02-20
07 Adrian Farrel Changed document writeup
2018-02-20
07 Giuseppe Fioccola New version available: draft-ietf-l2sm-l2vpn-service-model-07.txt
2018-02-20
07 (System) New version approved
2018-02-20
07 (System) Request for posting confirmation emailed to previous authors: Luay Jalil , Chongfeng Xie , Giuseppe Fioccola , Bin Wen
2018-02-20
07 Giuseppe Fioccola Uploaded new revision
2018-02-19
06 Adrian Farrel Changed document writeup
2018-02-18
06 Adrian Farrel Changed document writeup
2018-02-13
06 Adrian Farrel IETF WG state changed to In WG Last Call from WG Document
2018-02-09
06 Giuseppe Fioccola New version available: draft-ietf-l2sm-l2vpn-service-model-06.txt
2018-02-09
06 (System) New version approved
2018-02-09
06 (System) Request for posting confirmation emailed to previous authors: Luay Jalil , Chongfeng Xie , Giuseppe Fioccola , Bin Wen
2018-02-09
06 Giuseppe Fioccola Uploaded new revision
2018-01-17
05 Mehmet Ersue Request for Early review by YANGDOCTORS is assigned to Ladislav Lhotka
2018-01-17
05 Mehmet Ersue Request for Early review by YANGDOCTORS is assigned to Ladislav Lhotka
2018-01-17
05 Adrian Farrel Notification list changed to Adrian Farrel <adrian@olddog.co.uk>
2018-01-17
05 Adrian Farrel Document shepherd changed to Adrian Farrel
2018-01-17
05 Adrian Farrel Requested Early review by YANGDOCTORS
2018-01-17
05 Adrian Farrel Changed consensus to Yes from Unknown
2018-01-17
05 Adrian Farrel Intended Status changed to Proposed Standard from None
2018-01-16
05 Giuseppe Fioccola New version available: draft-ietf-l2sm-l2vpn-service-model-05.txt
2018-01-16
05 (System) New version approved
2018-01-16
05 (System) Request for posting confirmation emailed to previous authors: Luay Jalil , Chongfeng Xie , Giuseppe Fioccola , Bin Wen
2018-01-16
05 Giuseppe Fioccola Uploaded new revision
2017-11-12
04 Adrian Farrel Added to session: IETF-100: l2sm  Thu-1810
2017-10-30
04 Giuseppe Fioccola New version available: draft-ietf-l2sm-l2vpn-service-model-04.txt
2017-10-30
04 (System) New version approved
2017-10-30
04 (System) Request for posting confirmation emailed to previous authors: Luay Jalil , Chongfeng Xie , Giuseppe Fioccola , Bin Wen
2017-10-30
04 Giuseppe Fioccola Uploaded new revision
2017-09-18
03 Giuseppe Fioccola New version available: draft-ietf-l2sm-l2vpn-service-model-03.txt
2017-09-18
03 (System) New version approved
2017-09-18
03 (System) Request for posting confirmation emailed to previous authors: Luay Jalil , Chongfeng Xie , Giuseppe Fioccola , Bin Wen
2017-09-18
03 Giuseppe Fioccola Uploaded new revision
2017-07-03
02 Giuseppe Fioccola New version available: draft-ietf-l2sm-l2vpn-service-model-02.txt
2017-07-03
02 (System) New version approved
2017-07-03
02 (System) Request for posting confirmation emailed to previous authors: Bin Wen , Chongfeng Xie , Giuseppe Fioccola , Luay Jalil
2017-07-03
02 Giuseppe Fioccola Uploaded new revision
2017-05-23
01 Giuseppe Fioccola New version available: draft-ietf-l2sm-l2vpn-service-model-01.txt
2017-05-23
01 (System) New version approved
2017-05-23
01 (System) Request for posting confirmation emailed to previous authors: Bin Wen , Chongfeng Xie , Giuseppe Fioccola , Luay Jalil
2017-05-23
01 Giuseppe Fioccola Uploaded new revision
2017-02-26
00 Adrian Farrel This document now replaces draft-wen-l2sm-l2vpn-service-model instead of None
2017-02-26
00 Adrian Farrel New version available: draft-ietf-l2sm-l2vpn-service-model-00.txt
2017-02-26
00 (System) New version approved
2017-02-26
00 Adrian Farrel Request for posting confirmation emailed  to submitter and authors: Adrian Farrel , Bin Wen , Chongfeng Xie , Giuseppe Fioccola , Luay Jalil
2017-02-26
00 Adrian Farrel Uploaded new revision