OSPF Extensions for Segment Routing
draft-ietf-ospf-segment-routing-extensions-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) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-08-20
|
27 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2019-07-02
|
27 | (System) | RFC Editor state changed to REF from EDIT |
2019-05-28
|
27 | (System) | RFC Editor state changed to EDIT from MISSREF |
2018-12-05
|
27 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-27.txt |
2018-12-05
|
27 | (System) | Posted submission manually |
2018-11-20
|
26 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-26.txt |
2018-11-20
|
26 | (System) | Posted submission manually |
2018-04-20
|
25 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-25.txt |
2018-04-20
|
25 | (System) | Posted submission manually |
2018-03-27
|
24 | Alvaro Retana | Notification list changed to "Acee Lindem" <acee@cisco.com>, aretana.ietf@gmail.com from "Acee Lindem" <acee@cisco.com> |
2018-03-27
|
24 | Alvaro Retana | Shepherding AD changed to Alvaro Retana |
2017-12-28
|
24 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2017-12-20
|
24 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2017-12-19
|
24 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2017-12-19
|
24 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events' |
2017-12-18
|
24 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2017-12-18
|
24 | (System) | RFC Editor state changed to MISSREF |
2017-12-18
|
24 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2017-12-18
|
24 | (System) | Announcement was received by RFC Editor |
2017-12-18
|
24 | (System) | IANA Action state changed to In Progress |
2017-12-18
|
24 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2017-12-18
|
24 | Amy Vezza | IESG has approved the document |
2017-12-18
|
24 | Amy Vezza | Closed "Approve" ballot |
2017-12-18
|
24 | Amy Vezza | Ballot approval text was generated |
2017-12-18
|
24 | Alia Atlas | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed |
2017-12-14
|
24 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2017-12-14
|
24 | Michelle Cotton | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2017-12-14
|
24 | Alexey Melnikov | [Ballot comment] The document never specifies byte order for length fields. |
2017-12-14
|
24 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss |
2017-12-14
|
24 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2017-12-14
|
24 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-24.txt |
2017-12-14
|
24 | (System) | New version approved |
2017-12-14
|
24 | (System) | Request for posting confirmation emailed to previous authors: Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi … Request for posting confirmation emailed to previous authors: Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi , Rob Shakir |
2017-12-14
|
24 | Peter Psenak | Uploaded new revision |
2017-12-14
|
23 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2017-12-13
|
23 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2017-12-13
|
23 | Alvaro Retana | [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana |
2017-12-13
|
23 | Ben Campbell | [Ballot comment] Substantive Comments: - Requirements Language: There are a few instances of 2119 keywords in lower case. Please consider if those are meant to … [Ballot comment] Substantive Comments: - Requirements Language: There are a few instances of 2119 keywords in lower case. Please consider if those are meant to be normative. If not, then please use the boilerplate from RFC 8184, which explicitly excludes lower case instances as normative keywords. -3.1, 2nd to last paragraph: Why aren't the 3 "SHOULDs" "MUSTs"? It seems like these might have an impact on interoperability, or at least predictable behavior in edge conditions. -3.4: (same comment as for 3.1) Editorial Comments and Nits: -1, first paragraph: There are a lot of ideas packed into that paragraph. It's not clear to me which the "For example" sentences means to exemplify. -3.3, 2nd to last paragraph: Why is "NOT" capitalized? |
2017-12-13
|
23 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2017-12-13
|
23 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2017-12-13
|
23 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2017-12-13
|
23 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2017-12-13
|
23 | Suresh Krishnan | [Ballot comment] * It would be good to clarify that this document is intended for OSPFv2 only (probably in the title and/or abstract). It may … [Ballot comment] * It would be good to clarify that this document is intended for OSPFv2 only (probably in the title and/or abstract). It may also be worthwhile for the document and/or the Shepherd writeup to explain why the WG decided to separate the OSPFv3 extensions into a different document. * I think RFC2328 should be a Normative Reference and not an informative reference. |
2017-12-13
|
23 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2017-12-13
|
23 | Warren Kumari | [Ballot comment] I'm not sure that Susan Hare's OpsDir review (from -17) was addressed, unless it is: Reception of malformed TLV or Sub-TLV SHOULD … [Ballot comment] I'm not sure that Susan Hare's OpsDir review (from -17) was addressed, unless it is: Reception of malformed TLV or Sub-TLV SHOULD be counted and/or logged for further analysis. Logging of malformed TLVs and Sub-TLVs should be rate-limited to prevent a Denial of Service (DoS) attack (distributed or otherwise) from overloading the OSPF control plane." If this text was intended to cover it, I think it falls short - it is better than nothing, but I think could be clearer |
2017-12-13
|
23 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2017-12-13
|
23 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2017-12-13
|
23 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2017-12-13
|
23 | Alexey Melnikov | [Ballot discuss] This is generally a clearly written document, but it needs a few minor changes before I can recommend its approval for publication. 1) … [Ballot discuss] This is generally a clearly written document, but it needs a few minor changes before I can recommend its approval for publication. 1) In Section 3.2: o When a router receives multiple overlapping ranges, it MUST conform to the procedures defined in [I-D.ietf-spring-conflict-resolution]. RFC 2119 keyword usage makes the reference a Normative reference, yet it is currently listed as informative. 3.4. SRMS Preference TLV The Segment Routing Mapping Server Preference TLV (SRMS Preference TLV) is used to advertise a preference associated with the node that acts as an SR Mapping Server. The role of an SRMS is described in [I-D.ietf-spring-segment-routing-ldp-interop]. As draff-ietf-spring-segment-routing-ldp-interop needs to be read in order to understand what SR Mapping Server is, this reference must also be Normative. SRMS preference is defined in [I-D.ietf-spring-conflict-resolution]. This just confirms that this reference must be Normative. 2) In Section 3.1: When multiple SR-Algorithm TLVs are received from a given router, the receiver SHOULD use the first occurrence of the TLV in the Router Information LSA. If the SR-Algorithm TLV appears in multiple Router Information LSAs that have different flooding scopes, the SR- Algorithm TLV in the Router Information LSA with the area-scoped flooding scope SHOULD be used. If the SR-Algorithm TLV appears in multiple Router Information LSAs that have the same flooding scope, the SR-Algorithm TLV in the Router Information (RI) LSA with the numerically smallest Instance ID SHOULD be used and subsequent instances of the SR-Algorithm TLV SHOULD be ignored. In the last 2 sentences: why are you using SHOULD (twice) instead of MUST? This seems to affect interoperability. (I think there is similar text in another section.) |
2017-12-13
|
23 | Alexey Melnikov | [Ballot comment] Several TLVs have "Reserved" fields, yet you never explain what "Reserved" means. You do explain what reserved flags mean in some of them. … [Ballot comment] Several TLVs have "Reserved" fields, yet you never explain what "Reserved" means. You do explain what reserved flags mean in some of them. I suggest either explicitly explaining what Reserved means in each case or specify this in the terminology section near the beginning of the document. The document never specifies byte order for length fields. The acronym NSSA is never explained and it has no reference. |
2017-12-13
|
23 | Alexey Melnikov | Ballot comment and discuss text updated for Alexey Melnikov |
2017-12-13
|
23 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2017-12-13
|
23 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-23.txt |
2017-12-13
|
23 | (System) | New version approved |
2017-12-13
|
23 | (System) | Request for posting confirmation emailed to previous authors: Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi … Request for posting confirmation emailed to previous authors: Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi , Rob Shakir |
2017-12-13
|
23 | Peter Psenak | Uploaded new revision |
2017-12-12
|
22 | Amanda Baber | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2017-12-12
|
23 | (System) | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2017-12-12
|
22 | Alexey Melnikov | [Ballot discuss] This is generally a fine document, but it needs a few minor changes that need doing before it is approved for publication: |
2017-12-12
|
22 | Alexey Melnikov | [Ballot Position Update] New position, Discuss, has been recorded for Alexey Melnikov |
2017-12-12
|
22 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2017-12-12
|
22 | Alia Atlas | IESG state changed to IESG Evaluation from Waiting for Writeup |
2017-12-12
|
22 | Alia Atlas | Ballot has been issued |
2017-12-12
|
22 | Alia Atlas | [Ballot Position Update] New position, Yes, has been recorded for Alia Atlas |
2017-12-12
|
22 | Alia Atlas | Created "Approve" ballot |
2017-12-12
|
22 | Alia Atlas | Ballot writeup was changed |
2017-12-05
|
22 | Dan Romascanu | Request for Telechat review by GENART Completed: Ready. Reviewer: Dan Romascanu. Sent review to list. |
2017-11-30
|
22 | Jean Mahoney | Request for Telechat review by GENART is assigned to Dan Romascanu |
2017-11-30
|
22 | Jean Mahoney | Request for Telechat review by GENART is assigned to Dan Romascanu |
2017-11-27
|
22 | Alia Atlas | Placed on agenda for telechat - 2017-12-14 |
2017-11-27
|
22 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-22.txt |
2017-11-27
|
22 | (System) | New version approved |
2017-11-27
|
22 | (System) | Request for posting confirmation emailed to previous authors: Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi … Request for posting confirmation emailed to previous authors: Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi , Rob Shakir |
2017-11-27
|
22 | Peter Psenak | Uploaded new revision |
2017-10-24
|
21 | Alia Atlas | This is waiting to progress at the same telechat as the related SPRING documents. Ideally, the associated isis draft would also be ready to progress … This is waiting to progress at the same telechat as the related SPRING documents. Ideally, the associated isis draft would also be ready to progress then. |
2017-10-24
|
21 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-21.txt |
2017-10-24
|
21 | (System) | New version approved |
2017-10-24
|
21 | (System) | Request for posting confirmation emailed to previous authors: Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi … Request for posting confirmation emailed to previous authors: Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi , Rob Shakir |
2017-10-24
|
21 | Peter Psenak | Uploaded new revision |
2017-10-20
|
20 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2017-10-20
|
20 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-20.txt |
2017-10-20
|
20 | (System) | New version approved |
2017-10-20
|
20 | (System) | Request for posting confirmation emailed to previous authors: Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi … Request for posting confirmation emailed to previous authors: Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi , Rob Shakir |
2017-10-20
|
20 | Peter Psenak | Uploaded new revision |
2017-10-16
|
19 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2017-10-13
|
19 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2017-10-12
|
19 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2017-10-12
|
19 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-ospf-segment-routing-extensions-19. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-ospf-segment-routing-extensions-19. If any part of this review is inaccurate, please let us know. The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Services Operator understands that, upon approval of this document, there are four actions which we must complete. First, in the OSPF Router Information (RI) TLVs registry on the Open Shortest Path First (OSPF) Parameters registry page located at https://www.iana.org/assignments/ospf-parameters/ The temporary registration for value 8, SR-Algorithm TLV, will be made permanent and its reference changed to [ RFC-to-be ]. The temporary registration for value 9, SID/Label Range TLV, will be made permanent and its reference changed to [ RFC-to-be ]. IANA Question --> is any action to be taken with the temporary registration for value 12, Node MSD TLV? Two additional registrations are to be made as follows Value: [ TBD-at-registration ] TLV Name: SR Local Block TLV Reference: [ RFC-to-be ] Value: [ TBD-at-registration ] TLV Name: SRMS Preference TLV Reference: [ RFC-to-be ] We note that the authors suggest values 12 and 13 for these two registrations, however 12 is already allocated via a temporary registration (see above). Second,in theOSPFv2 Extended Prefix Opaque LSA TLVs registry on the Open Shortest Path First v2 (OSPFv2) Parameters registry page located at: https://www.iana.org/assignments/ospfv2-parameters/ the temporary registration for value 2, OSPF Extended Prefix Range TLV, will be made permanent and its reference will be changed to [ RFC-to-be ]. Third, in the OSPFv2 Extended Prefix TLV Sub-TLVs also on the Open Shortest Path First v2 (OSPFv2) Parameters registry page located at: https://www.iana.org/assignments/ospfv2-parameters/ The temporary registration for value 1, SID/Label Sub-TLV, will be made permanent and its reference will be changed to [ RFC-to-be ]. The temporary registration for value 2, Prefix SID Sub-TLV, will be made permanent and its reference will be changed to [ RFC-to-be ]. IANA Question --> is any action to be taken for the temporary registrations for values 3, 4, 5, 6, 7 adn 8 in this registry? Fourth, in the OSPFv2 Extended Link TLV Sub-TLVs registry also on the Open Shortest Path First v2 (OSPFv2) Parameters registry page located at: https://www.iana.org/assignments/ospfv2-parameters/ the following temporary registrations will be made permanent and their references changed to [ RFC-to-be ] as follows: Value: 1 Description: SID/Label Sub-TLV Reference: [ RFC-to-be ] Value: 2 Description: Adj-SID Sub-TLV Reference: [ RFC-to-be ] Value: 3 Description: LAN Adj-SID/Label Sub-TLV Reference: [ RFC-to-be ] The IANA Services Operator understands that these four actions are the only ones required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thank you, Sabrina Tanamal IANA Services Specialist |
2017-10-05
|
19 | Dan Romascanu | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Dan Romascanu. Sent review to list. |
2017-10-05
|
19 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker |
2017-10-05
|
19 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker |
2017-10-04
|
19 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Susan Hares |
2017-10-04
|
19 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Susan Hares |
2017-10-04
|
19 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
2017-10-04
|
19 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
2017-09-29
|
19 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2017-09-29
|
19 | Amy Vezza | The following Last Call announcement was sent out (ends 2017-10-13): From: The IESG To: IETF-Announce CC: akatlas@gmail.com, draft-ietf-ospf-segment-routing-extensions@ietf.org, ospf@ietf.org, Acee Lindem , … The following Last Call announcement was sent out (ends 2017-10-13): From: The IESG To: IETF-Announce CC: akatlas@gmail.com, draft-ietf-ospf-segment-routing-extensions@ietf.org, ospf@ietf.org, Acee Lindem , acee@cisco.com, ospf-chairs@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (OSPF Extensions for Segment Routing) to Proposed Standard The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'OSPF Extensions for Segment Routing' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-10-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the OSPF extensions required for Segment Routing. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2808/ https://datatracker.ietf.org/ipr/2233/ https://datatracker.ietf.org/ipr/2401/ |
2017-09-29
|
19 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2017-09-29
|
19 | Alia Atlas | Last call was requested |
2017-09-29
|
19 | Alia Atlas | Last call announcement was generated |
2017-09-29
|
19 | Alia Atlas | Ballot approval text was generated |
2017-09-29
|
19 | Alia Atlas | Ballot writeup was generated |
2017-09-29
|
19 | Alia Atlas | IESG state changed to Last Call Requested from AD Evaluation::Revised I-D Needed |
2017-09-18
|
19 | Alia Atlas | Still discussing the edge conditions for the SRMS mapping where the OSPF document special cases detecting that the prefix is announced by a downstream neighbor … Still discussing the edge conditions for the SRMS mapping where the OSPF document special cases detecting that the prefix is announced by a downstream neighbor and therefore does PHP in the forwarding plane. The reasoning behind this isn't covered in draft-ietf-spring-ldp-interop-08 nor in this draft. |
2017-09-18
|
19 | Alia Atlas | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2017-08-25
|
19 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2017-08-25
|
19 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-19.txt |
2017-08-25
|
19 | (System) | New version approved |
2017-08-25
|
19 | (System) | Request for posting confirmation emailed to previous authors: Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi … Request for posting confirmation emailed to previous authors: Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi , Rob Shakir |
2017-08-25
|
19 | Peter Psenak | Uploaded new revision |
2017-08-11
|
18 | Alia Atlas | 1) In Sec 3.1, "If the SR-Algorithm TLV appears in multiple Router Information LSAs that have different flooding scopes, the SR- Algorithm TLV … 1) In Sec 3.1, "If the SR-Algorithm TLV appears in multiple Router Information LSAs that have different flooding scopes, the SR- Algorithm TLV in the Router Information LSA with the narrowest flooding scope SHOULD be used. " Given that the area-scope is REQUIRED - shouldn't this also prefer the area-scope? Is there future-proofing being done? 2) In Sec 3.4: "For the purpose of the SRMS Preference TLV advertisement, AS-scoped flooding is REQUIRED. This is because SRMS servers can be located in a different area then consumers of the SRMS advertisements. If the SRMS advertisements from the SRMS server are only used inside the SRMS server's area, area-scoped flooding may be used." REQUIRED is like MUST - I think you mean "AS-scoped flooded SHOULD be used.... area-scoped flooding MAY be used." 3) In Sec 4. "The Segment Routing Mapping Server, which is described in [I-D.ietf-spring-segment-routing-ldp-interop], is an example where we need a single advertisement to advertise SIDs for multiple prefixes from a contiguous address range." I've read through the vastly improved section (thank you) in draft-ietf-spring-segment-routing-ldp-interop-08 and I don't see any explanation for why a contiguous address range is needed. I can speculate that a primary purpose is to advertise SIDs for the loopback addresses of routers that don't support SR - and those loopback addresses are likely to be allocated from a contiguous range (though why some wouldn't be supporting SR and cause gaps isn't clear). 4) Sec 5: In the end of Sec 4.2 in draft-ietf-spring-segment-routing-ldp-interop-08, it says "Note: SR mappings advertisements cannot set Penultimate Hop Popping. In the previous example, P6 requires the presence of the segment 103 such as to map it to the LDP label 1037. For that reason, the P flag available in the Prefix-SID is not available in the Remote-Binding SID." However, in this draft Sec 5 gives the following rules: "As the Mapping Server does not specify the originator of a prefix advertisement, it is not possible to determine PHP behavior solely based on the Mapping Server advertisement. However, PHP behavior SHOULD be done in following cases: The Prefix is intra-area type and the downstream neighbor is the originator of the prefix. The Prefix is inter-area type and downstream neighbor is an ABR, which is advertising prefix reachability and is also generating the Extended Prefix TLV with the A-flag set for this prefix as described in section 2.1 of [RFC7684]. The Prefix is external type and downstream neighbor is an ASBR, which is advertising prefix reachability and is also generating the Extended Prefix TLV with the A-flag set for this prefix as described in section 2.1 of [RFC7684]. These seem to be contradictory. 5) In Sec 7.1, it says "Multiple Mapping Servers can advertise Prefix-SIDs for the same prefix, in which case the same Prefix-SID MUST be advertised by all of them." What is forcing this constraint? Does it work if the Prefix-SID is an index into an SRGB or SRLB that is not the same value globally? I don't see it specified in Sec 7.2 of draft-ietf-spring-segment-routing-ldp-interop-08? |
2017-08-11
|
18 | Alia Atlas | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2017-07-24
|
18 | Acee Lindem | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? A Standards Track RFC is being requested and is indicated in the title page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes the OSPFv2 extensions for segment routing including Prefix-SID, Adjacency-SID, and Binding-SID. The extensions are based on RFC 7770. Working Group Summary: The Working Group discussion has been dominated by the initial vendors that implemented the specification (Juniper, Cisco, and Nokia). We've gone through several iterations over the last two and half years. The document has completed two separate IPR polls. It is in its second Working Group last call due to some additional protocol encodings and clarifications on the handling of error situations. The second Working Group last call is preceding without questions or significant comments. The ERO and binding-SID extensions were removed due to AD comments and these changes were Working Group last called. Document Quality: The document has been implemented by a number of vendors (refer to the implementation status section) and has been stable now for a few months. In fact, the only changes have been edits and clarifications based on WG last-call and chair review. Personnel: Acee Lindem is the Document Shepherd. Alia Atlas is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has reviewed each revision of the document and followed the discussion on the OSPF mailing list. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes - there is an IPR disclosure on non-WG version and two more on the WG version of the document. The terms are such that the patent will not be asserted unless the party asserts a patent against the holder (forget the term for this). https://datatracker.ietf.org/ipr/2233/ https://datatracker.ietf.org/ipr/2401/ https://datatracker.ietf.org/ipr/2808/ There have been three polls for knowledge of IPR with all authors responding. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is consensus from the WG and others outside the WG that this document can progress. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nits are all resolved. There are 7 comments from Idnits bug none of them are indicative of issues in the draft. For example, IPv6 examples are suggested but OSPFv2 only supports IPv4. The document does have seven authors. All the authors have played in active role in the development of the standard including periodic segment routing design team meetings. All of the authors have responded promptly to IPR polls. At least three of the authors represented independent implementations. Here are their roles and responsibilities: Peter Psenak - Main document editor and OSPFv2 segment routing encoding point-of-contact. Stefano Previdi - Main document editor for IS-IS segment routing and active participant in all discussions and design meetings. Clarence Filsfils - Segment routing design team lead and orgainization of discussions. Hannes Gredler - Member of OSPFv2 segment routing design team, author or merged draft, and representative of Juniper implementation. Rob Shakir - Member of OSPFv2 segment routing design team. Representative of operator's perspective. Wim Henderick - Member of OSPFv2 segment routing design team. Active participation in discussions and representative of Nokia's implementation. Jeff Tantsura - Member of OSPFv2 segment routing design team. Active participation in discussions and representative of Ericsson's implementation. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The Segment Routing extensions required allocation of a number of code points from the registries created for RFC 7770. These code points were pre-allocated through IANA early allocation as described in RFC 7120. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. |
2017-07-24
|
18 | Acee Lindem | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? A Standards Track RFC is being requested and is indicated in the title page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes the OSPFv2 extensions for segment routing including Prefix-SID, Adjacency-SID, and Binding-SID. The extensions are based on RFC 7770. Working Group Summary: The Working Group discussion has been dominated by the initial vendors that implemented the specification (Juniper, Cisco, and Nokia). We've gone through several iterations over the last two and half years. The document has completed two separate IPR polls. It is in its second Working Group last call due to some additional protocol encodings and clarifications on the handling of error situations. The second Working Group last call is preceding without questions or significant comments. The ERO and binding-SID extensions were removed due to AD comments and these changes were Working Group last called. Document Quality: The document has been implemented by a number of vendors (refer to the implementation status section) and has been stable now for a few months. In fact, the only changes have been edits and clarifications based on WG last-call and chair review. Personnel: Acee Lindem is the Document Shepherd. Alia Atlas is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has reviewed each revision of the document and followed the discussion on the OSPF mailing list. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes - there is an IPR disclosure on non-WG version and two more on the WG version of the document. The terms are such that the patent will not be asserted unless the party asserts a patent against the holder (forget the term for this). https://datatracker.ietf.org/ipr/2233/ https://datatracker.ietf.org/ipr/2401/ https://datatracker.ietf.org/ipr/2808/ There have been three polls for knowledge of IPR with all authors responding. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is consensus from the WG and others outside the WG that this document can progress. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nits are all resolved. There are 7 comments from Idnits bug none of them are indicative of issues in the draft. For example, IPv6 examples are suggested but OSPFv2 only supports IPv4. The document does have seven authors. All the authors have played in active role in the development of the standard including periodic segment routing design team meetings. All of the authors have responded promptly to IPR polls. At least three of the authors represented independent implementations. Here are their roles and responsibilities: Peter Psenak - Main document editor and OSPFv2 segment routing encoding point-of-contact. Stefano Previdi - Main document editor for IS-IS segment routing and active participant in all discussions and design meetings. Clarence Filsfils - Segment routing design team lead and orgainization of discussions. Hannes Gredler - Member of OSPFv2 segment routing design team, author or merged draft, and representative of Juniper implementation. Rob Shakir - Member of OSPFv2 segment routing design team. Representative of operator perspective. Wim Henderick - Member of OSPFv2 segment routing design team. Active participation in discussions and representative of Nokia's implementation. Jeff Tantsura - Member of OSPFv2 segment routing design team. Active participation in discussions and representative of Ericsson's implementation. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The Segment Routing extensions required allocation of a number of code points from the registries created for RFC 7770. These code points were pre-allocated through IANA early allocation as described in RFC 7120. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. |
2017-07-18
|
18 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-18.txt |
2017-07-18
|
18 | (System) | New version approved |
2017-07-18
|
18 | (System) | Request for posting confirmation emailed to previous authors: Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi … Request for posting confirmation emailed to previous authors: Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi , Rob Shakir |
2017-07-18
|
18 | Peter Psenak | Uploaded new revision |
2017-07-02
|
17 | Susan Hares | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Susan Hares. |
2017-06-23
|
17 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2017-06-23
|
17 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-17.txt |
2017-06-23
|
17 | (System) | New version approved |
2017-06-23
|
17 | (System) | Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils … Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , ospf-chairs@ietf.org, Rob Shakir |
2017-06-23
|
17 | Peter Psenak | Uploaded new revision |
2017-06-19
|
16 | Min Ye | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: John Drake. |
2017-05-31
|
16 | Min Ye | Request for Last Call review by RTGDIR is assigned to John Drake |
2017-05-31
|
16 | Min Ye | Request for Last Call review by RTGDIR is assigned to John Drake |
2017-05-31
|
16 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Susan Hares |
2017-05-31
|
16 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Susan Hares |
2017-05-30
|
16 | Alia Atlas | Requested Last Call review by RTGDIR |
2017-05-30
|
16 | Alia Atlas | Requested Last Call review by OPSDIR |
2017-05-30
|
16 | Alia Atlas | As is customary, I have done my AD review of draft-ietf-ospf-segment-routing-extensions-16 once publication has been requested. First, I would like to thank the editors & … As is customary, I have done my AD review of draft-ietf-ospf-segment-routing-extensions-16 once publication has been requested. First, I would like to thank the editors & many authors, Peter, Stefano, Clarence, Hannes, Rob, Wim & Jeff, for the work that they have put in so far and the remaining work that is greatly needed. While there are a great many issues to be handled, they fall primarily into three categories. The first is simply not going through and tightening up the details; for example, stating that the length of a TLV is variable provides no meaning. The second is that the technical documents from SPRING that this draft depends on do not adequately describe the use of the advertised information (SID/Label Binding TLV) or some of the concepts (e.g. SR Mapping Server). The third is a more common set of handling error cases and adding clarity to the intended behavior. I do not see issues with the encodings but I do see fragility with the unstated assumptions and behaviors. The draft describes encodings, but very little of the handling, behaviors, or meaning - and the references do not provide adequate detail. I have spent all day (and evening) doing this review and I am quite disappointed and concerned about the document. I would strongly recommend having sharing the next WGLC with the SPRING working group; perhaps more eyes will help with the discrepancies. I have not yet decided what to do about the "early" IANA allocation - which has now existed for this draft for 3 years. I do know that there are implementations, but I am currently seeing the failure of this work to successfully complete as an example of an issue with providing early allocations. MAJOR ISSUES: 1) This draft has 7 authors. The limit for authors & editors is 5, as is clearly stated in RFC 7322 Sec 4.1.1 and has been the case for well over a decade, unless there are extraordinary circumstances. Is there a reason to not simply list the active editor and move the others to contributors? One of the authors is already listed there. I regret that failure to deal earlier with this long-standing IETF policy will be delaying progressing the draft. 2) This expired individual draft(draft-minto-rsvp-lsp-egress-fast-protection-03) is listed as Informative - but IS ACTUALLY NORMATIVE since it DEFINES the "M-bit - When the bit is set, the binding represents a mirroring context as defined in [I-D.minto-rsvp-lsp-egress-fast-protection]." Unfortunately, when I look there for the definition of a mirroring context, it doesn't exists. 3) The following Informative references expired several years ago and - being individual drafts - do not appear to convey the SPRING or TEAS WG consensus. a) draft-filsfils-spring-segment-routing-ldp-interop-03 was replaced with draft-ietf-spring-segment-routing-ldp-interop-07 and there are considerable differences. b) It is unclear what happened to draft-filsfils-spring-segment-routing-use-cases-01, but I do not see any successor - or reason for this individual draft to explain the OSPFv2 extensions more than work from the SPRING WG. 4) Sec 3.3: Is it ok to advertise an SRLB TLV without advertising the SR-Algorithm TLV? What is the expected behavior and assumptions by the receiver? 5) Sec 3.4: What happens if an SRMS Preference TLV is advertised without an SR-Algorithm TLV in the same scope? I see that it says "For the purpose of the SRMS Preference Sub-TLV advertisement, AS scope flooding is required." but also provides for area scope flooding. Some words clarifying the expected behavior would be useful. 6) Sec 5: "In such case, MPLS EXP bits of the Prefix-SID are not preserved for the final destination (the Prefix-SID being removed)." I am quite startled to see an assumption that MPLS Pipe mode is being forced as part of specifying PHP mode! This will also break any ECN or 3-color marking that has affected the MPLS EXP bits. I would like to see and understand a clear justification for why short-pipe mode is being required instead of Uniform (or up to implementation/configuration.). Basically, this sentence means that transport considerations are a necessary section - which is completely inappropriate in an IGP draft. 7) Sec 6: This section defines the SID/Label Binding sub-TLV - which appears to be a way to advertise an explicit path - and has a SID/Label by which the path can be entered. How and what state is set up by the sending router to create the indicated segment is completely unclear. I have hunted through draft-ietf-spring-segment-routing, draft-ietf-spring-segment-routing-mpls, and draft-ietf-spring-segment-routing-ldp-interop, RFC7855, and draft-ietf-isis-segment-routing-extensions. As far as I can tell, NONE of them clearly describe the details of where and why this advertising is needed. Obviously, this mechanism does allow the potential shortening of the MPLS label stack at the cost of advertising multi-hop explicit path segments across the entire area or AS. There MUST be a normative description of what the sending router will do when a packet is received with the specified label. 8) Sec 4: "The Segment Routing Mapping Server, which is described in [I-D.filsfils-spring-segment-routing-ldp-interop]" Where precisely is an SRMS and its behavior/role actually defined? draft-ietf-spring-segment-routing-ldp-interop-07 claims:"SR to LDP interworking requires a SRMS as defined in [I-D.ietf-isis-segment-routing-extensions]." but that wouldn't be appropriate, of course, and it isn't there either! draft-ietf-spring-conflict-resolution-04 talks about SRMS, but doesn't define it. draft-ietf-spring-segment-routing-11 mentions in Sec 3.5.1 that "A Remote-Binding SID S advertised by the mapping server M" and refers to the ldp-interop draft for further details - but obviously not about an SRMS. Minor Issues: 1) In Sec 3.1, it says: "The SR-Algorithm TLV is optional. It MUST only be advertised once in the Router Information Opaque LSA. If the SID/Label Range TLV, as defined in Section 3.2, is advertised, then the SR-Algorithm TLV MUST also be advertised." Please provide a pointer in the text to the behavior for a receiving router if one or both of these are violated? For the requirement to advertise the SR-Algorithm TLV, please clarify that this is in the same RI LSA as the SID/Label Range TLV was advertised & with the same scope. What does it mean, in terms of the receiving router, to determine that the sending router supports SR or not - given the possibility of receiving other SR-related TLVS in an RI LSA without getting an SR-Algorithm TLV? 2) Sec 3.1: The SR-Algorithm TLV simply defines "Length: Variable". Given that advertising Algorithm 0 is required, I'm fairly sure that the Length has to be a minimum of 1 - and, to prevent overrun & weird issues, let's have a reasonable maximum (for instance, 24) too. It wouldn't hurt to remind readers that the length is just that of the value field - though experienced OSPF implementers will know that. 3) Sec 3.1 & Sec 3.2 & Sec 3.3: "For the purpose of SR-Algorithm TLV advertisement, area scope flooding is required." and "For the purpose of SID/Label Range TLV advertisement, area scope flooding is required." and "For the purpose of SR Local Block Sub-TLV TLV advertisement, area scope flooding is required." Please capitalize REQUIRED as per RFC 2119. Otherwise, please explain behavior when area scope isn't used. 4) Sec 3.2: The SID/Label Range TLV doesn't indicate that include a SID/Label sub-TLV is required - but I don't understand how it could be interpreted otherwise; nor does it indicate what to do if there are multiple SID/Label sub-TLVs included in a single SID/Label Range TLV. Again "Length" is just defined as variable. In this case, it clearly can't be less than 11 (probably 12, assuming padding to the 32-bit boundary). It would be useful to have an upper-bound on length, but at least here I can see the argument that meaningful flexibility is provided for. 5) SID index is used without introduction in Sec 3.2. It isn't defined in the terminology of draft-ietf-spring-segment-routing-11 and the other uses of it in this document aren't enough to clearly define it. Please add at least a description of its meaning before use - in a terminology section, if necessary. 6) Sec 3.2: "The originating router advertises the following ranges: Range 1: [100, 199] Range 2: [1000, 1099] Range 3: [500, 599]" Please turn this into the information actually advertised - i.e. Range 1: Range Size: 100 SID/Label sub-TLV: 100 => meaning [100, 199] etc. 7) 3.2. SID/Label Range TLV: Please specify that the sender MUST NOT advertise overlapping ranges & how to handle the case when it does. This is required by draft-ietf-spring-conflict-resolution. 8) Sec 3.3 SR Local Block (SRLB) Sub-TLV: The document doesn't specify that the SR Local Block TLV MUST include a SID/Label sub-TLV nor indicate what to do if multiple are included. The Length, again, isn't specified at all and clearly has at least a minimum. I don't see a reference to an SR Local Block or the need to advertise it in draft-ietf-spring-segment-routing-11; perhaps I missed where the requirement and usage are defined? 9) Sec 3.3: "Each time a SID from the SRLB is allocated, it SHOULD also be reported to all components..." Presumably, this is subjected to the normal OSPF dampening - it'd be nice to note that somewhere - since rapid sequential allocation may not provide the reporting speed anticipated. 10) Sec 4: "AF: Address family for the prefix. Currently, the only supported value is 0 for IPv4 unicast. The inclusion of address family in this TLV allows for future extension." Could you please clarify if this is to reuse the same TLV for OSPFv3 so IPv6 can be supported, are you thinking of extending OSPFv2 for IPv6 prefixes for some cases or something else? I think the current phrasing is likely to raise questions. Similarly, please define "Prefix length: Length of the prefix" clearly. I really don't understand what the benefit of having a TLV that pretends to support multiple AFs but can't is versus the clarity of specifying the prefix lengths. 11) Sec 4: Again "Length: Variable" - It should have a minimum and preferable describe a function for how it is computed. A maximum is probably unlikely with sub-TLVs. 12) Sec 4: OSPF Extended Prefix Range TLV: Does this TLV has any meaning or action associated with it without including sub-TLVs? Are there mandatory sub-TLVs? What is a receiving router to do with it? 13) Sec 5: "If multiple Prefix-SIDs are advertised for the same prefix, the receiving router MUST use the first encoded SID and MAY use subsequent SIDs." What does this even mean? A receiving router when making the decision to use a subsequent SID is making a decision to not use the first encoded SID; it's not like the router is going to stick both SID/Labels onto the stack. Please describe this in meaningful normative terms. 14) Sec 5:" When calculating the outgoing label for the prefix, the router MUST take into account the E and P flags advertised by the next-hop router if that router advertised the SID for the prefix. This MUST be done regardless of whether the next-hop router contributes to the best path to the prefix." First, I assume this is "NP flag" because there is no P flag. Second - please clarify to "take into account, as described below, the E and NP flags...". Third, the M flag must also be taken into account - given the text later in the section. 15) Sec 5: "When a Prefix-SID is advertised in an Extended Prefix Range TLV, then the value advertised in the Prefix SID Sub-TLV is interpreted as a starting SID value." This appears to contradict "SID/Index/Label: According to the V and L flags, it contains either: A 32-bit index defining the offset in the SID/Label space advertised by this router. A 24-bit label where the 20 rightmost bits are used for encoding the label value." I assume that what is meant by the first quote is "...is interpreted, if the V flag is clear, as a starting SID value, and if the V flag is set, as a starting Label value." Otherwise, it looks like the Prefix-SID sub-TLV couldn't be included in the Extended Prefix Range TLV if a label value would be used. It would be helpful for Example 2 to show the label case. 16) Sec 6.1: "aggregate IGP or TE path cost." Given that this is an OSPF draft, it'd be helpful to indicate whether there are challenges with non-comparable OSPF metrics (I'm thinking about AS-external type 2 costs) or if the path will never include such costs. 17) Sec 6.2: "a domain and hence need to be disambiguated using a domain-unique Router-ID." Given that the Prefix-SIDs and sub-TLVs can be distributed between areas and even redistributed between protocols, please clearly define what is meant by a "domain" or point to the appropriate definition. 18) Sec 4, 5, 6: Is it possible to have an OSPF Extended Prefix Range TLV that includes both a Prefix SID Sub-TLV and a SID/Label Binding Sub-TLV? What does that mean? What does it mean if there are multiple prefixes described in the OSPF Extended Prefix Range TLV that includes a SID/Label Binding Sub-TLV? Does the SID/Label sub-sub-TLV indicate a single SID Index or Label that is used for the single path to all those prefixes? Is it the start of a list of SID Indices or Labels? I see that the SID/Label Binding sub-TLV can be in both the OSPF Extended Prefx Range TLV as well as the OSPF Extended Prefix TLV - but there is no text on differences in interpretation. 19) Sec 7.1 & 7.2: Another couple "Length: Variable." Please actually specify the value. I think that, given the padding to 32-bit alignment, there is a single correct value. 20) Sec 7.1 and 7.2: Given that the Flag bits have exactly the same meaning - it'd be clearer to have them defined once. 21) Sec 8.1: "An SR Mapping Server MUST use the OSPF Extended Prefix Range TLV when advertising SIDs for prefixes. Prefixes of different route-types can be combined in a single OSPF Extended Prefix Range TLV advertised by an SR Mapping Server." So - I can't find a normative definition of an SRMS to determine why it is always necessary to use an OSPF Extended Prefix Range TLV instead of an OSPF Extended Prefix TLV. I don't see how advertising prefixes from different route-types can work unless the prefixes are adjacent, which seems likely to be uncommon. Perhaps what is meant is "Because the OSPF Extended Prefix Range TLV doesn't include a Route-Type field, as in the OSPF Extended Prefix TLV, it is possible to include adjacent prefixes from different Route-Types in the OSPF Extended Prefix Range TLV." 22) Sec 8.1: "If multiple routers advertise a Prefix-SID for the same prefix, then the Prefix-SID MUST be the same. This is required in order to allow traffic load-balancing when multiple equal cost paths to the destination exist in the OSPFv2 routing domain." How is this enforced? What are the consequences of it not being conformed to? This is NOT a protocol implementation requirement. This should really be called out in a Manageability Considerations with warnings. 23) Sec 8.2:"If no Prefix-SID was advertised for the prefix in the source area by the router that contributes to the best path to the prefix, the originating ABR will use the Prefix-SID advertised by any other router when propagating the Prefix-SID for the prefix to other areas." I believe that this depends on the assumption that if a Prefix-SID is advertised by any router, the Prefix-SID will be the same. Please be explicit in this assumption, since the requirement on the network operator should be clear as well as the consequences of not conforming. 24) Sec 10: The Implementation Status section should indicate that it is to be removed before publication as an RFC. Also, the complete implementation part seems a bit dated - given the draft's technical changes in the last 2 years. NITS: 1) Sec 2.1: s/"SID/Label TLV"/"SID/Label sub-TLV" 2) Sec 3.2:"Initially, the only supported Sub-TLV is the SID/Label TLV as defined in Section 2.1. The SID/Label advertised in the SID/Label TLV represents the first SID/Label in the advertised range." replace SID/Label TLV with SID/Label sub-TLV. 3) Sec 3.3 & Sec 3.4: " The SR Local Block (SRLB) Sub-TLV is a top-level TLV of the Router Information Opaque LSA (defined in [RFC7770])." Please correct the descriptions (many) to SR Local Block (SRLB) Sub-TLV to SR Local Block SRLB TLV. The same issue exists for "SRMS Preference Sub-TLV". |
2017-05-30
|
16 | Alia Atlas | IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested |
2017-05-23
|
16 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-16.txt |
2017-05-23
|
16 | (System) | New version approved |
2017-05-23
|
16 | (System) | Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils … Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Rob Shakir |
2017-05-23
|
16 | Peter Psenak | Uploaded new revision |
2017-05-22
|
15 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-15.txt |
2017-05-22
|
15 | (System) | New version approved |
2017-05-22
|
15 | (System) | Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils … Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Rob Shakir |
2017-05-22
|
15 | Peter Psenak | Uploaded new revision |
2017-05-04
|
14 | Acee Lindem | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? A Standards Track RFC is being requested and is indicated in the title page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes the OSPFv2 extensions for segment routing including Prefix-SID, Adjacency-SID, and Binding-SID. The extensions are based on RFC 7770. Working Group Summary: The Working Group discussion has been dominated by the initial vendors that implemented the specification (Juniper, Cisco, and Nokia). We've gone through several iterations over the last two and half years. The document has completed two separate IPR polls. It is in its second Working Group last call due to some additional protocol encodings and clarifications on the handling of error situations. The second Working Group last call is preceding without questions or significant comments. Document Quality: The document has been implemented by a number of vendors (refer to the implementation status section) and has been stable now for a few months. In fact, the only changes have been edits and clarifications based on WG last-call and chair review. Personnel: Acee Lindem is the Document Shepherd. Alia Atlas is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has reviewed each revision of the document and followed the discussion on the OSPF mailing list. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes - there is an IPR disclosure on non-WG version and two more on the WG version of the document. The terms are such that the patent will not be asserted unless the party asserts a patent against the holder (forget the term for this). https://datatracker.ietf.org/ipr/2233/ https://datatracker.ietf.org/ipr/2401/ https://datatracker.ietf.org/ipr/2808/ There have been three polls for knowledge of IPR with all authors responding. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is consensus from the WG and others outside the WG that this document can progress. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nits are all resolved. There are 7 comments from Idnits bug none of them are indicative of issues in the draft. For example, IPv6 examples are suggested but OSPFv2 only supports IPv4. The document does have seven authors. All the authors have played in active role in the development of the standard including periodic segment routing design team meetings. All of the authors have responded promptly to IPR polls. At least three of the authors represented independent implementations. There is absolutely no reason to relegate any of them to contributor status. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The Segment Routing extensions required allocation of a number of code points from the registries created for RFC 7770. These code points were pre-allocated through IANA early allocation as described in RFC 7120. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. |
2017-05-04
|
14 | Acee Lindem | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? A Standards Track RFC is being requested and is indicated in the title page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes the OSPFv2 extensions for segment routing including Prefix-SID, Adjacency-SID, and Binding-SID. The extensions are based on RFC 7770. Working Group Summary: The Working Group discussion has been dominated by the initial vendors that implemented the specification (Juniper, Cisco, and Nokia). We've gone through several iterations over the last two and half years. The document has completed two separate IPR polls. It is in its second Working Group last call due to some additional protocol encodings and clarifications on the handling of error situations. The second Working Group last call is preceding without questions or significant comments. Document Quality: The document has been implemented by a number of vendors (refer to the implementation status section) and has been stable now for a few months. In fact, the only changes have been edits and clarifications based on WG last-call and chair review. Personnel: Acee Lindem is the Document Shepherd. Alia Atlas is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has reviewed each revision of the document and followed the discussion on the OSPF mailing list. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes - there is an IPR disclosure on non-WG version and two more on the WG version of the document. The terms are such that the patent will not be asserted unless the party asserts a patent against the holder (forget the term for this). https://datatracker.ietf.org/ipr/2233/ https://datatracker.ietf.org/ipr/2401/ https://datatracker.ietf.org/ipr/2808/ There have been three polls for knowledge of IPR with all authors responding. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is consensus from the WG and others outside the WG that this document can progress. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nits are all resolved. The document does have seven authors. All the authors have played in active role in the development of the standard including periodic segment routing design team meetings. All of the authors have responded promptly to IPR polls. At least three of the authors represented independent implementations. There is absolutely no reason to relegate any of them to contributor status. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The Segment Routing extensions required allocation of a number of code points from the registries created for RFC 7770. These code points were pre-allocated through IANA early allocation as described in RFC 7120. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. |
2017-05-04
|
14 | Acee Lindem | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2017-05-04
|
14 | Acee Lindem | IESG state changed to Publication Requested from AD is watching |
2017-05-04
|
14 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-14.txt |
2017-05-04
|
14 | (System) | New version approved |
2017-05-04
|
14 | (System) | Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils … Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Rob Shakir |
2017-05-04
|
14 | Peter Psenak | Uploaded new revision |
2017-05-04
|
13 | Acee Lindem | IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
2017-05-04
|
13 | Acee Lindem | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2017-05-04
|
13 | Acee Lindem | IETF WG state changed to In WG Last Call from WG Document |
2017-05-04
|
13 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-13.txt |
2017-05-04
|
13 | (System) | New version approved |
2017-05-04
|
13 | (System) | Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils … Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Rob Shakir |
2017-05-04
|
13 | Peter Psenak | Uploaded new revision |
2017-04-27
|
12 | Min Ye | Request for Early review by RTGDIR Completed: Has Issues. Reviewer: Stig Venaas. |
2017-04-26
|
12 | Acee Lindem | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? A Standards Track RFC is being requested and is indicated in the title page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes the OSPFv2 extensions for segment routing including Prefix-SID, Adjacency-SID, and Binding-SID. The extensions are based on RFC 7770. Working Group Summary: The Working Group discussion has been dominated by the initial vendors that implemented the specification (Juniper, Cisco, and Nokia). We've gone through several iterations over the last two and half years. The document has completed two separate IPR polls. It is in its second Working Group last call due to some additional protocol encodings and clarifications on the handling of error situations. The second Working Group last call is preceding without questions or significant comments. Document Quality: The document has been implemented by a number of vendors (refer to the implementation status section) and has been stable now for a few months. In fact, the only changes have been edits and clarifications based on WG last-call and chair review. Personnel: Acee Lindem is the Document Shepherd. Alia Atlas is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has reviewed each revision of the document and followed the discussion on the OSPF mailing list. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes - there is an IPR disclosure on non-WG version and two more on the WG version of the document. The terms are such that the patent will not be asserted unless the party asserts a patent against the holder (forget the term for this). https://datatracker.ietf.org/ipr/2233/ https://datatracker.ietf.org/ipr/2401/ https://datatracker.ietf.org/ipr/2808/ There have been three polls for knowledge of IPR with all authors responding. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is consensus from the WG and others outside the WG that this document can progress. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nits are all resolved. The document does have seven authors. All the authors have played in active role in the development of the standard including periodic segment routing design team meetings. All of the authors have responded promptly to IPR polls. At least three of the authors represented independent implementations. There is absolutely no reason to relegate any of them to contributor status. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The Segment Routing extensions required allocation of a number of code points from the registries created for RFC 7770. These code points were pre-allocated through IANA early allocation as described in RFC 7120. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. |
2017-04-17
|
12 | Acee Lindem | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? A Standards Track RFC is being requested and is indicated in the title page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes the OSPFv2 extensions for segment routing including Prefix-SID, Adjacency-SID, and Binding-SID. The extensions are based on RFC 7770. Working Group Summary: The Working Group discussion has been dominated by the initial vendors that implemented the specification (Juniper, Cisco, and Nokia). We've gone through several iterations over the last two and half years. The document has completed two separate IPR polls. It is in its second Working Group last call due to some additional protocol encodings and clarifications on the handling of error situations. The second Working Group last call is preceding without questions or significant comments. Document Quality: The document has been implemented by a number of vendors (refer to the implementation status section) and has been stable now for a few months. In fact, the only changes have been edits and clarifications based on WG last-call and chair review. Personnel: Acee Lindem is the Document Shepherd. Alia Atlas is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has reviewed each revision of the document and followed the discussion on the OSPF mailing list. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes - there is an IPR disclosure on non-WG version and two more on the WG version of the document. The terms are such that the patent will not be asserted unless the party asserts a patent against the holder (forget the term for this). https://datatracker.ietf.org/ipr/2233/ https://datatracker.ietf.org/ipr/2401/ https://datatracker.ietf.org/ipr/2808/ There have been three polls for knowledge of IPR with all authors responding. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is consensus from the WG and others outside the WG that this document can progress. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nits are all resolved. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The Segment Routing extensions required allocation of a number of code points from the registries created for RFC 7770. These code points were pre-allocated through IANA early allocation as described in RFC 7120. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. |
2017-04-05
|
12 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Stig Venaas |
2017-04-05
|
12 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Stig Venaas |
2017-04-05
|
12 | Acee Lindem | Requested Early review by RTGDIR |
2017-03-08
|
12 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-12.txt |
2017-03-08
|
12 | (System) | New version approved |
2017-03-08
|
12 | (System) | Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils … Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Rob Shakir |
2017-03-08
|
12 | Peter Psenak | Uploaded new revision |
2017-02-28
|
11 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-11.txt |
2017-02-28
|
11 | (System) | New version approved |
2017-02-28
|
11 | (System) | Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils … Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Rob Shakir |
2017-02-28
|
11 | Peter Psenak | Uploaded new revision |
2016-10-28
|
10 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-10.txt |
2016-10-28
|
10 | (System) | New version approved |
2016-10-28
|
09 | (System) | Request for posting confirmation emailed to previous authors: "Jeff Tantsura" , "Rob Shakir" , "Hannes Gredler" , "Clarence Filsfils" , "Stefano Previdi" , "Peter Psenak" … Request for posting confirmation emailed to previous authors: "Jeff Tantsura" , "Rob Shakir" , "Hannes Gredler" , "Clarence Filsfils" , "Stefano Previdi" , "Peter Psenak" , ospf-chairs@ietf.org, "Wim Henderickx" |
2016-10-28
|
09 | Peter Psenak | Uploaded new revision |
2016-07-24
|
09 | Alia Atlas | Returned to the WG because discussion at IETF 96 indicated that technical changes were still anticipated. Requesting extension for the IANA registrations. |
2016-07-24
|
09 | Alia Atlas | IETF WG state changed to WG Document from Submitted to IESG for Publication |
2016-07-24
|
09 | Alia Atlas | Returning to the WG since discussion at IETF 96 indicated that the text was still undergoing technical changes. |
2016-07-24
|
09 | Alia Atlas | IESG state changed to AD is watching from Publication Requested |
2016-07-06
|
09 | Acee Lindem | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? A Standards Track RFC is being requested and is indicated in the title page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes the OSPFv2 extensions for segment routing including Prefix-SID, Adjacency-SID, and Binding-SID. The extensions are based on RFC 7770. Working Group Summary: The Working Group discussion has been dominated by the initial vendors that implemented the specification (Juniper, Cisco, and Nokia). We've gone through several iterations over the last two and half years. Document Quality: The document has been implemented by a number of vendors (refer to the implementation status section) and has been stable now for a few months. In fact, the only changes have been edits and clarifications based on WG last-call and chair review. Personnel: Acee Lindem is the Document Shepherd. Alia Atlas is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has reviewed each revision of the document and followed the discussion on the OSPF mailing list. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes - there is an IPR disclosure on non-WG version and a second one on the WG version of the document. The terms are such that the patent will not be asserted unless the party asserts a patent against the holder (forget the term for this). https://datatracker.ietf.org/ipr/2233/ There have been two polls for knowledge of IPR with all authors responding. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is consensus from the WG and others outside the WG that this document can progress. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nits are all resolved. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The Segment Routing extensions required allocation of a number of code points from the registries created for RFC 7770. These code points were pre-allocated through IANA early allocation as described in RFC 7120. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. |
2016-07-06
|
09 | Acee Lindem | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2016-07-06
|
09 | Acee Lindem | IESG state changed to Publication Requested from AD is watching |
2016-07-06
|
09 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-09.txt |
2016-06-17
|
08 | Alia Atlas | IESG state changed to AD is watching from Publication Requested |
2016-06-16
|
08 | Alia Atlas | New additional IPR - including a new patent application - was disclosed by Cisco, which is the affiliation of several authors, after the authors reported … New additional IPR - including a new patent application - was disclosed by Cisco, which is the affiliation of several authors, after the authors reported that there was no undisclosed IPR and after WGLC had completed. At a minimum, the WG needs to have an additional WGLC - highlighting the additional IPR and determining if there is consensus to publish. |
2016-06-16
|
08 | Alia Atlas | IETF WG state changed to WG Document from Submitted to IESG for Publication |
2016-06-15
|
Maddy Conner | Posted related IPR disclosure: Cisco Systems, Inc.'s Statement about IPR related to draft-ietf-ospf-segment-routing-extensions | |
2016-06-07
|
08 | Acee Lindem | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? A Standards Track RFC is being requested and is indicated in the title page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes the OSPFv2 extensions for segment routing including Prefix-SID, Adjacency-SID, and Binding-SID. The extensions are based on RFC 7770. Working Group Summary: The Working Group discussion has been dominated by the initial vendors that implemented the specification (Juniper, Cisco, and Nokia). We've gone through several iterations over the last two and half years. Document Quality: The document has been implemented by a number of vendors (refer to the implementation status section) and has been stable now for a few months. In fact, the only changes have been edits and clarifications based on WG last-call and chair review. Personnel: Acee Lindem is the Document Shepherd. Alia Atlas is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has reviewed each revision of the document and followed the discussion on the OSPF mailing list. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes - there is an IPR disclosure on non-WG version and a second one on the WG version of the document. The terms are such that the patent will not be asserted unless the party asserts a patent against the holder (forget the term for this). https://datatracker.ietf.org/ipr/2233/ There have been two polls for knowledge of IPR with all authors responding. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is consensus from the WG and others outside the WG that this document can progress. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nits are all resolved. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The Segment Routing extensions required allocation of a number of code points from the registries created for RFC 7770. These code points were pre-allocated through IANA early allocation as described in RFC 7120. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. |
2016-06-04
|
08 | Acee Lindem | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? A Standards Track RFC is being requested and is indicated in the title page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes the OSPFv2 extensions for segment routing including Prefix-SID, Adjacency-SID, and Binding-SID. The extensions are based on RFC 7770. Working Group Summary: The Working Group discussion has been dominated by the initial vendors that implemented the specification (Juniper, Cisco, and Nokia). We've gone through several iterations over the last two and half years. Document Quality: The document has been implemented by a number of vendors (refer to the implementation status section) and has been stable now for a few months. In fact, the only changes have been edits and clarifications based on WG last-call and chair review. Personnel: Acee Lindem is the Document Shepherd. Alia Atlas is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has reviewed each revision of the document and followed the discussion on the OSPF mailing list. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes - there is an IPR disclosure on non-WG version and a second one on the WG version of the document. The terms are such that the patent will not be asserted unless the party asserts a patent against the holder (forget the term for this). https://datatracker.ietf.org/ipr/2233/ (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is consensus from the WG and others outside the WG that this document can progress. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nits are all resolved. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The Segment Routing extensions required allocation of a number of code points from the registries created for RFC 7770. These code points were pre-allocated through IANA early allocation as described in RFC 7120. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. |
2016-06-04
|
08 | Acee Lindem | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? A Standards Track RFC is being requested and is indicated in the title page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes the OSPFv2 extensions for segment routing including Prefix-SID, Adjacency-SID, and Binding-SID. The extensions are based on RFC 7770. Working Group Summary: The Working Group discussion has been dominated by the initial vendors that implemented the specification (Juniper, Cisco, and Nokia). We've gone through several iterations over the last two and half years. Document Quality: The document has been implemented by a number of vendors (refer to the implementation status section) and has been stable now for a few months. In fact, the only changes have been edits and clarifications based on WG last-call and chair review. Personnel: Acee Lindem is the Document Shepherd. Alia Atlas is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has reviewed each revision of the document and followed the discussion on the OSPF mailing list. In fact, the document shepherd have provided more substantive comments and edits to the document than most of the authors. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes - there is an IPR disclosure on non-WG version and a second one on the WG version of the document. The terms are such that the patent will not be asserted unless the party asserts a patent against the holder (forget the term for this). https://datatracker.ietf.org/ipr/2233/ (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is consensus from the WG and others outside the WG that this document can progress. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nits are all resolved. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The Segment Routing extensions required allocation of a number of code points from the registries created for RFC 7770. These code points were pre-allocated through IANA early allocation as described in RFC 7120. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. |
2016-06-04
|
08 | Acee Lindem | Responsible AD changed to Alia Atlas |
2016-06-04
|
08 | Acee Lindem | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2016-06-04
|
08 | Acee Lindem | IESG state changed to Publication Requested |
2016-06-04
|
08 | Acee Lindem | IESG process started in state Publication Requested |
2016-06-04
|
08 | Acee Lindem | Changed document writeup |
2016-04-27
|
08 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-08.txt |
2016-04-21
|
07 | Acee Lindem | Notification list changed to "Acee Lindem" <acee@cisco.com> |
2016-04-21
|
07 | Acee Lindem | Document shepherd changed to Acee Lindem |
2016-04-21
|
07 | Acee Lindem | Changed consensus to Yes from Unknown |
2016-04-21
|
07 | Acee Lindem | Intended Status changed to Proposed Standard from None |
2016-03-21
|
07 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-07.txt |
2015-12-22
|
06 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-06.txt |
2015-11-09
|
05 | Acee Lindem | This document now replaces draft-psenak-ospf-segment-routing-extensions instead of None |
2015-06-26
|
05 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-05.txt |
2015-02-02
|
04 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-04.txt |
2014-12-02
|
03 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-03.txt |
2014-08-15
|
02 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-02.txt |
2014-07-31
|
(System) | Posted related IPR disclosure: Cisco's Statement of IPR Related to draft-ietf-ospf-segment-routing-extensions-01 | |
2014-07-03
|
01 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-01.txt |
2014-06-19
|
00 | Peter Psenak | New version available: draft-ietf-ospf-segment-routing-extensions-00.txt |