OSPF Extensions for Segment Routing
draft-ietf-ospf-segment-routing-extensions-27

Request for posting confirmation emailed to previous authors: Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi , Rob Shakir

[Ballot comment]
Substantive Comments:

- Requirements Language: There are a few instances of 2119 keywords in lower case. Please consider if those are meant to be normative. If not, then please use the boilerplate from RFC 8184, which explicitly excludes lower case instances as normative keywords.

-3.1, 2nd to last paragraph: Why aren't the 3 "SHOULDs" "MUSTs"? It seems like these might have an impact on interoperability, or at least predictable behavior in edge conditions.

-3.4: (same comment as for 3.1)

Editorial Comments and Nits:

-1, first paragraph: There are a lot of ideas packed into that paragraph. It's not clear to me which the "For example" sentences means to exemplify.

-3.3, 2nd to last paragraph: Why is "NOT" capitalized?

[Ballot comment]
* It would be good to clarify that this document is intended for OSPFv2 only (probably in the title and/or abstract). It may also be worthwhile for the document and/or the Shepherd writeup to explain why the WG decided to separate the OSPFv3 extensions into a different document.

* I think RFC2328 should be a Normative Reference and not an informative reference.

[Ballot comment]
I'm not sure that Susan Hare's OpsDir review (from -17) was addressed, unless it is:
  Reception of malformed TLV or Sub-TLV SHOULD be counted and/or logged for further analysis.  Logging of malformed TLVs and Sub-TLVs should be rate-limited to prevent a Denial of Service (DoS) attack (distributed or otherwise) from overloading the OSPF control plane."
If this text was intended to cover it, I think it falls short - it is better than nothing, but I think could be clearer

[Ballot discuss]
This is generally a clearly written document, but it needs a few minor changes before I can recommend its approval for publication.

1) In Section 3.2:

  o  When a router receives multiple overlapping ranges, it MUST
      conform to the procedures defined in
      [I-D.ietf-spring-conflict-resolution].

RFC 2119 keyword usage makes the reference a Normative reference, yet it is currently listed as informative.

3.4.  SRMS Preference TLV

  The Segment Routing Mapping Server Preference TLV (SRMS Preference
  TLV) is used to advertise a preference associated with the node that
  acts as an SR Mapping Server.  The role of an SRMS is described in
  [I-D.ietf-spring-segment-routing-ldp-interop].

As draff-ietf-spring-segment-routing-ldp-interop needs to be read in order to understand what SR Mapping Server is, this reference must also be Normative.

  SRMS preference is defined in [I-D.ietf-spring-conflict-resolution].

This just confirms that this reference must be Normative.

2) In Section 3.1:

  When multiple SR-Algorithm TLVs are received from a given router, the
  receiver SHOULD use the first occurrence of the TLV in the Router
  Information LSA.  If the SR-Algorithm TLV appears in multiple Router
  Information LSAs that have different flooding scopes, the SR-
  Algorithm TLV in the Router Information LSA with the area-scoped
  flooding scope SHOULD be used.  If the SR-Algorithm TLV appears in
  multiple Router Information LSAs that have the same flooding scope,
  the SR-Algorithm TLV in the Router Information (RI) LSA with the
  numerically smallest Instance ID SHOULD be used and subsequent
  instances of the SR-Algorithm TLV SHOULD be ignored.

In the last 2 sentences: why are you using SHOULD (twice) instead of MUST? This seems to affect interoperability.

(I think there is similar text in another section.)

[Ballot comment]
Several TLVs have "Reserved" fields, yet you never explain what "Reserved" means. You do explain what reserved flags mean in some of them. I suggest either explicitly explaining what Reserved means in each case or specify this in the terminology section near the beginning of the document.

The document never specifies byte order for length fields.

The acronym NSSA is never explained and it has no reference.

Request for posting confirmation emailed to previous authors: Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi , Rob Shakir

Request for posting confirmation emailed to previous authors: Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi , Rob Shakir

This is waiting to progress at the same telechat as the related SPRING documents.
Ideally, the associated isis draft would also be ready to progress then.

Request for posting confirmation emailed to previous authors: Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi , Rob Shakir

Request for posting confirmation emailed to previous authors: Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi , Rob Shakir

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

The IANA Services Operator has completed its review of draft-ietf-ospf-segment-routing-extensions-19. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

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

First, in the OSPF Router Information (RI) TLVs registry on the Open Shortest Path First (OSPF) Parameters registry page located at

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

The temporary registration for value 8, SR-Algorithm TLV, will be made permanent and its reference changed to [ RFC-to-be ].

The temporary registration for value 9, SID/Label Range TLV, will be made permanent and its reference changed to [ RFC-to-be ].

IANA Question --> is any action to be taken with the temporary registration for value 12, Node MSD TLV?

Two additional registrations are to be made as follows

Value: [ TBD-at-registration ]
TLV Name: SR Local Block TLV
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
TLV Name: SRMS Preference TLV
Reference: [ RFC-to-be ]

We note that the authors suggest values 12 and 13 for these two registrations, however 12 is already allocated via a temporary registration (see above).

Second,in theOSPFv2 Extended Prefix Opaque LSA TLVs registry on the Open Shortest Path First v2 (OSPFv2) Parameters registry page located at:

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

the temporary registration for value 2, OSPF Extended Prefix Range TLV, will be made permanent and its reference will be changed to [ RFC-to-be ].

Third, in the OSPFv2 Extended Prefix TLV Sub-TLVs also on the Open Shortest Path First v2 (OSPFv2) Parameters registry page located at:

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

The temporary registration for value 1, SID/Label Sub-TLV, will be made permanent and its reference will be changed to [ RFC-to-be ].

The temporary registration for value 2, Prefix SID Sub-TLV, will be made permanent and its reference will be changed to [ RFC-to-be ].

IANA Question --> is any action to be taken for the temporary registrations for values 3, 4, 5, 6, 7 adn 8 in this registry?

Fourth, in the OSPFv2 Extended Link TLV Sub-TLVs registry also on the Open Shortest Path First v2 (OSPFv2) Parameters registry page located at:

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

