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 |