A YANG Network Data Model for Layer 3 VPNs
RFC 9182

Received changes through RFC Editor sync (created alias RFC 9182, changed title to 'A YANG Network Data Model for Layer 3 VPNs', changed abstract to 'As a complement to the Layer 3 Virtual Private Network Service Model (L3SM), which is used for communication between customers and service providers, this document defines an L3VPN Network Model (L3NM) that can be used for the provisioning of Layer 3 Virtual Private Network (L3VPN) services within a service provider network. The model provides a network-centric view of L3VPN services.

The L3NM is meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. The model can also facilitate communication between a service orchestrator and a network controller/orchestrator.', changed pages to 129, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2022-02-15, changed IESG state to RFC Published)

[Ballot discuss]
Thank you for the work on this document, and apologies for the delayed review. I have one DISCUSS point, a couple of comments.

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion; I really think that the document would be improved with a change here, but can be convinced otherwise.

I have divided comments into "minor" (including the questions) and "nits". Neither require replies strictly speaking, please feel free to address as you see fit. I will appreciate answers to my questions, to improve my understanding. If any clarification comes out of it, I hope it will help improve the document.

Francesca

1. -----

                      leaf holdtime {
                        type uint32;
                        units "msec";

FP: This might be me not finding the right reference (or little knowledge of YANG), but I was wondering if "msec" was defined somewhere as a unit (note that the description does not mention that the unit is milliseconds either).

While doing my due diligence to see if I missed or misunderstood something, I researched the RFCs mentioned in the beginning of the YANG module:

  This module uses types defined in [RFC6991] and [RFC8343].  It also
  uses groupings defined in [RFC8519], [RFC8177], and [RFC8294].

And found no use of the "msec" unit. A quick google search shows that RFC 8299 uses it, so there is precedence for it, but I couldn't find its definition from that document either. All the other leaves use "milliseconds" (which is defined in RFC 8294), so my preference would be to have consistency, if "msec" was defined and I just missed it.

(Note that a similar remark could be made for "bps" used, which does not appear in the description text, and is also used in RFC 8466, however there is no issue about consistency there).

[Ballot comment]
## Minor

2. -----

  'status':  Indicates the status of the OSPF routing instance.

FP: Most likely a copy-paste leftover in section 7.6.3.4 should be IS-IS instead of OSPF.

3. -----

Section 7.6.3.5, re timers

FP: shouldn't the units be explicitly stated in the timers description text, or are they defined somewhere else? Actually, I can see the unit is specified later on in the YANG module - so my suggestion is to add some simple text in 7.6.3.5 to explicitly say that the timers are in seconds.

4. -----

                      leaf required-min-rx-interval {

FP: I see that RFC 5880 does not specify a default value for this; is there really no default that can be specified here?

## Nits

5. -----

                            "It is included only when enryption
                              is enabled.";
                        }

FP: typo s/enryption/encryption

[Ballot comment]
Thank you to Rifaat Shekh-Yusef for the SECDIR review.

Thank you for addressing my DISCUSS feedback.

==

** Section 9.  The text enumerating sensitive read operations provides no caution about protecting the various key material.  RFC8177 is cited later, but as noted in the DISCUSS, the suggested key wrap primitive is not usable with instances of “key” as the hex-key-string feature is not supported.

[Ballot comment]
Thanks for the many updates in the -12 through -14.
Just one final comment on the new changes:

Section 7.6.3

  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].

This paragraph appears both at the end of 7.6.3 and at the start of
7.6.3.1; presumably only the latter is needed.

[Ballot discuss]
(3) the ipsec authentication option for the various routing protocols
uses a string to identify an (IKE, unspecified version thereof) SA.  RFC
7296 doesn't have the concept of a name for an IKE SA itself, so I think
we need to provide more details on what is being named and what the
naming authority is.  IKE does have identities for the peers, if the
goal is to refer to the peer's identity for the SA.
[I'd like to see clarified that these human-readable names are administrator-assigned]

[Ballot comment]
Thanks for the many updates in the -12 and -13.
A couple things left to comment on; some on the new changes, and
some just retaining former discuss points that I demoted into non-blocking comments.

(former DISCUSS) 2) In a similar vein as Roman's Discuss (and perhaps obviated by it?), if
we're going to allow raw keys to be specified, as a string type, we
should be very clear about whether the string is hex-encoded,
base64-encoded, etc., in light of deployed experience with devices that
take the string and use it as the raw key (thereby eliminating a good
chunk of the key space from potential use).
[In the email thread I suggested some additional text that might help, for this topic.]

Section 7.6.3

  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].

This paragraph appears both at the end of 7.6.3 and at the start of
7.6.3.1; presumably only the latter is needed.

[Ballot comment]
I originally balloted Abstain, but after discussions and explanations from Rob I'm moving to No Objection.

I agree with Alvaro that there are inconsistencies that make deriving the mapping between the model and implementations tricky. However, I don't really think that that is the "fault" of this document, but rather is an artifact of the fact that there are so many different "types" of VPNs, and every standard/implementation/vendor has their own special knobs and features. This makes creating a generic model largely impossible - it either needs to be so restrictive that it is basically pointless, or so comprehensive that it is unwieldily.
I think that this document did a good job of trying to thread this needle (and I thank/congratulate the authors), but I still think that it is not really usable.
I also support Erik's discuss on Sec 7.6.2 -- this is also (I think) an artifact of trying to cover both too much and too little.