the following temporary registrations will be made permanent and their references changed to [ RFC-to-be ] as follows:

Value: 1
Description: SID/Label Sub-TLV
Reference: [ RFC-to-be ]

Value: 2
Description: Adj-SID Sub-TLV
Reference: [ RFC-to-be ]

Value: 3
Description: LAN Adj-SID/Label Sub-TLV
Reference: [ RFC-to-be ]

The IANA Services Operator understands that these four actions are the only ones 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 only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-10-13):

From: The IESG
To: IETF-Announce
CC: akatlas@gmail.com, draft-ietf-ospf-segment-routing-extensions@ietf.org, ospf@ietf.org, Acee Lindem , acee@cisco.com, ospf-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (OSPF Extensions for Segment Routing) to Proposed Standard


The IESG has received a request from the Open Shortest Path First IGP WG
(ospf) to consider the following document: - 'OSPF Extensions for Segment
Routing'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-10-13. 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


  Segment Routing (SR) allows a flexible definition of end-to-end paths
  within IGP topologies by encoding paths as sequences of topological
  sub-paths, called "segments".  These segments are advertised by the
  link-state routing protocols (IS-IS and OSPF).

  This draft describes the OSPF extensions required for Segment
  Routing.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2808/
  https://datatracker.ietf.org/ipr/2233/
  https://datatracker.ietf.org/ipr/2401/

Still discussing the edge conditions for the SRMS mapping where the OSPF document
special cases detecting that the prefix is announced by a downstream neighbor and therefore
does PHP in the forwarding plane.  The reasoning behind this isn't covered in
draft-ietf-spring-ldp-interop-08 nor in this draft.

Request for posting confirmation emailed to previous authors: Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi , Rob Shakir

1) In Sec 3.1, "If the SR-Algorithm TLV appears in multiple Router
  Information LSAs that have different flooding scopes, the SR-
  Algorithm TLV in the Router Information LSA with the narrowest
  flooding scope SHOULD be used.  "
  Given that the area-scope is REQUIRED - shouldn't this also prefer
  the area-scope?  Is there future-proofing being done?

2) In Sec 3.4: "For the purpose of the SRMS Preference TLV advertisement, AS-scoped flooding is REQUIRED.  This
  is because SRMS servers can be located in a different area then
  consumers of the SRMS advertisements.  If the SRMS advertisements
  from the SRMS server are only used inside the SRMS server's area,
  area-scoped flooding may be used."

REQUIRED is like MUST - I think you mean "AS-scoped flooded SHOULD be used.... area-scoped flooding MAY be used."

3) In Sec 4. "The Segment Routing Mapping Server, which is described in
  [I-D.ietf-spring-segment-routing-ldp-interop], is an example where we
  need a single advertisement to advertise SIDs for multiple prefixes
  from a contiguous address range."

I've read through the vastly improved section (thank you) in draft-ietf-spring-segment-routing-ldp-interop-08 and I don't see any explanation for why a contiguous address range is needed.

I can speculate that a primary purpose is to advertise SIDs for the loopback addresses of routers that don't support SR - and those loopback addresses are likely to be allocated from a contiguous range (though why some wouldn't be supporting SR and cause gaps isn't clear).

4) Sec 5: In the end of Sec 4.2 in draft-ietf-spring-segment-routing-ldp-interop-08, it says "Note: SR mappings advertisements cannot set Penultimate Hop Popping.
  In the previous example, P6 requires the presence of the segment 103
  such as to map it to the LDP label 1037.  For that reason, the P flag
  available in the Prefix-SID is not available in the Remote-Binding
  SID."
However, in this draft Sec 5 gives the following rules:

"As the Mapping Server does not specify the originator of a prefix advertisement, it is not possible to determine PHP behavior solely based on the Mapping Server advertisement. However, PHP behavior SHOULD be done in following cases: The Prefix is intra-area type and the downstream neighbor is the originator of the prefix. The Prefix is inter-area type and downstream neighbor is an ABR, which is advertising prefix reachability and is also generating the Extended Prefix TLV with the A-flag set for this prefix as described in section 2.1 of [RFC7684]. The Prefix is external type and downstream neighbor is an ASBR, which is advertising prefix reachability and is also generating the Extended Prefix TLV with the A-flag set for this prefix as described in section 2.1 of [RFC7684].

These seem to be contradictory.

5) In Sec 7.1, it says "Multiple Mapping Servers can advertise
  Prefix-SIDs for the same prefix, in which case the same Prefix-SID
  MUST be advertised by all of them."

What is forcing this constraint?  Does it work if the Prefix-SID is an index into an
SRGB or SRLB that is not the same value globally? I don't see it specified in Sec 7.2 of draft-ietf-spring-segment-routing-ldp-interop-08?

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

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up.  Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the following
    sections:

Technical Summary:
   
    This document describes the OSPFv2 extensions for segment routing
    including Prefix-SID, Adjacency-SID, and Binding-SID. The extensions
    are based on RFC 7770. 

Working Group Summary:
 
    The Working Group discussion has been dominated by the initial vendors
    that implemented the specification (Juniper, Cisco, and Nokia). We've
    gone through several iterations over the last two and half years.

    The document has completed two separate IPR polls. It is in its second
    Working Group last call due to some additional protocol encodings and
    clarifications on the handling of error situations. The second Working
    Group last call is preceding without questions or significant comments.

  The ERO and binding-SID extensions were removed due to AD comments
  and these changes were Working Group last called.

     
Document Quality:

      The document has been implemented by a number of vendors (refer to
      the implementation status section) and has been stable now for a few
      months. In fact, the only changes have been edits and clarifications
      based on WG last-call and chair review.

