Skip to main content

YANG Data Model for Segment Routing
draft-ietf-spring-sr-yang-30

Revision differences

Document history

Date Rev. By Action
2022-03-31
30 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events'
2021-05-26
30 (System)
Received changes through RFC Editor sync (created alias RFC 9020, changed abstract to 'This document defines three YANG data models.  The first is for …
Received changes through RFC Editor sync (created alias RFC 9020, changed abstract to 'This document defines three YANG data models.  The first is for Segment Routing (SR) configuration and operation, which is to be augmented by different Segment Routing data planes.  The next is a YANG data model that defines a collection of generic types and groupings for SR.  The third module defines the configuration and operational states for the Segment Routing MPLS data plane.', changed pages to 39, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2021-05-26, changed IESG state to RFC Published)
2021-05-26
30 (System) RFC published
2021-05-14
30 (System) RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9020">AUTH48-DONE</a> from AUTH48
2021-04-01
30 (System) RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9020">AUTH48</a>
2021-02-25
30 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-02-11
30 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Overtaken by Events'
2021-02-11
30 Tero Kivinen Assignment of request for Last Call review by SECDIR to Liang Xia was marked no-response
2021-02-05
30 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2021-02-05
30 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2021-02-05
30 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-02-05
30 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-02-02
30 (System) RFC Editor state changed to EDIT
2021-02-02
30 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-02-02
30 (System) Announcement was received by RFC Editor
2021-02-02
30 (System) IANA Action state changed to In Progress
2021-02-02
30 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2021-02-02
30 Amy Vezza IESG has approved the document
2021-02-02
30 Amy Vezza Closed "Approve" ballot
2021-02-02
30 Martin Vigoureux IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2021-02-02
30 Martin Vigoureux Ballot approval text was generated
2021-01-26
30 Roman Danyliw [Ballot comment]
Thanks for addressing my DISCUSS and COMMENT items.
2021-01-26
30 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2021-01-25
30 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-01-25
30 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-01-25
30 Yingzhen Qu New version available: draft-ietf-spring-sr-yang-30.txt
2021-01-25
30 (System) New version accepted (logged-in submitter: Yingzhen Qu)
2021-01-25
30 Yingzhen Qu Uploaded new revision
2021-01-22
29 Jean Mahoney Closed request for Last Call review by GENART with state 'Overtaken by Events'
2021-01-22
29 Jean Mahoney Assignment of request for Last Call review by GENART to Suhas Nandakumar was marked no-response
2021-01-21
29 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2021-01-21
29 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2021-01-21
29 Robert Wilton [Ballot comment]
Thank you for your work in getting another standard YANG model published.
2021-01-21
29 Robert Wilton [Ballot Position Update] New position, Yes, has been recorded for Robert Wilton
2021-01-21
29 Benjamin Kaduk
[Ballot comment]
If "srgb" already stands for "segment routing global block", what does
the extra "global" in "global-srgb" mean?

I support Roman's Discuss.

Section 4 …
[Ballot comment]
If "srgb" already stands for "segment routing global block", what does
the extra "global" in "global-srgb" mean?

I support Roman's Discuss.

Section 4

  The module ietf-segment-routing-mpls augments the "/rt:routing/
  sr:segment-routing:" with a sr-mpls container.  This container
  defines all the configuration parameters related to segment-routing
  MPLS data plane.

nit: missing "the" ("the segment-routing MPLS data plane").

      *  Connected prefixes : maps connected prefixes to a segment ID.
        Advertisement of the mapping will be done by IGP when enabled
        for segment routing (see Section 5).  The SID value can be
        expressed as an index (default), or an absolute value.  The
        "last-hop-behavior" configuration dictates the PHP behavior:
        "explicit-null", "php", or "non-php".

Is the penultimate hop here a SR hop (a la PSP) or an underlying routing
protocol hop?

Section 5.1.1.1

  (i.e., a bundle of adjacencies).  The "advertise-adj-group-sid"
  configuration controls whether or not an additional adjacency SID is
  advertised.

nit: I think it is better to say "controls for which group(s) an
additional adjacency SID is advertised" -- the current wording implies
that there would only be one additional SID, but IIUC it is one
additional SID per group.

  both interfaces L3 and L4.  This will result in R1 advertising an
  additional Adj-SID for each adjacency, for example a Adj-SID with S
  flag set and value of 400 will be added to L1 and L2.  A Adj-SID with
  S flag set and value of 500 will be added to L3 and L4.  As L1/L2 and
  L3/L4 does not share the same "group-id", a different SID value will
  be allocated.

I don't think I remember where the 'S flag' is specified (or the
'B-flag' in the following section).  This is still in the
protocol-independent part of the model/document, right?  (Also, nit,
please consistently hyphenate or don't hyphenate the "X flag"
construction.)

