Skip to main content

Segment Routing Prefix Segment Identifier Extensions for BGP
draft-ietf-idr-bgp-prefix-sid-27

Revision differences

Document history

Date Rev. By Action
2019-11-18
27 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2019-10-23
27 (System) from RFC-EDITOR
2019-08-20
27 (System) RFC Editor state changed to RFC-EDITOR from REF
2019-08-19
27 Gunter Van de Velde Assignment of request for Last Call review by OPSDIR to Tianran Zhou was marked no-response
2019-07-17
27 (System) RFC Editor state changed to REF from EDIT
2019-05-28
27 (System) RFC Editor state changed to EDIT from MISSREF
2018-08-22
27 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2018-08-13
27 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2018-08-13
27 (System) IANA Action state changed to In Progress from Waiting on Authors
2018-08-13
27 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-08-13
27 (System) IANA Action state changed to In Progress from Waiting on Authors
2018-08-13
27 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-08-10
27 (System) IANA Action state changed to In Progress from Waiting on Authors
2018-08-10
27 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-08-06
27 (System) RFC Editor state changed to MISSREF
2018-08-06
27 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2018-08-06
27 (System) Announcement was received by RFC Editor
2018-08-06
27 (System) IANA Action state changed to In Progress
2018-08-06
27 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2018-08-06
27 Cindy Morgan IESG has approved the document
2018-08-06
27 Cindy Morgan Closed "Approve" ballot
2018-08-06
27 Cindy Morgan Ballot approval text was generated
2018-08-06
27 Alvaro Retana IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2018-06-26
27 Acee Lindem New version available: draft-ietf-idr-bgp-prefix-sid-27.txt
2018-06-26
27 (System) New version approved
2018-06-26
27 (System) Request for posting confirmation emailed to previous authors: Arjun Sreekantiah , Stefano Previdi , Acee Lindem , Hannes Gredler , Clarence Filsfils
2018-06-26
27 Acee Lindem Uploaded new revision
2018-06-21
26 Jean Mahoney Closed request for Telechat review by GENART with state 'Team Will not Review Version'
2018-06-21
26 Cindy Morgan IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2018-06-21
26 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2018-06-21
26 Acee Lindem New version available: draft-ietf-idr-bgp-prefix-sid-26.txt
2018-06-21
26 (System) New version approved
2018-06-21
26 (System) Request for posting confirmation emailed to previous authors: Arjun Sreekantiah , Stefano Previdi , Acee Lindem , Hannes Gredler , Clarence Filsfils
2018-06-21
26 Acee Lindem Uploaded new revision
2018-06-21
25 Adam Roach [Ballot comment]
Thanks to Alvaro for clearing up my confusion about the scope of the changes in the document.
2018-06-21
25 Adam Roach [Ballot Position Update] Position for Adam Roach has been changed to No Objection from Discuss
2018-06-21
25 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2018-06-21
25 Suresh Krishnan
2018-06-21
25 Martin Vigoureux
[Ballot comment]
Hello,

thank you for this Document.
I have few comments:

Abstract:
references to "service chain" were removed from SPRING originated documents. Should we …
[Ballot comment]
Hello,

thank you for this Document.
I have few comments:

Abstract:
references to "service chain" were removed from SPRING originated documents. Should we do the same here?

1. Introduction
It looks to me that these two definitions are not identical. Should only one be kept?
  A group of inter-connected nodes that use SR forms an SR domain.
  An SR domain is defined as a single administrative domain for global SID assignment.
On that matter, I am not sure it is worth restating a definition further down "(i.e., the set of Autonomous Systems under a common administration and control and where SR is used)"

Aren't these two sentences somehow in conflict (i.e. "always global" Vs. "MAY be global"):
  A BGP Prefix-SID is always a global SID ([I-D.ietf-spring-segment-routing]) within the SR domain
  A BGP Prefix-SID MAY be global across ASes when the interconnected ASes agree on the SID allocation scheme.
I make the assumption that "interconnected ASes" which "agree on the SID allocation scheme" form an SR domain, but I may be wrong.

s/we always refer to the BGP segment by the BGP Prefix-SID/we always refer to the BGP-Prefix segment by the BGP Prefix-SID/ ?

  A BGP Prefix-SID MAY be attached to a prefix.
Do you mean a "A Prefix-SID MAY be attached to a BGP-Prefix" or do you mean "A BGP Prefix-SID attribute MAY be attached to a BGP IPv4/IPv6 Label Unicast prefix" ?
I would say the latter but that sentence: "A BGP-Prefix Segment is a BGP prefix with a Prefix-SID attached" (found couple of paragraphs above) makes me doubt.

3.1.  Label-Index TLV
  It MUST be ignored when received for other BGP AFI/SAFI combinations.
Is that constraint needed? I am asking because in the Introduction you seem to at least allow for other AFI/SAFI to use the BGP Prefix-SID.

3.2.  Originator SRGB TLV
Same comment as above this time for the Originator SRGB TLV

s/The originator SRGB/The Originator SRGB TLV/ (twice)

7.  IANA Considerations
  This document defines 3 TLVs for the BGP Prefix-SID attribute.
I guess that's a leftover from the IPv6 years. I only see two TLVs defined.

  2    Deprecated      this document
Would it be worth to document why this is indicated as being deprecated? I understand that this was assigned to IPv6 SID TLV in earlier versions of the Document and that the Document now leaves v6 oos, but I guess it wouldn't hurt to have a couple of sentences.