Personnel:

      Acee Lindem is the Document Shepherd.
      Alia Atlas is 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.

    The document shepherd has reviewed each revision of the document
    and followed the discussion on the OSPF mailing list.


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

      No.

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

      No.

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

      None.

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

    Yes.

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

      Yes - there is an IPR disclosure on non-WG version and two more
      on the WG version of the document. The terms are such that
      the patent will not be asserted unless the party asserts a patent
      against the holder (forget the term for this).

      https://datatracker.ietf.org/ipr/2233/
      https://datatracker.ietf.org/ipr/2401/
      https://datatracker.ietf.org/ipr/2808/

      There have been three polls for knowledge of IPR with all authors
      responding.


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

      There is consensus from the WG and others outside the WG that
      this document can progress.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      No.

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Nits are all resolved.  There are 7 comments from Idnits bug
      none of them are indicative of issues in the draft. For example,
      IPv6 examples are suggested but OSPFv2 only supports IPv4.
 
      The document does have seven authors. All the authors have
      played in active role in the development of the standard including
      periodic segment routing design team meetings.  All of the authors
      have responded promptly to IPR polls. At least three of the
      authors represented independent implementations. Here are their
      roles and responsibilities:

      Peter Psenak - Main document editor and OSPFv2 segment routing
                                encoding point-of-contact.
      Stefano Previdi - Main document editor for IS-IS segment routing
                                and active participant in all discussions and design
                                meetings.
      Clarence Filsfils - Segment routing design team lead and orgainization
                                        of discussions.
        Hannes Gredler - Member of OSPFv2 segment routing design team,
                                        author or merged draft, and representative of
                                        Juniper implementation.
        Rob Shakir - Member of OSPFv2 segment routing design team.
                                Representative of operator's perspective.
        Wim Henderick - Member of OSPFv2 segment routing design team.
                                        Active participation in discussions and representative
                                        of Nokia's implementation.
        Jeff Tantsura - Member of OSPFv2 segment routing design team.
                                    Active participation in discussions and representative
                                    of Ericsson's implementation.
       
       
(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type reviews.

      Not applicable.

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

      Yes.

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

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

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

      No.

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

    The Segment Routing extensions required allocation of a number of
    code points from the registries created for RFC 7770. These code
    points were pre-allocated through IANA early allocation as
    described in RFC 7120.

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

      None.

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

      Not applicable.

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

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up.  Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the following
    sections:

Technical Summary:
   
    This document describes the OSPFv2 extensions for segment routing
    including Prefix-SID, Adjacency-SID, and Binding-SID. The extensions
    are based on RFC 7770. 

Working Group Summary:
 
    The Working Group discussion has been dominated by the initial vendors
    that implemented the specification (Juniper, Cisco, and Nokia). We've
    gone through several iterations over the last two and half years.

    The document has completed two separate IPR polls. It is in its second
    Working Group last call due to some additional protocol encodings and
    clarifications on the handling of error situations. The second Working
    Group last call is preceding without questions or significant comments.

  The ERO and binding-SID extensions were removed due to AD comments
  and these changes were Working Group last called.

     
Document Quality:

      The document has been implemented by a number of vendors (refer to
      the implementation status section) and has been stable now for a few
      months. In fact, the only changes have been edits and clarifications
      based on WG last-call and chair review.

Personnel:

      Acee Lindem is the Document Shepherd.
      Alia Atlas is 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.

    The document shepherd has reviewed each revision of the document
    and followed the discussion on the OSPF mailing list.


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

      No.

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

      No.

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

      None.

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

    Yes.

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

      Yes - there is an IPR disclosure on non-WG version and two more
      on the WG version of the document. The terms are such that
      the patent will not be asserted unless the party asserts a patent
      against the holder (forget the term for this).

      https://datatracker.ietf.org/ipr/2233/
      https://datatracker.ietf.org/ipr/2401/
      https://datatracker.ietf.org/ipr/2808/

      There have been three polls for knowledge of IPR with all authors
      responding.


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

      There is consensus from the WG and others outside the WG that
      this document can progress.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      No.

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Nits are all resolved.  There are 7 comments from Idnits bug
      none of them are indicative of issues in the draft. For example,
      IPv6 examples are suggested but OSPFv2 only supports IPv4.
 
      The document does have seven authors. All the authors have
      played in active role in the development of the standard including
      periodic segment routing design team meetings.  All of the authors
      have responded promptly to IPR polls. At least three of the
      authors represented independent implementations. Here are their
      roles and responsibilities:

      Peter Psenak - Main document editor and OSPFv2 segment routing
                                encoding point-of-contact.
      Stefano Previdi - Main document editor for IS-IS segment routing
                                and active participant in all discussions and design
                                meetings.
      Clarence Filsfils - Segment routing design team lead and orgainization
                                        of discussions.
        Hannes Gredler - Member of OSPFv2 segment routing design team,
                                        author or merged draft, and representative of
                                        Juniper implementation.
        Rob Shakir - Member of OSPFv2 segment routing design team.
                                Representative of operator perspective.
        Wim Henderick - Member of OSPFv2 segment routing design team.
                                        Active participation in discussions and representative
                                        of Nokia's implementation.
        Jeff Tantsura - Member of OSPFv2 segment routing design team.
                                    Active participation in discussions and representative
                                    of Ericsson's implementation.
       
       
(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type reviews.

      Not applicable.

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

      Yes.

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

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

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

      No.

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

    The Segment Routing extensions required allocation of a number of
    code points from the registries created for RFC 7770. These code
    points were pre-allocated through IANA early allocation as
    described in RFC 7120.

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

      None.

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

      Not applicable.

Request for posting confirmation emailed to previous authors: Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi , Rob Shakir

Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , ospf-chairs@ietf.org, Rob Shakir

As is customary, I have done my AD review of draft-ietf-ospf-segment-routing-extensions-16 once publication has been requested.  First, I would like to thank the editors & many authors, Peter, Stefano, Clarence, Hannes, Rob, Wim & Jeff, for the work that they have put in so far and the remaining work that is greatly needed.

While there are a great many issues to be handled, they fall primarily into three categories.  The first is simply not going through and tightening up the details; for example, stating that the length of a TLV is variable provides no meaning.  The second is that the technical documents from SPRING that this draft depends on do not adequately describe the use of the advertised information (SID/Label Binding TLV) or some of the concepts (e.g. SR Mapping Server).  The third is a more common set of handling error cases and adding clarity to the intended behavior.  I do not see issues with the encodings but I do see fragility with the unstated assumptions and behaviors.  The draft describes encodings, but very little of the handling, behaviors, or meaning - and the references do not provide adequate detail.

I have spent all day (and evening) doing this review and I am quite disappointed and concerned about the document.  I would strongly recommend having sharing the next WGLC with the SPRING working group; perhaps more eyes will help with the discrepancies.

I have not yet decided what to do about the "early" IANA allocation - which has now existed for this draft for 3 years.  I do know that there are implementations,
but I am currently seeing the failure of this work to successfully complete as an example of an issue with providing early allocations. 

MAJOR ISSUES:

1) This draft has 7 authors.  The limit for authors & editors is 5, as is clearly stated in RFC 7322 Sec 4.1.1 and has been the case for well over a decade, unless there are extraordinary circumstances.  Is there a reason to not simply list the active editor and move the others to contributors?  One of the authors is already listed there.  I regret that failure to deal earlier with this long-standing IETF policy will be delaying progressing the draft.

2) This expired individual draft(draft-minto-rsvp-lsp-egress-fast-protection-03) is listed as Informative - but IS ACTUALLY NORMATIVE since it DEFINES the
"M-bit - When the bit is set, the binding represents a mirroring context as defined in [I-D.minto-rsvp-lsp-egress-fast-protection]."  Unfortunately, when I look there for the definition of a mirroring context, it doesn't exists.