Section 8.2

    grouping prefix-sid {
      description
        "This grouping defines cfg of prefix SID.";

nit: I think we can write out "config" or even "configuration" here.

Section 8.3

    feature max-sid-depth {
      description
        "Support for signaling MSD (Maximum SID Depth) in IGP.";
        reference "RFC 8476: Signaling Maximum SID Depth (MSD)
                              Using OSPF
                    RFC 8491: Signaling Maximum SID Depth (MSD)
                              Using IS-IS
                    RFC 8814: Singaling Maximum SID Deppt (MSD)
                              Using the Border Gateway Protocol
                              (BGP) - Link State";
    }

I feel like a few more words are in order -- do I claim the feature if I
inplement only one IGP's signaling?  Or do I need to have all three?  Or
"just" have support for it in all the IGPs that I support?

              enum "dual" {
                description
                  "Two Adj-SIDs will be associated with the adjacency
                    if the interface is protected. In this case, will
                    be advertised with backup flag set, the other will
                    be advertised with the backup flag clear. In case
                    protection is not configured, single Adj-SID will
                    be advertised with the backup flag clear.";

nit: some missing words, maybe "In this case, one will", ", and the
other will", "a single Adj-SID will".

        description
          "Node MSD is the lowest MSD supported by the node.";

nit(?): "lowest link MSD"?

        list label-blocks {
          [...]
          leaf lower-bound {
          [...]
          leaf upper-bound {
          [...]
          leaf size {
          [...]
          leaf free {
          [...]
          leaf used {

Is there really all the internal redundancy between these that it sounds
like there is?  Would we benefit from any YANG-level constraints or
other enforced consistency checks?

    notification segment-routing-global-sid-collision {
      [...]
      leaf received-target {
        type string;
        description
          "Target received in the router advertisement that caused
            the SID collision.";

I'm not entirely sure that string is the right type here (it cannot
handle arbitrary binary strings and must be UTF-8) ... if it's a SID,
don't we normally represent those as uint32?  Or if it's a proper
route-target structure that seems like it would need to allow arbitrary
binary content.  (The original-target leaf would be similarly affected,
of course.)

Section 9

I believe at this point we're converging on using RFC 8446 as the TLS
reference (even though the nominal boilerplate template has had RFC
5246
).  This would not imply a requirement to actually use TLS 1.3; it
just reflects that RFC 8446 is the current IETF reference for TLS.

Section 12.1

I guess RFC 3688 could probably be just an informative reference.
So could NETCONF and RESTCONF (6241 and 8040).
2021-01-21
29 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2021-01-20
29 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2021-01-20
29 Roman Danyliw
[Ballot discuss]
Section 9.  The primary impact of the manipulating writable nodes appears to be characterized as DoS.  Don’t the possible consequences also include the …
[Ballot discuss]
Section 9.  The primary impact of the manipulating writable nodes appears to be characterized as DoS.  Don’t the possible consequences also include the ability to leak traffic outside the trusted domain or to route traffic through arbitrary paths of the attackers choosing potentially enable on-path inspection or manipulation of traffic; or avoidance of security controls?
2021-01-20
29 Roman Danyliw
[Ballot comment]
** Section 9.  Thanks for using the templated YANG Security Considerations.  A nit on the references s/[RFC6536]/[RFC8341]/

** Section …
[Ballot comment]
** Section 9.  Thanks for using the templated YANG Security Considerations.  A nit on the references s/[RFC6536]/[RFC8341]/

** Section 9.  The following caution around readable nodes didn’t parse for me.  Was the intent as follows:

OLD
The exposure of both local
  bindings and SID database will exposure segment routing paths that
  may be attacked.

NEW
The exposure of either the local bindings or SID database would provide an attacker the segment routing paths and related topology information.

** Section 9.  Typo. s/a a/a/

** Section 9.  Typo. s/rediection/redirection/
2021-01-20
29 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2021-01-20
29 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2021-01-20
29 Alvaro Retana
[Ballot comment]
(1) I have a significant concern about the incomplete representation of the
MSD in this document.  Even though the model is incomplete, I …
[Ballot comment]
(1) I have a significant concern about the incomplete representation of the
MSD in this document.  Even though the model is incomplete, I am not balloting
DISCUSS because this point should be easy to address.

    grouping max-sid-depth {
      description
        "Maximum SID Depth (MSD) operational state grouping.";
      leaf node-msd {
        type uint8;
        description
          "Node MSD is the lowest MSD supported by the node.";
      }
      container link-msds {
        description
          "MSD supported by an individual interface.";
        list link-msds {
          key "interface";
          description
            "List of link MSDs.";
          leaf interface {
            type if:interface-ref;
            description
              "Reference to device interface.";
          }
          leaf msd {
            type uint8;
            description
              "MSD supported by the interface.";
          }
        }
      }
    }


(a) While there is a "type" mentioned, that seems to correspond to the
MSD-Value.  The MSD-Type is not included above.

(b) Note that the MSD is really a pair of MSD-Type/MSD-Value.  The description
above, even if extended to also include the MSD-Type, seems to allow for a
single pair, where multiple could be advertised per node/link.

(c) The ERLD (entropy-readable-label-depth, for which references should be
included) is advertised in the IGPs using the same mechanism as the MSD: using
the ERLD-MSD type.  IOW, the separation of the ERLD from the MSD in the module
is redundant/incorrect.

(d) MSD is a good example of a feature that is common to both the MPLS and
IPv6 dataplanes and should be in the common part of the model, not defined
separately for each.

(2) §3: "Module ietf-segment-routing-common defines generic types and
groupings that SHOULD be reused by IGP extension modules."  The SHOULD is out
place because the module is either supported or not, if it isn't then there is
no effect on interoperability because the IGP extension module presumably
chose a different option.  s/that SHOULD/to

(3) §3: There should be a representation of the ietf-segment-routing-common
module in this section.
2021-01-20
29 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2021-01-19
29 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2021-01-18
29 Erik Kline
[Ballot comment]
[[ questions ]]

[ section 8.3 ]

* On the bottom of page 18 there's a definition of an IS-IS system-id.
  draft-ietf-isis-yang-isis-cfg …
[Ballot comment]
[[ questions ]]

[ section 8.3 ]

* On the bottom of page 18 there's a definition of an IS-IS system-id.
  draft-ietf-isis-yang-isis-cfg has a definition of a system-id as well as
  an extended-system-id.  Should this document reference that document's
  {extended-,}system-id definitions?

  I just wonder if this other document is somehow "more authoritative" for
  this type of thing, and therefore wondering whether referencing it would
  be the right thing to do.
2021-01-18
29 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2021-01-14
29 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document even if I am balloting ABSTAIN, this is useful piece and it should really …
[Ballot comment]
Thank you for the work put into this document even if I am balloting ABSTAIN, this is useful piece and it should really be improved to fix my ABSTAIN reasons so that I could actively support it. Read my ABSTAIN ballot as "I oppose this document but understand that others differ and am not going to stand in the way of the others" per https://www.ietf.org/standards/process/iesg-ballots/ .

Please note that I am neither a YANG expert nor a segment routing one (hence my ABSTAIN rather than a DISCUSS).

Based on title, I was expecting this document to be generic and to see companion YANG models for the MPLS and IPv6 data planes but it seems that this document also augments *only* the MPLS one. The asymmetry does not look good to me... Are the authors/WG sure that the IPv6 YANG model can also be specified by augmenting this model (draft-ietf-spring-srv6-yang-00 is still a -00 ...) and relying on types defined in ietf-segment-routing-common ? Especially when noting that the authors are different ?

The YANG model for SR is really short (mostly meaningless except for one more tag in the namespace tree):
  "module: ietf-segment-routing
    augment /rt:routing:
      +--rw segment-routing"

To be honest, I strongly dislike the fact that there is no common element between the YANG modules for MPLS and IPv6 data planes inside ietf-segment-routing. I admit that I am not an SR expert but I would have expected more common elements: policies, routing protocols, SID, link bundles, ... even if the leaves could be instantiated as generic types to be augmented later.

One additional regret is that the document shepherd write-up is really really short. But it includes the most important element (to my eyes): the WG feedback & consensus.

Regards,

-éric
2021-01-14
29 Éric Vyncke Ballot comment text updated for Éric Vyncke
2021-01-14
29 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document even if I am balloting ABSTAIN, this is useful piece and it should really …
[Ballot comment]
Thank you for the work put into this document even if I am balloting ABSTAIN, this is useful piece and it should really be improved to fix my ABSTAIN reasons so that I could actively support it. Read my ABSTAIN ballot as "I oppose this document but understand that others differ and am not going to stand in the way of the others" per https://www.ietf.org/standards/process/iesg-ballots/ .

Please note that I am neither a YANG expert nor a segment routing one (hence my ABSTAIN rather than a DISCUSS).

Based on title, I was expecting this document to be generic and to see companion YANG models for the MPLS and IPv6 data planes but it seems that this document also augments *only* the MPLS one. The asymmetry does not look good to me... Are the authors/WG sure that the IPv6 YANG model can also be specified by augmenting this model (draft-ietf-spring-srv6-yang-00 is still a -00 ...) and relying on types defined in ietf-segment-routing-common ? Especially when noting that the authors are different ?

The YANG model for SR is really short (mostly meaning less except to add one tag in the namespace tree):
  "module: ietf-segment-routing
    augment /rt:routing:
      +--rw segment-routing"

To be honest, I strongly dislike the fact that there is no common element between the YANG modules for MPLS and IPv6 data planes inside ietf-segment-routing. I admit that I am not an SR expert but I would have expected more common elements: policies, routing protocols, SID, bundlings, ... even if the leaves could be instantiated as generic types to be augmented later.

One additional regret is that the document shepherd write-up is really really short. But it includes the most important element (to my eyes): the WG feedback & consensus.

Regards,

-éric
2021-01-14
29 Éric Vyncke [Ballot Position Update] New position, Abstain, has been recorded for Éric Vyncke
2021-01-13
29 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2021-01-06
29 Amy Vezza Placed on agenda for telechat - 2021-01-21
2021-01-06
29 Martin Vigoureux Ballot has been issued
2021-01-06
29 Martin Vigoureux [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux
2021-01-06
29 Martin Vigoureux Created "Approve" ballot
2021-01-06
29 Martin Vigoureux IESG state changed to IESG Evaluation from Waiting for Writeup
2021-01-06
29 Martin Vigoureux Ballot writeup was changed
2020-12-08
29 Yingzhen Qu New version available: draft-ietf-spring-sr-yang-29.txt
2020-12-08
29 (System) New version accepted (logged-in submitter: Yingzhen Qu)
2020-12-08
29 Yingzhen Qu Uploaded new revision
2020-12-08
28 Tal Mizrahi Request for Early review by RTGDIR Completed: Has Issues. Reviewer: Tal Mizrahi.
2020-11-30
28 (System) IESG state changed to Waiting for Writeup from In Last Call
2020-11-28
28 Acee Lindem New version available: draft-ietf-spring-sr-yang-28.txt
2020-11-28
28 (System) New version accepted (logged-in submitter: Acee Lindem)
2020-11-28
28 Acee Lindem Uploaded new revision
2020-11-27
27 Min Ye Assignment of request for Early review by RTGDIR to Tony Przygienda was withdrawn
2020-11-27
27 Min Ye Request for Early review by RTGDIR is assigned to Tony Przygienda
2020-11-27
27 Min Ye Request for Early review by RTGDIR is assigned to Tony Przygienda
2020-11-27
27 Acee Lindem New version available: draft-ietf-spring-sr-yang-27.txt
2020-11-27
27 (System) New version accepted (logged-in submitter: Acee Lindem)
2020-11-27
27 Acee Lindem Uploaded new revision
2020-11-25
26 Acee Lindem New version available: draft-ietf-spring-sr-yang-26.txt
2020-11-25
26 (System) New version accepted (logged-in submitter: Acee Lindem)
2020-11-25
26 Acee Lindem Uploaded new revision
2020-11-25
25 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Zitao Wang
2020-11-25
25 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Zitao Wang
2020-11-24
25 Yingzhen Qu New version available: draft-ietf-spring-sr-yang-25.txt
2020-11-24
25 (System) New version accepted (logged-in submitter: Yingzhen Qu)
2020-11-24
25 Yingzhen Qu Uploaded new revision
2020-11-24
24 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-11-24
24 Yingzhen Qu New version available: draft-ietf-spring-sr-yang-24.txt
2020-11-24
24 (System) New version accepted (logged-in submitter: Yingzhen Qu)
2020-11-24
24 Yingzhen Qu Uploaded new revision
2020-11-24
23 Sabrina Tanamal IANA Experts State changed to Expert Reviews OK
2020-11-24
23 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2020-11-24
23 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2020-11-24
23 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-spring-sr-yang-23. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-spring-sr-yang-23. If any part of this review is inaccurate, please let us know.

The IANA Services 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/

three, new namespaces will be registered as follows:

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

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

ID: yang:ietf-segment-routing-mpls
URI: urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls
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/

three, new YANG modules will be registered as follows:

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

Name: ietf-segment-routing-common
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-common
Prefix: sr-cmn
Module:
Reference: [ RFC-to-be ]

Name: ietf-segment-routing-mpls
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls
Prefix: sr-mpls
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
2020-11-23
23 Min Ye Assignment of request for Early review by RTGDIR to Jon Mitchell was marked no-response
2020-11-23
23 Min Ye Request for Early review by RTGDIR is assigned to Tal Mizrahi
2020-11-23
23 Min Ye Request for Early review by RTGDIR is assigned to Tal Mizrahi
2020-11-21
23 Jean Mahoney Request for Last Call review by GENART is assigned to Suhas Nandakumar
2020-11-21
23 Jean Mahoney Request for Last Call review by GENART is assigned to Suhas Nandakumar
2020-11-19
23 Tero Kivinen Request for Last Call review by SECDIR is assigned to Liang Xia
2020-11-19
23 Tero Kivinen Request for Last Call review by SECDIR is assigned to Liang Xia
2020-11-17
23 Min Ye Request for Early review by RTGDIR is assigned to Jon Mitchell
2020-11-17
23 Min Ye Request for Early review by RTGDIR is assigned to Jon Mitchell
2020-11-17
23 Min Ye Assignment of request for Early review by RTGDIR to Mike McBride was rejected
2020-11-17
23 Min Ye Request for Early review by RTGDIR is assigned to Mike McBride
2020-11-17
23 Min Ye Request for Early review by RTGDIR is assigned to Mike McBride
2020-11-16
23 Amy Vezza IANA Review state changed to IANA - Review Needed
2020-11-16
23 Amy Vezza
The following Last Call announcement was sent out (ends 2020-11-30):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: jmh@joelhalpern.com, draft-ietf-spring-sr-yang@ietf.org, …
The following Last Call announcement was sent out (ends 2020-11-30):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: jmh@joelhalpern.com, draft-ietf-spring-sr-yang@ietf.org, spring@ietf.org, martin.vigoureux@nokia.com, Joel Halpern <jmh@joelhalpern.com>, spring-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-spring-sr-yang-23.txt> (YANG Data Model for Segment Routing) to Proposed Standard


The IESG has received a request from the Source Packet Routing in Networking
WG (spring) to consider the following document: - 'YANG Data Model for
Segment Routing'
  <draft-ietf-spring-sr-yang-23.txt> 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 2020-11-30. 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 for segment routing
  configuration and operation, which is to be augmented by different
  segment routing data planes.  The document also defines a YANG model
  that is intended to be used on network elements to configure or
  operate segment routing MPLS data plane, as well as some generic
  containers to be reused by IGP protocol modules to support segment
  routing.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/



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




2020-11-16
23 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2020-11-16
23 Amy Vezza Last call announcement was generated
2020-11-16
23 Acee Lindem New version available: draft-ietf-spring-sr-yang-23.txt
2020-11-16
23 (System) New version accepted (logged-in submitter: Acee Lindem)
2020-11-16
23 Acee Lindem Uploaded new revision
2020-11-16
22 Martin Vigoureux Requested Early review by RTGDIR
2020-11-16
22 Martin Vigoureux Last call was requested
2020-11-16
22 Martin Vigoureux Last call announcement was generated
2020-11-16
22 Martin Vigoureux Ballot approval text was generated
2020-11-16
22 Martin Vigoureux Ballot writeup was generated
2020-11-16
22 Martin Vigoureux IESG state changed to Last Call Requested from AD Evaluation
2020-11-16
22 Martin Vigoureux IESG state changed to AD Evaluation from Publication Requested
2020-11-12
22 Martin Vigoureux Changed consensus to Yes from Unknown
2020-11-12
22 Martin Vigoureux Notification list changed to Joel Halpern <jmh@joelhalpern.com> from Rob Shakir <robjs@google.com>, Joel Halpern <jmh@joelhalpern.com>
2020-08-26
22 Yingzhen Qu New version available: draft-ietf-spring-sr-yang-22.txt
2020-08-26
22 (System) New version approved
2020-08-26
22 (System)
Request for posting confirmation emailed to previous authors: Jeff Tantsura <jefftant.ietf@gmail.com>, Pushpasis Sarkar <pushpasis.ietf@gmail.com>, Stephane Litkowski <slitkows.ietf@gmail.com>, Yingzhen Qu …
Request for posting confirmation emailed to previous authors: Jeff Tantsura <jefftant.ietf@gmail.com>, Pushpasis Sarkar <pushpasis.ietf@gmail.com>, Stephane Litkowski <slitkows.ietf@gmail.com>, Yingzhen Qu <yingzhen.qu@futurewei.com>, Acee Lindem <acee@cisco.com>
2020-08-26
22 Yingzhen Qu Uploaded new revision
2020-08-25
21 Yingzhen Qu New version available: draft-ietf-spring-sr-yang-21.txt
2020-08-25
21 (System) New version approved
2020-08-25
21 (System)
Request for posting confirmation emailed to previous authors: Pushpasis Sarkar <pushpasis.ietf@gmail.com>, Acee Lindem <acee@cisco.com>, Stephane Litkowski <slitkows.ietf@gmail.com>, Jeff Tantsura …
Request for posting confirmation emailed to previous authors: Pushpasis Sarkar <pushpasis.ietf@gmail.com>, Acee Lindem <acee@cisco.com>, Stephane Litkowski <slitkows.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Yingzhen Qu <yingzhen.qu@futurewei.com>
2020-08-25
21 Yingzhen Qu Uploaded new revision
2020-08-24
20 Ladislav Lhotka Request for Last Call review by YANGDOCTORS Completed: Ready with Nits. Reviewer: Ladislav Lhotka. Sent review to list.
2020-08-17
20 Yingzhen Qu New version available: draft-ietf-spring-sr-yang-20.txt
2020-08-17
20 (System) New version accepted (logged-in submitter: Yingzhen Qu)
2020-08-17
20 Yingzhen Qu Uploaded new revision
2020-08-02
19 Yingzhen Qu New version available: draft-ietf-spring-sr-yang-19.txt
2020-08-02
19 (System) New version approved
2020-08-02
19 (System)
Request for posting confirmation emailed to previous authors: Jeff Tantsura <jefftant.ietf@gmail.com>, Acee Lindem <acee@cisco.com>, Yingzhen Qu <yingzhen.qu@futurewei.com>, Stephane Litkowski …
Request for posting confirmation emailed to previous authors: Jeff Tantsura <jefftant.ietf@gmail.com>, Acee Lindem <acee@cisco.com>, Yingzhen Qu <yingzhen.qu@futurewei.com>, Stephane Litkowski <slitkows.ietf@gmail.com>, Pushpasis Sarkar <pushpasis.ietf@gmail.com>
2020-08-02
19 Yingzhen Qu Uploaded new revision
2020-07-28
18 Joel Halpern
Summary:
    The document shepherd is Joel Halpern.  The responsible Area Director is Martin Vigoureaux.

    The document is the base YANG Data …
Summary:
    The document shepherd is Joel Halpern.  The responsible Area Director is Martin Vigoureaux.

    The document is the base YANG Data Model for Segment Routing.  It provides a module for base configuration and operation of segment routing systems.  It also provides a module for detailed configuration and operation of MPLS segment routing.

Review and Consensus:
    The document has been well-reviewed within the SPRING working group.  An early YANG Doctor review was done, and the issues from that review addressed.  A last call YANG Doctor review has been requested.  There was good support for the document in the working group, and no controversy during the last call.  Some minor typographic issues were found and fixed during the shepherd review.

Intellectual Property:
    All authors have confirmed that all known relevant IPR has been disclosed as per BCP 78/79.  There are no IPR disclosures on the document.
2020-07-28
18 Joel Halpern Responsible AD changed to Martin Vigoureux
2020-07-28
18 Joel Halpern IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2020-07-28
18 Joel Halpern IESG state changed to Publication Requested from I-D Exists
2020-07-28
18 Joel Halpern IESG process started in state Publication Requested
2020-07-28
18 Joel Halpern
Summary:
    The document shepherd is Joel Halpern.  The responsible Area Director is Martin Vigoureaux.

    The document is the base YANG Data …
Summary:
    The document shepherd is Joel Halpern.  The responsible Area Director is Martin Vigoureaux.

    The document is the base YANG Data Model for Segment Routing.  It provides a module for base configuration and operation of segment routing systems.  It also provides a module for detailed configuration and operation of MPLS segment routing.

Review and Consensus:
    The document has been well-reviewed within the SPRING working group.  An early YANG Doctor review was done, and the issues from that review addressed.  A last call YANG Doctor review has been requested.  There was good support for the document in the working group, and no controversy during the last call.  Some minor typographic issues were found and fixed during the shepherd review.

Intellectual Property:
    All authors have confirmed that all known relevant IPR has been disclosed as per BCP 78/79.  There are no IPR disclosures on the document.
2020-07-28
18 Mehmet Ersue Request for Last Call review by YANGDOCTORS is assigned to Ladislav Lhotka
2020-07-28
18 Mehmet Ersue Request for Last Call review by YANGDOCTORS is assigned to Ladislav Lhotka
2020-07-28
18 Joel Halpern Requested Last Call review by YANGDOCTORS
2020-07-26
18 Yingzhen Qu New version available: draft-ietf-spring-sr-yang-18.txt
2020-07-26
18 (System) New version accepted (logged-in submitter: Yingzhen Qu)
2020-07-26
18 Yingzhen Qu Uploaded new revision
2020-07-09
17 Yingzhen Qu New version available: draft-ietf-spring-sr-yang-17.txt
2020-07-09
17 (System) New version approved
2020-07-09
17 (System)
Request for posting confirmation emailed to previous authors: Jeff Tantsura <jefftant.ietf@gmail.com>, Acee Lindem <acee@cisco.com>, Stephane Litkowski <slitkows.ietf@gmail.com>, Yingzhen Qu …
Request for posting confirmation emailed to previous authors: Jeff Tantsura <jefftant.ietf@gmail.com>, Acee Lindem <acee@cisco.com>, Stephane Litkowski <slitkows.ietf@gmail.com>, Yingzhen Qu <yingzhen.qu@futurewei.com>, Pushpasis Sarkar <pushpasis.ietf@gmail.com>
2020-07-09
17 Yingzhen Qu Uploaded new revision
2020-07-09
16 Yingzhen Qu New version available: draft-ietf-spring-sr-yang-16.txt
2020-07-09
16 (System) New version approved
2020-07-09
16 (System)
Request for posting confirmation emailed to previous authors: Acee Lindem <acee@cisco.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Stephane Litkowski <slitkows.ietf@gmail.com>, Yingzhen Qu …
Request for posting confirmation emailed to previous authors: Acee Lindem <acee@cisco.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Stephane Litkowski <slitkows.ietf@gmail.com>, Yingzhen Qu <yingzhen.qu@futurewei.com>, Pushpasis Sarkar <pushpasis.ietf@gmail.com>
2020-07-09
16 Yingzhen Qu Uploaded new revision
2020-07-07
15 Joel Halpern The WG Last Call completed successfully.  The Shepherd is preparing the writeup.
2020-07-07
15 Joel Halpern IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2020-06-23
15 Jim Guichard Notification list changed to Rob Shakir <robjs@google.com>, Joel Halpern <jmh@joelhalpern.com> from Rob Shakir <robjs@google.com>
2020-06-23
15 Jim Guichard Document shepherd changed to Joel M. Halpern
2020-06-23
15 Jim Guichard IETF WG state changed to In WG Last Call from WG Document
2020-01-09
15 Yingzhen Qu New version available: draft-ietf-spring-sr-yang-15.txt
2020-01-09
15 (System) New version approved
2020-01-09
15 (System)
Request for posting confirmation emailed to previous authors: Yingzhen Qu <yingzhen.qu@futurewei.com>, Stephane Litkowski <slitkows.ietf@gmail.com>, Acee Lindem <acee@cisco.com>, Pushpasis Sarkar …
Request for posting confirmation emailed to previous authors: Yingzhen Qu <yingzhen.qu@futurewei.com>, Stephane Litkowski <slitkows.ietf@gmail.com>, Acee Lindem <acee@cisco.com>, Pushpasis Sarkar <pushpasis.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>
2020-01-09
15 Yingzhen Qu Uploaded new revision
2019-11-03
14 Yingzhen Qu New version available: draft-ietf-spring-sr-yang-14.txt
2019-11-03
14 (System) New version accepted (logged-in submitter: Yingzhen Qu)
2019-11-03
14 Yingzhen Qu Uploaded new revision
2019-07-07
13 Yingzhen Qu New version available: draft-ietf-spring-sr-yang-13.txt
2019-07-07
13 (System) New version approved
2019-07-07
13 (System)
Request for posting confirmation emailed to previous authors: Yingzhen Qu <yingzhen.qu@huawei.com>, Pushpasis Sarkar <pushpasis.ietf@gmail.com>, spring-chairs@ietf.org, Acee Lindem <acee@cisco.com>, …
Request for posting confirmation emailed to previous authors: Yingzhen Qu <yingzhen.qu@huawei.com>, Pushpasis Sarkar <pushpasis.ietf@gmail.com>, spring-chairs@ietf.org, Acee Lindem <acee@cisco.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Stephane Litkowski <stephane.litkowski@orange.com>
2019-07-07
13 Yingzhen Qu Uploaded new revision
2019-02-28
12 Acee Lindem New version available: draft-ietf-spring-sr-yang-12.txt
2019-02-28
12 (System) New version approved
2019-02-28
12 (System)
Request for posting confirmation emailed to previous authors: Yingzhen Qu <yingzhen.qu@huawei.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Acee Lindem <acee@cisco.com>, Pushpasis Sarkar …
Request for posting confirmation emailed to previous authors: Yingzhen Qu <yingzhen.qu@huawei.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Acee Lindem <acee@cisco.com>, Pushpasis Sarkar <pushpasis.ietf@gmail.com>, Stephane Litkowski <stephane.litkowski@orange.com>
2019-02-28
12 Acee Lindem Uploaded new revision
2019-02-15
11 Yingzhen Qu New version available: draft-ietf-spring-sr-yang-11.txt
2019-02-15
11 (System) New version approved
2019-02-15
11 (System)
Request for posting confirmation emailed to previous authors: Yingzhen Qu <yingzhen.qu@huawei.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Acee Lindem <acee@cisco.com>, Pushpasis Sarkar …
Request for posting confirmation emailed to previous authors: Yingzhen Qu <yingzhen.qu@huawei.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Acee Lindem <acee@cisco.com>, Pushpasis Sarkar <pushpasis.ietf@gmail.com>, Stephane Litkowski <stephane.litkowski@orange.com>
2019-02-15
11 Yingzhen Qu Uploaded new revision
2018-12-31
10 Yingzhen Qu New version available: draft-ietf-spring-sr-yang-10.txt
2018-12-31
10 (System) New version approved
2018-12-31
10 (System)
Request for posting confirmation emailed to previous authors: Yingzhen Qu <yingzhen.qu@huawei.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, spring-chairs@ietf.org, Pushpasis Sarkar <pushpasis.ietf@gmail.com>, …
Request for posting confirmation emailed to previous authors: Yingzhen Qu <yingzhen.qu@huawei.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, spring-chairs@ietf.org, Pushpasis Sarkar <pushpasis.ietf@gmail.com>, Stephane Litkowski <stephane.litkowski@orange.com>
2018-12-31
10 Yingzhen Qu Uploaded new revision
2018-12-30
09 (System) Document has expired
2018-10-24
09 Rob Shakir Notification list changed to Rob Shakir <robjs@google.com>
2018-10-24
09 Rob Shakir Document shepherd changed to Rob Shakir
2018-10-24
09 Ladislav Lhotka Request for Early review by YANGDOCTORS Completed: On the Right Track. Reviewer: Ladislav Lhotka. Sent review to list.
2018-10-18
09 Mehmet Ersue Request for Early review by YANGDOCTORS is assigned to Ladislav Lhotka
2018-10-18
09 Mehmet Ersue Request for Early review by YANGDOCTORS is assigned to Ladislav Lhotka
2018-10-16
09 Bruno Decraene Requested Early review by YANGDOCTORS
2018-07-06
09 Bruno Decraene Added to session: IETF-102: spring  Mon-1330
2018-06-28
09 Yingzhen Qu New version available: draft-ietf-spring-sr-yang-09.txt
2018-06-28
09 (System) New version approved
2018-06-28
09 (System)
Request for posting confirmation emailed to previous authors: Yingzhen Qu <yingzhen.qu@huawei.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Pushpasis Sarkar <pushpasis.ietf@gmail.com>, Stephane Litkowski …
Request for posting confirmation emailed to previous authors: Yingzhen Qu <yingzhen.qu@huawei.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Pushpasis Sarkar <pushpasis.ietf@gmail.com>, Stephane Litkowski <stephane.litkowski@orange.com>
2018-06-28
09 Yingzhen Qu Uploaded new revision
2017-12-28
08 Yingzhen Qu New version available: draft-ietf-spring-sr-yang-08.txt
2017-12-28
08 (System) New version approved
2017-12-28
08 (System)
Request for posting confirmation emailed to previous authors: Yingzhen Qu <yingzhen.qu@huawei.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Pushpasis Sarkar <pushpasis.ietf@gmail.com>, Stephane Litkowski …
Request for posting confirmation emailed to previous authors: Yingzhen Qu <yingzhen.qu@huawei.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Pushpasis Sarkar <pushpasis.ietf@gmail.com>, Stephane Litkowski <stephane.litkowski@orange.com>
2017-12-28
08 Yingzhen Qu Uploaded new revision
2017-11-06
07 Bruno Decraene Added to session: IETF-100: spring  Wed-1520
2017-07-01
07 Yingzhen Qu New version available: draft-ietf-spring-sr-yang-07.txt
2017-07-01
07 (System) New version approved
2017-07-01
07 (System)
Request for posting confirmation emailed to previous authors: Yingzhen Qu <yingzhen.qu@huawei.com>, Stephane Litkowski <stephane.litkowski@orange.com>, Pushpasis Sarkar <pushpasis.ietf@gmail.com>, Jeff Tantsura …
Request for posting confirmation emailed to previous authors: Yingzhen Qu <yingzhen.qu@huawei.com>, Stephane Litkowski <stephane.litkowski@orange.com>, Pushpasis Sarkar <pushpasis.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>
2017-07-01
07 Yingzhen Qu Uploaded new revision
2017-03-10
06 Yingzhen Qu New version available: draft-ietf-spring-sr-yang-06.txt
2017-03-10
06 (System) New version approved
2017-03-10
06 (System)
Request for posting confirmation emailed to previous authors: Yingzhen Qu <yiqu@cisco.com>, Stephane Litkowski <stephane.litkowski@orange.com>, spring-chairs@ietf.org, Pushpasis Sarkar <pushpasis.ietf@gmail.com>, …
Request for posting confirmation emailed to previous authors: Yingzhen Qu <yiqu@cisco.com>, Stephane Litkowski <stephane.litkowski@orange.com>, spring-chairs@ietf.org, Pushpasis Sarkar <pushpasis.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>
2017-03-10
06 Yingzhen Qu Uploaded new revision
2016-11-13
05 Martin Vigoureux Added -05 to session: IETF-97: spring  Thu-0930
2016-11-13
05 Martin Vigoureux Removed from session: IETF-97: spring  Thu-0930
2016-11-02
05 Bruno Decraene Added to session: IETF-97: spring  Thu-0930
2016-10-28
05 Yingzhen Qu New version available: draft-ietf-spring-sr-yang-05.txt
2016-10-28
05 (System) New version approved
2016-10-28
04 (System)
Request for posting confirmation emailed to previous authors: "Pushpasis Sarkar" <psarkar@juniper.net>, "Jeff Tantsura" <jefftant.ietf@gmail.com>, spring-chairs@ietf.org, "Yingzhen Qu" <yiqu@cisco.com>, …
Request for posting confirmation emailed to previous authors: "Pushpasis Sarkar" <psarkar@juniper.net>, "Jeff Tantsura" <jefftant.ietf@gmail.com>, spring-chairs@ietf.org, "Yingzhen Qu" <yiqu@cisco.com>, "Stephane Litkowski" <stephane.litkowski@orange.com>
2016-10-28
04 Yingzhen Qu Uploaded new revision
2016-10-24
04 Yingzhen Qu New version available: draft-ietf-spring-sr-yang-04.txt
2016-10-24
04 (System) New version approved
2016-10-24
03 (System)
Request for posting confirmation emailed to previous authors: "Pushpasis Sarkar" <psarkar@juniper.net>, "Stephane Litkowski" <stephane.litkowski@orange.com>, spring-chairs@ietf.org, "Yingzhen Qu" <yiqu@cisco.com>, …
Request for posting confirmation emailed to previous authors: "Pushpasis Sarkar" <psarkar@juniper.net>, "Stephane Litkowski" <stephane.litkowski@orange.com>, spring-chairs@ietf.org, "Yingzhen Qu" <yiqu@cisco.com>, "Jeff Tantsura" <jeff.tantsura@ericsson.com>
2016-10-24
03 Yingzhen Qu Uploaded new revision
2016-07-07
03 Yingzhen Qu New version available: draft-ietf-spring-sr-yang-03.txt
2016-03-18
02 Yingzhen Qu New version available: draft-ietf-spring-sr-yang-02.txt
2015-10-17
01 Yingzhen Qu New version available: draft-ietf-spring-sr-yang-01.txt
2015-07-20
00 Bruno Decraene This document now replaces draft-litkowski-spring-sr-yang instead of None
2015-07-20
00 Bruno Decraene Intended Status changed to Proposed Standard from None
2015-07-20
00 Stephane Litkowski New version available: draft-ietf-spring-sr-yang-00.txt