Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing
draft-ietf-idr-bgp-ls-segment-routing-ext-18
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2021-08-05
|
18 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-07-07
|
18 | (System) | RFC Editor state changed to AUTH48 |
2021-04-30
|
18 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2021-04-15
|
18 | Ketan Talaulikar | New version available: draft-ietf-idr-bgp-ls-segment-routing-ext-18.txt |
2021-04-15
|
18 | (System) | New version accepted (logged-in submitter: Ketan Talaulikar) |
2021-04-15
|
18 | Ketan Talaulikar | Uploaded new revision |
2021-04-14
|
17 | (System) | RFC Editor state changed to EDIT from MISSREF |
2021-03-21
|
17 | Ketan Talaulikar | New version available: draft-ietf-idr-bgp-ls-segment-routing-ext-17.txt |
2021-03-21
|
17 | (System) | New version approved |
2021-03-21
|
17 | (System) | Request for posting confirmation emailed to previous authors: Clarence Filsfils , Hannes Gredler , Ketan Talaulikar , Mach Chen , Stefano Previdi |
2021-03-21
|
17 | Ketan Talaulikar | Uploaded new revision |
2019-08-26
|
16 | Gunter Van de Velde | Request closed, assignment withdrawn: Joel Jaeggli Last Call OPSDIR review |
2019-08-26
|
16 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Team Will not Review Version' |
2019-07-10
|
16 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2019-07-10
|
16 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2019-07-09
|
16 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-07-07
|
16 | Min Ye | Assignment of request for Last Call review by RTGDIR to Nicolai Leymann was marked no-response |
2019-07-04
|
16 | (System) | RFC Editor state changed to MISSREF |
2019-07-04
|
16 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-07-04
|
16 | (System) | Announcement was received by RFC Editor |
2019-07-04
|
16 | (System) | IANA Action state changed to In Progress |
2019-07-04
|
16 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-07-04
|
16 | Cindy Morgan | IESG has approved the document |
2019-07-04
|
16 | Cindy Morgan | Closed "Approve" ballot |
2019-07-04
|
16 | Cindy Morgan | Ballot approval text was generated |
2019-07-04
|
16 | Alvaro Retana | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2019-06-27
|
16 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-06-27
|
16 | Ketan Talaulikar | New version available: draft-ietf-idr-bgp-ls-segment-routing-ext-16.txt |
2019-06-27
|
16 | (System) | New version approved |
2019-06-27
|
16 | (System) | Request for posting confirmation emailed to previous authors: Mach Chen , Clarence Filsfils , Stefano Previdi , Hannes Gredler , Ketan Talaulikar |
2019-06-27
|
16 | Ketan Talaulikar | Uploaded new revision |
2019-06-13
|
15 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2019-06-13
|
15 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2019-06-13
|
15 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-06-13
|
15 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2019-06-12
|
15 | Suresh Krishnan | [Ballot comment] * Section 2.3.3. I think the figure should say "4 or 16 octet Router-ID" instead of "4 or 6 octet Router-ID" as the … [Ballot comment] * Section 2.3.3. I think the figure should say "4 or 16 octet Router-ID" instead of "4 or 6 octet Router-ID" as the IPv6 router ID will be 16 octets long |
2019-06-12
|
15 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-06-12
|
15 | Adam Roach | [Ballot comment] Thanks for the work that everyone did on this document. I have only one very minor comment. §2.1.2: > Reserved: 1 octet … [Ballot comment] Thanks for the work that everyone did on this document. I have only one very minor comment. §2.1.2: > Reserved: 1 octet that SHOULD be set to 0 and MUST be ignored on > receipt. Making this a "SHOULD" rather than a "MUST" seems like it might interfere with any future attempts to use this field, since compliant implementations might have set the byte to arbitrary values. This comment applies to other "reserved" fields in this document. |
2019-06-12
|
15 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2019-06-12
|
15 | Barry Leiba | [Ballot comment] Just an absolute nit in Section 1: A segment can represent any instruction; topological or service-based. The semicolon is the wrong … [Ballot comment] Just an absolute nit in Section 1: A segment can represent any instruction; topological or service-based. The semicolon is the wrong punctuation here. A colon would work, as would a comma or a dash. |
2019-06-12
|
15 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2019-06-12
|
15 | Benjamin Kaduk | [Ballot comment] -15 I agree with Mirja that mentioning the scope earlier in the document would be helpful (but will follow the discussion in her … [Ballot comment] -15 I agree with Mirja that mentioning the scope earlier in the document would be helpful (but will follow the discussion in her ballot thread). Basically, even though the SR Architecture is clear about the scope being limited to a trusted administrative domain, it's still helpful to remind the reader briefly at the start of the document that there is some expectation of trust to all participants receiving this information, and that it is not expected to leave into the broader Internet or generic BGP peers. Section 1 When Segment Routing is enabled in an IGP domain, segments are advertised in the form of Segment Identifiers (SIDs). The IGP link- state routing protocols have been extended to advertise SIDs and other SR-related information. IGP extensions are described in: IS-IS [I-D.ietf-isis-segment-routing-extensions], OSPFv2 [I-D.ietf-ospf-segment-routing-extensions] and OSPFv3 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [...] nit: I think "described for" is more appropriate than "described in", which might suggest to the reader that these are part of the core protocols. Section 2.1.1 Length: Variable. Either 3 or 4 depending whether the value is encoded as a label or as an index/SID. nit: I think the secdir reviewer's concern might be alleviated by spelling these constants as 0x0003 and 0x0004. Section 2.1.2 Are the "SID/Label sub-TLV N" fields actually variable length? The description seems to be saying that we can only use the "label" variant encoding, which makes the overall length of the sub-TLV 7 bytes, always. Flags: 1 octet of flags as defined in [I-D.ietf-isis-segment-routing-extensions] for IS-IS. The flags are not currently defined for OSPFv2 and OSPFv3 and SHOULD be set to 0 and MUST be ignored on receipt. I agree with the other reviewers that the SHOULD here is surprising. Perhaps "Until the specification of flag value usage for OSPFv2 and/or OSPFv3 is defined, the flags MUST be set to zero and ignored on receipt"? The case for Reserved seems even more clear to mandate setting to zero. Section 2.1.3 Do the algorithm values need to appear in any specific order? The note about the maximum length being 256 seems to imply that duplicates are not expected, but I do not see any specific text forbidding them. Section 2.1.4 [Same comments as Section 2.1.2 about variable length sub-TLVs, and SHOULD/MUST] Section 2.2.1 The Adjacency SID TLV is used in order to advertise information related to an Adjacency SID. This information is derived from Adj- SID sub-TLV of IS-IS [I-D.ietf-isis-segment-routing-extensions], OSPFv2 [I-D.ietf-ospf-segment-routing-extensions] and OSPFv3 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. nit: I think this should be "Adj-SID sub-TLVs" plural. Weight: 1 octet carrying the weight used for load-balancing purposes. Maybe reference RFC 8402 for the weight semantics? (Otherwise we have to guess whether a larger value means to send more traffic vs. less traffic.) [Same comment about SHOULD/MUST for Reserved] Section 2.2.2 [same comment about Weight and SHOULD/MUST for Reserved] Do we want some IANA considerations and/or regisitry modifications to provide for any future BGP-LS Attribute TLVs that might be defined and be appropriate to include as sub-TLVs of the L2 Bundle Member Attribute TLV? Section 2.3.1 [same comment about SHOULD/MUST for Reserved] Section 2.3.3 The figure says "4 or 6 octet Router-ID"; should that bt "4 or 16" to match the body text? Section 2.3.4 [same comment about SHOULD/MUST for Reserved] It's a little weird to blandly cite the OSPF document for the Range Size definition and expect that to plainly transfer over to the IS-IS case as well. (Also, the linked document has three different usages for "Range Size"; I assume we mean the one in Section 4, "OSPF Extended Prefix Range TLV", since it's the right width, but it might be worth stating explicitly.) I didn't take the time to try to convince myself that the sub-TLV usage for prefix-to-SID mappings matches up with the statement that the length is "11 or 12 depending on Label or Index encoding of the SID", but I think the TLV overhead would push the length larger than 12. Section 5 The links for "required security and authentication mechanisms" are a little surprising, as those documents are the segment-routing-extensions documents for IS-IS and OSPF, respectively, and do not define the mechamisms themselves, rather referring to other document for the details of the security mechanisms. Furthermore, there seem to only be SHOULD-level requirements for authentication mechanisms, and only in certain cases (and only in the OSPFv2 document). So to say "the required mechanisms" here seems misleading, in that the set of *required* mechanisms seems to be the empty set. I always have a hard time accepting statements about "present no additional risk"; we are going from presenting "generic" link-state/prefix/node information across the BGP-LS domain to additionally presenting information about the SR topology and segment location/identifiers. So, one might concoct a scenario in which an attacker can learn about the internal SR configuration/topology based on the information conveyed by the mechanisms in this document, which is in some sense an "additional risk". That said, it is probably a minor one, given the expected scope of distribution. |
2019-06-12
|
15 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2019-06-12
|
15 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2019-06-12
|
15 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2019-06-12
|
15 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-06-12
|
15 | Warren Kumari | [Ballot comment] I'd like to strongly support Mirja's comment -- having this buried in the Security Considerations section makes it easy to miss, and that … [Ballot comment] I'd like to strongly support Mirja's comment -- having this buried in the Security Considerations section makes it easy to miss, and that does set the tone for the rest of the document.. Also, thank you for this document -- it is nice to see this finally getting out the door. Special thanks for the Manageability Considerations section |
2019-06-12
|
15 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-06-11
|
15 | Roman Danyliw | [Ballot comment] (1) Section 2.0. Does the sentence, “This document adds additional BGP-LS Attribute TLVs in order to encode SR information” imply that this document … [Ballot comment] (1) Section 2.0. Does the sentence, “This document adds additional BGP-LS Attribute TLVs in order to encode SR information” imply that this document should explicitly update RFC7752? (2) Add more detailed citations -- Section 2.x. Section 2.1.x. When citing a reference to explain a given TLV/sub-TLV, consider adding the relevant section number to improve readability. For example: OLD: Section 2.1.1, IS-IS, as defined by the SID/Label sub-TLV in [I-D.ietf-isis-segment-routing-extensions]. NEW: Section 2.1.1, IS-IS, as defined by the SID/Label sub-TLV in Section 3.2 of [I-D.ietf-isis-segment-routing-extensions]. -- Section 2.1.2 Per the octet of flags, please specify the specific section number of [I-D.ietf-isis-segment-routing-extensions]. -- Section 2.2.*. Consider adding the appropriate section number in the references when described the flags field. (3) Section 2.1.4. Per “SID/Label sub-TLV (as defined in Section 2.1.1) which encodes the first label in the range”, why is this just the first label? Isn’t there the potential of a series of labels each in a distinct SID/Label sub-TLV? (4) Section 2.2.2. Is there a reference to explain the semantics of the weight field? (5) Section 2.3.1. Is there a reference to explain the semantics of the algorithm field? (6) Editorial Nits: -- Section 2.1.1. Missing word: s/The TLV and has the following format:/ /The TLV and sub-TLV has the following format:/ -- Section 2.1.5. Typo. s/a unsigned/an unsigned/ |
2019-06-11
|
15 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2019-06-10
|
15 | Luc André Burdet | Assignment of request for Last Call review by RTGDIR to He Jia was withdrawn |
2019-06-10
|
15 | Luc André Burdet | Request for Last Call review by RTGDIR is assigned to Nicolai Leymann |
2019-06-10
|
15 | Luc André Burdet | Request for Last Call review by RTGDIR is assigned to Nicolai Leymann |
2019-06-10
|
15 | Luc André Burdet | Request for Last Call review by RTGDIR is assigned to He Jia |
2019-06-10
|
15 | Luc André Burdet | Request for Last Call review by RTGDIR is assigned to He Jia |
2019-06-10
|
15 | Luc André Burdet | Assignment of request for Last Call review by RTGDIR to Victoria Pritchard was rejected |
2019-05-31
|
15 | Mirja Kühlewind | [Ballot comment] There is the following statement on the applicability of this approach in the security consideration section: “The SR traffic engineering policies using … [Ballot comment] There is the following statement on the applicability of this approach in the security consideration section: “The SR traffic engineering policies using the SIDs advertised via BGP-LS are expected to be used entirely within this trusted SR domain (e.g. between multiple AS/ domains within a single provider network). Therefore, precaution is necessary to ensure that the SR information advertised via BGP-LS sessions is limited to consumers in a secure manner within this trusted SR domain.” As this is every essential to the scope of the document I would like to see this earlier in the document, e.g. in the intro, and own applicability section, or even in the abstract. One additional comment on the shepherd write-up: I find the write-up a bit confusing but I assume that this document has wg consensus, even though it might be rough. There is a request to the IESG to make a judgment if this approach should be taken forward in general. However, if there are no technical or security concerns here and there is wg consensus, I don’t think I understand this request; expect this is not seen as covered by the charter, however, I don’t think this is indicated in the shepherd write-up. |
2019-05-31
|
15 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-05-30
|
15 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-05-30
|
15 | Ketan Talaulikar | New version available: draft-ietf-idr-bgp-ls-segment-routing-ext-15.txt |
2019-05-30
|
15 | (System) | New version approved |
2019-05-30
|
15 | (System) | Request for posting confirmation emailed to previous authors: Mach Chen , Clarence Filsfils , Stefano Previdi , Hannes Gredler , Ketan Talaulikar |
2019-05-30
|
15 | Ketan Talaulikar | Uploaded new revision |
2019-05-24
|
14 | Amy Vezza | Placed on agenda for telechat - 2019-06-13 |
2019-05-24
|
14 | Alvaro Retana | IESG state changed to IESG Evaluation from Waiting for Writeup |
2019-05-24
|
14 | Alvaro Retana | Ballot has been issued |
2019-05-24
|
14 | Alvaro Retana | [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana |
2019-05-24
|
14 | Alvaro Retana | Created "Approve" ballot |
2019-05-24
|
14 | Alvaro Retana | Ballot writeup was changed |
2019-05-23
|
14 | Paul Wouters | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Paul Wouters. Sent review to list. |
2019-05-23
|
14 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-05-22
|
14 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2019-05-22
|
14 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-idr-bgp-ls-segment-routing-ext-14. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-idr-bgp-ls-segment-routing-ext-14. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete. In the BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs registry on the Border Gateway Protocol - Link State (BGP-LS) Parameters registry page located at: https://www.iana.org/assignments/bgp-ls-parameters/ we'll update the references for the following TLV codepoints to [ RFC-to-be ]. +----------------+-----------------------------+ | TLV Code Point | Description | +----------------+-----------------------------+ | 1034 | SR Capabilities | | 1035 | SR Algorithm | | 1036 | SR Local Block | | 1037 | SRMS Preference | | 1099 | Adjacency SID | | 1100 | LAN Adjacency SID | | 1158 | Prefix SID | | 1159 | Range | | 1161 | SID/Label | | 1170 | Prefix Attribute Flags | | 1171 | Source Router-ID | | 1172 | L2 Bundle Member Attributes | +----------------+-----------------------------+ The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-05-20
|
14 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2019-05-20
|
14 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2019-05-20
|
14 | Roni Even | Request for Last Call review by GENART Completed: Ready. Reviewer: Roni Even. Sent review to list. |
2019-05-16
|
14 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Paul Wouters |
2019-05-16
|
14 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Paul Wouters |
2019-05-10
|
14 | Min Ye | Request for Last Call review by RTGDIR is assigned to Victoria Pritchard |
2019-05-10
|
14 | Min Ye | Request for Last Call review by RTGDIR is assigned to Victoria Pritchard |
2019-05-09
|
14 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2019-05-09
|
14 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2019-05-09
|
14 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2019-05-09
|
14 | Amy Vezza | The following Last Call announcement was sent out (ends 2019-05-23): From: The IESG To: IETF-Announce CC: idr@ietf.org, Susan Hares , idr-chairs@ietf.org, aretana.ietf@gmail.com, … The following Last Call announcement was sent out (ends 2019-05-23): From: The IESG To: IETF-Announce CC: idr@ietf.org, Susan Hares , idr-chairs@ietf.org, aretana.ietf@gmail.com, draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org, shares@ndzh.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (BGP Link-State extensions for Segment Routing) to Proposed Standard The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'BGP Link-State 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 2019-05-23. 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 for a flexible definition of end-to-end paths by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by routing protocols e.g. by the link state routing protocols (IS-IS, OSPFv2 and OSPFv3) within IGP topologies. This draft defines extensions to the BGP Link-state address-family in order to carry segment routing information via BGP. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-ext/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-ext/ballot/ No IPR declarations have been submitted directly on this I-D. |
2019-05-09
|
14 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2019-05-09
|
14 | Alvaro Retana | Requested Last Call review by RTGDIR |
2019-05-09
|
14 | Alvaro Retana | Last call was requested |
2019-05-09
|
14 | Alvaro Retana | Ballot approval text was generated |
2019-05-09
|
14 | Alvaro Retana | Ballot writeup was generated |
2019-05-09
|
14 | Alvaro Retana | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2019-05-09
|
14 | Alvaro Retana | Last call announcement was generated |
2019-05-09
|
14 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-05-09
|
14 | Ketan Talaulikar | New version available: draft-ietf-idr-bgp-ls-segment-routing-ext-14.txt |
2019-05-09
|
14 | (System) | New version approved |
2019-05-09
|
14 | (System) | Request for posting confirmation emailed to previous authors: Mach Chen , Clarence Filsfils , Stefano Previdi , Hannes Gredler , Ketan Talaulikar |
2019-05-09
|
14 | Ketan Talaulikar | Uploaded new revision |
2019-05-08
|
13 | Alvaro Retana | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2019-04-18
|
13 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-04-18
|
13 | Ketan Talaulikar | New version available: draft-ietf-idr-bgp-ls-segment-routing-ext-13.txt |
2019-04-18
|
13 | (System) | New version approved |
2019-04-18
|
13 | (System) | Request for posting confirmation emailed to previous authors: Mach Chen , Clarence Filsfils , Stefano Previdi , Hannes Gredler , Ketan Talaulikar |
2019-04-18
|
13 | Ketan Talaulikar | Uploaded new revision |
2019-03-21
|
12 | Alvaro Retana | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2019-03-08
|
12 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-03-08
|
12 | Ketan Talaulikar | New version available: draft-ietf-idr-bgp-ls-segment-routing-ext-12.txt |
2019-03-08
|
12 | (System) | New version approved |
2019-03-08
|
12 | (System) | Request for posting confirmation emailed to previous authors: Mach Chen , Clarence Filsfils , Stefano Previdi , Hannes Gredler , Ketan Talaulikar |
2019-03-08
|
12 | Ketan Talaulikar | Uploaded new revision |
2019-02-12
|
11 | Alvaro Retana | === AD Review of draft-ietf-idr-bgp-ls-segment-routing-ext-11 === https://mailarchive.ietf.org/arch/msg/idr/G_k3hBm4-K5O6onooVc6yuCdz6g Dear authors: I just finished my review of this document -- please see inline comments/questions. In general, I … === AD Review of draft-ietf-idr-bgp-ls-segment-routing-ext-11 === https://mailarchive.ietf.org/arch/msg/idr/G_k3hBm4-K5O6onooVc6yuCdz6g Dear authors: I just finished my review of this document -- please see inline comments/questions. In general, I think that there is more work needed in at least two fronts: (1) Consistency in the specification of the new TLVs. Most of the descriptions point at other documents, but they don't do so in a consistent manner: some at the start of the section, others when pointing at the values, etc. Please be consistent! Given that §2.4/2.5 already have a summary, I personally find the information in the individual sections redundant. Instead of a statement at the start of a section, I prefer you to be specific about the values -- see §2.1.2 for an example. Please note that most of my comments related to the specification of the TLVs apply to multiple sections, not just the one where I made them. I pointed this out in most cases, but may have missed some. (2) Error Handling. As has been discussed on the list (for example in [1], [2] and [3]), rfc7752 could use enhancements as it relates to considering error handling with applications such as SR, and in general. Those issues don't need to be fixed in this document, but I would like to see in this document some text about the potential effect: maybe in terms of the effect than an error might have from an operations or management point of view... See my comments below for specifics. Again, not looking for this document to "fix" BGP-LS, but to consider the effect on the expected function a controller might have, as described in the Introduction. [1] https://mailarchive.ietf.org/arch/msg/idr/Tm0vlu-ECSnIAyO1byj68AJm2XU [2] https://mailarchive.ietf.org/arch/msg/idr/0qsjuVaEhroKInHZMohP6HnsWd8 [3] https://mailarchive.ietf.org/arch/msg/idr/-CZGAiC8D3KogLnUs6ClW_KlU24 Thanks! Alvaro. [Line numbers come from idnits.] ... 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. [major] Please use the rfc8174 template. ... 99 1. Introduction ... 110 Two types of IGP segments are defined, Prefix segments and Adjacency 111 segments. Prefix segments, by default, represent an ECMP-aware 112 shortest-path to a prefix, as per the state of the IGP topology. 113 Adjacency segments represent a hop over a specific adjacency between 114 two nodes in the IGP. A prefix segment is typically a multi-hop path 115 while an adjacency segment, in most of the cases, is a one-hop path. 116 [RFC8402]. [nit] rfc8402 defines more than 2 IGP segments. [nit] s/one-hop path. [RFC8402]./one-hop path [RFC8402]. 118 When Segment Routing is enabled in a IGP domain, segments are 119 advertised in the form of Segment Identifiers (SIDs). The IGP link- 120 state routing protocols have been extended to advertise SIDs and 121 other SR-related information. IGP extensions are described in: IS-IS 122 [I-D.ietf-isis-segment-routing-extensions], OSPFv2 123 [I-D.ietf-ospf-segment-routing-extensions] and OSPFv3 124 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. Using these 125 extensions, Segment Routing can be enabled within an IGP domain. [nit] s/a IGP domain/an IGP domain 127 +------------+ 128 | Consumer | 129 +------------+ 130 ^ 131 | 132 v 133 +-------------------+ 134 | BGP Speaker | +-----------+ 135 | (Route-Reflector) | | Consumer | 136 +-------------------+ +-----------+ 137 ^ ^ ^ ^ 138 | | | | 139 +---------------+ | +-------------------+ | 140 | | | | 141 v v v v 142 +-----------+ +-----------+ +-----------+ 143 | BGP | | BGP | | BGP | 144 | Speaker | | Speaker | . . . | Speaker | 145 +-----------+ +-----------+ +-----------+ 146 ^ ^ ^ 147 | | | 148 IGP IGP IGP 150 Figure 1: Link State info collection [nit] Maybe move this Figure so it is closer to where it is referenced. ... 159 In order to address the need for applications that require 160 topological visibility across IGP areas, or even across Autonomous 161 Systems (AS), the BGP-LS address-family/sub-address-family have been 162 defined to allow BGP to carry Link-State information. The BGP 163 Network Layer Reachability Information (NLRI) encoding format for 164 BGP-LS and a new BGP Path Attribute called the BGP-LS attribute are 165 defined in [RFC7752]. The identifying key of each Link-State object, 166 namely a node, link, or prefix, is encoded in the NLRI and the 167 properties of the object are encoded in the BGP-LS attribute. 168 Figure 1 describes a typical deployment scenario. In each IGP area, 169 one or more nodes are configured with BGP-LS. These BGP speakers 170 form an IBGP mesh by connecting to one or more route-reflectors. 171 This way, all BGP speakers (specifically the route-reflectors) obtain 172 Link-State information from all IGP areas (and from other ASes from 173 EBGP peers). An external component connects to the route-reflector 174 to obtain this information (perhaps moderated by a policy regarding 175 what information is or isn't advertised to the external component). [minor] The way that the propagation of information can be controlled by policy is important. Please make sure that the text is clear in the fact that the discussion above is referencing rfc7752 (and that the reference to it is not just about the encodings). 177 This document describes extensions to BGP-LS to advertise the SR 178 information. An external component (e.g., a controller) then can 179 collect SR information from across an SR domain and construct the 180 end-to-end path (with its associated SIDs) that need to be applied to 181 an incoming packet to achieve the desired end-to-end forwarding. 182 Here the SR domain is defined as a single administrative domain that 183 may be comprised of a single AS or multiple ASes under consolidated 184 global SID administration. [nit] s/under consolidated/under a consolidated [major] Please don't redefine "SR domain". The definition above is not the same as what rfc8402 says (in §2). Easy fix: simply put a reference to rfc8402 next to the first mention of "SR domain", and delete that last sentence. 186 2. BGP-LS Extensions for Segment Routing 188 This document defines SR extensions to BGP-LS and specifies the TLVs 189 and sub-TLVs for advertising SR information within the BGP-LS 190 Attribute. Section 2.4 and Section 2.5 illustrates the equivalent 191 TLVs and sub-TLVs in IS-IS, OSPFv2 and OSPFv3 protocols. [nit] "illustrates" sounds like giving examples of equivalent TLVs. But I think that the tables don't show examples, they show/point to the corresponding TLVs. Perhaps use a different word... ... 200 Some of the TLVs defined in this document contain fields (e.g. flags) 201 whose semantics need to be interpreted accordingly to the respective 202 underlying IS-IS, OSPFv2 or OSPFv3 protocol. The receiver of the 203 BGP-LS update for any of the NLRIs MUST check the Protocol-ID of the 204 NLRI and refer to the underlying protocol specification in order to 205 parse such fields. The individual field descriptions in the sub- 206 sections below point to the relevant underlying protocol 207 specifications for such fields. [major] "The receiver of the BGP-LS update for any of the NLRIs MUST check the Protocol-ID of the NLRI and refer to the underlying protocol specification in order to parse such fields." This text is a general statement ("for any of the NLRIs") that seems to want to Update rfc7752, where Protocol-ID is defined...but I don't think that is the intent, right? Note that rfc7752 doesn't explicitly mandate that the "receiver...refer to the underlying protocol specification" -- it just implies it when talking about the Opaque TLVs. IOW, this seems like a significant change as related to other BGP-LS specs. Note also that §5 (Manageability Considerations) has the following text, which I think is in contradiction of the one above: ... ... The semantic or content checking for the TLVs specified in this document and their association with the BGP-LS NLRI types or their BGP-LS Attribute is left to the consumer of the BGP-LS information (e.g. an application or a controller) and not the BGP protocol. ... The handling of semantic or content errors by the consumer would be dictated by the nature of its application usage and hence is beyond the scope of this document. 209 2.1. Node Attributes TLVs 211 The following Node Attribute TLVs are defined: 213 +-----------------+----------+---------------+ 214 | Description | Length | Section | 215 +-----------------+----------+---------------+ 216 | SID/Label | variable | Section 2.1.1 | 217 | SR Capabilities | variable | Section 2.1.2 | 218 | SR Algorithm | variable | Section 2.1.3 | 219 | SR Local Block | variable | Section 2.1.4 | 220 | SRMS Preference | variable | Section 2.1.5 | 221 +-----------------+----------+---------------+ 223 Table 1: Node Attribute TLVs [minor] It would be nice if the table also contained the TLV Type. This comment applies to other similar tables. [minor] §2.1.2/2.1.3 use a "-" in the name of the TLV. Please be consistent as both versions are used throughout the document. [nit] Yes, the length is variable, but in some cases the possible values are known. For example, the length of the SID/Label sub-TLV can only be 3 or 4. Consider indicating that. OTOH, I don't see why indicating the Length is significant at this point -- IOW, I would even suggest removing that column. 225 These TLVs can ONLY be added to the BGP-LS Attribute associated with 226 the Node NLRI that originates the corresponding underlying IGP TLV/ 227 sub-TLV described below. [minor] "the Node NLRI that originates the corresponding underlying IGP..." The Node NLRI doesn't originate anything...it describes the IGP node that originates something... Please be specific. [major] The text above sounds as if you want to mandate something... Writing "ONLY" in caps doesn't have a Normative effect. Should there be a "MUST" somewhere? Or perhaps soften a little: s/can ONLY/should only The next question is: what if they are added somewhere else? There doesn't seem to be a way for the receiver to know if the TLVs are associated with the correct Node NLRI... I'm guessing that all the receiver can do is assume that the TLV is referring to the right node... From the text, I'm assuming that the use is intended to be limited to the Node NLRI. Unfortunately, rfc7752 doesn't specify actions to be taken if that is not the case. This comment applies to other places where the "ONLY be added" phrase exists. 229 2.1.1. SID/Label Sub-TLV 231 The SID/Label TLV is used as sub-TLV by the SR-Capabilities 232 (Section 2.1.2) and SRLB (Section 2.1.4) TLVs and has the following 233 format: [nit] s/used as sub-TLV/used as a sub-TLV [minor] This is the first time that SRLB is used in this document, please use the extended version here: s/SRLB/SR Local Block (SRLB) ... 245 Type: TBD, see Section 4. [minor] The code points have already been assigned (early allocation). Please change "TBD" for the actual values. 247 Length: Variable, 3 or 4. [nit] The Length is really not variable...it's 3 or 4. ... 254 The receiving router MUST ignore the SID/Label sub-TLV if the 255 length is other then 3 or 4. [major] If the sub-TLV is ignored, the information in the SR-Capabilities or SR Local Block TLVs will be incomplete (at best). What is the potential impact of that? Is the received information still useful? Should other actions be taken? 257 2.1.2. SR-Capabilities TLV 259 The SR-Capabilities TLV is used in order to advertise the node's SR 260 Capabilities including its Segment Routing Global Base (SRGB) 261 range(s). In the case of IS-IS, the capabilities also include the 262 IPv4 and IPv6 support for SR-MPLS forwarding plane. This information 263 is derived from the protocol specific advertisements. [nit] s/support for SR-MPLS forwarding plane/support for the SR-MPLS forwarding plane 265 o IS-IS, as defined by the SR-Capabilities sub-TLV in 266 [I-D.ietf-isis-segment-routing-extensions]. 268 o OSPFv2/OSPFv3, as defined by the SID/Label Range TLV in 269 [I-D.ietf-ospf-segment-routing-extensions] and 270 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [minor] The text above, pointing at the individual IGP specs is present in many of the descriptions for the TLVs, but not all. Sections 2.4/2.5 have tables that also point at the equivalent TLVs. I'm looking for consistency: either indicate in each section where the information is derived from, or not. Given that §2.4/2.5 already have a summary, I personally find the information (like the one above) in the individual sections redundant. Instead of the statement above, I prefer you to be specific about the values described below -- for example, when describing the Range Size field below, you could say something like this: OLD> Range Size: 3 octet value indicating the number of labels in the range. NEW> Range Size: 3 octet value indicating the number of labels in the range. The value and characteristics of this field are derived from the Range field in the SR-Capabilities sub-TLV in [I-D.ietf-isis-segment-routing-extensions], or from the Range Size field in the SID/Label Range TLV in [I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. Note that doing it this way saves you the need to define the characteristics of each field (because even if the values are derived, the TLVs here are new). This comment obviously applies to all similar instances in the document. 272 The SR Capabilities TLV has following format: [nit] s/has following format/has the following format ... 290 Length: Variable. [major] Yes, it's variable, but it has to be at least 12. What should a router do if the length is < 12? After that, there are only specific valid lengths: 12, 13, 19, 21, etc. What if the length is not one of those values? I couldn't find guidance in rfc7752. The closest statement is from §6.2.2 (Fault Management), where one of the "checks for determining if a message is malformed...Does any fixed-length TLV correspond to the TLV Length field in this document?" This TLV is not fixed-length, but the possibilities are finite. Note that rfc7752 says that if the length is not the expected one, then the whole BGP-LS attribute is discarded. For this specific case, it means that the controller wouldn't have complete knowledge of the network, even if the information derived from the IGP is correct... This comment applies to other similar instances. 292 Flags: 1 octet of flags as defined in 293 [I-D.ietf-isis-segment-routing-extensions]. [major] When the BGP-LS information comes from OSPF, how should the flags be interpreted? There is no indication in the corresponding OSPF drafts of "IPv4 and IPv6 support for SR-MPLS" -- should the bits always be unset? ... 300 Range Size: 3 octet value indicating the number of labels in 301 the range. [nit] s/labels/labels or SIDs [major] What numbers are valid in the Range Size field? Can it be 0? Take a look above at my comments about derived values. 303 SID/Label sub-TLV (as defined in Section 2.1.1) which encodes 304 the first label in the range. [nit] s/first label/first label or SID ... 339 2.1.4. SR Local Block TLV ... 380 Flags: 1 octet of flags. None are defined at this stage. [major] Only the corresponding ISIS sub-TLV has Flags defined -- and I realize that the text above is the same as in draft-ietf-isis-segment-routing-extensions. I think you really don't want this field to evolve independently. IOW, please use a description like the you used for the Flags in the SR-Capabilities TLV. ... 393 2.1.5. SRMS Preference TLV ... 427 The use of the SRMS Preference TLV is defined in 428 [I-D.ietf-isis-segment-routing-extensions], 429 [I-D.ietf-ospf-segment-routing-extensions] and 430 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [major] This document only defines how to carry information in BGP-LS, not what to do with it. IOW, I think that the last paragraph is not needed, it is out of scope of this document... 432 2.2. Link Attribute TLVs 434 The following Link Attribute TLVs are are defined: 436 +----------------------------------------+----------+---------------+ 437 | Description | Length | Section | 438 +----------------------------------------+----------+---------------+ 439 | Adjacency Segment Identifier (Adj-SID) | variable | Section 2.2.1 | 440 | TLV | | | 441 | LAN Adjacency Segment Identifier (Adj- | variable | Section 2.2.2 | 442 | SID) TLV | | | 443 | L2 Bundle Member TLV | variable | Section 2.2.3 | 444 +----------------------------------------+----------+---------------+ 446 Table 2: Link Attribute TLVs [minor] The names used above don't match the names used in the sections below. ... 452 For a LAN, normally a node only announces its adjacency to the IS-IS 453 pseudo-node (or the equivalent OSPF Designated and Backup Designated 454 Routers)[I-D.ietf-isis-segment-routing-extensions]. The LAN 455 Adjacency Segment TLV allows a node to announce adjacencies to all 456 other nodes attached to the LAN in a single instance of the BGP-LS 457 Link NLRI. Without this TLV, the corresponding BGP-LS link NLRI 458 would need to be originated for each additional adjacency in order to 459 advertise the SR TLVs for these neighbor adjacencies. [minor] This paragraph maybe fits better in §2.2.2. 461 2.2.1. Adjacency SID TLV ... 482 Flags. 1 octet field of following flags as defined in 483 [I-D.ietf-isis-segment-routing-extensions], 484 [I-D.ietf-ospf-segment-routing-extensions] and 485 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. NEW> Flags: 1 octet field. The value corresponds to the Flags specified for the Adj-SID Sub-TLV in [I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-ospf-segment-routing-extensions] or [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 487 Weight: Weight used for load-balancing purposes. [minor] Similar to the above text... 489 Reserved: 2 octets that SHOULD be set to 0 and MUST be ignored on 490 receipt. 492 SID/Index/Label: Label or index value depending on the flags 493 setting as defined in [I-D.ietf-isis-segment-routing-extensions], 494 [I-D.ietf-ospf-segment-routing-extensions] and 495 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [minor] Similar text here too... 497 2.2.2. LAN Adjacency SID TLV ... [major] The OSPF Neighbor ID / IS-IS System-ID field is not defined. 542 2.2.3. L2 Bundle Member [nit] s/L2 Bundle Member/L2 Bundle Member Attribute TLV 544 The L2 Bundle Member Attribute TLV identifies an L2 Bundle Member 545 link which in turn is associated with a parent L3 link. The L3 link 546 is described by the Link NLRI defined in [RFC7752] and the L2 Bundle 547 Member Attribute TLV is associated with the Link NLRI. The TLV MAY 548 include sub-TLVs which describe attributes associated with the bundle 549 member. The identified bundle member represents a unidirectional 550 path from the originating router to the neighbor specified in the 551 parent L3 Link. Multiple L2 Bundle Member Attribute TLVs MAY be 552 associated with a Link NLRI. [minor] "identifies an L2 Bundle Member link...The identified bundle member". Are we talking about a link or just the members? ... 574 L2 Bundle Member Descriptor: A Link Local Identifier as defined in 575 [RFC4202]. [major] From the text, it looks like this information is not something that is learned from the IGP, which is then just transported by BGP-LS (just like the rest of the TLVs in this document), but table 5 points at draft-ietf-isis-l2bundles. Why is draft-ietf-isis-l2bundles not used to describe this TLV? [major] rfc4202 is not IS-IS-specific. What about OSPF? I note that rfc4203 defines OSPF extensions that include the Link Local Identifier, so this concept is not foreign to it. 577 Link attributes for L2 Bundle Member Links are advertised as sub-TLVs 578 of the L2Bundle Member Attribute TLV. The sub-TLVs are identical to 579 existing BGP-LS TLVs as identified in the table below. [nit] s/L2Bundle/L2 Bundle ... 633 2.3.1. Prefix-SID TLV ... [major] draft-ietf-ospf-segment-routing-extensions also includes the MT-ID in the Prefix SID Sub-TLV. Is that not needed by a controller? 691 2.3.2. Prefix Attribute Flags TLV ... 711 Length: variable. [minor] The length of the flags fields in rfc7794/rfc7684 are both one octet long. Can this length be made fixed? [major] I could not find a Flags field for OSPFv3 in rfc5340. [minor] From Table 7, it seems that the reference to rfc8362 points to the "Prefix Options Field", is that correct? 713 Flags: a variable length flag field (according to the length 714 field). Flags are routing protocol specific and are to be parsed 715 as below: 717 * IS-IS flags are defined in [RFC7794] 719 * OSPFv2 flags are defined in [RFC7684] 721 * OSPFv3 flags map to the Prefix Options field defined in 722 [RFC7794] and extended via [RFC8362] [nit] The text at the top of this section refers to rfc5340... [major] rfc7794 only talks about IS-IS, not OSPFv3. 724 2.3.3. Source Router Identifier (Source Router-ID) TLV 726 The Source Router-ID TLV contains the IPv4 or IPv6 Router-ID of the 727 originator of the Prefix. For IS-IS protocol this is as defined in 728 [RFC7794]. The Source Router-ID TLV may be used to carry the OSPF 729 Router-ID of the prefix originator. [major] Reference for OSPF? Only "may"?? [major] rfc7752 defines the IGP Router-ID TLV to carry the same information. What is the relationship between these two TLVs? Since the IGP Router-ID TLV is mandatory, are there cases where this one may not be needed? ... 745 Length: 4 or 16. [major] OSPF always uses a 32-bit number. IOW, the length is fixed for OSPF. ... 749 2.3.4. Range TLV 751 The range TLV is used in order to advertise a range of prefix-to-SID 752 mappings as part of the Segment Routing Mapping Server functionality 753 [I-D.ietf-spring-segment-routing-ldp-interop], as defined in the 754 respective underlying IGP SR extensions 755 [I-D.ietf-ospf-segment-routing-extensions], 756 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] and 757 [I-D.ietf-isis-segment-routing-extensions]. The Prefix-NLRI to which 758 the Range TLV is attached MUST be advertised as a non-routing prefix 759 where no IGP metric TLV (TLV 1095) is attached. [major] What do you mean in the final sentence? It sounds as if the IGP metric TLV and the Range TLV are mutually exclusive and should never be advertised together. Is that it? If so, what should the receiver do if they are? 761 The format of the Range TLV is as follows: 763 0 1 2 3 764 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Type | Length | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Flags | Reserved | Range Size | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 // sub-TLVs // 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 where: [nit] That "where" should be after the Figure title. 775 Figure 2: Range TLV format ... [minor] As will all the other sections, please be consistent and fold the sub-sections below into the description above. 804 2.3.4.1. Advertisement Procedure for OSPF 806 The OSPFv2/OSPFv3 Extended Prefix Range TLV is encoded in the Range 807 TLV. The flags of the Range TLV have the semantic mapped to the 808 definition in [I-D.ietf-ospf-segment-routing-extensions] section 4 or 809 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] section 4. 811 Then the prefix-to-SID mapping from the OSPF Prefix SID sub-TLV is 812 encoded using the BGP-LS Prefix-SID TLV as defined in Section 2.3.1 813 with the flags set according to the definition in 814 [I-D.ietf-ospf-segment-routing-extensions] section 5 or 815 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] section 5. [major] The Extended Prefix Range TLV contains other fields not present here: AF, for instance. The last paragraph seems to indicate that the prefix information will be in the BGP-LS Prefix-SID TLV, but that information doesn't come from the Extended Prefix Range TLV (and it doesn't include the AF). What am I missing? [major] The text above seems to imply that the Range TLV and the Prefix-SID TLV should always be included together. Is that true? If so, please make it more explicit. 817 2.3.4.2. Advertisement Procedure for IS-IS 819 The IS-IS SID/Label Binding TLV, when used to signal mapping server 820 label bindings, is encoded in the Range TLV. The flags of the Range 821 TLV have the sematic mapped to the definition in 822 [I-D.ietf-isis-segment-routing-extensions] section 2.4.1. 824 Then the prefix-to-SID mappings from the IS-IS Prefix SID sub-TLV is 825 encoded using the BGP-LS Prefix-SID TLV as defined in Section 2.3.1 826 with the flags set according to the definition in 827 [I-D.ietf-isis-segment-routing-extensions] section 2.4.4.1. [major] Same questions (as above) related to the other fields in the SID/Label Binding TLV, and the relationship between the Range TLV and the Prefix-SID TLV. 829 2.4. Equivalent IS-IS Segment Routing TLVs/Sub-TLVs ... 837 +---------------------------------------+----------+----------------+ 838 | Description | Length | IS-IS TLV/sub- | 839 | | | TLV | 840 +---------------------------------------+----------+----------------+ 841 | SR Capabilities | variable | 2 [1] | 842 | SR Algorithm | variable | 19 [2] | 843 | SR Local Block | variable | 22 [3] | 844 | SRMS Preference | 1 | 19 [4] | 845 | Adjacency Segment Identifier (Adj- | variable | 31 [5] | 846 | SID) | | | 847 | LAN Adjacency Segment Identifier | variable | 32 [6] | 848 | (LAN-Adj-SID) | | | 849 | Prefix SID | variable | 3 [7] | 850 | Range | variable | 149 [8] | 851 | SID/Label TLV | variable | 1 [9] | 852 | Prefix Attribute Flags | variable | 4 [10] | 853 | Source Router ID | variable | 11/12 [11] | 854 | L2 Bundle Member TLV | variable | 25 [12] | 855 +---------------------------------------+----------+----------------+ [major] Instead of using URIs, please put an explicit pointer to the RFC/ID (and if desired, the section)...and make sure that there are corresponding References. If a document is referenced only in this table, then the Reference can be Informative. [nit] For Tables 5-7: No need to use "TLV" in the description. 857 Table 5: IS-IS Segment Routing Extensions TLVs/Sub-TLVs 859 2.5. Equivalent OSPFv2/OSPFv3 Segment Routing TLVs/Sub-TLVs ... 886 Table 6: OSPF Segment Routing Extensions TLVs/Sub-TLVs [nit] s/OSPF/OSPFv2 [minor] The OSPF tables don't include the Source Router ID or the L2 Bundle Member TLVs. Is there a reason for that, or just an oversight? ... 908 3. Implementation Status [nit] This section says nothing. :-( At least a pointer to https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-segment-routing-ext-implementations might be nice. OR, you can just remove it. ... 943 4. IANA Considerations 945 This document requests assigning code-points from the registry "BGP- 946 LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute 947 TLVs" based on table Table 8. The column "IS-IS TLV/Sub-TLV" defined 948 in the registry does not require any value and should be left empty. [major] The early allocation has already been done...so this document doesn't request assignment from IANA. Please update. ... 977 5. Manageability Considerations 979 This section is structured as recommended in [RFC5706]. 981 The new protocol extensions introduced in this document augment the 982 existing IGP topology information that was distributed via [RFC7752]. 983 Procedures and protocol extensions defined in this document do not 984 affect the BGP protocol operations and management other than as 985 discussed in the Manageability Considerations section of [RFC7752]. 986 Specifically, the malformed attribute tests for syntactic checks in 987 the Fault Management section of [RFC7752] now encompass the new BGP- 988 LS Attribute TLVs defined in this document. The semantic or content 989 checking for the TLVs specified in this document and their 990 association with the BGP-LS NLRI types or their BGP-LS Attribute is 991 left to the consumer of the BGP-LS information (e.g. an application 992 or a controller) and not the BGP protocol. [nit] s/that was distributed/that is distributed 994 A consumer of the BGP-LS information is retrieving this information 995 from a BGP protocol component that is doing the signaling over a BGP- 996 LS session, via some APIs or a data model (refer Section 1 and 2 of 997 [RFC7752]). The handling of semantic or content errors by the 998 consumer would be dictated by the nature of its application usage and 999 hence is beyond the scope of this document. This document only 1000 introduces new Attribute TLVs and an error in them would result in 1001 only that specific attribute being discarded with an error log. [nit] s/is retrieving this/retrieves this [minor] "...retrieving this information...over a BGP-LS session, via some APIs or a data model (refer Section 1 and 2 of [RFC7752])." I think that even mentioning that an API or data model can be used instead of BGP-LS is a stretch -- that is not how I interpret the initial sections in rfc7752 (which are just background sections), and there are no formal API/data model definition. [major] "...new Attribute TLVs and an error in them would result in only that specific attribute being discarded with an error log." According to rfc7752, this statement is true only for syntactic errors, not semantic ones. Semantic errors ("left to the consumer", as mentioned above) means that the BGP-LS session can be used to transport trash (trash-in-trash-out). Jeff Haas brought this up during the WGLC [4]. I agree (with the Chairs' conclusion) that this issue is bigger than this document -- but (because we don't have a current solution) I would like to see it mentioned somewhere as a potential issue (maybe in the Management or Security Considerations sections, your choice). [4] https://mailarchive.ietf.org/arch/msg/idr/Yfp6WyqnRtMAOeZvSvK7rYCUkHg [major] rfc7752 does mandate the use of "attribute discard" (rfc7606). I would really like to see a discussion (or at least a mention) around the fact that discarding an attribute may result in the receiver not having complete information. In the case of SR, this implies that the controller may not have complete information to calculate the paths. I think this is an issue bigger than this document, so I am not asking you to solve it...I'm just asking for the document to acknowledge that it exists and to mention what the potential impact may be. 1003 The extensions, specified in this document, do not introduce any new 1004 configuration or monitoring aspects in BGP or BGP-LS other than as 1005 discussed in [RFC7752]. The manageability aspects of the underlying 1006 SR features are covered by [I-D.ietf-spring-sr-yang], 1007 [I-D.ietf-isis-sr-yang] and [I-D.ietf-ospf-sr-yang]. [minor] While the Yang models have to do with management, there are no "manageability aspects of the underlying SR features" included there. [major] Following the recommendations from rfc5706, a Fault Management section would be appropriate to include considerations related to the use of BGP-LS as a transport for SR information (given this is the first draft to propose it), and the possible errors mentioned here... Again, not looking for solutions, just acknowledgement. 1009 6. Security Considerations 1011 The new protocol extensions introduced in this document augment the 1012 existing IGP topology information that was distributed via [RFC7752]. 1013 The Security Considerations section of [RFC7752] also applies to 1014 these extensions. The procedures and new TLVs defined in this 1015 document, by themselves, do not affect the BGP-LS security model 1016 discussed in [RFC7752]. [nit] s/that was distributed/that is distributed 1018 BGP-LS SR extensions enable traffic engineering use-cases within the 1019 Segment Routing domain. SR operates within a trusted domain (refer 1020 Security Considerations section in [RFC8402] for more detail) and its 1021 security considerations also apply to BGP-LS sessions when carrying 1022 SR information.The SR traffic engineering policies using the SIDs 1023 advertised via BGP-LS are expected to be used entirely within this 1024 trusted SR domain (e.g. between multiple AS/domains within a single 1025 provider network). Therefore, precaution is necessary to ensure that 1026 the SR information collected via BGP-LS is limited to specific 1027 controllers or applications in a secure manner within this SR domain. [nit] s/trusted domain (refer Security Considerations section in [RFC8402] for more detail)/trusted domain [RFC8402] [nit] s/SR information.The SR traffic/SR information. The SR traffic [major] "SR operates within a trusted domain...[RFC8402]...and its security considerations also apply to BGP-LS sessions when carrying SR information." The Security Considerations in rfc8404 really only talk about the data plane -- I don't see how they apply to the BGP-LS sessions. [major] "...precaution is necessary to ensure that the SR information collected via BGP-LS is limited to specific controllers or applications..." This sounds as if you're referring to information that (once collected) can be shared between controllers -- I think that case is out of scope. If you are trying to talk about the BGP sessions, then I think the language needs a little more work. BTW, the paragraph below also talks about BGP sessions; suggestion: keep the common topics together. [major] The end of the last sentence says "...in a secure manner within this SR domain". Assuming that we're talking about BGP sessions, what does that mean? Does it mean anything beyond what BGP is normally specified to do? If not, then I would recommend taking that piece of text out to not invite more questions than needed. [minor] You talk about "controllers or applications", but in the rest of the document you have mostly used "consumer" (which is a good thing because it shows consistency with rfc8402). Suggestion: use "consumers" here as well. 1029 The isolation of BGP-LS peering sessions is also required to ensure 1030 that BGP-LS topology information (including the newly added SR 1031 information) is not advertised to an external BGP peering session 1032 outside an administrative domain. [major] What does "isolation of BGP-LS peering sessions" mean? Why is it not Normatively REQUIRED? [major] From prior experience (see draft-ietf-idr-te-pm-bgp), the SecDir/Sec ADs asked for text related to why it is ok to transport the new information in BGP. This is the text that resulted from that discussion: The TLVs introduced in this document are used to propagate IGP defined information ([I-D.ietf-lsr-isis-rfc7810bis] and [RFC7471].) These TLVs represent the state and resource availability of the IGP link. The IGP instances originating these TLVs are assumed to support all the required security and authentication mechanisms (as described in [I-D.ietf-lsr-isis-rfc7810bis] and [RFC7471]) in order to prevent any security issue when propagating the TLVs into BGP-LS. The advertisement of the link attribute information defined in this document presents no additional risk beyond that associated with the existing set of link attribute information already supported in [RFC7752]. Note that this text is complementary to what is already stated in the first paragraph -- but goes into a more explicit explanation and brings in the security considerations from the documents where the IGP extensions are defined. Consider adding something similar here. ... 1126 9.2. Informative References ... 1159 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1160 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1161 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1162 July 2018, . [major] I think this should be a Normative reference. 1164 9.3. URIs [major] As mentioned before, please use References (above) instead of URIs. ... 1197 [12] http://tools.ietf.org/html/draft-ietf-isis-l2bundles-07 [major] The reference should become Normative (see §2.2.3). |
2019-02-12
|
11 | Alvaro Retana | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2019-02-11
|
11 | Susan Hares | Shepherd Write-up: per RFC 4858, template: 2/24/2012 last updated 2/11/2019. -------------- (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, … Shepherd Write-up: per RFC 4858, template: 2/24/2012 last updated 2/11/2019. -------------- (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? Standards RFC - additions to RFC7752 (BGP-LS) in the BGP-LS NLRI in order to pass segment routing (SR) information for IGPS in the BGP-LS NLRI. Extension to RFC7752 to add this information includes: a) Node NLRI within the BGP-LS NLRI that passes SR identifiers (SID), SR capabilities, SR algorithm, SR local block range, and SR mapping server preference. b) The Link NLRI within BGP-LS NLRI that passes SIDs for adjacency, LAN adjaency SID, L2 Bundle TLV. c) prefix NLRI within BGP-LS NLRI that passes: Prefix SID, Prefix attribute (OSPFv2, OSPFv3, ISISflags), Range of prefixes. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by routing protocols e.g. by the link state routing protocols (IS-IS, OSPFv2 and OSPFv3) within IGP topologies. This draft defines extensions to the BGP Link-state address-family defined in RFC7752 in order to carry segment routing information for IGPs in BGP. Extensions include additions to SR routing identifiers (SIDs) for IGP nodes, link adjacencies, and prefixes as well as passing information on SR capabilities, algorithms and mapping servers. Working Group Summary The WG has reviewed the BGP-LS segment routing drafts for 3-5 years in coordination with the SPRING, MPLS, and BESS working groups. Please read the RFC 8402 and draft-ietf-spring-segement-routing-central-epe-15 to understand the architecture construct. This draft is one of a family of BGP additions for BGP-LS segment routing (SR) and and BGP Traffic Engineering (TE) that IDR is standardizing after receiving reports of 2 independent implementations. Other drafts for segment routing reading for standardization include: draft-ietf-idr-bgp-prefix-sid and draft-ietf-idr-bgp-ls-segment-routing-ext. Other drafts for BGP-LS based TE include: draft-ietf-idr-bgp-ls-node-admin-tag-extension and draft-ietf-idr-te-pm-bgp-10. Document Quality 1) technical quality: Existing implementations of the protocol: 2 from Cisco https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-segment-routing-ext-implementations Plans: Huawei has indicated plans to implement. Careful reviews: Jeff Haas (via comments on list) - resulted in -06 https://www.ietf.org/mail-archive/web/idr/current/msg19251.html John Scudder's follow-up https://www.ietf.org/mail-archive/web/idr/current/msg19219.html Aijun Wang https://www.ietf.org/mail-archive/web/idr/current/msg19251.html (Note: Aijun Wang is part of the operational community as operator of a network in China). WGLC: https://www.ietf.org/mail-archive/web/idr/current/msg19116.html RTG-DIR QA reviewer: Victoria Pritchard (pritchardv0@gmail.com) https://mailarchive.ietf.org/arch/msg/rtg-dir/WmMfeAGp6C0j3WRf4NISO9nQOP0\ OPS-DIR QA Reviewer: Joel Jaeggli https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ls-segment-routing-ext-06-opsdir-early-jaeggli-2018-05-08/ Shepherd's comments on RTG-DIR QA review responses: https://mailarchive.ietf.org/arch/msg/idr/mVc8RYCSXCbjWFa9kQOJ58Kd6tI Shepherd's additional comments on security: see thread: https://www.ietf.org/mail-archive/web/idr/current/msg19987.html OPS Comments from Grow WG- sent to grow WG, but no comments received. AD is welcome to ping WG chairs again. Summary for IESG of the security thread: The inclusion of the reference in the security consideration in -10.txt of a specific reference to RFC8402 (SR architecture) and a clear statement that these BGP-LS extensions are to be operated in a trusted domain with isolated BGP peers with filtering restrictions so that this information cannot go outside this peers. In this shepherd's understandings, these restrictions form a web of trusted BGP peers. If these BGP peers operate in the SR-MPLS environment, the authors believe the security analysis provided by RFC4381 should apply. The shepherd is concerned regarding this statement, but if the deployment is within a web of trusted BGP peers then it is the web of trusted BGP peers (each validated by configuration and other means) to the web. These security restrictions are in addition to the RFC7752 security restrictions. Since RFC7752 does not provide require a trusted domain or BGP-LS isolation these additional restrictions are important. Personnel Document Shepherd: Susan Hares Responsible AD: Alvaro Retana RTG-DIR QA reviewer: Victoria Pritchard (pritchardv0@gmail.com) OPS-DIR: QA reviewer: Joel Jaeggli Key onlist reviewers: Jeff Haas, Aijun Wang (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. Reviewer went through draft aligning it with other Spring and IDR work. Reviwer went through the following key reviews: 1) WG LC - Jeff Haas, Aijun Wang 2) Requested QA Reviews RTG-DIR reviewer: Victoria Pritchard (pritchardv0@gmail.com) https://mailarchive.ietf.org/arch/msg/rtg-dir/WmMfeAGp6C0j3WRf4NISO9nQOP0 RTG-DIR QA reviewer: https://mailarchive.ietf.org/arch/msg/rtg-dir/WmMfeAGp6C0j3WRf4NISO9nQOP0 3) Requested Grow WG to review these two drafts for operational usefulness (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. No nits. (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 additional review. (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. Robert Raszuk (and Tony Li's agreement) WG LC is worth reviewing here: (see https://www.ietf.org/mail-archive/web/idr/current/msg19124.html) Robert Rasuk and Tony Li feel that BGP-LS (RFC7752) was unwise direction for BGP, and expanding it is a greater error. The BGP-LS proponents suggested that BGP-LS was simply a way to get IGP data (OSPFv2/v3, ISIS) out of a network for processing. These segment routing additions take the BGP-LS work beyond its initial description of providing information to manage network into the realm of supporting a centralized SDN controller which creates Segment Routing infrastructure. The IESG should consider whether this general application of BGP-LS into creating routing infrastructure is important. If it is, approve this document for publication and the WG chairs and AD will note this decision point. If it is not, then reject this document for publication with the a clear statement that this expansion of work is not appropriate. (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. Stefano Previdi https://www.ietf.org/mail-archive/web/idr/current/msg18493.html https://www.ietf.org/mail-archive/web/idr/current/msg19229.html https://mailarchive.ietf.org/arch/msg/idr/ei5hc-2kVeWscuSsdvnRx9g4pUI Ketan Talaulikar https://www.ietf.org/mail-archive/web/idr/current/msg19225.html Clarence Filsfils https://www.ietf.org/mail-archive/web/idr/current/msg18497.html https://mailarchive.ietf.org/arch/msg/idr/WD1d9B0ZJRZx3HQ3pji3BTyQUxo Hannes Gredler https://www.ietf.org/mail-archive/web/idr/current/msg18498.html https://www.ietf.org/mail-archive/web/idr/current/msg19231.html https://mailarchive.ietf.org/arch/msg/idr/b5nsKpRyh4I5SvDKlGRnKABnSqo Mach Chen https://www.ietf.org/mail-archive/web/idr/current/msg18501.html (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR Disclosure (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? WG in this area tends to be strong pushing toward the draft, but there are concerns raised by the Robert Raszuk, Tony LI, and others regarding this use of BGP as a transport for information. (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 threats of an appeal. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No nits (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. (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? Non-RFC normative draft-ietf-idr-te-pm-bgp 0- approved for RFC draft-ietf-isis-segment-routing-extensions - approved for publication draft-ietf-ospf-ospfv3-segment-routing-extensions-15.txt = approved for publication (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. te the aut -Not as I understand RFC3967 (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. These are additions to RFC7752. (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). AFAIK - this draft followed early allocation procedures correctly. I have sent a request for a IANA QA review, and received an "OK" from IANA. Please do a re-check of the last version. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. none. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None needed |
2019-02-11
|
11 | Susan Hares | Shepherd Write-up: per RFC 4858, template: 2/24/2012 last updated 2/11/2019. -------------- (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, … Shepherd Write-up: per RFC 4858, template: 2/24/2012 last updated 2/11/2019. -------------- (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? Standards RFC - additions to RFC7752 (BGP-LS) in the BGP-LS NLRI in order to pass segment routing (SR) information for IGPS in the BGP-LS NLRI. Extension to RFC7752 to add this information includes: a) Node NLRI within the BGP-LS NLRI that passes SR identifiers (SID), SR capabilities, SR algorithm, SR local block range, and SR mapping server preference. b) The Link NLRI within BGP-LS NLRI that passes SIDs for adjacency, LAN adjaency SID, L2 Bundle TLV. c) prefix NLRI within BGP-LS NLRI that passes: Prefix SID, Prefix attribute (OSPFv2, OSPFv3, ISISflags), Range of prefixes. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by routing protocols e.g. by the link state routing protocols (IS-IS, OSPFv2 and OSPFv3) within IGP topologies. This draft defines extensions to the BGP Link-state address-family defined in RFC7752 in order to carry segment routing information for IGPs in BGP. Extensions include additions to SR routing identifiers (SIDs) for IGP nodes, link adjacencies, and prefixes as well as passing information on SR capabilities, algorithms and mapping servers. Working Group Summary The WG has reviewed the BGP-LS segment routing drafts for 3-5 years in coordination with the SPRING, MPLS, and BESS working groups. Please read the draft-ietf-spring-segment-routing and draft-ietf-spring-segement-routing-central-epe-15 to understand the architecture construct. This draft is one of a family of BGP additions for BGP-LS segment routing (SR) and and BGP Traffic Engineering (TE) that IDR is standardizing after receiving reports of 2 independent implementations. Other drafts for segment routing reading for standardization include: draft-ietf-idr-bgp-prefix-sid and draft-ietf-idr-bgp-ls-segment-routing-ext. Other drafts for BGP-LS based TE include: draft-ietf-idr-bgp-ls-node-admin-tag-extension and draft-ietf-idr-te-pm-bgp-10. Document Quality 1) technical quality: Existing implementations of the protocol: 2 from Cisco https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-segment-routing-ext-implementations Plans: Huawei has indicated plans to implement. Careful reviews: Jeff Haas (via comments on list) - resulted in -06 https://www.ietf.org/mail-archive/web/idr/current/msg19251.html John Scudder's follow-up https://www.ietf.org/mail-archive/web/idr/current/msg19219.html Aijun Wang https://www.ietf.org/mail-archive/web/idr/current/msg19251.html (Note: Aijun Wang is employed by: Network R&D and Operation Support Department China Telecom Corporation Limited Beijing Research Institute,Beijing, China.) WGLC: https://www.ietf.org/mail-archive/web/idr/current/msg19116.html RTG-DIR QA reviewer: Victoria Pritchard (pritchardv0@gmail.com) https://mailarchive.ietf.org/arch/msg/rtg-dir/WmMfeAGp6C0j3WRf4NISO9nQOP0\ OPS-DIR QA Reviewer: Joel Jaeggli https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ls-segment-routing-ext-06-opsdir-early-jaeggli-2018-05-08/ Shepherd's comments on RTG-DIR QA review responses: https://mailarchive.ietf.org/arch/msg/idr/mVc8RYCSXCbjWFa9kQOJ58Kd6tI Shepherd's additional comments on security: see thread: https://www.ietf.org/mail-archive/web/idr/current/msg19987.html OPS Comments from Grow WG- sent to grow WG, but no comments received. AD is welcome to ping WG chairs again. Summary for IESG of the security thread: The inclusion of the reference in the security consideration in -10.txt of a specific reference to RFC8402 (SR architecture) and a clear statement that these BGP-LS extensions are to be operated in a trusted domain with isolated BGP peers with filtering restrictions so that this information cannot go outside this peers. In my understandings, these restrictions form a web of trusted BGP peers. If these BGP peers operate in the SR-MPLS environment, the security analysis provided by RFC4381 should apply. These security restrictions are in addition to the RFC7752 security restrictions. Since RFC7752 does not provide require a trusted domain or BGP-LS isolation these additional restrictions are important. Personnel Document Shepherd: Susan Hares Responsible AD: Alvaro Retana RTG-DIR QA reviewer: Victoria Pritchard (pritchardv0@gmail.com) OPS-DIR: QA reviewer: Joel Jaeggli Key onlist reviewers: Jeff Haas, Aijun Wang (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. Reviewer went through draft aligning it with other Spring and IDR work. Reviwer went through the following key reviews: 1) WG LC - Jeff Haas, Aijun Wang 2) Requested QA Reviews RTG-DIR reviewer: Victoria Pritchard (pritchardv0@gmail.com) https://mailarchive.ietf.org/arch/msg/rtg-dir/WmMfeAGp6C0j3WRf4NISO9nQOP0 RTG-DIR QA reviewer: https://mailarchive.ietf.org/arch/msg/rtg-dir/WmMfeAGp6C0j3WRf4NISO9nQOP0 3) Requested Grow WG to review these two drafts for operational usefulness (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. No nits. (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 additional review. (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. Robert Raszuk (and Tony Li's agreement) WG LC is worth reviewing here: (see https://www.ietf.org/mail-archive/web/idr/current/msg19124.html) Robert Rasuk and Tony Li feel that BGP-LS (RFC7752) was unwise direction for BGP, and expanding it is a greater error. The BGP-LS proponents suggested that BGP-LS was simply a way to get IGP data (OSPFv2/v3, ISIS) out of a network for processing. The segment routing additions take the BGP-LS work into supporting a centralized SDN controller which creates Segment Routing. The IESG should consider whether this is appropriate. (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. Stefano Previdi https://www.ietf.org/mail-archive/web/idr/current/msg18493.html https://www.ietf.org/mail-archive/web/idr/current/msg19229.html https://mailarchive.ietf.org/arch/msg/idr/ei5hc-2kVeWscuSsdvnRx9g4pUI Ketan Talaulikar https://www.ietf.org/mail-archive/web/idr/current/msg19225.html Clarence Filsfils https://www.ietf.org/mail-archive/web/idr/current/msg18497.html https://mailarchive.ietf.org/arch/msg/idr/WD1d9B0ZJRZx3HQ3pji3BTyQUxo Hannes Gredler https://www.ietf.org/mail-archive/web/idr/current/msg18498.html https://www.ietf.org/mail-archive/web/idr/current/msg19231.html https://mailarchive.ietf.org/arch/msg/idr/b5nsKpRyh4I5SvDKlGRnKABnSqo Mach Chen https://www.ietf.org/mail-archive/web/idr/current/msg18501.html (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR Disclosure (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? WG in this area tends to be strong pushing toward the draft, but there are concerns raised by the Robert Raszuk, Tony LI, and others regarding this use of BGP as a transport for information. (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 threats of an appeal. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No nits (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. (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? Non-RFC normative draft-ietf-idr-te-pm-bgp - passed WG LC, this shepherd forward to IESG, see note below. draft-ietf-isis-segment-routing-extensions -pased WG LC, awaiting shepherd's write-up draft-ietf-ospf-ospfv3-segment-routing-extensions-15.txt - passed WG LC, AD review asked for a revised ID. draft-ietf-idr-te-pm-bgp has been forwarded to the IESG, but the sec-dir early review found problems. See this discussion: https://www.ietf.org/mail-archive/web/idr/current/msg19953.html Explanation for the IESG on draft-ietf-idr-te-pm-bgp The shepherd disagreed with the authors on the quality of the security consideration's section in draft-ietf-idr-te-pm-bgp. One of the authors (Les Ginsberg) felt the shepherd/WG chair suggest to revise the security consideration secion was unreasonable. The resolution was to have an independent secdir review of this draft that focused specifically on the security considerations. Security directorate found the same concerns the shepherd did that the security considerations in RFC5572 are vague and do not provide sufficient protection for this additional TE information. Please see the shepherd review for that draft for further details. (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. -Not as I understand RFC3967 (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. These are additions to RFC5572. (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). AFAIK - this draft followed early allocation procedures correctly. I have sent a request for a IANA QA review, and received an "OK" from IANA. Please do a re-check of the last version. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. none. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None needed |
2018-12-14
|
11 | Alvaro Retana | IESG state changed to AD Evaluation from Publication Requested |
2018-12-14
|
11 | Alvaro Retana | Notification list changed to Susan Hares <shares@ndzh.com>, aretana.ietf@gmail.com from Susan Hares <shares@ndzh.com> |
2018-11-04
|
11 | Susan Hares | Shepherd Write-up: per RFC 4858, template: 2/24/2012 Action items: 1) Sent to the Routing AD for publication 2) Resent to Grow WG (11/4/2018) to … Shepherd Write-up: per RFC 4858, template: 2/24/2012 Action items: 1) Sent to the Routing AD for publication 2) Resent to Grow WG (11/4/2018) to get early feedback on ops-dir - -------------- (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? Standards RFC - additions to RFC7752 (BGP-LS) in the BGP-LS NLRI in order to pass segment routing (SR) information for IGPS in the BGP-LS NLRI. Extension to RFC7752 to add this information includes: a) Node NLRI within the BGP-LS NLRI that passes SR identifiers (SID), SR capabilities, SR algorithm, SR local block range, and SR mapping server preference. b) The Link NLRI within BGP-LS NLRI that passes SIDs for adjacency, LAN adjaency SID, L2 Bundle TLV. c) prefix NLRI within BGP-LS NLRI that passes: Prefix SID, Prefix attribute (OSPFv2, OSPFv3, ISISflags), Range of prefixes. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by routing protocols e.g. by the link state routing protocols (IS-IS, OSPFv2 and OSPFv3) within IGP topologies. This draft defines extensions to the BGP Link-state address-family defined in RFC7752 in order to carry segment routing information for IGPs in BGP. Extensions include additions to SR routing identifiers (SIDs) for IGP nodes, link adjacencies, and prefixes as well as passing information on SR capabilities, algorithms and mapping servers. Working Group Summary The WG has reviewed the BGP-LS segment routing drafts for 3-5 years in coordination with the SPRING, MPLS, and BESS working groups. Please read the draft-ietf-spring-segment-routing and draft-ietf-spring-segement-routing-central-epe-15 to understand the architecture construct. This draft is one of a family of BGP additions for BGP-LS segment routing (SR) and and BGP Traffic Engineering (TE) that IDR is standardizing after receiving reports of 2 independent implementations. Other drafts for segment routing reading for standardization include: draft-ietf-idr-bgp-prefix-sid and draft-ietf-idr-bgp-ls-segment-routing-ext. Other drafts for BGP-LS based TE include: draft-ietf-idr-bgp-ls-node-admin-tag-extension and draft-ietf-idr-te-pm-bgp-10. Document Quality 1) technical quality: Existing implementations of the protocol: 2 from Cisco https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-segment-routing-ext-implementations Plans: Huawei has indicated plans to implement. Careful reviews: Jeff Haas (via comments on list) - resulted in -06 https://www.ietf.org/mail-archive/web/idr/current/msg19251.html John Scudder's follow-up https://www.ietf.org/mail-archive/web/idr/current/msg19219.html Aijun Wang https://www.ietf.org/mail-archive/web/idr/current/msg19251.html (Note: Aijun Wang is employed by: Network R&D and Operation Support Department China Telecom Corporation Limited Beijing Research Institute,Beijing, China.) WGLC: https://www.ietf.org/mail-archive/web/idr/current/msg19116.html RTG-DIR QA reviewer: Victoria Pritchard (pritchardv0@gmail.com) https://mailarchive.ietf.org/arch/msg/rtg-dir/WmMfeAGp6C0j3WRf4NISO9nQOP0\ OPS-DIR QA Reviewer: Joel Jaeggli https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ls-segment-routing-ext-06-opsdir-early-jaeggli-2018-05-08/ Shepherd's comments on RTG-DIR QA review responses: https://mailarchive.ietf.org/arch/msg/idr/mVc8RYCSXCbjWFa9kQOJ58Kd6tI Shepherd's additional comments on security: see thread: https://www.ietf.org/mail-archive/web/idr/current/msg19987.html Summary for IESG of the security thread: The inclusion of the reference in the security consideration in -10.txt of a specific reference to RFC8402 (SR architecture) and a clear statement that these BGP-LS extensions are to be operated in a trusted domain with isolated BGP peers with filtering restrictions so that this information cannot go outside this peers. In my understandings, these restrictions form a web of trusted BGP peers. If these BGP peers operate in the SR-MPLS environment, the security analysis provided by RFC4381 should apply. These security restrictions are in addition to the RFC7752 security restrictions. Since RFC7752 does not provide require a trusted domain or BGP-LS isolation these additional restrictions are important. Personnel Document Shepherd: Susan Hares Responsible AD: Alvaro Retana RTG-DIR QA reviewer: Victoria Pritchard (pritchardv0@gmail.com) OPS-DIR: QA reviewer: Joel Jaeggli Key onlist reviewers: Jeff Haas, Aijun Wang (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. Reviewer went through draft aligning it with other Spring and IDR work. Reviwer went through the following key reviews: 1) WG LC - Jeff Haas, Aijun Wang 2) Requested QA Reviews RTG-DIR reviewer: Victoria Pritchard (pritchardv0@gmail.com) https://mailarchive.ietf.org/arch/msg/rtg-dir/WmMfeAGp6C0j3WRf4NISO9nQOP0 RTG-DIR QA reviewer: https://mailarchive.ietf.org/arch/msg/rtg-dir/WmMfeAGp6C0j3WRf4NISO9nQOP0 3) Requested Grow WG to review these two drafts for operational usefulness (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. No nits. (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 additional review. (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. Robert Raszuk (and Tony Li's agreement) WG LC is worth reviewing here: (see https://www.ietf.org/mail-archive/web/idr/current/msg19124.html) Robert Rasuk and Tony Li feel that BGP-LS (RFC7752) was unwise direction for BGP, and expanding it is a greater error. The BGP-LS proponents suggested that BGP-LS was simply a way to get IGP data (OSPFv2/v3, ISIS) out of a network for processing. The segment routing additions take the BGP-LS work into supporting a centralized SDN controller which creates Segment Routing. The IESG should consider whether this is appropriate. (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. Stefano Previdi https://www.ietf.org/mail-archive/web/idr/current/msg18493.html https://www.ietf.org/mail-archive/web/idr/current/msg19229.html https://mailarchive.ietf.org/arch/msg/idr/ei5hc-2kVeWscuSsdvnRx9g4pUI Ketan Talaulikar https://www.ietf.org/mail-archive/web/idr/current/msg19225.html Clarence Filsfils https://www.ietf.org/mail-archive/web/idr/current/msg18497.html https://mailarchive.ietf.org/arch/msg/idr/WD1d9B0ZJRZx3HQ3pji3BTyQUxo Hannes Gredler https://www.ietf.org/mail-archive/web/idr/current/msg18498.html https://www.ietf.org/mail-archive/web/idr/current/msg19231.html https://mailarchive.ietf.org/arch/msg/idr/b5nsKpRyh4I5SvDKlGRnKABnSqo Mach Chen https://www.ietf.org/mail-archive/web/idr/current/msg18501.html (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR Disclosure (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? WG in this area tends to be strong pushing toward the draft, but there are concerns raised by the Robert Raszuk, Tony LI, and others regarding this use of BGP as a transport for information. (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 threats of an appeal. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No nits (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. (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? Non-RFC normative draft-ietf-idr-te-pm-bgp - passed WG LC, this shepherd forward to IESG, see note below. draft-ietf-isis-segment-routing-extensions -pased WG LC, awaiting shepherd's write-up draft-ietf-ospf-ospfv3-segment-routing-extensions-15.txt - passed WG LC, AD review asked for a revised ID. draft-ietf-idr-te-pm-bgp has been forwarded to the IESG, but the sec-dir early review found problems. See this discussion: https://www.ietf.org/mail-archive/web/idr/current/msg19953.html Explanation for the IESG on draft-ietf-idr-te-pm-bgp The shepherd disagreed with the authors on the quality of the security consideration's section in draft-ietf-idr-te-pm-bgp. One of the authors (Les Ginsberg) felt the shepherd/WG chair suggest to revise the security consideration secion was unreasonable. The resolution was to have an independent secdir review of this draft that focused specifically on the security considerations. Security directorate found the same concerns the shepherd did that the security considerations in RFC5572 are vague and do not provide sufficient protection for this additional TE information. Please see the shepherd review for that draft for further details. (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. -Not as I understand RFC3967 (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. These are additions to RFC5572. (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). AFAIK - this draft followed early allocation procedures correctly. I have sent a request for a IANA QA review, and received an "OK" from IANA. Please do a re-check of the last version. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. none. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None needed |
2018-11-04
|
11 | Susan Hares | Responsible AD changed to Alvaro Retana |
2018-11-04
|
11 | Susan Hares | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-11-04
|
11 | Susan Hares | IESG state changed to Publication Requested |
2018-11-04
|
11 | Susan Hares | IESG process started in state Publication Requested |
2018-11-04
|
11 | Susan Hares | Tag Other - see Comment Log cleared. |
2018-11-04
|
11 | Susan Hares | Changed document writeup |
2018-10-22
|
11 | Ketan Talaulikar | New version available: draft-ietf-idr-bgp-ls-segment-routing-ext-11.txt |
2018-10-22
|
11 | (System) | New version approved |
2018-10-22
|
11 | (System) | Request for posting confirmation emailed to previous authors: Mach Chen , Clarence Filsfils , Stefano Previdi , Hannes Gredler , Ketan Talaulikar |
2018-10-22
|
11 | Ketan Talaulikar | Uploaded new revision |
2018-10-21
|
11 | (System) | Request for posting confirmation emailed to previous authors: Mach Chen , Clarence Filsfils , Stefano Previdi , Hannes Gredler , Ketan Talaulikar |
2018-10-21
|
11 | Ketan Talaulikar | Uploaded new revision |
2018-10-20
|
10 | Susan Hares | Changed document writeup |
2018-10-20
|
10 | Susan Hares | Revised IDs have resolved shepherd's comments. 1 week WG LC on changes has been issued (10/20) due on 10/26/2018. |
2018-10-20
|
10 | Susan Hares | Tag Other - see Comment Log set. Tags Revised I-D Needed - Issue raised by WG, Doc Shepherd Follow-up Underway cleared. |
2018-10-20
|
10 | Susan Hares | Changed document writeup |
2018-10-19
|
10 | Ketan Talaulikar | New version available: draft-ietf-idr-bgp-ls-segment-routing-ext-10.txt |
2018-10-19
|
10 | (System) | New version approved |
2018-10-19
|
10 | (System) | Request for posting confirmation emailed to previous authors: Mach Chen , Clarence Filsfils , Stefano Previdi , Hannes Gredler , Ketan Talaulikar |
2018-10-19
|
10 | Ketan Talaulikar | Uploaded new revision |
2018-10-10
|
09 | Ketan Talaulikar | New version available: draft-ietf-idr-bgp-ls-segment-routing-ext-09.txt |
2018-10-10
|
09 | (System) | New version approved |
2018-10-10
|
09 | (System) | Request for posting confirmation emailed to previous authors: Mach Chen , Clarence Filsfils , Stefano Previdi , Hannes Gredler , Ketan Talaulikar |
2018-10-10
|
09 | Ketan Talaulikar | Uploaded new revision |
2018-06-26
|
08 | Susan Hares | Changed document writeup |
2018-06-25
|
08 | Susan Hares | Changed document writeup |
2018-06-17
|
08 | Susan Hares | Changed document writeup |
2018-06-17
|
08 | Susan Hares | Authors need to address Shepherd's review and QA review |
2018-06-17
|
08 | Susan Hares | Tags Revised I-D Needed - Issue raised by WG, Doc Shepherd Follow-up Underway set. |
2018-06-17
|
08 | Susan Hares | Changed document writeup |
2018-06-17
|
08 | Susan Hares | Changed document writeup |
2018-06-16
|
08 | Susan Hares | Changed document writeup |
2018-06-16
|
08 | Susan Hares | Changed document writeup |
2018-06-16
|
08 | Susan Hares | Changed document writeup |
2018-06-16
|
08 | Susan Hares | Changed document writeup |
2018-06-16
|
08 | Susan Hares | Changed document writeup |
2018-06-16
|
08 | Susan Hares | Changed document writeup |
2018-06-15
|
08 | Susan Hares | Changed document writeup |
2018-06-15
|
08 | Susan Hares | Changed document writeup |
2018-06-15
|
08 | Susan Hares | Changed document writeup |
2018-06-08
|
08 | Min Ye | Request for Early review by RTGDIR Completed: Has Issues. Reviewer: Victoria Pritchard. |
2018-05-23
|
08 | Ketan Talaulikar | New version available: draft-ietf-idr-bgp-ls-segment-routing-ext-08.txt |
2018-05-23
|
08 | (System) | New version approved |
2018-05-23
|
08 | (System) | Request for posting confirmation emailed to previous authors: Mach Chen , Clarence Filsfils , Stefano Previdi , Hannes Gredler , Ketan Talaulikar |
2018-05-23
|
08 | Ketan Talaulikar | Uploaded new revision |
2018-05-18
|
07 | Susan Hares | Changed document writeup |
2018-05-15
|
07 | Ketan Talaulikar | New version available: draft-ietf-idr-bgp-ls-segment-routing-ext-07.txt |
2018-05-15
|
07 | (System) | New version approved |
2018-05-15
|
07 | (System) | Request for posting confirmation emailed to previous authors: Mach Chen , Clarence Filsfils , Stefano Previdi , Hannes Gredler , Ketan Talaulikar |
2018-05-15
|
07 | Ketan Talaulikar | Uploaded new revision |
2018-05-08
|
06 | Joel Jaeggli | Request for Early review by OPSDIR Completed: Has Nits. Reviewer: Joel Jaeggli. Sent review to list. |
2018-05-07
|
06 | Min Ye | Request for Early review by RTGDIR is assigned to Victoria Pritchard |
2018-05-07
|
06 | Min Ye | Request for Early review by RTGDIR is assigned to Victoria Pritchard |
2018-05-07
|
06 | Carlos Pignataro | Assignment of request for Early review by RTGDIR to Carlos Pignataro was rejected |
2018-05-07
|
06 | Gunter Van de Velde | Request for Early review by OPSDIR is assigned to Joel Jaeggli |
2018-05-07
|
06 | Gunter Van de Velde | Request for Early review by OPSDIR is assigned to Joel Jaeggli |
2018-05-06
|
06 | Min Ye | Request for Early review by RTGDIR is assigned to Carlos Pignataro |
2018-05-06
|
06 | Min Ye | Request for Early review by RTGDIR is assigned to Carlos Pignataro |
2018-05-04
|
06 | Susan Hares | Notification list changed to Susan Hares <shares@ndzh.com> |
2018-05-04
|
06 | Susan Hares | Document shepherd changed to Susan Hares |
2018-05-04
|
06 | Susan Hares | Requested Early review by RTGDIR |
2018-05-04
|
06 | Susan Hares | Requested Early review by OPSDIR |
2018-05-03
|
06 | John Scudder | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2018-04-11
|
06 | Ketan Talaulikar | New version available: draft-ietf-idr-bgp-ls-segment-routing-ext-06.txt |
2018-04-11
|
06 | (System) | New version approved |
2018-04-11
|
06 | (System) | Request for posting confirmation emailed to previous authors: Mach Chen , Clarence Filsfils , Stefano Previdi , Hannes Gredler , Ketan Talaulikar |
2018-04-11
|
06 | Ketan Talaulikar | Uploaded new revision |
2018-04-10
|
05 | Ketan Talaulikar | New version available: draft-ietf-idr-bgp-ls-segment-routing-ext-05.txt |
2018-04-10
|
05 | (System) | New version approved |
2018-04-10
|
05 | (System) | Request for posting confirmation emailed to previous authors: Mach Chen , Clarence Filsfils , Stefano Previdi , Hannes Gredler , Ketan Talaulikar |
2018-04-10
|
05 | Ketan Talaulikar | Uploaded new revision |
2018-01-25
|
04 | Ketan Talaulikar | New version available: draft-ietf-idr-bgp-ls-segment-routing-ext-04.txt |
2018-01-25
|
04 | (System) | New version approved |
2018-01-25
|
04 | (System) | Request for posting confirmation emailed to previous authors: idr-chairs@ietf.org, Peter Psenak , Hannes Gredler , Mach Chen , Clarence Filsfils , Stefano Previdi |
2018-01-25
|
04 | Ketan Talaulikar | Uploaded new revision |
2017-10-19
|
03 | John Scudder | From: "John G. Scudder" Subject: Re: draft-ietf-idr-bgp-ls-segment-routing-ext prior to WG LC (7/17 - 7/31) Date: October 19, 2017 at 3:59:26 PM GMT+3 To: "idr@ietf. org" … From: "John G. Scudder" Subject: Re: draft-ietf-idr-bgp-ls-segment-routing-ext prior to WG LC (7/17 - 7/31) Date: October 19, 2017 at 3:59:26 PM GMT+3 To: "idr@ietf. org" Cc: "Dongjie (Jimmy)" , Susan Hares Hi All, I see that we never formally closed this WGLC. Since there were no replies at all to the WGLC, there is no consensus to advance the document. Presumably there is still interest in it, considering we were asked for -- and provided -- early allocations, subsequent to the WGLC. So, I guess the WG should reconsider the WGLC in the future, after we've processed the other outstanding WGLCs in our queue. --John |
2017-10-19
|
03 | John Scudder | IETF WG state changed to WG Document from In WG Last Call |
2017-07-26
|
03 | Stefano Previdi | New version available: draft-ietf-idr-bgp-ls-segment-routing-ext-03.txt |
2017-07-26
|
03 | (System) | New version approved |
2017-07-26
|
03 | (System) | Request for posting confirmation emailed to previous authors: Mach Chen , Stefano Previdi , Peter Psenak , Hannes Gredler , Clarence Filsfils |
2017-07-26
|
03 | Stefano Previdi | Uploaded new revision |
2017-07-15
|
02 | Susan Hares | IETF WG state changed to In WG Last Call from WG Document |
2017-06-25
|
02 | Stefano Previdi | New version available: draft-ietf-idr-bgp-ls-segment-routing-ext-02.txt |
2017-06-25
|
02 | (System) | New version approved |
2017-06-25
|
02 | (System) | Request for posting confirmation emailed to previous authors: Stefano Previdi , Hannes Gredler , idr-chairs@ietf.org, Peter Psenak , " jefftant@gmail.com" , Mach Chen … Request for posting confirmation emailed to previous authors: Stefano Previdi , Hannes Gredler , idr-chairs@ietf.org, Peter Psenak , " jefftant@gmail.com" , Mach Chen , Clarence Filsfils |
2017-06-25
|
02 | Stefano Previdi | Uploaded new revision |
2017-02-09
|
01 | Stefano Previdi | New version available: draft-ietf-idr-bgp-ls-segment-routing-ext-01.txt |
2017-02-09
|
01 | (System) | New version approved |
2017-02-09
|
01 | (System) | Request for posting confirmation emailed to previous authors: "Mach Chen" , idr-chairs@ietf.org, "Hannes Gredler" , "Clarence Filsfils" , "Stefano Previdi" , " jefftant@gmail.com" … Request for posting confirmation emailed to previous authors: "Mach Chen" , idr-chairs@ietf.org, "Hannes Gredler" , "Clarence Filsfils" , "Stefano Previdi" , " jefftant@gmail.com" , "Peter Psenak" |
2017-02-09
|
01 | Stefano Previdi | Uploaded new revision |
2016-12-01
|
00 | Susan Hares | This document now replaces draft-gredler-idr-bgp-ls-segment-routing-ext instead of None |
2016-12-01
|
00 | Susan Hares | Changed consensus to Yes from Unknown |
2016-12-01
|
00 | Susan Hares | Intended Status changed to Proposed Standard from None |
2016-11-14
|
00 | Stefano Previdi | New version available: draft-ietf-idr-bgp-ls-segment-routing-ext-00.txt |
2016-11-14
|
00 | (System) | WG -00 approved |
2016-11-14
|
00 | Stefano Previdi | Set submitter to "Stefano Previdi ", replaces to (none) and sent approval email to group chairs: idr-chairs@ietf.org |
2016-11-14
|
00 | Stefano Previdi | Uploaded new revision |