3) The following Informative references expired several years ago and - being individual drafts - do not appear to convey the SPRING or TEAS WG consensus.
  a)  draft-filsfils-spring-segment-routing-ldp-interop-03 was replaced with draft-ietf-spring-segment-routing-ldp-interop-07 and there are considerable differences.
  b) It is unclear what happened to draft-filsfils-spring-segment-routing-use-cases-01, but I do not see any successor - or reason for this individual draft to explain the OSPFv2 extensions more than work from the SPRING WG.

4) Sec 3.3: Is it ok to advertise an SRLB TLV without advertising the SR-Algorithm TLV?  What is the expected behavior and assumptions by the receiver?

5) Sec 3.4:  What happens if an SRMS Preference TLV is advertised without an SR-Algorithm TLV in the same scope?  I see that it says "For the purpose of the SRMS Preference Sub-TLV advertisement, AS scope flooding is required." but also provides for area scope flooding.  Some words clarifying the expected behavior would be useful.

6) Sec 5: "In such case, MPLS EXP bits of the Prefix-SID are not preserved for
the final destination (the Prefix-SID being removed)."  I am quite startled to see an assumption that MPLS Pipe mode is being forced as part of specifying PHP mode!  This will also break any ECN or 3-color marking that has affected the MPLS EXP bits.  I would like to see and understand a clear justification for why short-pipe mode is being required instead of Uniform (or up to implementation/configuration.).  Basically, this sentence means that transport considerations are a necessary section - which is completely inappropriate in an IGP draft.

7) Sec 6: This section defines the SID/Label Binding sub-TLV - which appears to be a way to advertise an explicit path - and has a SID/Label by which the path can be entered.  How and what state is set up by the sending router to create the indicated segment is completely unclear.  I have hunted through draft-ietf-spring-segment-routing, draft-ietf-spring-segment-routing-mpls, and draft-ietf-spring-segment-routing-ldp-interop, RFC7855, and draft-ietf-isis-segment-routing-extensions.  As far as I can tell, NONE of them clearly describe the details of where and why this advertising is needed.  Obviously, this mechanism does allow the potential shortening of the MPLS label stack at the cost of advertising multi-hop explicit path segments across the entire area or AS.  There MUST be a normative description of what the sending router will do when a packet is received with the specified label. 

8) Sec 4: "The Segment Routing Mapping Server, which is described in [I-D.filsfils-spring-segment-routing-ldp-interop]"  Where precisely is an SRMS and its behavior/role actually defined?  draft-ietf-spring-segment-routing-ldp-interop-07 claims:"SR to LDP interworking requires a SRMS as defined in [I-D.ietf-isis-segment-routing-extensions]." but that wouldn't be appropriate, of course, and it isn't there either!  draft-ietf-spring-conflict-resolution-04 talks about SRMS, but doesn't define it.  draft-ietf-spring-segment-routing-11 mentions in Sec 3.5.1 that "A Remote-Binding SID S advertised by the mapping server M" and refers to the ldp-interop draft for further details - but obviously not about an SRMS.

Minor Issues:

1) In Sec 3.1, it says: "The SR-Algorithm TLV is optional. It MUST only be advertised once in the Router Information Opaque LSA.  If the SID/Label Range TLV, as defined in Section 3.2, is advertised, then the SR-Algorithm TLV MUST
also be advertised."  Please provide a pointer in the text to the behavior for a receiving router if one or both of these are violated?  For the requirement to advertise the SR-Algorithm TLV, please clarify that this is in the same RI LSA as the SID/Label Range TLV was advertised & with the same scope.  What does it mean, in terms of the receiving router, to determine that the sending router supports SR or not - given the possibility of receiving other SR-related TLVS in an RI LSA without getting an SR-Algorithm TLV?

2) Sec 3.1: The SR-Algorithm TLV simply defines "Length: Variable".  Given that advertising Algorithm 0 is required, I'm fairly sure that the Length has to be a minimum of 1 - and, to prevent overrun & weird issues, let's have a reasonable maximum (for instance, 24) too.  It wouldn't hurt to remind readers that the length is just that of the value field - though experienced OSPF implementers will know that.

3) Sec 3.1 & Sec 3.2 & Sec 3.3: "For the purpose of SR-Algorithm TLV advertisement, area scope flooding is required." and "For the purpose of SID/Label Range TLV advertisement, area scope flooding is required."  and "For the purpose of SR Local Block Sub-TLV TLV advertisement, area scope flooding is required." Please capitalize REQUIRED as per RFC 2119.  Otherwise, please explain behavior when area scope isn't used.