Thank you
2018-06-21
25 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2018-06-20
25 Eric Rescorla [Ballot comment]
Thanks for addressing my comments.
2018-06-20
25 Eric Rescorla [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla
2018-06-20
25 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2018-06-20
25 Alissa Cooper
[Ballot comment]
Abstract:

"This document defines an optional, transitive BGP attribute for
  announcing BGP Prefix Segment Identifiers (BGP Prefix-SID)
  information the specification for …
[Ballot comment]
Abstract:

"This document defines an optional, transitive BGP attribute for
  announcing BGP Prefix Segment Identifiers (BGP Prefix-SID)
  information the specification for SR-MPLS SIDs."

This is a sentence fragment.

IANA considerations:

"Currently, IANA temporarily assigned the following:

      40 BGP Prefix-SID (TEMPORARY - registered 2015-09-30, expires
      2016-09-30) [draft-ietf-idr-bgp-prefix-sid]"

I'm not sure that this needs to stay in the document, but if it does, it shouldn't say "currently" (since that won't be true for long) and the dates should be updated to reflect the fact that the temporary registration was extended a couple of times, until 09-30-2018.
2018-06-20
25 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-06-19
25 Adam Roach
2018-06-19
25 Adam Roach [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach
2018-06-19
25 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2018-06-19
25 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2018-06-19
25 Benjamin Kaduk
[Ballot comment]
Please expand NLRI on first use.

The "MUST be present" (in BGP Prefix-SID) in Section 3.1 seems to
potentially be in conflict with …
[Ballot comment]
Please expand NLRI on first use.

The "MUST be present" (in BGP Prefix-SID) in Section 3.1 seems to
potentially be in conflict with the "are only used when SR is
applied to the MPLS dataplane" in Section 3, but it's quite possible
that I'm just missing the piece that ties things together.

Section 7

It's a little weird to mark the value 2 as "deprecated" with
reference "this document" but not have the previous usage described at
all in the final version.

Section 9

It might be nice to note the consequences of the BGP Prefix-SID
attribute's non-protection by BGPsec signatures, though thank you
for calling out the lack of coverage.
2018-06-19
25 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2018-06-19
25 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-06-18
25 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2018-06-18
25 Warren Kumari
[Ballot comment]
I'm balloting NoObjection, but I'm sad that nothing came of my previous request:

"Major(ish) issue:
Section 5.  Advertising BGP Prefix-SID Attribute
  "The …
[Ballot comment]
I'm balloting NoObjection, but I'm sad that nothing came of my previous request:

"Major(ish) issue:
Section 5.  Advertising BGP Prefix-SID Attribute
  "The BGP Prefix-SID attribute MAY be attached to labeled BGP prefixes
  (IPv4/IPv6) [RFC8277] or to IPv6 unicast prefixes [RFC4760].  In
  order to prevent distribution of the BGP Prefix-SID attribute beyond
  its intended scope of applicability, attribute filtering SHOULD be
  deployed."
Thank you for including this -- however, as I'm sure you know, the state of BGP filtering in the wild is, er, poor. Can you please provide some additional guidance? For example, could you include an appendix with examples? Or simply a bit more text on determining the scope of applicability? Apologies if I missed this, but should this by default be filtered on eBGP sessions? The included text is a great start, but some more (so people don't miss it and shoot themselves in the foot would be much appreciated.
"
2018-06-18
25 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2018-06-18
25 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2018-06-18
25 Mirja Kühlewind
[Ballot comment]
Minor, no critical comment:
I still don't really see why reserved bits and flags are needed given they are both defined the same …
[Ballot comment]
Minor, no critical comment:
I still don't really see why reserved bits and flags are needed given they are both defined the same way ("MUST be clear on transmission and MUST be ignored on reception."). Or more generally, I don't see at all why a flags field is needed given you can also just always create a new TLV...
2018-06-18
25 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2018-06-15
25 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2018-06-15
25 Acee Lindem New version available: draft-ietf-idr-bgp-prefix-sid-25.txt
2018-06-15
25 (System) New version approved
2018-06-15
25 (System) Request for posting confirmation emailed to previous authors: Arjun Sreekantiah , Stefano Previdi , Acee Lindem , Hannes Gredler , Clarence Filsfils
2018-06-15
25 Acee Lindem Uploaded new revision
2018-06-15
24 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2018-06-14
24 Jean Mahoney Request for Telechat review by GENART is assigned to Peter Yee
2018-06-14
24 Jean Mahoney Request for Telechat review by GENART is assigned to Peter Yee
2018-06-14
24 Acee Lindem New version available: draft-ietf-idr-bgp-prefix-sid-24.txt
2018-06-14
24 (System) New version approved
2018-06-14
24 (System) Request for posting confirmation emailed to previous authors: Arjun Sreekantiah , Stefano Previdi , Acee Lindem , Hannes Gredler , Clarence Filsfils
2018-06-14
24 Acee Lindem Uploaded new revision
2018-06-14
23 Cindy Morgan Telechat date has been changed to 2018-06-21 from 2018-02-08
2018-06-14
23 Cindy Morgan Ballot has been issued
2018-06-14
23 Acee Lindem New version available: draft-ietf-idr-bgp-prefix-sid-23.txt
2018-06-14
23 (System) New version approved
2018-06-14
23 (System) Request for posting confirmation emailed to previous authors: Arjun Sreekantiah , Stefano Previdi , Acee Lindem , Hannes Gredler , Clarence Filsfils
2018-06-14
23 Acee Lindem Uploaded new revision
2018-06-13
22 Bruno Decraene Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Bruno Decraene. Sent review to list.
2018-06-13
22 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2018-06-13
22 Acee Lindem New version available: draft-ietf-idr-bgp-prefix-sid-22.txt
2018-06-13
22 (System) New version approved
2018-06-13
22 (System) Request for posting confirmation emailed to previous authors: Arjun Sreekantiah , Stefano Previdi , Acee Lindem , Hannes Gredler , Clarence Filsfils
2018-06-13
22 Acee Lindem Uploaded new revision
2018-06-13
21 Peter Yee Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee. Sent review to list.
2018-06-12
21 Alvaro Retana IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2018-06-12
21 Alvaro Retana
[Ballot comment]
Note to the IESG:

This is a returning document.  It went through IESG Evaluation and was approved at the Feb 8, 2018 Telechat. …
[Ballot comment]
Note to the IESG:

This is a returning document.  It went through IESG Evaluation and was approved at the Feb 8, 2018 Telechat.

After approval (version -16 addressed any remaining Telechat comments), the authors proposed significant changes to the content of the document to remove support for the IPv6 SID due to lack of implementation and support [1].  The document went again through WG and IETF LCs.  Note that the IPv6-specific work is being addressed in a different document.

For your convenience, here are the diffs: https://www.ietf.org/rfcdiff?url1=draft-ietf-idr-bgp-prefix-sid-16&url2=draft-ietf-idr-bgp-prefix-sid-21

[1] https://mailarchive.ietf.org/arch/msg/idr/FM31nSL78B5L5yCBZB17NfLwQy4/?qid=7f0a07c88788f56211e8702176812f8e
2018-06-12
21 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2018-06-12
21 Alvaro Retana Created "Approve" ballot
2018-06-12
21 Alvaro Retana Closed "Approve" ballot
2018-06-12
21 Alvaro Retana Ballot writeup was changed
2018-06-12
21 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2018-06-11
21 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2018-06-11
21 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

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

The IANA Functions Operator has completed its review of draft-ietf-idr-bgp-prefix-sid-21. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of [ RFC-to-be ], there are four actions which we must complete.

First, in the BGP Path Attributes registry on the Border Gateway Protocol (BGP) Parameters registry page located at:

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

the BGP Path Attribute #40:

BGP Prefix-SID (TEMPORARY - registered 2015-09-30, extension registered 2017-08-31, expires 2018-09-30)

will have its temporary assignment made permanent and its reference changed from the current document to [ RFC-to-be ].

Second, a new registry is to be created called the BGP Prefix-SID TLV Types registry. The new registry will be located on the Border Gateway Protocol (BGP) Parameters registry page located at:

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

The reference for the new registry will be: [ RFC-to-be ]. The registration procedures for the new registry will be:

Values 1-254 First Come First Served
Value 0 and 255 reserved

There are initial registrations in the new registry as follows:

Value Type Reference
-----+---------------+---------------
0 Reserved [ RFC-to-be ]
1 Label-Index [ RFC-to-be ]
2 Deprecated [ RFC-to-be ]
3 Originator SRGB [ RFC-to-be ]
4-254 Unassigned
255 Reserved [ RFC-to-be ]


Third, a new registry is to be created called the BGP Prefix-SID Label-Index TLV Flags. The new registry will be located on the Border Gateway Protocol (BGP) Parameters registry page located at:

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

The refernce for the new registry will be: [ RFC-to-be ]. The registration procedures for the new registry will be: First Come First Served (FCFS).

There are no initial values for this new registry.

Fourth, a new registry will be created called the BGP Prefix-SID Originator SRGB TLV Flags registry. The new registry will be located on the Border Gateway Protocol (BGP) Parameters registry page located at:

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

The reference for the new registry will be: [ RFC-to-be ]. The registration procedures for the new registry will be: The registration procedures for the new registry will be: First Come First Served (FCFS).

There are no initial values for this new registry.

The IANA Services Operator understands that these are the only actions required to be completed upon approval of [ RFC-to-be ].

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

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2018-06-05
21 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tianran Zhou
2018-06-05
21 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tianran Zhou
2018-05-31
21 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2018-05-31
21 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2018-05-29
21 Min Ye Request for Last Call review by RTGDIR is assigned to Bruno Decraene
2018-05-29
21 Min Ye Request for Last Call review by RTGDIR is assigned to Bruno Decraene
2018-05-29
21 Amy Vezza
The following Last Call announcement was sent out (ends 2018-06-12):

From: The IESG
To: IETF-Announce
CC: idr@ietf.org, Susan Hares , idr-chairs@ietf.org, draft-ietf-idr-bgp-prefix-sid@ietf.org, …
The following Last Call announcement was sent out (ends 2018-06-12):

From: The IESG
To: IETF-Announce
CC: idr@ietf.org, Susan Hares , idr-chairs@ietf.org, draft-ietf-idr-bgp-prefix-sid@ietf.org, John Scudder , jgs@juniper.net, aretana.ietf@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Segment Routing Prefix SID extensions for BGP) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document: - 'Segment Routing Prefix SID extensions for
BGP'
  as Proposed Standard

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


  The Segment Routing (SR) architecture allows a node to steer a packet
  flow through any topological path and service chain by leveraging
  source routing.  The ingress node prepends an SR header to a packet
  containing a set of segment identifiers (SID).  Each SID represents a
  topological or a service-based instruction.  Per-flow state is
  maintained only on the ingress node of the SR domain.  An SR domain
  is defined as a single administrative domain for global SID
  assignment.

  This document defines an optional, transitive BGP attribute for
  announcing BGP Prefix Segment Identifiers (BGP Prefix-SID)
  information.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-prefix-sid/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-prefix-sid/ballot/


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




2018-05-29
21 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2018-05-29
21 Amy Vezza Last call announcement was generated
2018-05-29
21 Acee Lindem New version available: draft-ietf-idr-bgp-prefix-sid-21.txt
2018-05-29
21 (System) New version approved
2018-05-29
21 (System) Request for posting confirmation emailed to previous authors: Arjun Sreekantiah , Stefano Previdi , Acee Lindem , Hannes Gredler , Clarence Filsfils
2018-05-29
21 Acee Lindem Uploaded new revision
2018-05-29
20 Alvaro Retana Requested Last Call review by RTGDIR
2018-05-29
20 Alvaro Retana Last call was requested
2018-05-29
20 Alvaro Retana IESG state changed to Last Call Requested from AD Evaluation
2018-05-29
20 Alvaro Retana Last call announcement was generated
2018-05-29
20 Alvaro Retana IESG state changed to AD Evaluation from Publication Requested
2018-05-18
20 John Scudder
Shepherd template: (per RFC 4858, date 2/24/2012)

1) What type of RFC?

Proposed standard, on the template header.

(2) The IESG approval announcement includes …
Shepherd template: (per RFC 4858, date 2/24/2012)

1) What type of RFC?

Proposed standard, on the template 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
  Segment Routing (SR) architecture allows a node to steer a packet
  flow through any topological path and service chain by leveraging
  source routing.  The ingress node prepends a SR header to a packet
  containing a set of segment identifiers (SID).  Each SID represents a
  topological or a service-based instruction.  Per-flow state is
  maintained only at the ingress node of the SR domain.

Working Group Summary
WG consensus is strong.  2 companies have implementations (rtbrick and cisco). 
The first WG call came at a bad time, but the subsequent call shows agreement:
https://www.ietf.org/mail-archive/web/idr/current/msg18257.html
Following the WGLC the AD returned the document with further comments. These
were also discussed fairly extensively on the list:
https://mailarchive.ietf.org/arch/msg/idr/AExuEN7r8H7GbAZOZIRJWp8bYmM
https://mailarchive.ietf.org/arch/msg/idr/o0kWeM_pwKq6eHMczoBO3XkAz-c/?qid=None

Late changes included removal of the IPv6 SID TLV (which had gone unimplemented)
and several lesser things.

Document Quality
  Existing Implementations of protocol: 2 companies,  4 implementations see:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-prefix-sid%20implementations

Two rtg-dir QA early reviews
Chris Hopps:
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-prefix-sid-04-rtgdir-early-hopps-2017-03-07-4/
Bruno Decraene
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-prefix-sid-04-rtgdir-early-decraene-2017-06-16/


Personnel
Document Shepherds: Susan Hares, John Scudder
AD:  Alvaro Retana
RTG-DIR review (1): Christian Hopps
RTG-DIR QA review (2): Bruno Decraene
SEC-DIR early reviiew (3): Brian Weis 