[Ballot discuss]
(1) I think there may be some ambiguity we need to resolve, relating to
per-AF router IDs and other per-AF lists:

                  list router-id {
                    key "address-family";
                    description
                      "Router-id per address family.";
                    leaf address-family {
                      type identityref {
                        base vpn-common:address-family;
                      }
                      description
                        "Indicates the address family for which the
                          Router-ID applies.";

What actually gets used as the router-id for a given address family if
both "dual-stack" and that address family are present in this list?

There's some similar potential for amiguity in the
"redistribute-connected" list for BGP routing, that is also keyed on an
address-family identityref.

(2) In a similar vein as Roman's Discuss (and perhaps obviated by it?), if
we're going to allow raw keys to be specified, as a string type, we
should be very clear about whether the string is hex-encoded,
base64-encoded, etc., in light of deployed experience with devices that
take the string and use it as the raw key (thereby eliminating a good
chunk of the key space from potential use).

(2.5) For raw keys, should we be using nacm:default-deny-all?

(3) the ipsec authentication option for the various routing protocols
uses a string to identify an (IKE, unspecified version thereof) SA.  RFC
7296 doesn't have the concept of a name for an IKE SA itself, so I think
we need to provide more details on what is being named and what the
naming authority is.  IKE does have identities for the peers, if the
goal is to refer to the peer's identity for the SA.

(4) I'd also like to have a discussion about the NTP configuration
options; in particular, we currently have an enumeration to select
between broadcast client and broadcast server, with no option apparent
for symmetric or other NTP modes.  Given the rigidity of YANG
enumerations, I'd like to confirm that no other NTP modes could be
appropriate on the network access before we lock in to this model.

[Ballot comment]
I expect there's a large degree of personal preference involved, but I
find it easier to read the document when the tree (fragment) precedes
the per-field descriptions; this document has many instances of the
other order (as well as some instances of my preferred order).

Section 1

  The L3NM focuses on BGP Provider Edge (PE) based Layer 3 VPNs as
  described in [RFC4026][RFC4110][RFC4364] and Multicast VPNs as
  described in [RFC6037][RFC6513].

RFC 6037 is Historic; is it nonetheless still a worthwhile reference?

Section 7.6.1

  tunnel selection.  The container can also identify the pseudowire
  (Section 5.2 of [RFC4447]).

RFC 4447 is showing up as obsolete, obsoleted by RFC RFC 8077.

Section 7.6.2

Is the indentation of the tree diagram correct between
"(allocation-type)?" and ":(dhcp-relay)"?  I think that dhcp-relay
should be at the same level as provider-dhcp -- maybe the implicit
'case' around "container provider-dhcp" is confusing the tooling?

Section 7.6.3

        When the IPv4 or dual-stack address-family is requested, it is
        up to the implementation to decide whether OSPFv2 [RFC4577] or

Which implementation?  The service orchestrator's?  (The phrase "up to
the implementation" appears at least one other place, as well.)

    'authentication':  Controls the authentication schemes to be
        enabled for the OSPF instance.  The following options are
        supported: IPsec for OSPFv3 authentication [RFC4552],
        authentication trailer for OSPFv2 [RFC5709] [RFC7474] and
        OSPFv3 [RFC7166].
    [...]
        |    |  +--rw authentication
        |    |  |  +--rw enable?            boolean
        |    |  |  +--rw keying-material
        |    |  |    +--rw (option)?
        |    |  |        +--:(md5)
        |    |  |        |  +--rw md5-keychain?
        |    |  |        |          kc:key-chain-ref
        |    |  |        +--:(ipsec)
        |    |  |          +--rw sa?  string

I don't think "md5" is the right identifier for the node holding the OSPF
authentication-trailer keying material.

Section 7.6.6

Interjecting some (sub-?)sub-subtrees and their fields before completing the
list of nodes in the "toplevel" subtree makes the narrative somewhat
hard to follow.

Section 7.7

  The model supports a single type of tree: Any-Source Multicast (ASM),
  Source-Specific Multicast (SSM), or bidirectional.

It's surprising (to me) to see that the YANG is not a choice, then,
which would be an intuitive fit for "choose exactly one type".
(nit) maybe say single type of tree per VPN instance?

  When a particular VPN using ASM requires a more optimal traffic
  delivery, 'optimal-traffic-delivery' can be set.  When set to 'true',

"optimal traffic delivery" sounds like something that every customer is
going to want ... if that's what it does, why is it even an option? ;)

Section 8

Comments at the end of blocks for what container/etc. is being closed
might help readability.

    typedef area-address {
      type string {
        pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}';

I guess this is related to Alvaro's Abstain, but it is very surprising
that there is not some preexisting definition of IS-IS area-address that
we can import and use.

              leaf ne-id {
                type string;
                description
                  "Unique identifier of the network element where the VPN
                    node is deployed.";

When I first saw this I wondered if a union with leafref could be
useful, for cases where there were nodes already identified in a
different data model.  Since this service model operates at a layer
that's rather removed from specific devices, though, it's not really
clear how often such a case would come up in practice.

                  leaf interface-id {
                    type string;
                    description
                      "Identifier for the physical or logical
                        interface.
                        The identification of the sub-interface
                        is provided at the connection and/or IP
                        connection levels.";

(similarly here)

                      container dot1q {
                        when "derived-from-or-self(../type, "
                            + "'vpn-common:dot1q')" {
                          description
                            "Only applies when the type of the
                              tagged interface is 'dot1q'.";
                        }
                        if-feature "vpn-common:dot1q";

The identity itself is conditional on the vpn-common:dot1q feature, so
it's not entirely clear to me if there's value in repeating the
if-feature stanza here.
Likewise for qinq.
(A similar scenario arises for the specific routing-protocols, I think.)

                        leaf type {
                          type identityref {
                            base l2-tunnel-type;
                          }
                          description
                            "Selects the tunnel termiantion option for
                              each vpn-network-access.";
                        }
                        container pseudowire {
                          description
                            "Includes pseudowire termination parameters.";

Why no "when" stanzas for the pseudowire/vpls/vxlan containers, so they
only appear for the relevant tunnel type?

                          choice service-type {
                            description
                              "Choice based on the DHCPv6 service type.";
                            case provider-dhcp-servers {
                              leaf-list server-ip-address {
                                type inet:ipv6-address;
                                description
                                  "IPv6 addresses of the provider's
                                    DHCPv6 server.";
                              }
                            }
                            case server {

I don't think I understand what the distinction is supposed to be
between "provider-dhcp-servers" and just "server".  It seems like the
"server" case is still describing a scenario with provider-run DHCP
servers.  There doesn't seem to be much discussion in §7.6.2 around
Figure 12 to help, either.

                        container bgp-timers {
                          description
                            "Includes two BGP timers that can be
                              customized when building a VPN service
                              with BGP used as CE-PE routing
                              protocol.";
                          leaf keepalive {
                            type uint16 {
                              range "0..21845";

Why is the maximum of 0x5555 hardcoded?  RFC 4271 says that "a
reasonable maximum time between KEEPALIVE messages would be one third of
the Hold Time interval", but that seems like general guidance and not a
protocol invariant.

                        leaf ping-reply {
                          type boolean;
                          description
                            "Controls whether the VRRP speaker should
                              answer to ping requests.";

What's the default behavior?

                    container ntp {

It would be great if we could work in an NTS reference somewhere (RFC
8915).

                      leaf remote-source {
                        type boolean;
                        default "false";
                        description
                          "When true, there is no PIM adjacency on
                            the interface.";
                      }

I think some more description would be very helpful here.  E.g., RFC
7761 does not mention "remote" or "adjacency", so it's hard to figure
out where to start reading to understand this configuration.

Section 9

Thank you for calling out the privacy considerations relating to
customer names and IP addresses!

I am happy to see that you already answered Roman's question about the
sensitivity to write operations of vpn-profiles; thanks for that as
well.

Thanks as well for adding the note about MD5 security in response to the
last-call feedback.

I expect that there are some ways in which knowing the internal
configuration of the VPN service would make attacking it easier (knowing
what DHCP addresses to squat on, internal addresses to target with DoS
attack, etc.), but don't see any fundamental or critical aspects that
need to be called out specifically.

Should we mention that the keychain functionality uses NACM to deny
access to the keys, or is that considered "well known" at this point?

Section 11+

Regrettably, I ran out of time when reviewing this document.  So I
didn't really look at the examples or the classification of the
references.

NITS

Section 2

  VPN node:  An abstraction that represents a set of policies applied
      on a PE and that belong to a single VPN service.  A VPN service
      involves one or more VPN nodes.  As it is an abstraction, the
      network controller will take on how to implement a VPN node.  For
      example, typically, in a BGP-based VPN, a VPN node could be mapped
      into a Virtual Routing and Forwarding (VRF).

I don't recall seeing "VRF" used in this manner before; I feel like I
ususally see "instance" or some other word after it.

Section 4

  L3VPN service.  For example, the customer may supply an IP
  Connectivity Provisioning Profile (CPP) [RFC7297], an enhanced VPN
  (VPN+) service [I-D.ietf-teas-enhanced-vpn], or an IETF network slice
  service [I-D.ietf-teas-ietf-network-slices].

I'm having a hard time finding a parallel structure in "customer may
supply [a profile], [a service], or [a service]".  Are the latter two
items intending to refer to a description or instance of the service in
question?

  Note also that both the L3SM and the L3NM may be used in the context
  of the Abstraction and Control of TE Networks (ACTN) [RFC8453].

I would expect to see the word "Framework" after ACTN.

Section 7.2

  each VPN service provider.  The model only includes an identifier to
  these profiles in order to ease identifying and binding local

The RFC Editor will no doubt have suggestions here as well, but I think
"ease identification and binding of" or "facilitate identifying and
binding" would flow better here.

Section 7.6

  'vpn-instance-profile':  Provides a pointer to an active VPN instance
      profile at the VPN node level.  Referencing an active VPN instance
      profile implies that all associated data nodes will be inherited
      by the VPN network access.  However, some inherited data nodes
      (e.g., multicast) can be refined at the VPN network access level.
      In such case, refined values take precedence over inherited ones.

IIUC this is not the YANG "refine" directive, so maybe a different word
like "overridden" at the VPN network access level, and "local values
take precedence over inherited ones", is better?

Section 7.6.3

    'max-prefix':  Indicates the maximum number of BGP prefixes
        allowed in the BGP session.  If the limit is reached, the
        action indicated in 'action-violate' will be followed.

s/action-violate/violate-action/ to match the actual model

Section 8

    identity discard {
      base local-defined-next-hop;
      description
        "Indicates an action to discard traffic for the
          corresponding destination.
          For example, this can be used to blackhole traffic.";

I expect that the RFC Editor is going to flag "blackhole" and ask if you
really want to use it, on the inclusive-terminology front.

    grouping vpn-instance-profile {
      description
        "Grouping for data nodes that may be factorized
          among many levels of the model. The grouping can
          be used to define generic profiles at the VPN service
          level and then called at the VPN node and VPN network
          access levels.";

I'm not sure whether "called" is a conventional word for this behavior;
would "referenced" be accurate?

                      leaf type {
                        type identityref {
                          base vpn-common:encapsulation-type;
                        }
                        default "vpn-common:priority-tagged";
                        description
                          "Tagged interface type. By default, the type of
                            the tagged interface is 'priority-tagged'.";

Given that there's a "vpn-common:untagged-int" identity that is usable
here, is "Tagged interface type" really 100% accurate?

                          "Defines a layer 2 tunnel termination.
                            It is only applicable when a tunnel is
                            required. The supported values are:
                            pseudowire, VPLS and, VXLAN. Other
                            values may defined, if needed.";

"may be defined"

                        leaf prepend-global-as {
                          type boolean;
                          default "false";
                          description
                            "In some situations, the ASN that is
                              provided at the VPN node level may be
                              distinct from the one configured at the
                              VPN network access level. When such
                              ASNs are provided, they are both
                              prepended to the BGP route updates
                              for this access. To disable that
                              behavior, the prepend-global-as
                              must be set to 'false'.  [...]

It's surprising to see "when such ASNs are provided, they are both
prepended [...] to disable that behavior" when the default is "false".

                            enum active {
                              description
                                "Interface sends or receives IS-IS
                                  protocol control packets.";

Maybe s/or/and/?

                    }
                    container encryption-profile {
                      when "../encryption/enabled = 'true'" {
                        description
                          "Indicates the layer on which encryption
                            is enabled.";

This description stanza is for the "when" directive, and doesn't seem
appropriate for that action.

                        }
                        leaf max-entries {
                          type uint32;
                          description
                            "Indicates the maximum MLD entries.";

"maximum number of"

> (1) What type of RFC is being requested
>    Why is this the proper type of RFC?
>    Is this type of RFC indicated in the title page header?

This draft is requested for publication as a Proposed Standard.
This is appropriate for a YANG model that will be implemented and must
interoperate.
The status is properly indicated on the title page.

> (2) The IESG approval announcement includes a Document Announcement
>    Write-Up.
>
> Technical Summary:

This document defines an L3VPN Network YANG Model (L3NM) that can be
used for the provisioning of Layer 3 Virtual Private Network (VPN)
services within a service provider network.  The model provides a
network-centric view of L3VPN services.

L3NM is meant to be used by a network controller to derive the
configuration information that will be sent to relevant network
devices.  The model can also facilitate the communication between a
service orchestrator and a network controller/orchestrator.

> Working Group Summary:

There was no controversy.

This model was driven by implementers seeking to use the L3SM [RFC8309]
to provide L3VPN services using orchestrator and controller software.
They determined that an intermediary network-centric (rather than
service-centric) model was required, and they quickly built support
with other implementers.

During the later stages of work on this document, it was determined that
there was commonality between this model and a model for L2VPN.  The
common parts were pulled out into a separate model presented in another
document.

> Document Quality:

This document notes four implementations: Nokia, Huawei, Infinera,
Ribbon-ECI.

The document shepherd is aware of one other commercial implementation
and one prototype implementation.

> Personnel:

Adrian Farrel (adrian@olddog.co.uk) is the Document Shepherd
Rob Wilton (rwilton@cisco.com) iss the Responsible Area Director

> (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.

I reviewed this draft in detail during WG last call and all of the
issues I raised have been addressed. I have done a quick review of the
most recent version mainly focused on the changes. This version is
ready for publication.

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

No concerns. Indeed, the number of implementers participating has
resulted in a deep and broad review.

> (5) Do portions of the document need review from a particular or from
>    broader perspective? If so, describe the review that took place.

This document contains a YANG model and so review by YANG specialists
is in order.

An early YANG Doctor review was conducted on -03 by Radek Krejci and
the issues raised were fixed.

A subsequent YANG Doctor review on -07 at WG last call was also done by
Radek Krejci. It found only one simple nit, and this has been fixed in
the current version.

> (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?

No issues.

> (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.

All authors and contributors have so confirmed.

IPR protestations can be found on the thread https://mailarchive.ietf.org/arch/msg/opsawg/ajoTnvgF5YuYtnUk1Li5BdnBJxQ/

This records no known IPR from the full set of:
  Authors: Oscar Gonzalez de Dios, Mohamed Boucadair, Samier Barguil Giraldo, Qin Wu, Alejandro Aguado
  Contributors: Victor Lopez, Erez Segev

One Contributor (Luis Angel Munoz) notes no IPR on the thread https://mailarchive.ietf.org/arch/msg/opsawg/3U-FxleAm739Zx4gMAHw3eWLIdw/

The final Contributor (Lucia Oliva) reports no IPR on the thread https://mailarchive.ietf.org/arch/msg/opsawg/x-oi9vLlEWgUpP_yu827SJ7CWPs/

> (8) Has an IPR disclosure been filed that references this document?

No IPR disclosed.

> (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?

OPSAWG is an odd WG in that it has several different communities of
interest that rarely cross-review work. As a result, judging broad
consensus in the WG is a challenge.

Nevertheless, the enthusiastic participation by a long list of authors
and contributors, the frequent open design team tele-meetings, and the
additional reviews from five people during last call with no major
objections, suggest good consensus.

While the design teams were well-attended, they left some visibility
holes concerning the work and failed to report back to the broader WG.
This has been corrected with regular readouts on the mailing list, as
well as requests to the mailing list for input on decisions.

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

No discontent voiced.

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

idnits is clean. The warnings have been checked and found to be benign.

> (12) Describe how the document meets any required formal review
>      criteria.

See (5) for YANG Doctor reviews.
YANG validation (in the datatracker) shows 0 errors, 0 warnings

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

Yes. Both normative and informative references are present.

> (14) Are there normative references to documents that are not ready
>      for advancement or are otherwise in an unclear state?

One normative reference is to draft-ietf-opsawg-vpn-common. This is a
partner document that is moving forward at the same time. It is ready
for advancement.

All other normative references are to RFCs.

> (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.

No downrefs.

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

No status changes.

> (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 8126).

The IANA section is simple.
It requests assignments from two clearly identified registries in
accordance with the allocation procedures for those registries.
No new registries are created.

> (18) List any new IANA registries that require Expert Review for
>      future allocations.

None.

> (19) Describe reviews and automated checks performed by the Document
>      Shepherd to validate sections of the document written in a formal
>      language.

The datatracker YANG validation is clean. See (12) and (20)

> (20) If the document contains a YANG module, has the module been
>      checked with any of the recommended validation tools
>      (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for
>      syntax and formatting validation?
>      Does the YANG module comply with the Network Management Datastore
>      Architecture (NMDA) as specified in RFC8342?

The YANG validation results are clean.
To the best of my knowledge, the model complies with the NMDA.

[Ballot comment]
I am abstaining for similar reasons to Alvaro -- there are inconsistencies that make deriving the mapping between the model and implementations tricky. However, I don't really think that that is the "fault" of this document, but rather is an artifact of the fact that there are so many different "types" of VPNs, and every standard/implementation/vendor has their own special knobs and features. This makes creating a generic model largely impossible - it either needs to be so restrictive that it is basically pointless, or so comprehensive that it is unwieldily.
I think that this document did a good job of trying to thread this needle (and I thank/congratulate the authors), but I still think that it is not really usable.
I also support Erik's discuss on Sec 7.6.2 -- this is also (I think) an artifact of trying to cover both too much and too little.

[Ballot discuss]
[general]

* I'm sure there are plenty things I'm not understanding, and probably
  these things are easy to address.  But in general I feel like there
  could be some tension between needing to specify/model the L3
  attributes that are used to provision both the endpoint and the
  clients with a possibly somewhat cleaner separation for holding client
  IP provisioning info.  At what point, for example, should there be
  something like a separate "client-ip-provisioning-profile" string
  that is referenced?  I think some of the richness of what can be
  expressed in IPv6 RAs may be bringing these ideas up, some of which
  can be expressed in DHCP as well but operationally may be less common.
  The contents of RIOs in particular seem like a bit of client
  provisioning information that an endpoint might need to be aware
  of as well.

[S7.6.2]

* Provisioning IPv6 clients can be more rich than the DHCPv6/SLAAC
  model noted here (and much more so than IPv4/DHCPv4).

  Since you document how local-address/prefix-length becomes a PIO,
  should there be other related IP connectivity provisioning information
  in here, like:

      * more than just one PIO? (is this just repeated
        ip-connection/ipv6 entries, one for each on-link prefix?)
      * one or more RIOs that might need to be advertised to clients?
      * others (PVDIO, ...)?

  If this is "out of scope" for this document, where does it belong
  in the overall provisioning of an L3VPN service (out of curiosity,
  given that this document kinda models DHCP IP allocation ranges)?

[S8]

* Under provider DHCPv6 servers, the server definition has an
  "address-assign" choice of "number" with a
  "number-of-dynamic-address" (defaulting to "1"), but the description
  talks about the number of allocated prefixes.  Should this value be
  "number-of-dynamic-prefixes" instead?

* Which of these elements describes whether or not DHCPv6 PD
  (Prefix Delegation) is enabled, and the prefix pools used?

[Ballot comment]
[S7.2, nit]

* "refers to as set of policies" ->
  "refers to a set of policies"

[S7.3, nit]

* "a P node or event a dedicated node" ->
  "a P node or even a dedicated node"

[S7.4, nit]

* "Indicates the maximum prefixes" ->
  "Indicates the maximum number of prefixes", perhaps?

[S7.6.1, nit]

* "is the layer two connections" ->
  "is the layer two connection"

  (although this sentence may be redundant with the one two sentences
  prior)

[S7.6.6, nit]

* "carrierscarrier" -> "carriers-carrier"

[Ballot comment]
I understand that L3NM is not a device model and that, as such, it is not intended to include every possible parameter. 

However, not leveraging existing work has resulted in inconsistencies: from using different names to changing implementation expectations.  I believe that this result impacts the implementation-specific work needed to derive device-specific actions (using existing models) and potentially reduces the value of using this network model.

Many WGs in the routing area work on related technology, including bess, idr, lsr, pim, bfd, rtgwg, and teas. However, I found no evidence in the archives that any of these WGs were consulted or asked to review this work.

Both points (lack of reuse and lack of review) have been mentioned in the mailing list, so I assume they have been considered.  This fact and the existence of multiple implementations lead me to ABSTAIN.

[Ballot discuss]
This specification refers to ietf-opsawg-vpn-common for qos related matching, hence I am raising similar discussion as I had for ietf-opsawg-vpn-common (see here https://datatracker.ietf.org/doc/draft-ietf-opsawg-vpn-common/).

This specification specifies qos classification based on L4 criteria and describes the procedure for TCP and UDP. It is possible that new L4 protocols (for example QUIC) use UDP as substrate hence can create ambiguity based of the procedure described in the specification.

This specification should consider such potential substrate usage of L4 protocols (specially UDP) and hint on the potential augmentations (there might be several ways to do that) or scope it down to not support such cases.

[Ballot comment]
Thanks to the authors for their efforts in the specification.

Additional comment(s)-

* I think if would be good if this specification also discusses the implication of wrong classification (e.g. for qos) based on the model specified here (no particular suggestion from me where but may be in security considerations).

[Ballot comment]
It would be useful to summarize this document's relationship to RFC8299 in the abstract.

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 7.6.3. , paragraph 43, nit:
> icates which BFD flavor is used to setup the session (e.g., classic BFD [RFC
>                                    ^^^^^
The verb "set up" is spelled as two words. The noun "setup" is spelled as one.

Section 7.7. , paragraph 1, nit:
> y applicable if both RP redundancy and and delivery through optimal path are
>                                    ^^^^^^^
Possible typo: you repeated a word.

Section 8. , paragraph 8, nit:
>  VPLS and, VXLAN. Other values may defined, if needed."; leaf type { type ide
>                                    ^^^^^^^
The modal verb "may" requires the verb's base form.

Section 8. , paragraph 32, nit:
> cription "Reference to the TCP-AO key chain."; reference "RFC 8177: YANG Key
>                                  ^^^^^^^^^
This word is normally spelled as one.

Section 8. , paragraph 32, nit:
> description "Reference to the MD5 key chain."; reference "RFC 8177: YANG Key
>                                  ^^^^^^^^^
This word is normally spelled as one.

Section 8. , paragraph 32, nit:
> f; description "Customer-supplied key chain."; } } } } } container service {
>                                  ^^^^^^^^^
This word is normally spelled as one.

Section 8. , paragraph 32, nit:
> cast static source/group associated to to IGMP session"; leaf group-addr { ty
>                                    ^^^^^
Possible typo: you repeated a word.

Document references draft-ietf-opsawg-vpn-common-09, but -10 is the latest
available revision.

Obsolete reference to RFC4447, obsoleted by RFC8077 (this may be on purpose).

These URLs point to tools.ietf.org, which is being deprecated:
* http://tools.ietf.org/wg/opsawg/

[Ballot comment]
Thank you to Rifaat Shekh-Yusef for the SECDIR review.

To the authors: the explanatory text in Sections 4 and 7 made this large YANG model very accessible.  It's sometimes hard to find the right balance between the text narrative and letting the model speak for itself, but this document negotiated it well.

** Section 7.6.5.  Could we ever end up in a situation where security/enabled=True but the key-chain-ref pointed a key-chain who’s crypto-algorithm was cleartext?

** Section 9.  In addition to sensitivity of customer-name and ip-connection to read operation, wouldn’t the corresponding topology information revealed by pretty much everything in vpn-service also be of concern?

** Section 9.  The text enumerating sensitive read operations provides no caution about protecting the various key material.  RFC8177 is cited later, but as noted in the DISCUSS, the suggested key wrap primitive is not usable with instances of “key” as the hex-key-string feature is not supported. 

** Typos:

Section 7.5.  Typo. s/rendez-vous/rendezvous/

YANG.  A few places. s/adresss/addresses/

YANG.  Typo. s/oubtound/outbound/

[Ballot discuss]
** RFC8177 already defines a container to represent an individual key -- key-string – as both a string and hex format. Additionally, this representation has built in ACLs to protect it.  This model appears to maximize flexibility by supporting both key-chains and an explicit key for protocols like BGP, RIP and ISIS.  Is there a reason why this model does not (or perhaps cannot) reuse the key-string representation from RFC8177 (the same way key-chain is)? And/or to not provide the flexibility for a hex encoded key?

** Section 9.  The text notes that ‘vpn-service’ is sensitive to write operations.  Wouldn’t ‘vpn-profiles’ be equally sensitive to alterations with similar consequences?  For example, altering an encryption-profile-identifier could change the algorithm chosen or the key.

[Ballot comment]
Thank you to Rifaat Shekh-Yusef for the SECDIR review.

To the authors: the explanatory text in Sections 4 and 7 made this large YANG model accessible and understandable.  It's sometimes hard to find the right balance between the text narrative and letting the model speak for itself, but this document negotiated it well.

** Section 7.6.5.  Could we ever end up in a situation where security/enabled=True but the key-chain-ref pointed a key-chain who’s crypto-algorithm was cleartext?

** Section 9.  In addition to sensitivity of customer-name and ip-connection to read operation, wouldn’t the corresponding topology information revealed by pretty much everything in vpn-service also be of concern?

** Section 9.  The text enumerating sensitive read operations provides no caution about protecting the various key material.  RFC8177 is cited later, but as noted in the DISCUSS, the suggested key wrap primitive is not usable with instances of “key” as the hex-key-string feature is not supported. 

** Typos:

Section 7.5.  Typo. s/rendez-vous/rendezvous/

YANG.  A few places. s/adresss/addresses/

YANG.  Typo. s/oubtound/outbound/

[Ballot discuss]
(7.6.3) Is there a reason the TCP-AO model in this draft is different from the one in draft-ietf-idr-bgp-model-11? That draft is using a model developed in the TCPM WG (draft-ietf-tcpm-yang-tcp) specifically for that purpose.

If there is no compelling requirement for something different, or the TCPM modelling work can be stretched to cover this use case as well, it would be far better than rolling a totally separate TCP YANG model here.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-opsawg-l3sm-l3nm-10. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a new namespace will be registered as follows:

ID: yang:ietf-l3vpn-ntw
URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request.  This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

a new YANG module will be registered as follows:

Name: ietf-l3vpn-ntw
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw
Prefix: l3nm
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

The IANA Services Operator understands that these are the only actions required to be completed upon approval of 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,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-08-06):

From: The IESG
To: IETF-Announce
CC: adrian@olddog.co.uk, draft-ietf-opsawg-l3sm-l3nm@ietf.org, opsawg-chairs@ietf.org, opsawg@ietf.org, rwilton@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (A Layer 3 VPN Network YANG Model) to Proposed Standard


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'A Layer 3
VPN Network YANG Model'
  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
last-call@ietf.org mailing lists by 2021-08-06. 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 an L3VPN Network YANG Model (L3NM) that can be
  used for the provisioning of Layer 3 Virtual Private Network (VPN)
  services within a service provider network.  The model provides a
  network-centric view of L3VPN services.

  L3NM is meant to be used by a network controller to derive the
  configuration information that will be sent to relevant network
  devices.  The model can also facilitate the communication between a
  service orchestrator and a network controller/orchestrator.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-l3sm-l3nm/



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

> (1) What type of RFC is being requested
>    Why is this the proper type of RFC?
>    Is this type of RFC indicated in the title page header?

This draft is requested for publication as a Draft Standard.
This is appropriate for a YANG model that will be implemented and must
interoperate.
The status is properly indicated on the title page.

> (2) The IESG approval announcement includes a Document Announcement
>    Write-Up.
>
> Technical Summary:

This document defines an L3VPN Network YANG Model (L3NM) that can be
used for the provisioning of Layer 3 Virtual Private Network (VPN)
services within a service provider network.  The model provides a
network-centric view of L3VPN services.

L3NM is meant to be used by a network controller to derive the
configuration information that will be sent to relevant network
devices.  The model can also facilitate the communication between a
service orchestrator and a network controller/orchestrator.

> Working Group Summary:

There was no controversy.

This model was driven by implementers seeking to use the L3SM [RFC8309]
to provide L3VPN services using orchestrator and controller software.
They determined that an intermediary network-centric (rather than
service-centric) model was required, and they quickly built support
with other implementers.

During the later stages of work on this document, it was determined that
there was commonality between this model and a model for L2VPN.  The
common parts were pulled out into a separate model presented in another
document.

> Document Quality:

This document notes four implementations: Nokia, Huawei, Infinera,
Ribbon-ECI.

The document shepherd is aware of one other commercial implementation
and one prototype implementation.

> Personnel:

Adrian Farrel (adrian@olddog.co.uk) is the Document Shepherd
Rob Wilton (rwilton@cisco.com) iss the Responsible Area Director

> (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.

I reviewed this draft in detail during WG last call and all of the
issues I raised have been addressed. I have done a quick review of the
most recent version mainly focused on the changes. This version is
ready for publication.

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

No concerns. Indeed, the number of implementers participating has
resulted in a deep and broad review.

> (5) Do portions of the document need review from a particular or from
>    broader perspective? If so, describe the review that took place.

This document contains a YANG model and so review by YANG specialists
is in order.

An early YANG Doctor review was conducted on -03 by Radek Krejci and
the issues raised were fixed.

A subsequent YANG Doctor review on -07 at WG last call was also done by
Radek Krejci. It found only one simple nit, and this has been fixed in
the current version.

> (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?

No issues.

> (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.

All authors and contributors have so confirmed.

IPR protestations can be found on the thread https://mailarchive.ietf.org/arch/msg/opsawg/ajoTnvgF5YuYtnUk1Li5BdnBJxQ/

This records no known IPR from the full set of:
  Authors: Oscar Gonzalez de Dios, Mohamed Boucadair, Samier Barguil Giraldo, Qin Wu, Alejandro Aguado
  Contributors: Victor Lopez, Erez Segev

One Contributor (Luis Angel Munoz) notes no IPR on the thread https://mailarchive.ietf.org/arch/msg/opsawg/3U-FxleAm739Zx4gMAHw3eWLIdw/

The final Contributor (Lucia Oliva) reports no IPR on the thread https://mailarchive.ietf.org/arch/msg/opsawg/x-oi9vLlEWgUpP_yu827SJ7CWPs/

> (8) Has an IPR disclosure been filed that references this document?

No IPR disclosed.

> (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?

OPSAWG is an odd WG in that it has several different communities of
interest that rarely cross-review work. As a result, judging broad
consensus in the WG is a challenge.

Nevertheless, the enthusiastic participation by a long list of authors
and contributors, the frequent open design team tele-meetings, and the
additional reviews from five people during last call with no major
objections, suggest good consensus.

While the design teams were well-attended, they left some visibility
holes concerning the work and failed to report back to the broader WG.
This has been corrected with regular readouts on the mailing list, as
well as requests to the mailing list for input on decisions.

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

No discontent voiced.

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

idnits is clean. The warnings have been checked and found to be benign.

> (12) Describe how the document meets any required formal review
>      criteria.

See (5) for YANG Doctor reviews.
YANG validation (in the datatracker) shows 0 errors, 0 warnings

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

Yes. Both normative and informative references are present.

> (14) Are there normative references to documents that are not ready
>      for advancement or are otherwise in an unclear state?

One normative reference is to draft-ietf-opsawg-vpn-common. This is a
partner document that is moving forward at the same time. It is ready
for advancement.

All other normative references are to RFCs.

> (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.

No downrefs.

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

No status changes.

> (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 8126).

The IANA section is simple.
It requests assignments from two clearly identified registries in
accordance with the allocation procedures for those registries.
No new registries are created.

> (18) List any new IANA registries that require Expert Review for
>      future allocations.

None.

> (19) Describe reviews and automated checks performed by the Document
>      Shepherd to validate sections of the document written in a formal
>      language.

The datatracker YANG validation is clean. See (12) and (20)

> (20) If the document contains a YANG module, has the module been
>      checked with any of the recommended validation tools
>      (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for
>      syntax and formatting validation?
>      Does the YANG module comply with the Network Management Datastore
>      Architecture (NMDA) as specified in RFC8342?

The YANG validation results are clean.
To the best of my knowledge, the model complies with the NMDA.

> (1) What type of RFC is being requested
>    Why is this the proper type of RFC?
>    Is this type of RFC indicated in the title page header?

This draft is requested for publication as a Draft Standard.
This is appropriate for a YANG model that will be implemented and must
interoperate.
The status is properly indicated on the title page.

> (2) The IESG approval announcement includes a Document Announcement
>    Write-Up.
>
> Technical Summary:

This document defines an L3VPN Network YANG Model (L3NM) that can be
used for the provisioning of Layer 3 Virtual Private Network (VPN)
services within a service provider network.  The model provides a
network-centric view of L3VPN services.

L3NM is meant to be used by a network controller to derive the
configuration information that will be sent to relevant network
devices.  The model can also facilitate the communication between a
service orchestrator and a network controller/orchestrator.

> Working Group Summary:

There was no controversy.

This model was driven by implementers seeking to use the L3SM [RFC8309]
to provide L3VPN services using orchestrator and controller software.
They determined that an intermediary network-centric (rather than
service-centric) model was required, and they quickly built support
with other implementers.

During the later stages of work on this document, it was determined that
there was commonality between this model and a model for L2VPN.  The
common parts were pulled out into a separate model presented in another
document.

> Document Quality:

This document notes four implementations: Nokia, Huawei, Infinera,
Ribbon-ECI.

The document shepherd is aware of one other commercial implementation
and one prototype implementation.

> Personnel:

Adrian Farrel (adrian@olddog.co.uk) is the Document Shepherd
Rob Wilton (rwilton@cisco.com) iss the Responsible Area Director

> (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.

I reviewed this draft in detail during WG last call and all of the
issues I raised have been addressed. I have done a quick review of the
most recent version mainly focused on the changes. This version is
ready for publication.

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

No concerns. Indeed, the number of implementers participating has
resulted in a deep and broad review.

> (5) Do portions of the document need review from a particular or from
>    broader perspective? If so, describe the review that took place.

This document contains a YANG model and so review by YANG specialists
is in order.

An early YANG Doctor review was conducted on -03 by Radek Krejci and
the issues raised were fixed.

A subsequent YANG Doctor review on -07 at WG last call was also done by
Radek Krejci. It found only one simple nit, and this has been fixed in
the current version.

> (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?

No issues.

> (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.

All authors and contributors have so confirmed.

IPR protestations can be found on the thread https://mailarchive.ietf.org/arch/msg/opsawg/ajoTnvgF5YuYtnUk1Li5BdnBJxQ/

This records no known IPR from the full set of:
  Authors: Oscar Gonzalez de Dios, Mohamed Boucadair, Samier Barguil Giraldo, Qin Wu, Alejandro Aguado
  Contributors: Victor Lopez, Erez Segev

One Contributor (Luis Angel Munoz) notes no IPR on the thread https://mailarchive.ietf.org/arch/msg/opsawg/3U-FxleAm739Zx4gMAHw3eWLIdw/

The final Contributor (Lucia Oliva) reports no IPR on the thread https://mailarchive.ietf.org/arch/msg/opsawg/x-oi9vLlEWgUpP_yu827SJ7CWPs/

> (8) Has an IPR disclosure been filed that references this document?

No IPR disclosed.

> (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?

OPSAWG is an odd WG in that it has several different communities of
interest that rarely cross-review work. As a result, judging broad
consensus in the WG is a challenge.

Nevertheless, the enthusiastic participation by a long list of authors
and contributors, the frequent open design team tele-meetings, and the
additional reviews from five people during last call with no major
objections, suggest good consensus.

While the design teams were well-attended, they left some visibility
holes concerning the work and failed to report back to the broader WG.
This has been corrected with regular readouts on the mailing list, as
well as requests to the mailing list for input on decisions.

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

No discontent voiced.

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

idnits is clean. The warnings have been checked and found to be benign.

> (12) Describe how the document meets any required formal review
>      criteria.

See (5) for YANG Doctor reviews.
YANG validation (in the datatracker) shows 0 errors, 0 warnings

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

Yes. Both normative and informative references are present.

> (14) Are there normative references to documents that are not ready
>      for advancement or are otherwise in an unclear state?

One normative reference is to draft-ietf-opsawg-vpn-common. This is a
partner document that is moving forward at the same time. It is ready
for advancement.

All other normative references are to RFCs.

> (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.

No downrefs.

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

No status changes.

> (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 8126).

The IANA section is simple.
It requests assignments from two clearly identified registries in
accordance with the allocation procedures for those registries.
No new registries are created.

> (18) List any new IANA registries that require Expert Review for
>      future allocations.

None.

> (19) Describe reviews and automated checks performed by the Document
>      Shepherd to validate sections of the document written in a formal
>      language.

The datatracker YANG validation is clean. See (12) and (20)

> (20) If the document contains a YANG module, has the module been
>      checked with any of the recommended validation tools
>      (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for
>      syntax and formatting validation?
>      Does the YANG module comply with the Network Management Datastore
>      Architecture (NMDA) as specified in RFC8342?

The YANG validation results are clean.
To the best of my knowledge, the model complies with the NMDA.

> (1) What type of RFC is being requested
>    Why is this the proper type of RFC?
>    Is this type of RFC indicated in the title page header?

This draft is requested for publication as a Draft Standard.
This is appropriate for a YANG model that will be implemented and must
interoperate.
The status is properly indicated on the title page.

> (2) The IESG approval announcement includes a Document Announcement
>    Write-Up.
>
> Technical Summary:

This document defines an L3VPN Network YANG Model (L3NM) that can be
used for the provisioning of Layer 3 Virtual Private Network (VPN)
services within a service provider network.  The model provides a
network-centric view of L3VPN services.

L3NM is meant to be used by a network controller to derive the
configuration information that will be sent to relevant network
devices.  The model can also facilitate the communication between a
service orchestrator and a network controller/orchestrator.

> Working Group Summary:

There was no controversy.

This model was driven by implementers seeking to use the L3SM [RFC8309]
to provide L3VPN services using orchestrator and controller software.
They determined that an intermediary network-centric (rather than
service-centric) model was required, and they quickly built support
with other implementers.

During the later stages of work on this document, it was determined that
there was commonality between this model and a model for L2VPN.  The
common parts were pulled out into a separate model presented in another
document.

> Document Quality:

This document notes four implementations: Nokia, Huawei, Infinera,
Ribbon-ECI.

The document shepherd is aware of one other commercial implementation
and one prototype implementation.

> Personnel:

Adrian Farrel (adrian@olddog.co.uk) is the Document Shepherd
Rob Wilton (rwilton@cisco.com) iss the Responsible Area Director

> (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.

I reviewed this draft in detail during WG last call and all of the
issues I raised have been addressed. I have done a quick review of the
most recent version mainly focused on the changes. This version is
ready for publication.

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

No concerns. Indeed, the number of implementers participating has
resulted in a deep and broad review.

> (5) Do portions of the document need review from a particular or from
>    broader perspective? If so, describe the review that took place.

This document contains a YANG model and so review by YANG specialists
is in order.
An early YANG Doctor review was conducted on -03 by Radek Krejci and
the issues raised were fixed.
A subsequent YANG Doctor review on -07 at WG last call was also done by
Radek Krejci. It found only one simple nit, and this has been fixed in
the current version.

> (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?

No issues.

> (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.

All authors and contributors have so confirmed.

IPR protestations can be found on the thread https://mailarchive.ietf.org/arch/msg/opsawg/ajoTnvgF5YuYtnUk1Li5BdnBJxQ/

This records no known IPR from the full set of:
  Authors: Oscar Gonzalez de Dios, Mohamed Boucadair, Samier Barguil Giraldo, Qin Wu, Alejandro Aguado
  Contributors: Victor Lopez, Erez Segev

One Contributor (Luis Angel Munoz) notes no IPR on the thread https://mailarchive.ietf.org/arch/msg/opsawg/3U-FxleAm739Zx4gMAHw3eWLIdw/

The final Contributor (Lucia Oliva) reports no IPR on the thread https://mailarchive.ietf.org/arch/msg/opsawg/x-oi9vLlEWgUpP_yu827SJ7CWPs/

> (8) Has an IPR disclosure been filed that references this document?

No IPR disclosed.

> (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?

OPSAWG is an odd WG in that it has several different communities of
interest that rarely cross-review work. As a result, judging broad
consensus in the WG is a challenge.

Nevertheless, the enthusiastic participation by a long list of authors
and contributors, the frequent open design team tele-meetings, and the
additional reviews from five people during last call with no major
objections, suggest good consensus.

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

No discontent voiced.

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

idnits is clean. The warnings have been checked and found to be benign.

> (12) Describe how the document meets any required formal review
>      criteria.

See (5) for YANG Doctor reviews.
YANG validation (in the datatracker) shows 0 errors, 0 warnings

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

Yes. Both normative and informative references are present.

> (14) Are there normative references to documents that are not ready
>      for advancement or are otherwise in an unclear state?

One normative reference is to draft-ietf-opsawg-vpn-common. This is a
partner document that is moving forward at the same time. It is ready
for advancement.

All other normative references are to RFCs.

> (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.

No downrefs.

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

No status changes.

> (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 8126).

The IANA section is simple.
It requests assignments from two clearly identified registries in
accordance with the allocation procedures for those registries.
No new registries are created.

> (18) List any new IANA registries that require Expert Review for
>      future allocations.

None.

> (19) Describe reviews and automated checks performed by the Document
>      Shepherd to validate sections of the document written in a formal
>      language.

The datatracker YANG validation is clean. See (12) and (20)

> (20) If the document contains a YANG module, has the module been
>      checked with any of the recommended validation tools
>      (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for
>      syntax and formatting validation?
>      Does the YANG module comply with the Network Management Datastore
>      Architecture (NMDA) as specified in RFC8342?

The YANG validation results are clean.
To the best of my knowledge, the model complies with the NMDA.

IPR protestations can be found on the thread https://mailarchive.ietf.org/arch/msg/opsawg/ajoTnvgF5YuYtnUk1Li5BdnBJxQ/
This records no known IPR from the full set of:
Authors: Oscar Gonzalez de Dios, Mohamed Boucadair, Samier Barguil Giraldo, Qin Wu, Alejandro Aguado
Contributors: Victor Lopez, Erez Segev
With one Contributor (Luis Angel Munoz) noting no IPR on the thread https://mailarchive.ietf.org/arch/msg/opsawg/3U-FxleAm739Zx4gMAHw3eWLIdw/
And the final Contributor (Lucia Oliva) reporting no IPR on the thread https://mailarchive.ietf.org/arch/msg/opsawg/x-oi9vLlEWgUpP_yu827SJ7CWPs/

IPR protestations can be found on the thread https://mailarchive.ietf.org/arch/msg/opsawg/ajoTnvgF5YuYtnUk1Li5BdnBJxQ/
This records no known IPR from the full set of:
Authors: Oscar Gonzalez de Dios, Mohamed Boucadair, Samier Barguil Giraldo, Qin Wu, Alejandro Aguado
Contributors: Victor Lopez
With one Contributor (Luis Angel Munoz) noting no IPR on the thread https://mailarchive.ietf.org/arch/msg/opsawg/3U-FxleAm739Zx4gMAHw3eWLIdw/
And the final Contributor (Lucia Oliva) reporting no IPR on the thread https://mailarchive.ietf.org/arch/msg/opsawg/x-oi9vLlEWgUpP_yu827SJ7CWPs/
MISSING: Erez Segev

IPR protestations can be found on the thread https://mailarchive.ietf.org/arch/msg/opsawg/ajoTnvgF5YuYtnUk1Li5BdnBJxQ/
This records no known IPR from the full set of:
Authors: Oscar Gonzalez de Dios, Mohamed Boucadair, Samier Barguil Giraldo, Qin Wu
MISSING: Alejandro Aguado
Contributors: Victor Lopez
With one Contributor (Luis Angel Munoz) noting no IPR on the thread https://mailarchive.ietf.org/arch/msg/opsawg/3U-FxleAm739Zx4gMAHw3eWLIdw/
And the final Contributor (Lucia Oliva) reporting no IPR on the thread https://mailarchive.ietf.org/arch/msg/opsawg/x-oi9vLlEWgUpP_yu827SJ7CWPs/
MISSING: Erez Segev

IPR protestations can be found on the thread https://mailarchive.ietf.org/arch/msg/opsawg/ajoTnvgF5YuYtnUk1Li5BdnBJxQ/
This records no known IPR from the full set of:
Authors: Oscar Gonzalez de Dios, Mohamed Boucadair, Samier Barguil Giraldo, Qin Wu
Contributors: Victor Lopez
With the final Contributor (Luis Angel Munoz) noting no IPR on the thread https://mailarchive.ietf.org/arch/msg/opsawg/3U-FxleAm739Zx4gMAHw3eWLIdw/