4) Sec 3.2:  The SID/Label Range TLV doesn't indicate that include a SID/Label sub-TLV is required - but I don't understand how it could be interpreted otherwise; nor does it indicate what to do if there are multiple SID/Label sub-TLVs included in a single SID/Label Range TLV. Again "Length" is just defined as variable.  In this case, it clearly can't be less than 11 (probably 12, assuming padding to the 32-bit boundary).  It would be useful to have an upper-bound on length, but at least here I can see the argument that meaningful flexibility is provided for.

5) SID index is used without introduction in Sec 3.2.  It isn't defined in the terminology of draft-ietf-spring-segment-routing-11 and the other uses of it in this document aren't enough to clearly define it.  Please add at least a description of its meaning before use - in a terminology section, if necessary.

6) Sec 3.2: "The originating router advertises the following ranges:
        Range 1: [100, 199]
        Range 2: [1000, 1099]
        Range 3: [500, 599]"
Please turn this into the information actually advertised - i.e.
  Range 1: Range Size: 100  SID/Label sub-TLV: 100  => meaning [100, 199]
etc. 

7) 3.2. SID/Label Range TLV:  Please specify that the sender MUST NOT advertise overlapping ranges & how to handle the case when it does.  This is required by draft-ietf-spring-conflict-resolution.

8) Sec 3.3  SR Local Block (SRLB) Sub-TLV: The document doesn't specify that the SR Local Block TLV MUST include a SID/Label sub-TLV nor indicate what to do if multiple are included.  The Length, again, isn't specified at all and clearly has at least a minimum.  I don't see a reference to an SR Local Block or the need to advertise it in draft-ietf-spring-segment-routing-11; perhaps I missed where the requirement and usage are defined?

9) Sec 3.3: "Each time a SID from the SRLB is allocated, it SHOULD also be
  reported to all components..."  Presumably, this is subjected to the normal OSPF dampening - it'd be nice to note that somewhere - since rapid sequential allocation may not provide the reporting speed anticipated.

10) Sec 4: "AF: Address family for the prefix. Currently, the only supported
      value is 0 for IPv4 unicast.  The inclusion of address family in
      this TLV allows for future extension."  Could you please clarify if this is to reuse the same TLV for OSPFv3 so IPv6 can be supported, are you thinking of extending OSPFv2 for IPv6 prefixes for some cases or something else? I think the current phrasing is likely to raise questions.  Similarly, please define "Prefix length: Length of the prefix" clearly.  I really don't understand what the benefit of having a TLV that pretends to support multiple AFs but can't is versus the clarity of specifying the prefix lengths.

11) Sec 4:  Again "Length: Variable" - It should have a minimum and preferable describe a function for how it is computed.  A maximum is probably unlikely  with sub-TLVs.

12) Sec 4: OSPF Extended Prefix Range TLV:  Does this TLV has any meaning or action associated with it without including sub-TLVs?  Are there mandatory sub-TLVs?  What is a receiving router to do with it?

13) Sec 5: "If multiple Prefix-SIDs are advertised for the same prefix, the
  receiving router MUST use the first encoded SID and MAY use
  subsequent SIDs."  What does this even mean?  A receiving router when making the decision to use a subsequent SID is making a decision to not use the first encoded SID; it's not like the router is going to stick both SID/Labels onto the stack.  Please describe this in meaningful normative terms.

14) Sec 5:" When calculating the outgoing label for the prefix, the router MUST
  take into account the E and P flags advertised by the next-hop router
  if that router advertised the SID for the prefix.  This MUST be done
  regardless of whether the next-hop router contributes to the best
  path to the prefix."  First, I assume this is "NP flag" because there is no P flag.
  Second - please clarify to "take into account, as described below, the E and NP flags...".  Third, the M flag must also be taken into account - given the text later in the section.

15) Sec 5: "When a Prefix-SID is advertised in an Extended Prefix Range TLV, then the value advertised in the Prefix SID Sub-TLV is interpreted as a
  starting SID value."  This appears to contradict "SID/Index/Label: According to the V and L flags, it contains either:

        A 32-bit index defining the offset in the SID/Label space
        advertised by this router.

        A 24-bit label where the 20 rightmost bits are used for
        encoding the label value."
  I assume that what is meant by the first quote is "...is interpreted, if the V flag is clear, as a starting SID value, and if the V flag is set, as a starting Label value."  Otherwise, it looks like the Prefix-SID sub-TLV couldn't be included in the Extended Prefix Range TLV if a label value would be used.

It would be helpful for Example 2 to show the label case.

16) Sec 6.1: "aggregate IGP or TE path cost."  Given that this is an OSPF draft, it'd be helpful to indicate whether there are challenges with non-comparable OSPF metrics (I'm thinking about AS-external type 2 costs) or if the path will never include such costs. 

17) Sec 6.2: "a domain and hence need to be disambiguated using a domain-unique Router-ID."  Given that the Prefix-SIDs and sub-TLVs can be distributed between areas and even redistributed between protocols, please clearly define what is meant by a "domain" or point to the appropriate definition.

18) Sec 4, 5, 6:  Is it possible to have an OSPF Extended Prefix Range TLV that includes both a Prefix SID Sub-TLV and a SID/Label Binding Sub-TLV?  What does that mean?

What does it mean if there are multiple prefixes described in the OSPF Extended Prefix Range TLV that includes a SID/Label Binding Sub-TLV?  Does the SID/Label sub-sub-TLV indicate a single SID Index or Label that is used for the single path to all those prefixes?  Is it the start of a list of SID Indices or Labels?
I see that the SID/Label Binding sub-TLV can be in both the OSPF Extended Prefx Range TLV as well as the OSPF Extended Prefix TLV - but there is no text on differences in interpretation.

19) Sec 7.1 & 7.2: Another  couple "Length: Variable."  Please actually specify the value. I think that, given the padding to 32-bit alignment, there is a single correct value.

20) Sec 7.1 and 7.2: Given that the Flag bits have exactly the same meaning - it'd be clearer to have them defined once.