(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 had careful read-throughs by both IDR co-chairs (who have
both shepherded the document at various times), with subsequent Q&A and
revision with the authors.

Note, this report covers draft-ietf-idr-bgp-prefix-sid-20.

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

No - between IDR and Spring RTG-DIR reviews, chair reviews and
implementations, the depth of the review seems appropriate. The multiple
WGLC and post-WGLC discussions show that a number of people reviewed the
document carefully.

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

The shepherd was concerned that secdir evaluate whether there were any
additional concerns about multidomain segment routing, over and above
those of BGP-enabled MPLS. The secdir review can be found at
https://mailarchive.ietf.org/arch/msg/secdir/0If6B8IZbm1mT_q9eeMztRSDLIQ
which found the draft to be "ready with nits". The authors and chairs
discussed the nits with the reviewer, Brian Weis. Brian was satisfied
with the response:
https://mailarchive.ietf.org/arch/msg/secdir/nQvAURcxKnPpa5OcUCiD9priPy0/?qid=717a41094f2f9cf83a44c7ea6726c399

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

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/UPZgjGaOAUOGRQGP3QVGY4pXyYI

Hannes Gredler:
https://mailarchive.ietf.org/arch/msg/idr/ll_rycW7FGuHAFRhXwF0rMNghCY

Acee Lindem
https://mailarchive.ietf.org/arch/search/?email_list=idr&q=prefix-sid

Keyur Patel
https://mailarchive.ietf.org/arch/msg/idr/4iBE_Zkz4OwBtaTY-O84OA-NgU4

Stefano Previdi (sprevidi)"
https://mailarchive.ietf.org/arch/msg/idr/QaK3Cb_oeKBIELAUhUpyQn8RlOM

Saikat Ray
https://mailarchive.ietf.org/arch/msg/idr/BsW2BKYy4hwcEOI5JRNXmfp2ge4

Arjun Sreekantiah
https://mailarchive.ietf.org/arch/msg/idr/xtOYnEpupBEw9ZgGTUfGsaAifcc

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

None.

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

Solid.  The link to MPLS and Spring has caused significant review.

(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 appeals or discontent related to draft.

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

No nits other than a backdated reference that can be resolved by the
RFC Editor.

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

N/A

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

Most normative references are RFCs, but see answer to (15).

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

There are normative dependencies on:
draft-ietf-spring-segment-routing-15 (in RFC Ed Queue)
and draft-ietf-spring-segment-routing-mpls-13. The SPRING chairs
say this one has been through a first WGLC, received additional AD
and other feedback, been revised, and soon will go through a second
WGLC. So it seems likely it will move forward promptly.

(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 changes.  It will create an additional IDR Attribute, but this is an
addition rather than a change to earlier IDR specifications.

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

Confirmed.

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

None needed.
2018-05-18
20 John Scudder IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2018-05-18
20 John Scudder IESG state changed to Publication Requested from AD is watching
2018-05-18
20 John Scudder
Shepherd template: (per RFC 4858, date 2/24/2012)

1) What type of RFC?

Proposed standard, on the template header.

(2) The IESG approval announcement includes …
Shepherd template: (per RFC 4858, date 2/24/2012)

1) What type of RFC?

Proposed standard, on the template 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
  Segment Routing (SR) architecture allows a node to steer a packet
  flow through any topological path and service chain by leveraging
  source routing.  The ingress node prepends a SR header to a packet
  containing a set of segment identifiers (SID).  Each SID represents a
  topological or a service-based instruction.  Per-flow state is
  maintained only at the ingress node of the SR domain.

Working Group Summary
WG consensus is strong.  2 companies have implementations (rtbrick and cisco). 
The first WG call came at a bad time, but the subsequent call shows agreement:
https://www.ietf.org/mail-archive/web/idr/current/msg18257.html
Following the WGLC the AD returned the document with further comments. These
were also discussed fairly extensively on the list:
https://mailarchive.ietf.org/arch/msg/idr/AExuEN7r8H7GbAZOZIRJWp8bYmM
https://mailarchive.ietf.org/arch/msg/idr/o0kWeM_pwKq6eHMczoBO3XkAz-c/?qid=None

Late changes included removal of the IPv6 SID TLV (which had gone unimplemented)
and several lesser things.

Document Quality
  Existing Implementations of protocol: 2 companies,  4 implementations see:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-prefix-sid%20implementations

Two rtg-dir QA early reviews
Chris Hopps:
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-prefix-sid-04-rtgdir-early-hopps-2017-03-07-4/
Bruno Decraene
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-prefix-sid-04-rtgdir-early-decraene-2017-06-16/


Personnel
Document Shepherds: Susan Hares, John Scudder
AD:  Alvaro Retana
RTG-DIR review (1): Christian Hopps
RTG-DIR QA review (2): Bruno Decraene
SEC-DIR early reviiew (3): Brian Weis 

(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 had careful read-throughs by both IDR co-chairs (who have
both shepherded the document at various times), with subsequent Q&A and
revision with the authors.

Note, this report covers draft-ietf-idr-bgp-prefix-sid-20.

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

No - between IDR and Spring RTG-DIR reviews, chair reviews and
implementations, the depth of the review seems appropriate. The multiple
WGLC and post-WGLC discussions show that a number of people reviewed the
document carefully.

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

The shepherd was concerned that secdir evaluate whether there were any
additional concerns about multidomain segment routing, over and above
those of BGP-enabled MPLS. The secdir review can be found at
https://mailarchive.ietf.org/arch/msg/secdir/0If6B8IZbm1mT_q9eeMztRSDLIQ
which found the draft to be "ready with nits". The authors and chairs
discussed the nits with the reviewer, Brian Weis. Brian was satisfied
with the response:
https://mailarchive.ietf.org/arch/msg/secdir/nQvAURcxKnPpa5OcUCiD9priPy0/?qid=717a41094f2f9cf83a44c7ea6726c399

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

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/UPZgjGaOAUOGRQGP3QVGY4pXyYI

Hannes Gredler:
https://mailarchive.ietf.org/arch/msg/idr/ll_rycW7FGuHAFRhXwF0rMNghCY

Acee Lindem
https://mailarchive.ietf.org/arch/search/?email_list=idr&q=prefix-sid

Keyur Patel
https://mailarchive.ietf.org/arch/msg/idr/4iBE_Zkz4OwBtaTY-O84OA-NgU4

Stefano Previdi (sprevidi)"
https://mailarchive.ietf.org/arch/msg/idr/QaK3Cb_oeKBIELAUhUpyQn8RlOM

Saikat Ray
https://mailarchive.ietf.org/arch/msg/idr/BsW2BKYy4hwcEOI5JRNXmfp2ge4

Arjun Sreekantiah
https://mailarchive.ietf.org/arch/msg/idr/xtOYnEpupBEw9ZgGTUfGsaAifcc

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

None.

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

Solid.  The link to MPLS and Spring has caused significant review.

(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 appeals or discontent related to draft.

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

No nits other than a backdated reference that can be resolved by the
RFC Editor.

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

N/A

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

Most normative references are RFCs, but see answer to (15).

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

There are normative dependencies on:
draft-ietf-spring-segment-routing-15 (in RFC Ed Queue)
and draft-ietf-spring-segment-routing-mpls-13. The SPRING chairs
say this one has been through a first WGLC, received additional AD
and other feedback, been revised, and soon will go through a second
WGLC. So it seems likely it will move forward promptly.

(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 changes.  It will create an additional IDR Attribute, but this is an
addition rather than a change to earlier IDR specifications.

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

Confirmed.

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

None needed.
2018-05-18
20 John Scudder
Shepherd template: (per RFC 4858, date 2/24/2012)
Status:  Check implementation reports while in IETF LC, updating shepherd report before end of IETF LC


1) …
Shepherd template: (per RFC 4858, date 2/24/2012)
Status:  Check implementation reports while in IETF LC, updating shepherd report before end of IETF LC


1) What type of RFC?

Proposed standard, on the template 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
  Segment Routing (SR) architecture allows a node to steer a packet
  flow through any topological path and service chain by leveraging
  source routing.  The ingress node prepends a SR header to a packet
  containing a set of segment identifiers (SID).  Each SID represents a
  topological or a service-based instruction.  Per-flow state is
  maintained only at the ingress node of the SR domain.

Working Group Summary
WG consensus is strong.  2 companies have implementations (rtbrick and cisco). 
The first WG call came at a bad time, but the subsequent call shows agreement:
https://www.ietf.org/mail-archive/web/idr/current/msg18257.html
Following the WGLC the AD returned the document with further comments. These
were also discussed fairly extensively on the list:
https://mailarchive.ietf.org/arch/msg/idr/AExuEN7r8H7GbAZOZIRJWp8bYmM
https://mailarchive.ietf.org/arch/msg/idr/o0kWeM_pwKq6eHMczoBO3XkAz-c/?qid=None

Late changes included removal of the IPv6 SID TLV (which had gone unimplemented)
and several lesser things.

Document Quality
  Existing Implementations of protocol: 2 companies,  4 implementations see:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-prefix-sid%20implementations

Two rtg-dir QA early reviews
Chris Hopps:
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-prefix-sid-04-rtgdir-early-hopps-2017-03-07-4/
Bruno Decraene
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-prefix-sid-04-rtgdir-early-decraene-2017-06-16/


Personnel
Document Shepherds: Susan Hares, John Scudder
AD:  Alvaro Retana
RTG-DIR review (1): Christian Hopps
RTG-DIR QA review (2): Bruno Decraene
SEC-DIR early reviiew (3): Brian Weis 

(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 had careful read-throughs by both IDR co-chairs (who have
both shepherded the document at various times), with subsequent Q&A and
revision with the authors.

Note, this report covers draft-ietf-idr-bgp-prefix-sid-20.

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

No - between IDR and Spring RTG-DIR reviews, chair reviews and
implementations, the depth of the review seems appropriate. The multiple
WGLC and post-WGLC discussions show that a number of people reviewed the
document carefully.

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

The shepherd was concerned that secdir evaluate whether there were any
additional concerns about multidomain segment routing, over and above
those of BGP-enabled MPLS. The secdir review can be found at
https://mailarchive.ietf.org/arch/msg/secdir/0If6B8IZbm1mT_q9eeMztRSDLIQ
which found the draft to be "ready with nits". The authors and chairs
discussed the nits with the reviewer, Brian Weis. Brian was satisfied
with the response:
https://mailarchive.ietf.org/arch/msg/secdir/nQvAURcxKnPpa5OcUCiD9priPy0/?qid=717a41094f2f9cf83a44c7ea6726c399

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

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/UPZgjGaOAUOGRQGP3QVGY4pXyYI

Hannes Gredler:
https://mailarchive.ietf.org/arch/msg/idr/ll_rycW7FGuHAFRhXwF0rMNghCY

Acee Lindem
https://mailarchive.ietf.org/arch/search/?email_list=idr&q=prefix-sid

Keyur Patel
https://mailarchive.ietf.org/arch/msg/idr/4iBE_Zkz4OwBtaTY-O84OA-NgU4

Stefano Previdi (sprevidi)"
https://mailarchive.ietf.org/arch/msg/idr/QaK3Cb_oeKBIELAUhUpyQn8RlOM

Saikat Ray
https://mailarchive.ietf.org/arch/msg/idr/BsW2BKYy4hwcEOI5JRNXmfp2ge4

Arjun Sreekantiah
https://mailarchive.ietf.org/arch/msg/idr/xtOYnEpupBEw9ZgGTUfGsaAifcc

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

None.

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

Solid.  The link to MPLS and Spring has caused significant review.

(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 appeals or discontent related to draft.

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

No nits other than a backdated reference that can be resolved by the
RFC Editor.

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

N/A

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

Most normative references are RFCs, but see answer to (15).

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

There are normative dependencies on:
draft-ietf-spring-segment-routing-15 (in RFC Ed Queue)
and draft-ietf-spring-segment-routing-mpls-13. The SPRING chairs
say this one has been through a first WGLC, received additional AD
and other feedback, been revised, and soon will go through a second
WGLC. So it seems likely it will move forward promptly.

(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 changes.  It will create an additional IDR Attribute, but this is an
addition rather than a change to earlier IDR specifications.

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

Confirmed.

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

None needed.
2018-05-08
20 Acee Lindem New version available: draft-ietf-idr-bgp-prefix-sid-20.txt
2018-05-08
20 (System) New version approved
2018-05-08
20 (System) Request for posting confirmation emailed to previous authors: Arjun Sreekantiah , Stefano Previdi , Acee Lindem , Hannes Gredler , Clarence Filsfils
2018-05-08
20 Acee Lindem Uploaded new revision
2018-04-07
19 Acee Lindem New version available: draft-ietf-idr-bgp-prefix-sid-19.txt
2018-04-07
19 (System) New version approved
2018-04-07
19 (System) Request for posting confirmation emailed to previous authors: Arjun Sreekantiah , Stefano Previdi , Acee Lindem , Hannes Gredler , Clarence Filsfils
2018-04-07
19 Acee Lindem Uploaded new revision
2018-04-06
18 John Scudder Notification list changed to Susan Hares <shares@ndzh.com>, aretana.ietf@gmail.com, John Scudder <jgs@juniper.net> from Susan Hares <shares@ndzh.com>, aretana.ietf@gmail.com
2018-04-06
18 John Scudder Document shepherd changed to John Scudder
2018-03-27
18 Acee Lindem New version available: draft-ietf-idr-bgp-prefix-sid-18.txt
2018-03-27
18 (System) New version approved
2018-03-27
18 (System) Request for posting confirmation emailed to previous authors: Arjun Sreekantiah , Stefano Previdi , Acee Lindem , Hannes Gredler , Clarence Filsfils
2018-03-27
18 Acee Lindem Uploaded new revision
2018-03-27
17 John Scudder Tag Revised I-D Needed - Issue raised by WG cleared.
2018-03-27
17 John Scudder IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2018-03-26
17 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2018-02-23
17 Susan Hares IETF WG state changed to In WG Last Call from WG Document
2018-02-23
17 Alvaro Retana Tag Revised I-D Needed - Issue raised by WG set.
2018-02-23
17 Alvaro Retana IETF WG state changed to WG Document from Submitted to IESG for Publication
2018-02-20
17 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2018-02-20
17 Acee Lindem New version available: draft-ietf-idr-bgp-prefix-sid-17.txt
2018-02-20
17 (System) New version approved
2018-02-20
17 (System) Request for posting confirmation emailed to previous authors: Arjun Sreekantiah , Stefano Previdi , Acee Lindem , Hannes Gredler , Clarence Filsfils
2018-02-20
17 Acee Lindem Uploaded new revision
2018-02-20
16 Alvaro Retana
After IESG approval, the authors proposed significant changes to the content of the document to remove support for the IPv6 SID due to lack of …
After IESG approval, the authors proposed significant changes to the content of the document to remove support for the IPv6 SID due to lack of implementation and support [1].  The result should be that the document is simplified.  This is a significant change!

I am returning the document to the WG to discuss this proposal and update the document accordingly.  The expectation is that that if the proposal is accepted for the WG to postpone the IPv6-specific work (to be done in a different document), and not abandon it.

[1] https://mailarchive.ietf.org/arch/msg/idr/FM31nSL78B5L5yCBZB17NfLwQy4/?qid=7f0a07c88788f56211e8702176812f8e
2018-02-20
16 Alvaro Retana IESG state changed to AD is watching from Approved-announcement to be sent::AD Followup
2018-02-16
16 Tero Kivinen Closed request for Last Call review by SECDIR with state 'No Response'
2018-02-13
16 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-02-13
16 Acee Lindem New version available: draft-ietf-idr-bgp-prefix-sid-16.txt
2018-02-13
16 (System) New version approved
2018-02-13
16 (System) Request for posting confirmation emailed to previous authors: Arjun Sreekantiah , Stefano Previdi , Acee Lindem , Hannes Gredler , Clarence Filsfils
2018-02-13
16 Acee Lindem Uploaded new revision
2018-02-12
15 Alvaro Retana The latest update resulted in a few more comments and may require the WG to take a new look.
2018-02-12
15 Alvaro Retana IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::AD Followup
2018-02-12
15 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-02-12
15 Acee Lindem New version available: draft-ietf-idr-bgp-prefix-sid-15.txt
2018-02-12
15 (System) New version approved
2018-02-12
15 (System) Request for posting confirmation emailed to previous authors: Arjun Sreekantiah , Stefano Previdi , Acee Lindem , Hannes Gredler , Clarence Filsfils
2018-02-12
15 Acee Lindem Uploaded new revision
2018-02-08
14 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2018-02-07
14 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2018-02-07
14 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2018-02-07
14 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2018-02-07
14 Adam Roach [Ballot comment]
Please expand "AFI/SAFI" on first use.
2018-02-07
14 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2018-02-07
14 Ben Campbell
[Ballot comment]
(The document has been updated since I made my review notes. Apologies if any of my comments no longer apply.)

Substantive:

- 1: …
[Ballot comment]
(The document has been updated since I made my review notes. Apologies if any of my comments no longer apply.)

Substantive:

- 1: I agree with Alissa's comment about finding a less controversial example than DPI.

-9: last paragraph: Can you offer a citation for the "standard BGP mechansism (filters)"? I assume they are in one of the documents cited in the first paragraph of this section, but it would help to cite the specific document and section.

Editorial and nits:

- Abstract and section 1: Both are missing an article (probably "The")  before "Segment Routing (SR) architecture"
2018-02-07
14 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2018-02-07
14 Warren Kumari
[Ballot comment]
Thanks for Acee for addressing my DISCUSS - cleared.

Major(ish) issue:
Section 5.  Advertising BGP Prefix-SID Attribute
  "The BGP Prefix-SID attribute MAY …
[Ballot comment]
Thanks for Acee for addressing my DISCUSS - cleared.

Major(ish) issue:
Section 5.  Advertising BGP Prefix-SID Attribute
  "The BGP Prefix-SID attribute MAY be attached to labeled BGP prefixes
  (IPv4/IPv6) [RFC8277] or to IPv6 unicast prefixes [RFC4760].  In
  order to prevent distribution of the BGP Prefix-SID attribute beyond
  its intended scope of applicability, attribute filtering SHOULD be
  deployed."
Thank you for including this -- however, as I'm sure you know, the state of BGP filtering in the wild is, er, poor. Can you please provide some additional guidance? For example, could you include an appendix with examples? Or simply a bit more text on determining the scope of applicability? Apologies if I missed this, but should this by default be filtered on eBGP sessions? The included text is a great start, but some more (so people don't miss it and shoot themselves in the foot would be much appreciated.

Nits:
Section 1:
" the SID consists of a label while when SR is applied to the IPv6 dataplane the SID consists of an IPv6 address."
I think that "of a label, while" would make this much more readable. It took me a few tries without it.

Section 4:
" A BGP speaker receiving a BGP Prefix-SID attribute from an EBGP
  neighbor residing outside the boundaries of the SR domain, MUST
  discard the attribute unless it is configured to accept the attribute
  from the EBGP neighbor."
Spurious comma between domain and MUST (yeah, I want a comma above, I don't want one here, no pleasing some people. They are nits :-))
2018-02-07
14 Warren Kumari [Ballot Position Update] Position for Warren Kumari has been changed to No Objection from Discuss
2018-02-07
14 Acee Lindem New version available: draft-ietf-idr-bgp-prefix-sid-14.txt
2018-02-07
14 (System) New version approved
2018-02-07
14 (System) Request for posting confirmation emailed to previous authors: Arjun Sreekantiah , Stefano Previdi , Acee Lindem , Hannes Gredler , Clarence Filsfils
2018-02-07
14 Acee Lindem Uploaded new revision
2018-02-07
13 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-02-07
13 Kathleen Moriarty [Ballot comment]
I support Warren's discuss and Alexey's comment on logging.
2018-02-07
13 Kathleen Moriarty Ballot comment text updated for Kathleen Moriarty
2018-02-07
13 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2018-02-07
13 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2018-02-07
13 Warren Kumari
[Ballot discuss]
I had the same logging question an Alexey and guessed (perhaps incorrectly) that this was to try and prevent DoSing the logging infrastructure …
[Ballot discuss]
I had the same logging question an Alexey and guessed (perhaps incorrectly) that this was to try and prevent DoSing the logging infrastructure by sending too many log messages. If this is the reason, I think that it should be better spelled out -- and if this is *not* the reason, I think that there needs to be a good explanation.
Note that I will happy clear as soon as someone says "Yeah, we've heard and will deal with this" -- I think that this is a fine document and that addressing this issue should be a minor change, but important enough for operational reasons that it needs to be discussed.
2018-02-07
13 Warren Kumari
[Ballot comment]
Major(ish) issue:
Section 5.  Advertising BGP Prefix-SID Attribute
  "The BGP Prefix-SID attribute MAY be attached to labeled BGP prefixes
  (IPv4/IPv6) [ …
[Ballot comment]
Major(ish) issue:
Section 5.  Advertising BGP Prefix-SID Attribute
  "The BGP Prefix-SID attribute MAY be attached to labeled BGP prefixes
  (IPv4/IPv6) [RFC8277] or to IPv6 unicast prefixes [RFC4760].  In
  order to prevent distribution of the BGP Prefix-SID attribute beyond
  its intended scope of applicability, attribute filtering SHOULD be
  deployed."
Thank you for including this -- however, as I'm sure you know, the state of BGP filtering in the wild is, er, poor. Can you please provide some additional guidance? For example, could you include an appendix with examples? Or simply a bit more text on determining the scope of applicability? Apologies if I missed this, but should this by default be filtered on eBGP sessions? The included text is a great start, but some more (so people don't miss it and shoot themselves in the foot would be much appreciated.

Nits:
Section 1:
" the SID consists of a label while when SR is applied to the IPv6 dataplane the SID consists of an IPv6 address."
I think that "of a label, while" would make this much more readable. It took me a few tries without it.

Section 4:
" A BGP speaker receiving a BGP Prefix-SID attribute from an EBGP
  neighbor residing outside the boundaries of the SR domain, MUST
  discard the attribute unless it is configured to accept the attribute
  from the EBGP neighbor."
Spurious comma between domain and MUST (yeah, I want a comma above, I don't want one here, no pleasing some people. They are nits :-))
2018-02-07
13 Warren Kumari [Ballot Position Update] New position, Discuss, has been recorded for Warren Kumari
2018-02-07
13 Brian Weis Request for Early review by SECDIR Completed: Ready. Reviewer: Brian Weis.
2018-02-06
13 Suresh Krishnan
[Ballot comment]
I don't see how the MUST in this receiving behavior in Section 4.2.

"However, a BGP Prefix-SID attribute corresponding to the BGP IPv6 …
[Ballot comment]
I don't see how the MUST in this receiving behavior in Section 4.2.

"However, a BGP Prefix-SID attribute corresponding to the BGP IPv6 address family without an IPv6 SID TLV MUST be ignored."

makes sense with the MAY in the sending behavior

"A BGP speaker that originates an IPv6 prefix with the BGP Prefix-SID attribute MAY include the IPv6 SID TLV."

Can you please clarify?
2018-02-06
13 Suresh Krishnan Ballot comment text updated for Suresh Krishnan
2018-02-06
13 Suresh Krishnan
[Ballot comment]
I am not sure how to reconcile the MUST in this receiving behavior in Section 4.2.

"However, a BGP Prefix-SID attribute corresponding to …
[Ballot comment]
I am not sure how to reconcile the MUST in this receiving behavior in Section 4.2.

"However, a BGP Prefix-SID attribute corresponding to the BGP IPv6 address family without an IPv6 SID TLV MUST be ignored."

with the MAY in the sending behavior

"A BGP speaker that originates an IPv6 prefix with the BGP Prefix-SID attribute MAY include the IPv6 SID TLV."

Can you please clarify?
2018-02-06
13 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-02-06
13 Eric Rescorla
[Ballot comment]

  BGP Prefix-SID attribute, it MUST program the derived label as the
  local label for the prefix in its MPLS dataplane.  In …
[Ballot comment]

  BGP Prefix-SID attribute, it MUST program the derived label as the
  local label for the prefix in its MPLS dataplane.  In case of any
  error, a BGP speaker MUST resort to the error handling rules
This seems over-strong, as the next paragraph suggests that you might reject it due to policy.


  This document defines a new BGP attribute in order to address the use
  case described in [I-D.ietf-spring-segment-routing-msdc].  It i
  assumed that the new attribute (BGP Prefix-SID) advertisement is
Nit: "is assumed", i think?


  inherits the security considerations expressed in: [RFC4271] and
  [RFC3107].
This section seems like it needs to discuss how the security of this mechanism interacts with BGPSEC, etc. Maybe it's just "the same as everything else" but perhaps not...
2018-02-06
13 Eric Rescorla [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla
2018-02-06
13 Alissa Cooper
[Ballot comment]
Is there a different, less controversial example that could be given in the first paragraph of the document than "pass through deep packet …
[Ballot comment]
Is there a different, less controversial example that could be given in the first paragraph of the document than "pass through deep packet inspection"?
2018-02-06
13 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-02-05
13 Acee Lindem New version available: draft-ietf-idr-bgp-prefix-sid-13.txt
2018-02-05
13 (System) New version approved
2018-02-05
13 (System) Request for posting confirmation emailed to previous authors: Arjun Sreekantiah , Stefano Previdi , Acee Lindem , Hannes Gredler , Clarence Filsfils
2018-02-05
13 Acee Lindem Uploaded new revision
2018-02-05
12 Alexey Melnikov
[Ballot comment]
I tend to agree with Mirja that you either don't currently need registry for flags or need it with a stricter policy than …
[Ballot comment]
I tend to agree with Mirja that you either don't currently need registry for flags or need it with a stricter policy than First Come First Served.

Nits:

4.  Receiving BGP Prefix-SID Attribute

  A BGP speaker receiving a BGP Prefix-SID attribute from an EBGP
  neighbor residing outside the boundaries of the SR domain MUST
  discard the attribute unless it is configured to accept the attribute
  from the EBGP neighbor.  A BGP speaker MAY log an error for further
  analysis when discarding an attribute.

Is there any reason why logging is just MAY? This would help big time in debugging issues.
You are also using "SHOULD log" in other places in the document. So I suggest:

MAY log an error ==> SHOULD log an error

(Actually "MAY log" appears twice in the document)


I suggest you use a more common "extensibility" instead of "extendibility", but maybe this is just me :-).
2018-02-05
12 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2018-02-05
12 Mirja Kühlewind
[Ballot comment]
Minor commets:

1) Maybe spell out NLRI on first occurrence (sec 2).

2) Given there are currently no flags defined, wouldn't it be …
[Ballot comment]
Minor commets:

1) Maybe spell out NLRI on first occurrence (sec 2).

2) Given there are currently no flags defined, wouldn't it be sufficient to use the 8-bit reserved field for flags? Also do you really want to create an empty registry on a first-come first-serve basis for the flags now? Have there been any use cases discussed already? Is it likely that assignments will be made soon and is first-com first-serve the right policy for these expected assignments? Note that such registries can also be created at a later point when really needed.
2018-02-05
12 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2018-02-04
12 Acee Lindem New version available: draft-ietf-idr-bgp-prefix-sid-12.txt
2018-02-04
12 (System) New version approved
2018-02-04
12 (System) Request for posting confirmation emailed to previous authors: Arjun Sreekantiah , Stefano Previdi , Acee Lindem , Hannes Gredler , Clarence Filsfils
2018-02-04
12 Acee Lindem Uploaded new revision
2018-02-02
11 Min Ye Request for Telechat review by RTGDIR Completed: Has Nits. Reviewer: Tony Przygienda.
2018-02-01
11 Peter Yee Request for Telechat review by GENART Completed: Ready. Reviewer: Peter Yee. Sent review to list.
2018-02-01
11 Jean Mahoney Request for Telechat review by GENART is assigned to Peter Yee
2018-02-01
11 Jean Mahoney Request for Telechat review by GENART is assigned to Peter Yee
2018-01-31
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2018-01-31
11 Acee Lindem New version available: draft-ietf-idr-bgp-prefix-sid-11.txt
2018-01-31
11 (System) New version approved
2018-01-31
11 (System) Request for posting confirmation emailed to previous authors: Arjun Sreekantiah , Stefano Previdi , Acee Lindem , Hannes Gredler , Clarence Filsfils
2018-01-31
11 Acee Lindem Uploaded new revision
2018-01-31
10 Peter Yee Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee. Sent review to list.
2018-01-26
10 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2018-01-26
10 Alvaro Retana IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2018-01-26
10 Alvaro Retana Ballot has been issued
2018-01-26
10 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2018-01-26
10 Alvaro Retana Created "Approve" ballot
2018-01-26
10 Alvaro Retana Ballot writeup was changed
2018-01-26
10 Alvaro Retana IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup
2018-01-26
10 (System) IESG state changed to Waiting for Writeup from In Last Call
2018-01-25
10 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2018-01-25
10 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-idr-bgp-prefix-sid-09. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-idr-bgp-prefix-sid-09. 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 [ RFC-to-be ].

The IANA Services Operator understands that, upon approval of [ RFC-to-be ], there are fouractions which we must complete.

First, in the BGP Path Attributes registry on the Border Gateway Protocol (BGP) Parameters registry page located at:

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

the temporary registration for path attribute value 40:

BGP Prefix-SID (TEMPORARY - registered 2015-09-30, extension registered 2017-08-31, expires 2018-09-30)

will be made permanent and its reference changed to [ RFC-to-be ].

Second, a new registry is to be created called the BGP Prefix-SID TLV Types registry. The registration procedure for the new registry will be first come, first served for the values 1 thorugh 254. Values 0 and 255 will be reserved.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

We understand that there are initial registrations in this new registry as follows:

Value Type Reference
-----+---------------+-------------
0 Reserved [ RFC-to-be ]
1 Label-Index [ RFC-to-be ]
2 IPv6 SID [ RFC-to-be ]
3 Originator SRGB [ RFC-to-be ]
4-254 Unassigned
255 Reserved [ RFC-to-be ]

Third, a new registry is to be created called the Label-Index TLV Flags registry. Initially, the registry will be empty. The registration procedure for the new registry will be first come, first served for the values 1 thorugh 254. Values 0 and 255 will be reserved.

IANA Question --> Is this to be a subregistry of the new BGP Prefix-SID TLV Types registry created in step 2 above?

We understand that the initial registry will be:

Value Type Reference
-----+---------------+-------------
0 Reserved [ RFC-to-be ]
1-254 Unassigned
255 Reserved [ RFC-to-be ]

Fourth, a new registry is to be created called the SRGB Originator TLV Flags registry. Initially, the registry will be empty. The registration procedure for the new registry will be first come, first served for the values 1 thorugh 254. Values 0 and 255 will be reserved.

IANA Question --> Is this also to be a subregistry of the new BGP Prefix-SID TLV Types registry created in step 2 above?

We understand that the initial registry will be:

Value Type Reference
-----+---------------+-------------
0 Reserved [ RFC-to-be ]
1-254 Unassigned
255 Reserved [ RFC-to-be ]

The IANA Services Operator understands that these three actions are the only ones required to be completed upon approval of [ RFC-to-be ].

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 the list of actions that will be performed.


Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2018-01-19
10 Susan Hares
Shepherd temlate: (per RFC 4858, date 2/24/2012)
Status:  Check implementation reports while in IETF LC, updating shepherd report before end of IETF LC


1) …
Shepherd temlate: (per RFC 4858, date 2/24/2012)
Status:  Check implementation reports while in IETF LC, updating shepherd report before end of IETF LC


1) What type of RFC?  proposed standard, on the template 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
  Segment Routing (SR) architecture allows a node to steer a packet
  flow through any topological path and service chain by leveraging
  source routing.  The ingress node prepends a SR header to a packet
  containing a set of segment identifiers (SID).  Each SID represents a
  topological or a service-based instruction.  Per-flow state is
  maintained only at the ingress node of the SR domain.

Working Group Summary
WG consensus is strong.  2 companies have implementations (rtbrick and cisco). 
The first WG call came at a bad time, but the subsequent call shows agreement.
final call:
https://www.ietf.org/mail-archive/web/idr/current/msg18257.html

Document Quality
  Existing Implementations of protocol: 2 companies,  4 implementations see:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-prefix-sid%20implementations

Two rtg-dir QA early reviews
Chris Hopps:
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-prefix-sid-04-rtgdir-early-hopps-2017-03-07-4/
Bruno Decraene
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-prefix-sid-04-rtgdir-early-decraene-2017-06-16/


Personnel
Document Shepherd: Susan hares
AD:  Alvaro Retana
RTG-DIR review (1): Christian Hopps
RTG-DIR QA review (2): Bruno Decraene
SEC-DIR early reviiew (3): Brian Weis 

(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 IDR has


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

No - between IDR and Spring RTG-DIR reviews, chair reviews and implementations,  the depth of the review seems appropriate.

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

SEC-DIR review was requested to see if multi-domain segment routing provided any additional concerns above those of BGP-enabled MPLS.  SEC-DIr response is overdue by 15 days.  The shepherd does not personally perceive any security issues beyond those equivalent to a BGP-enable MPLS.

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

The AD should be aware this is linked to SPRING and MPLS drafts.
This draft indicates MPLS drafts RFC3107 and RFC4760
The MPLS cross review has not been done, but will be started
on 6/15/2017.  Please note that MPLS RFC3107bis has been revised.

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

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/UPZgjGaOAUOGRQGP3QVGY4pXyYI

Hannes Gredler:
https://mailarchive.ietf.org/arch/msg/idr/ll_rycW7FGuHAFRhXwF0rMNghCY

Acee Lindem
https://mailarchive.ietf.org/arch/search/?email_list=idr&q=prefix-sid


Keyur Patel
https://mailarchive.ietf.org/arch/msg/idr/4iBE_Zkz4OwBtaTY-O84OA-NgU4

Stefano Previdi (sprevidi)"
https://mailarchive.ietf.org/arch/msg/idr/QaK3Cb_oeKBIELAUhUpyQn8RlOM

Saikat Ray
https://mailarchive.ietf.org/arch/msg/idr/BsW2BKYy4hwcEOI5JRNXmfp2ge4

Arjun Sreekantiah
https://mailarchive.ietf.org/arch/msg/idr/xtOYnEpupBEw9ZgGTUfGsaAifcc

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

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

Solid.  The link to MPLS and Spring has caused significant review.

(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 appeals or discontent related to draft.

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

ID nits show that the current version has a back dated:
  draft-ietf-idr-bgpls-segment-routing-epe-11

We are progressing both documents in parallel to the IESG.

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

No

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

All nomative references are RFCs.
Please note that RFC3107 is being revised by the MPLS WG.

(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 changes.  It will create an additional IDR Attribute, but this is an addition
rather than a change to earlier IDR specifications.

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



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

All registries are standards registries and not Designated Expert review.

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

None needed.
2018-01-18
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Stefan Winter
2018-01-18
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Stefan Winter
2018-01-18
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Brian Weis
2018-01-18
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Brian Weis
2018-01-18
10 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2018-01-18
10 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2018-01-16
10 Acee Lindem New version available: draft-ietf-idr-bgp-prefix-sid-10.txt
2018-01-16
10 (System) New version approved
2018-01-16
10 (System) Request for posting confirmation emailed to previous authors: Arjun Sreekantiah , Stefano Previdi , Acee Lindem , Hannes Gredler , Clarence Filsfils
2018-01-16
10 Acee Lindem Uploaded new revision
2018-01-15
09 Jonathan Hardwick Request for Telechat review by RTGDIR is assigned to Tony Przygienda
2018-01-15
09 Jonathan Hardwick Request for Telechat review by RTGDIR is assigned to Tony Przygienda
2018-01-12
09 Cindy Morgan IANA Review state changed to IANA - Review Needed
2018-01-12
09 Cindy Morgan
The following Last Call announcement was sent out (ends 2018-01-26):

From: The IESG
To: IETF-Announce
CC: idr@ietf.org, Susan Hares , idr-chairs@ietf.org, draft-ietf-idr-bgp-prefix-sid@ietf.org, …
The following Last Call announcement was sent out (ends 2018-01-26):

From: The IESG
To: IETF-Announce
CC: idr@ietf.org, Susan Hares , idr-chairs@ietf.org, draft-ietf-idr-bgp-prefix-sid@ietf.org, aretana.ietf@gmail.com, shares@ndzh.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Segment Routing Prefix SID extensions for BGP) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document: - 'Segment Routing Prefix SID extensions for
BGP'
  as Proposed Standard

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

Abstract


  Segment Routing (SR) architecture allows a node to steer a packet
  flow through any topological path and service chain by leveraging
  source routing.  The ingress node prepends an SR header to a packet
  containing a set of segment identifiers (SID).  Each SID represents a
  topological or a service-based instruction.  Per-flow state is
  maintained only on the ingress node of the SR domain.

  This document defines an optional, transitive BGP attribute for
  announcing BGP Prefix Segment Identifiers (BGP Prefix-SID)
  information.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-prefix-sid/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-prefix-sid/ballot/


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




2018-01-12
09 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2018-01-12
09 Jonathan Hardwick Request for Telechat review by RTGDIR is assigned to Victoria Pritchard
2018-01-12
09 Jonathan Hardwick Request for Telechat review by RTGDIR is assigned to Victoria Pritchard
2018-01-12
09 Alvaro Retana Requested Telechat review by RTGDIR
2018-01-12
09 Alvaro Retana Placed on agenda for telechat - 2018-02-08
2018-01-12
09 Alvaro Retana Last call was requested
2018-01-12
09 Alvaro Retana Ballot approval text was generated
2018-01-12
09 Alvaro Retana Ballot writeup was generated
2018-01-12
09 Alvaro Retana IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2018-01-12
09 Alvaro Retana Last call announcement was generated
2018-01-05
09 Acee Lindem New version available: draft-ietf-idr-bgp-prefix-sid-09.txt
2018-01-05
09 (System) New version approved
2018-01-05
09 (System) Request for posting confirmation emailed to previous authors: Arjun Sreekantiah , Stefano Previdi , Acee Lindem , Hannes Gredler , Clarence Filsfils
2018-01-05
09 Acee Lindem Uploaded new revision
2018-01-02
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-01-02
08 Acee Lindem New version available: draft-ietf-idr-bgp-prefix-sid-08.txt
2018-01-02
08 (System) New version approved
2018-01-02
08 (System) Request for posting confirmation emailed to previous authors: idr-chairs@ietf.org, Arjun Sreekantiah , Acee Lindem , Hannes Gredler , Clarence Filsfils , Stefano Previdi
2018-01-02
08 Acee Lindem Uploaded new revision
2017-12-21
07 Alvaro Retana
=== AD Review of draft-ietf-idr-bgp-prefix-sid-07 ===
https://mailarchive.ietf.org/arch/msg/idr/WWrIDbm3XvgG3m_46G6HtI4Tbu8/?qid=b438ce1ceb656eb821b405c3c9a99311

Dear authors:

Hi!  I just finished reading this document.

I have a significant number of comments (please see …
=== AD Review of draft-ietf-idr-bgp-prefix-sid-07 ===
https://mailarchive.ietf.org/arch/msg/idr/WWrIDbm3XvgG3m_46G6HtI4Tbu8/?qid=b438ce1ceb656eb821b405c3c9a99311

Dear authors:

Hi!  I just finished reading this document.

I have a significant number of comments (please see below).  Two of them I
would like to highlight up here.

(1) References to draft-ietf-spring-segment-routing-msdc

In the current text, draft-ietf-spring-segment-routing-msdc is not only
referenced as an example of the use of the BGP Prefix-SID attribute, but in
a Normative way to indicate how the attribute should be treated.  While
there’s nothing wrong with draft-ietf-spring-segment-routing-msdc (it
already passed IETF LC and is in IESG Evaluation), I’m sure there are other
applications for the new attribute, right?  The importance given to it in
this document, which should elevate it to a Normative reference, is
probably more than it deserves since it just focuses on describing "the
design to deploy segment routing in [large-scale] data-centers” and it
doesn’t contain a list of requirements nor it mandates how the new
attribute should be used.  Note also
that draft-ietf-spring-segment-routing-msdc refers normatively to this
document to explain the use case, so pointing Normatively back to it
creates a loop....  Please treat draft-ietf-spring-segment-routing-msdc as
what is should be: a good Informative reference — I put specific comments
above about the text below (see M1).


(2) Error Handling

The error handling (in Section 6) specifies that “attribute discard”
(rfc7606) should be used if the attribute is malformed.  I think that
behavior has a direct effect on the path used to forward the traffic, which
puts it then in conflict with rfc7606 because it clearly says that
"Attribute discard...MUST NOT be used except in the case of an attribute that
has no effect on route selection or installation.”  Please see M9 below.


I will wait for the Major comments to be addressed before starting the IETF
LC.

Thanks!

Alvaro.



Major:

M1. References to draft-ietf-spring-segment-routing-msdc.  As I mentioned
above, I believe that this document gives a lot more importance
to draft-ietf-spring-segment-routing-msdc than it deserves — for one, I
think that draft-ietf-spring-segment-routing-msdc should not be considered
as a Normative source for this document, but as it stands right now its
reference would have to in fact be Normative.

M1.1 Section 1: "As described in [I-D.ietf-spring-segment-routing-msdc],
the BGP Prefix-SID attribute defined in this document can be attached to
prefixes from AFI/SAFI...labeled IPv4/IPv6 Unicast...unlabeled IPv6
Unicast”.  draft-ietf-spring-segment-routing-msdc does describe that, but
within the DC application — IOW, just because one use case uses the BGP
Prefix SID in that way doesn’t mean that it determines it’s use…just an
example.  s/As described in [I-D.ietf-spring-segment-routing-msdc]/

M1.2. s/[I-D.ietf-spring-segment-routing-msdc] describes use cases where
the Prefix-SID is used for the above
AFI/SAFI./[I-D.ietf-spring-segment-routing-msdc] describes use cases where
the Prefix-SID is used for the above AFI/SAFI in a MSDC.

M1.3. Section 1: "As described in [I-D.ietf-spring-segment-routing-msdc], a
BGP Prefix-SID MAY be attached to a prefix.”

M1.3.1. draft-ietf-spring-segment-routing-msdc doesn’t even use Normative
language

M.1.3.2. ...even if it did, what is the option?  Why is “MAY” used?  What
else can the BGP Prefix-SID be attached to?  Everywhere else in this
document, the text talks about attachment to a prefix.

M1.3.3. Section 5. (Announcing BGP-Prefix-SID Attribute) makes a similar
statement: "The BGP Prefix-SID attribute MAY be attached to labeled BGP
prefixes (IPv4/IPv6) [RFC3107] or to IPv6 prefixes [RFC4760].”  Same
questions: is there another option?  In this case, did you mean “…MUST only
be attached to…”?

M1.4. Section 2.1: "As described in [I-D.ietf-spring-segment-routing-msdc]
the operator assigns a globally unique “index”, L_I…”.  Again, that’s an
example…. s/As described in [I-D.ietf-spring-segment-routing-msdc]/

M1.4.1. [nit] BTW, is there a reason for “index” to be in “”??  It isn’t
anywhere else.

M1.4.2. [minor] Also, please be consistent.  In some places you use “Label
Index” (as in the packet format), but also “label index”, label_index,
label-index, Label-Index, simply index or even the (redundant?) "index
L_I".  Some of those may be ok, but many seem to talk about the same thing
while calling it by slightly different names.

M1.5. Section 2.2: "As illustrated in
[I-D.ietf-spring-segment-routing-msdc]...the BGP Prefix-SID consists of an
IPv6 address…”. s/As illustrated in [I-D.ietf-spring-segment-routing-msdc]/

M1.6. Section 3.3: "It is used to build segment routing policies when
different SRGB's are used in the fabric
([I-D.ietf-spring-segment-routing-msdc]).”
I’m assuming that the fabric is not the only use case of having different
SRGBs, right?  Make the statement general and not dependent
on I-D.ietf-spring-segment-routing-msdc.

M1.7. Section 8: "This document defines a new BGP attribute in order to
address the use case described in [I-D.ietf-spring-segment-routing-msdc].”
I’m sure that is not the only use case…reword to show it is an example.

M1.8. Section 9: "The BGP Prefix-SID attribute addresses the requirements
introduced in [I-D.ietf-spring-segment-routing-msdc]…”.
draft-ietf-spring-segment-routing-msdc
doesn’t actually present requirements…but an application in the DC...


M2. TLV Definitions:

M2.1. [minor] what is the unit used in the Length?  Bytes, octets, bits

M2.2. Please define a registry and a registration policy for the Flag
fields.


M3. What should be done if a Label-Index TLV is received if an unlabeled
IPv6 prefix or if the IPv6 SID TLV is received with a labeled prefix?  I
assume they MUST be ignored…but please include that in the text.


M4. IPv6 SID TLV

M4.1. Section 3.2 defines this TLV as optional ("IPv6-SID TLV MAY be
present”), ok.  Section 4.2 then says that "If present, then the
receiver assumes
that the originator supports SR on the IPv6 dataplane.”  This seems to
indicate that the purpose of this TLV is not only to advertise an SID, but
to communicate support for SR, is that correct?  Later, 5.2 again says that
the sender "MAY include the IPv6 SID TLV”.  If this TLV is not present, can
the receiver assume that the originator doesn’t support SR?  I’m wondering
about the optional nature of the TLV, it seems to be mandatory if the
sender wants the receiver to know that it supports SR, and whenever an IPv6
SID needs to be advertised (which seems like always when using the IPv6
dataplane).  What am I missing?

M4.2. [nit] s/IPv6-SID/IPv6 SID


M5. Section 4: "A BGP speaker receiving a BGP Prefix-SID attribute from an
EBGP neighbor residing outside the boundaries of the SR domain, SHOULD discard
the attribute unless it is configured…”. If that is the only exception,
then s/SHOULD/MUST

M5.1. The same text is present in 4.2.  If the text in 4 applies to both
dataplanes, then the text in 4.2 is redundant.


M6. In 4.1: "A BGP speaker MAY be locally configured with an
SRGB=[SRGB_Start, SRGB_End].  The preferred method for deriving the SRGB is
a matter of local node configuration.”  Given that the "method for deriving
the SRGB is a matter of local node configuration”, that “MAY” is out of
place since it has no Normative value.  s/MAY/may


M7. Section 4.1 explains the conditions under which the BGP Prefix-SID
attribute should be considered unacceptable, and it says that the receiver
of “an unacceptable BGP Prefix-SID attribute...MUST treat the path as if it
came without a Prefix-SID attribute.”  However, Section 5.1 says that a
"speaker that advertises a path received from one of its neighbors SHOULD
advertise the Prefix-SID received with the path without modification
regardless of whether the Prefix-SID was acceptable”.  I think there is a
Normative contradiction here because the MUST seems to imply that the
attribute is to be dropped (“as if it came without”), but the SHOULD
indicates the opposite.  I can also see how the text could be interpreted
as “just ignore the attribute but forward it”.  Please clarify so there is
no confusion.

M7.1. I assume that the acceptable condition doesn’t just apply to the MPLS
data plane.  It may be clearer if the text in 4.1 was moved to a common
section.

M7.2. Note that the same text (from 5.1) is repeated in 5.2.  It may be
clearer if the specification was in a common place instead.


M8. Section 6: "If the BGP Prefix-SID attribute appears more than once in
an BGP Update message, then, according to [RFC7606], all the occurrences of
the attribute other than the first one SHALL be discarded and the BGP Update
message SHALL continue to be processed.”  Note that rfc7606 doesn’t say
exactly that, instead it says "all the occurrences of the attribute other
than the first one SHALL be discarded and the UPDATE message will continue to
be processed”.  Yes, it’s a slight difference, but it’s not the same.  In
this case, the Normative language is already in rfc7606, so there’s no real
need to repeat it here (if you do, please use “”).  Suggestion:
“…according to rfc7606, only the first occurrence will be considered.”


M9.  If the attribute is malformed then the index or SID in it won’t be
used by the receiver (attribute discard) as specified in Section 6.
Section 4.1 explains how a local label is assigned if the BGP Prefix-SID
attribute is unacceptable.

M9.1. I’m assuming that the local label assignment in 4.1 includes the case
when the attribute is malformed (i.e. not just the unacceptable case).  Is
that true?  Using a local label would result in successfully delivering
the traffic to the destination, but not using the intended SR path, right?
If that is true, then the malformed attribute case would have an effect on
route selection/installation and could result (among other things) in the
traffic taking an unwanted path due to policy, a path that is congested,
etc.…and that is explicitly the case where rfc7606 specifies that attribute
discard MUST NOT be used.  It seems that any action beyond attribute
discard may be too harsh given that a local label can be assigned…but the
current specification ("MUST treat the path as if it came without a
Prefix-SID attribute...MUST assign a local (also called dynamic) label”) is
in conflict with rfc7606.  I would be ok if the document explained the
potential issues and made the local label behavior optional (pending a
discussion in the WG and maybe an update to rfc7606).  BTW, was this
discussed in the WG (I couldn’t find a related discussion in the archive)?

M9.2. What about the IPv6 case?  If the attribute is malformed, then the
receiver won’t have an IPv6 SID to use — again, there seems to be a clear
effect on route selection and installation.


M10. Section 8. (Manageability Considerations).  There’s a Normative
conflict on these two sentences: "By default, a BGP Prefix-SID attribute
SHOULD NOT be originated and attached to a prefix.  The operator MUST be
capable of explicitly enabling the BGP Prefix-SID origination.”  The “MUST"
indicates that the operator has to be involved, but the "SHOULD NOT"
implies that there are cases where it is ok for the operator not to be
involved.


M11. Security Considerations

M11.1. You should mention the Security Considerations of the overall SR
architecture.

M11.2. While I agree with the rest of this section, I think there’s a new
risk that is introduced by the attribute: the modification of the TLVs in
transit.  For example, if one of the transit BGP speakers modifies the
Label Index to make it an unacceptable TLV (according to 4.1) then it would
have the effect of potentially causing the traffic to take a different
path.  I don’t think there’s a mitigation mechanism (specially because the
document describes upfront the unacceptable criteria — which is what opens
this door), but recognizing the modification risk and at least mentioning
that all the routers are part of the same domain (trusted) would be a good
idea.


M12. The Reference to rfc4760 should be Normative.



Minor:

P1. Please update the Requirements Language to use the new template in
rfc8174.

P2. rfc3107 hs been obsoleted by rfc8277

P3. s/as_path/AS_PATH

P4. s/is assumed to be done through/is done through

P5. "As defined in [I-D.ietf-spring-segment-routing-mpls], the index L_I is
an offset in the SRGB.”  The reference should
be I-D.ietf-spring-segment-routing (that is where the index and the SRGB
are explained).

P6. Please be consistent when referring to the new attribute: s/Prefix-SID
attribute/BGP Prefix-SID attribute



Nits:

N1. s/It i assumed/It is assumed
2017-12-21
07 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2017-12-20
07 Alvaro Retana IESG state changed to AD Evaluation from Publication Requested
2017-12-20
07 Alvaro Retana Notification list changed to Susan Hares <shares@ndzh.com>, aretana.ietf@gmail.com from Susan Hares <shares@ndzh.com>
2017-10-17
07 Arjun Sreekantiah New version available: draft-ietf-idr-bgp-prefix-sid-07.txt
2017-10-17
07 (System) New version approved
2017-10-17
07 (System) Request for posting confirmation emailed to previous authors: Arjun Sreekantiah , Stefano Previdi , Acee Lindem , Hannes Gredler , Clarence Filsfils
2017-10-17
07 Arjun Sreekantiah Uploaded new revision
2017-07-16
06 Susan Hares
Shepherd temlate: (per RFC 4858, date 2/24/2012)


(1) What type of RFC?  proposed standard, on the template header

(2) The IESG approval announcement includes …
Shepherd temlate: (per RFC 4858, date 2/24/2012)


(1) What type of RFC?  proposed standard, on the template 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
  Segment Routing (SR) architecture allows a node to steer a packet
  flow through any topological path and service chain by leveraging
  source routing.  The ingress node prepends a SR header to a packet
  containing a set of segment identifiers (SID).  Each SID represents a
  topological or a service-based instruction.  Per-flow state is
  maintained only at the ingress node of the SR domain.

Working Group Summary
WG consensus is strong.  2 companies have implementations (rtbrick and cisco). 
The first WG call came at a bad time, but the subsequent call shows agreement.
final call:
https://www.ietf.org/mail-archive/web/idr/current/msg18257.html

Document Quality
  Existing Implementations of protocol: 2 companies,  4 implementations see:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-prefix-sid%20implementations

rtg-dir QA early review (nits only:
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-prefix-sid-04-rtgdir-early-hopps-2017-03-07-4/
final rtg-dir- Review (due 6/28/2017)
No other documents:

Personnel

Document Shepherd: Susan hares
AD:  Alvaro Retana
RTG-DIR review (1): Christian Hopps
RTG-DIR QA review (2): Bruno Decraene
SEC-DIR early reviiew (3): Brian Weis (due 6/29/2016)  - not completed

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

1) Review document + discussed with co-chair + WG secretary
2) Checked nits (note - next update will fix out of date)
3) Requested RTG-DIR review
4) Check implementation reports


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

No - between IDR and Spring RTG-DIR reviews, chair reviews and implementations,  the depth of the review seems appropriate.

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

SEC-DIR review was requested to see if multi-domain segment routing provided any additional concerns above those of BGP-enabled MPLS.  SEC-DIr response is overdue by 15 days.  The shepherd does not personally perceive any security issues beyond those equivalent to a BGP-enable MPLS.

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

The AD should be aware this is linked to SPRING and MPLS drafts.
This draft indicates MPLS drafts RFC3107 and RFC4760
The MPLS cross review has not been done, but will be started
on 6/15/2017.  Please note that MPLS RFC3107bis has been revised.

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

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/UPZgjGaOAUOGRQGP3QVGY4pXyYI

Hannes Gredler:
https://mailarchive.ietf.org/arch/msg/idr/ll_rycW7FGuHAFRhXwF0rMNghCY

Acee Lindem
https://mailarchive.ietf.org/arch/search/?email_list=idr&q=prefix-sid


Keyur Patel
https://mailarchive.ietf.org/arch/msg/idr/4iBE_Zkz4OwBtaTY-O84OA-NgU4

Stefano Previdi (sprevidi)"
https://mailarchive.ietf.org/arch/msg/idr/QaK3Cb_oeKBIELAUhUpyQn8RlOM

Saikat Ray
https://mailarchive.ietf.org/arch/msg/idr/BsW2BKYy4hwcEOI5JRNXmfp2ge4

Arjun Sreekantiah
https://mailarchive.ietf.org/arch/msg/idr/xtOYnEpupBEw9ZgGTUfGsaAifcc

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

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

Solid.  The link to MPLS and Spring has caused significant review.

(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 appeals or discontent related to draft.

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

ID nits show that the current version has a back dated:
  draft-ietf-idr-bgpls-segment-routing-epe-11

We are progressing both documents in parallel to the IESG.

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

No

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

All nomative references are RFCs.
Please note that RFC3107 is being revised by the MPLS WG.

(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 changes.  It will create an additional IDR Attribute, but this is an addition
rather than a change to earlier IDR specifications.

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



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

All registries are standards registries and not Designated Expert review.

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

None needed.
2017-07-16
06 Susan Hares Responsible AD changed to Alvaro Retana
2017-07-16
06 Susan Hares IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2017-07-16
06 Susan Hares IESG state changed to Publication Requested
2017-07-16
06 Susan Hares IESG process started in state Publication Requested
2017-07-16
06 Susan Hares Changed consensus to Yes from Unknown
2017-07-16
06 Susan Hares Intended Status changed to Proposed Standard from None
2017-07-16
06 Susan Hares Changed document writeup
2017-07-16
06 Susan Hares Changed document writeup
2017-06-24
06 Tero Kivinen Request for Early review by SECDIR is assigned to Brian Weis
2017-06-24
06 Tero Kivinen Request for Early review by SECDIR is assigned to Brian Weis
2017-06-16
06 Stefano Previdi New version available: draft-ietf-idr-bgp-prefix-sid-06.txt
2017-06-16
06 (System) New version approved
2017-06-16
06 (System) Request for posting confirmation emailed to previous authors: Stefano Previdi , idr-chairs@ietf.org, Arjun Sreekantiah , Acee Lindem , Hannes Gredler , Clarence Filsfils
2017-06-16
06 Stefano Previdi Uploaded new revision
2017-06-16
05 Susan Hares Changed document writeup
2017-06-16
05 Bruno Decraene Request for Early review by RTGDIR Completed: Has Issues. Reviewer: Bruno Decraene.
2017-06-15
05 Susan Hares Changed document writeup
2017-06-15
05 Susan Hares Requested Early review by SECDIR
2017-06-15
05 Susan Hares Changed document writeup
2017-06-15
05 Susan Hares Changed document writeup
2017-06-15
05 Susan Hares IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2017-06-15
05 Jonathan Hardwick Request for Early review by RTGDIR is assigned to Bruno Decraene
2017-06-15
05 Jonathan Hardwick Request for Early review by RTGDIR is assigned to Bruno Decraene
2017-06-14
05 Susan Hares Requested Early review by RTGDIR
2017-04-20
05 Stefano Previdi New version available: draft-ietf-idr-bgp-prefix-sid-05.txt
2017-04-20
05 (System) New version approved
2017-04-20
05 (System)
Request for posting confirmation emailed to previous authors: Stefano Previdi , idr-chairs@ietf.org, Arjun Sreekantiah , Saikat Ray , Keyur Patel , Acee Lindem , …
Request for posting confirmation emailed to previous authors: Stefano Previdi , idr-chairs@ietf.org, Arjun Sreekantiah , Saikat Ray , Keyur Patel , Acee Lindem , Hannes Gredler , Clarence Filsfils
2017-04-20
05 Stefano Previdi Uploaded new revision
2017-03-07
04 Christian Hopps Request for Early review by RTGDIR Completed: Has Nits. Reviewer: Christian Hopps.
2017-03-06
04 Susan Hares IETF WG state changed to In WG Last Call from WG Document
2017-02-22
04 Jonathan Hardwick Request for Early review by RTGDIR is assigned to Christian Hopps
2017-02-22
04 Jonathan Hardwick Request for Early review by RTGDIR is assigned to Christian Hopps
2017-02-21
04 Susan Hares Requested Early review by RTGDIR
2017-02-21
04 Susan Hares Notification list changed to Susan Hares <shares@ndzh.com>
2017-02-21
04 Susan Hares Document shepherd changed to Susan Hares
2016-12-12
04 Stefano Previdi New version available: draft-ietf-idr-bgp-prefix-sid-04.txt
2016-12-12
04 (System) New version approved
2016-12-12
04 (System)
Request for posting confirmation emailed to previous authors: "Arjun Sreekantiah" , "Saikat Ray" , "Hannes Gredler" , "Clarence Filsfils" , "Stefano Previdi" , "Keyur Patel" …
Request for posting confirmation emailed to previous authors: "Arjun Sreekantiah" , "Saikat Ray" , "Hannes Gredler" , "Clarence Filsfils" , "Stefano Previdi" , "Keyur Patel" , idr-chairs@ietf.org, "Acee Lindem"
2016-12-12
04 Stefano Previdi Uploaded new revision
2016-06-16
03 Stefano Previdi New version available: draft-ietf-idr-bgp-prefix-sid-03.txt
2015-12-21
02 Stefano Previdi New version available: draft-ietf-idr-bgp-prefix-sid-02.txt
2015-10-14
01 Stefano Previdi New version available: draft-ietf-idr-bgp-prefix-sid-01.txt
2015-08-28
00 Susan Hares This document now replaces draft-keyupate-idr-bgp-prefix-sid instead of None
2015-08-27
00 Stefano Previdi New version available: draft-ietf-idr-bgp-prefix-sid-00.txt