21) Sec 8.1: "An SR Mapping Server MUST use the OSPF Extended Prefix Range TLV when advertising SIDs for prefixes.  Prefixes of different route-types can be combined in a single OSPF Extended Prefix Range TLV advertised by an SR Mapping Server."    So - I can't find a normative definition of an SRMS to determine why it is always necessary to use an OSPF Extended Prefix Range TLV instead of an OSPF Extended Prefix TLV.  I don't see how advertising prefixes from different route-types can work unless the prefixes are adjacent, which seems likely to be uncommon.  Perhaps what is meant is "Because the OSPF Extended Prefix Range TLV doesn't include a Route-Type field, as in the OSPF Extended Prefix TLV, it is possible to include adjacent prefixes from different Route-Types in the OSPF Extended Prefix Range TLV."

22) Sec 8.1: "If multiple routers advertise a Prefix-SID for the same prefix, then
the Prefix-SID MUST be the same.  This is required in order to allow traffic load-balancing when multiple equal cost paths to the destination exist in the OSPFv2 routing domain."  How is this enforced?  What are the consequences of it not being conformed to?  This is NOT a protocol implementation requirement.  This should really be called out in a Manageability Considerations with warnings.

23) Sec 8.2:"If no Prefix-SID was advertised for the prefix in the source area
      by the router that contributes to the best path to the prefix, the
      originating ABR will use the Prefix-SID advertised by any other
      router when propagating the Prefix-SID for the prefix to other
      areas."  I believe that this depends on the assumption that if a Prefix-SID is advertised by any router, the Prefix-SID will be the same.  Please be explicit in this assumption, since the requirement on the network operator should be clear as well as the consequences of not conforming.

24) Sec 10:  The Implementation Status section should indicate that it is to be removed before publication as an RFC.  Also, the complete implementation part seems a bit dated - given the draft's technical changes in the last 2 years.


NITS:

1) Sec 2.1: s/"SID/Label TLV"/"SID/Label sub-TLV"

2) Sec 3.2:"Initially, the only supported Sub-TLV is the SID/Label TLV as defined
  in Section 2.1.  The SID/Label advertised in the SID/Label TLV
  represents the first SID/Label in the advertised range."
  replace SID/Label TLV with SID/Label sub-TLV.

3) Sec 3.3 & Sec 3.4: " The SR Local Block (SRLB) Sub-TLV is a top-level TLV of the Router Information Opaque LSA (defined in [RFC7770])."  Please correct the descriptions (many) to SR Local Block (SRLB) Sub-TLV to SR Local Block SRLB TLV.  The same issue exists for "SRMS Preference Sub-TLV".

Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Rob Shakir

Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Rob Shakir

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

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up.  Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the following
    sections:

Technical Summary:
   
    This document describes the OSPFv2 extensions for segment routing
    including Prefix-SID, Adjacency-SID, and Binding-SID. The extensions
    are based on RFC 7770. 

Working Group Summary:
 
    The Working Group discussion has been dominated by the initial vendors
    that implemented the specification (Juniper, Cisco, and Nokia). We've
    gone through several iterations over the last two and half years.

    The document has completed two separate IPR polls. It is in its second
    Working Group last call due to some additional protocol encodings and
    clarifications on the handling of error situations. The second Working
    Group last call is preceding without questions or significant comments.
     
Document Quality:

      The document has been implemented by a number of vendors (refer to
      the implementation status section) and has been stable now for a few
      months. In fact, the only changes have been edits and clarifications
      based on WG last-call and chair review.

Personnel:

      Acee Lindem is the Document Shepherd.
      Alia Atlas is 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.

    The document shepherd has reviewed each revision of the document
    and followed the discussion on the OSPF mailing list.


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

      No.

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

      No.

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

      None.

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

    Yes.

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

      Yes - there is an IPR disclosure on non-WG version and two more
      on the WG version of the document. The terms are such that
      the patent will not be asserted unless the party asserts a patent
      against the holder (forget the term for this).

      https://datatracker.ietf.org/ipr/2233/
      https://datatracker.ietf.org/ipr/2401/
      https://datatracker.ietf.org/ipr/2808/

      There have been three polls for knowledge of IPR with all authors
      responding.


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

      There is consensus from the WG and others outside the WG that
      this document can progress.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      No.

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Nits are all resolved.  There are 7 comments from Idnits bug
      none of them are indicative of issues in the draft. For example,
      IPv6 examples are suggested but OSPFv2 only supports IPv4.
 
      The document does have seven authors. All the authors have
      played in active role in the development of the standard including
      periodic segment routing design team meetings.  All of the authors
      have responded promptly to IPR polls. At least three of the
      authors represented independent implementations. There is
      absolutely no reason to relegate any of them to contributor status.

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

      Not applicable.

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

      Yes.

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

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

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

      No.

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

    The Segment Routing extensions required allocation of a number of
    code points from the registries created for RFC 7770. These code
    points were pre-allocated through IANA early allocation as
    described in RFC 7120.

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

      None.

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

      Not applicable.

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

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up.  Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the following
    sections:

Technical Summary:
   
    This document describes the OSPFv2 extensions for segment routing
    including Prefix-SID, Adjacency-SID, and Binding-SID. The extensions
    are based on RFC 7770. 

Working Group Summary:
 
    The Working Group discussion has been dominated by the initial vendors
    that implemented the specification (Juniper, Cisco, and Nokia). We've
    gone through several iterations over the last two and half years.

    The document has completed two separate IPR polls. It is in its second
    Working Group last call due to some additional protocol encodings and
    clarifications on the handling of error situations. The second Working
    Group last call is preceding without questions or significant comments.
     
Document Quality:

      The document has been implemented by a number of vendors (refer to
      the implementation status section) and has been stable now for a few
      months. In fact, the only changes have been edits and clarifications
      based on WG last-call and chair review.

Personnel:

      Acee Lindem is the Document Shepherd.
      Alia Atlas is 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.

    The document shepherd has reviewed each revision of the document
    and followed the discussion on the OSPF mailing list.


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

      No.

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

      No.

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

      None.

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

    Yes.

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

      Yes - there is an IPR disclosure on non-WG version and two more
      on the WG version of the document. The terms are such that
      the patent will not be asserted unless the party asserts a patent
      against the holder (forget the term for this).

      https://datatracker.ietf.org/ipr/2233/
      https://datatracker.ietf.org/ipr/2401/
      https://datatracker.ietf.org/ipr/2808/

      There have been three polls for knowledge of IPR with all authors
      responding.


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

      There is consensus from the WG and others outside the WG that
      this document can progress.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      No.

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Nits are all resolved. 
 
      The document does have seven authors. All the authors have
      played in active role in the development of the standard including
      periodic segment routing design team meetings.  All of the authors
      have responded promptly to IPR polls. At least three of the
      authors represented independent implementations. There is
      absolutely no reason to relegate any of them to contributor status.

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

      Not applicable.

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

      Yes.

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

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

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

      No.

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

    The Segment Routing extensions required allocation of a number of
    code points from the registries created for RFC 7770. These code
    points were pre-allocated through IANA early allocation as
    described in RFC 7120.

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

      None.

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

      Not applicable.

Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Rob Shakir

Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Rob Shakir

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

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up.  Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the following
    sections:

Technical Summary:
   
    This document describes the OSPFv2 extensions for segment routing
    including Prefix-SID, Adjacency-SID, and Binding-SID. The extensions
    are based on RFC 7770. 

Working Group Summary:
 
    The Working Group discussion has been dominated by the initial vendors
    that implemented the specification (Juniper, Cisco, and Nokia). We've
    gone through several iterations over the last two and half years.

    The document has completed two separate IPR polls. It is in its second
    Working Group last call due to some additional protocol encodings and
    clarifications on the handling of error situations. The second Working
    Group last call is preceding without questions or significant comments.
     
Document Quality:

      The document has been implemented by a number of vendors (refer to
      the implementation status section) and has been stable now for a few
      months. In fact, the only changes have been edits and clarifications
      based on WG last-call and chair review.

Personnel:

      Acee Lindem is the Document Shepherd.
      Alia Atlas is 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.

    The document shepherd has reviewed each revision of the document
    and followed the discussion on the OSPF mailing list.


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

      No.

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

      No.

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

      None.

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

    Yes.

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

      Yes - there is an IPR disclosure on non-WG version and two more
      on the WG version of the document. The terms are such that
      the patent will not be asserted unless the party asserts a patent
      against the holder (forget the term for this).

      https://datatracker.ietf.org/ipr/2233/
      https://datatracker.ietf.org/ipr/2401/
      https://datatracker.ietf.org/ipr/2808/

      There have been three polls for knowledge of IPR with all authors
      responding.


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

      There is consensus from the WG and others outside the WG that
      this document can progress.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      No.

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Nits are all resolved. 
 
      The document does have seven authors. All the authors have
      played in active role in the development of the standard including
      periodic segment routing design team meetings.  All of the authors
      have responded promptly to IPR polls. At least three of the
      authors represented independent implementations. There is
      absolutely no reason to relegate any of them to contributor status.

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

      Not applicable.

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

      Yes.

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

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

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

      No.

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

    The Segment Routing extensions required allocation of a number of
    code points from the registries created for RFC 7770. These code
    points were pre-allocated through IANA early allocation as
    described in RFC 7120.

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

      None.

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

      Not applicable.

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

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up.  Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the following
    sections:

Technical Summary:
   
    This document describes the OSPFv2 extensions for segment routing
    including Prefix-SID, Adjacency-SID, and Binding-SID. The extensions
    are based on RFC 7770. 

Working Group Summary:
 
    The Working Group discussion has been dominated by the initial vendors
    that implemented the specification (Juniper, Cisco, and Nokia). We've
    gone through several iterations over the last two and half years.

    The document has completed two separate IPR polls. It is in its second
    Working Group last call due to some additional protocol encodings and
    clarifications on the handling of error situations. The second Working
    Group last call is preceding without questions or significant comments.
     
Document Quality:

      The document has been implemented by a number of vendors (refer to
      the implementation status section) and has been stable now for a few
      months. In fact, the only changes have been edits and clarifications
      based on WG last-call and chair review.

Personnel:

      Acee Lindem is the Document Shepherd.
      Alia Atlas is 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.

    The document shepherd has reviewed each revision of the document
    and followed the discussion on the OSPF mailing list.


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

      No.

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

      No.

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

      None.

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

    Yes.

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

      Yes - there is an IPR disclosure on non-WG version and two more
      on the WG version of the document. The terms are such that
      the patent will not be asserted unless the party asserts a patent
      against the holder (forget the term for this).

      https://datatracker.ietf.org/ipr/2233/
      https://datatracker.ietf.org/ipr/2401/
      https://datatracker.ietf.org/ipr/2808/

      There have been three polls for knowledge of IPR with all authors
      responding.


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

      There is consensus from the WG and others outside the WG that
      this document can progress.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      No.

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Nits are all resolved.

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

      Not applicable.

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

      Yes.

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

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

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

      No.

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

    The Segment Routing extensions required allocation of a number of
    code points from the registries created for RFC 7770. These code
    points were pre-allocated through IANA early allocation as
    described in RFC 7120.

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

      None.

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

      Not applicable.

Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Rob Shakir

Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Rob Shakir

Request for posting confirmation emailed to previous authors: "Jeff Tantsura" , "Rob Shakir" , "Hannes Gredler" , "Clarence Filsfils" , "Stefano Previdi" , "Peter Psenak" , ospf-chairs@ietf.org, "Wim Henderickx"

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

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up.  Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the following
    sections:

Technical Summary:
   
    This document describes the OSPFv2 extensions for segment routing
    including Prefix-SID, Adjacency-SID, and Binding-SID. The extensions
    are based on RFC 7770. 

Working Group Summary:
 
    The Working Group discussion has been dominated by the initial vendors
    that implemented the specification (Juniper, Cisco, and Nokia). We've
    gone through several iterations over the last two and half years.
     
Document Quality:

      The document has been implemented by a number of vendors (refer to
      the implementation status section) and has been stable now for a few
      months. In fact, the only changes have been edits and clarifications
      based on WG last-call and chair review.

Personnel:

      Acee Lindem is the Document Shepherd.
      Alia Atlas is 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.

    The document shepherd has reviewed each revision of the document
    and followed the discussion on the OSPF mailing list.


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

      No.

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

      No.

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

      None.

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

    Yes.

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

      Yes - there is an IPR disclosure on non-WG version and a second
      one on the WG version of the document. The terms are such that
      the patent will not be asserted unless the party asserts a patent
      against the holder (forget the term for this).

      https://datatracker.ietf.org/ipr/2233/

      There have been two polls for knowledge of IPR with all authors
      responding.


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

      There is consensus from the WG and others outside the WG that
      this document can progress.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      No.

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Nits are all resolved.

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

      Not applicable.

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

      Yes.

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

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

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

      No.

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

    The Segment Routing extensions required allocation of a number of
    code points from the registries created for RFC 7770. These code
    points were pre-allocated through IANA early allocation as
    described in RFC 7120.

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

      None.

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

      Not applicable.

New additional IPR - including a new patent application - was disclosed by Cisco, which is the affiliation of several authors,
after the authors reported that there was no undisclosed IPR  and after WGLC had completed.

At a minimum, the WG needs to have an additional WGLC - highlighting the additional IPR and determining if there is consensus
to publish.

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

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up.  Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the following
    sections:

Technical Summary:
   
    This document describes the OSPFv2 extensions for segment routing
    including Prefix-SID, Adjacency-SID, and Binding-SID. The extensions
    are based on RFC 7770. 

Working Group Summary:
 
    The Working Group discussion has been dominated by the initial vendors
    that implemented the specification (Juniper, Cisco, and Nokia). We've
    gone through several iterations over the last two and half years.
     
Document Quality:

      The document has been implemented by a number of vendors (refer to
      the implementation status section) and has been stable now for a few
      months. In fact, the only changes have been edits and clarifications
      based on WG last-call and chair review.

Personnel:

      Acee Lindem is the Document Shepherd.
      Alia Atlas is 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.

    The document shepherd has reviewed each revision of the document
    and followed the discussion on the OSPF mailing list.


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

      No.

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

      No.

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

      None.

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

    Yes.

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

      Yes - there is an IPR disclosure on non-WG version and a second
      one on the WG version of the document. The terms are such that
      the patent will not be asserted unless the party asserts a patent
      against the holder (forget the term for this).

      https://datatracker.ietf.org/ipr/2233/

      There have been two polls for knowledge of IPR with all authors
      responding.


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

      There is consensus from the WG and others outside the WG that
      this document can progress.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      No.

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Nits are all resolved.

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

      Not applicable.

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

      Yes.

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

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

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

      No.

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

    The Segment Routing extensions required allocation of a number of
    code points from the registries created for RFC 7770. These code
    points were pre-allocated through IANA early allocation as
    described in RFC 7120.

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

      None.

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

      Not applicable.

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

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up.  Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the following
    sections:

Technical Summary:
   
    This document describes the OSPFv2 extensions for segment routing
    including Prefix-SID, Adjacency-SID, and Binding-SID. The extensions
    are based on RFC 7770. 

Working Group Summary:
 
    The Working Group discussion has been dominated by the initial vendors
    that implemented the specification (Juniper, Cisco, and Nokia). We've
    gone through several iterations over the last two and half years.
     
Document Quality:

      The document has been implemented by a number of vendors (refer to
      the implementation status section) and has been stable now for a few
      months. In fact, the only changes have been edits and clarifications
      based on WG last-call and chair review.

Personnel:

      Acee Lindem is the Document Shepherd.
      Alia Atlas is 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.

    The document shepherd has reviewed each revision of the document
    and followed the discussion on the OSPF mailing list.


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

      No.

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

      No.

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

      None.

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

    Yes.

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

      Yes - there is an IPR disclosure on non-WG version and a second
      one on the WG version of the document. The terms are such that
      the patent will not be asserted unless the party asserts a patent
      against the holder (forget the term for this).

      https://datatracker.ietf.org/ipr/2233/


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

      There is consensus from the WG and others outside the WG that
      this document can progress.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      No.

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Nits are all resolved.

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

      Not applicable.

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

      Yes.

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

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

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

      No.

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

    The Segment Routing extensions required allocation of a number of
    code points from the registries created for RFC 7770. These code
    points were pre-allocated through IANA early allocation as
    described in RFC 7120.

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

      None.

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

      Not applicable.

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

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up.  Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the following
    sections:

Technical Summary:
   
    This document describes the OSPFv2 extensions for segment routing
    including Prefix-SID, Adjacency-SID, and Binding-SID. The extensions
    are based on RFC 7770. 

Working Group Summary:
 
    The Working Group discussion has been dominated by the initial vendors
    that implemented the specification (Juniper, Cisco, and Nokia). We've
    gone through several iterations over the last two and half years.
     
Document Quality:

      The document has been implemented by a number of vendors (refer to
      the implementation status section) and has been stable now for a few
      months. In fact, the only changes have been edits and clarifications
      based on WG last-call and chair review.

Personnel:

      Acee Lindem is the Document Shepherd.
      Alia Atlas is 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.

    The document shepherd has reviewed each revision of the document
    and followed the discussion on the OSPF mailing list. In fact, the
    document shepherd have provided more substantive comments and edits
    to the document than most of the authors.


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

      No.

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

      No.

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

      None.

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

    Yes.

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

      Yes - there is an IPR disclosure on non-WG version and a second
      one on the WG version of the document. The terms are such that
      the patent will not be asserted unless the party asserts a patent
      against the holder (forget the term for this).

      https://datatracker.ietf.org/ipr/2233/


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

      There is consensus from the WG and others outside the WG that
      this document can progress.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      No.

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Nits are all resolved.

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

      Not applicable.

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

      Yes.

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

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

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

      No.

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

    The Segment Routing extensions required allocation of a number of
    code points from the registries created for RFC 7770. These code
    points were pre-allocated through IANA early allocation as
    described in RFC 7120.

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

      None.

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

      Not applicable.