Signaling Maximum SID Depth (MSD) Using IS-IS
RFC 8491
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2018-11-15
|
19 | (System) | IANA registries were updated to include RFC8491 |
|
2018-11-14
|
19 | (System) | Received changes through RFC Editor sync (created alias RFC 8491, changed title to 'Signaling Maximum SID Depth (MSD) Using IS-IS', changed abstract to 'This … Received changes through RFC Editor sync (created alias RFC 8491, changed title to 'Signaling Maximum SID Depth (MSD) Using IS-IS', changed abstract to 'This document defines a way for an Intermediate System to Intermediate System (IS-IS) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment ID (SID) stack can be supported in a given network. This document only defines one type of MSD: Base MPLS Imposition. However, it defines an encoding that can support other MSD types. This document focuses on MSD use in a network that is Segment Routing (SR) enabled, but MSD may also be useful when SR is not enabled.', changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2018-11-14, changed IESG state to RFC Published) |
|
2018-11-14
|
19 | (System) | RFC published |
|
2018-11-12
|
19 | (System) | RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc8491">AUTH48-DONE</a> from AUTH48 |
|
2018-11-07
|
19 | (System) | RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc8491">AUTH48</a> from RFC-EDITOR |
|
2018-10-22
|
19 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
|
2018-10-17
|
19 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2018-10-17
|
19 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
|
2018-10-17
|
19 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
|
2018-10-17
|
19 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2018-10-09
|
19 | Les Ginsberg | New version available: draft-ietf-isis-segment-routing-msd-19.txt |
|
2018-10-09
|
19 | (System) | New version approved |
|
2018-10-09
|
19 | (System) | Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg … Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg <ginsberg@cisco.com> |
|
2018-10-09
|
19 | Les Ginsberg | Uploaded new revision |
|
2018-10-08
|
18 | (System) | RFC Editor state changed to EDIT |
|
2018-10-08
|
18 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
|
2018-10-08
|
18 | (System) | Announcement was received by RFC Editor |
|
2018-10-08
|
18 | (System) | IANA Action state changed to In Progress |
|
2018-10-08
|
18 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
|
2018-10-08
|
18 | Amy Vezza | IESG has approved the document |
|
2018-10-08
|
18 | Amy Vezza | Closed "Approve" ballot |
|
2018-10-08
|
18 | Alvaro Retana | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
|
2018-10-08
|
18 | Alvaro Retana | Ballot approval text was generated |
|
2018-10-04
|
18 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2018-10-04
|
18 | Les Ginsberg | New version available: draft-ietf-isis-segment-routing-msd-18.txt |
|
2018-10-04
|
18 | (System) | New version approved |
|
2018-10-04
|
18 | (System) | Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg … Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg <ginsberg@cisco.com> |
|
2018-10-04
|
18 | Les Ginsberg | Uploaded new revision |
|
2018-09-27
|
17 | Jean Mahoney | Closed request for Last Call review by GENART with state 'No Response' |
|
2018-09-27
|
17 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
|
2018-09-27
|
17 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
|
2018-09-27
|
17 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
|
2018-09-27
|
17 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
|
2018-09-26
|
17 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
|
2018-09-26
|
17 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
|
2018-09-26
|
17 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
|
2018-09-26
|
17 | Benjamin Kaduk | [Ballot comment] Sorry for the re-send; I forgot to add the following paragraph: I'm not sure I followed correctly some discussion around the rtgdir review, … [Ballot comment] Sorry for the re-send; I forgot to add the following paragraph: I'm not sure I followed correctly some discussion around the rtgdir review, specifically the meaning of the indicated MSD value for SR-enabled vs. non-SR-enabled networks. In particular, I still don't really understand why it's okay to use the same codepoint (value 1 as assigned here) for the max SID depth in SR-enabled networks and for the max label depth in non-SR MPLS networks. Why couldn't they just be separate MSD Type codepoints? The shepherd writeup is silent about the WG's discussion of the IPR disclosure (but the corresponding ospf draft says this sort of thing is typical for LSR drafts). Section 3 The link MSD sub-TLV is defined for TLVs 22, 23, 25, 141, 222, and 223 to carry the MSD of the interface associated with the link. MSD Please add the appropriate qualifier (IS-IS?) before the list of TLV numbers. MSD-Value is a number in the range of 0-255. For all MSD-Types, 0 represents lack of the ability to support SID stack of any depth; any other value represents that of the link. It's unclear that there's a referent for "that of the link" to attach to. That is, is it better to say "represents the maximum SID depth supported by the link" (or similar)? Section 6 As discussed in the secdir review, this section needs to include guidance to the Experts to check that the meaning of the absence of an MSD type is specified. Given the text in draft-ietf-ospf-segment-routing-msd that attempts to place a similar requirement on future MSD types (but for OSPF vs. IS-IS usage thereof), hopefully this guidance can be phrased in an appropriately general fashion so as to apply to all places where the registered MSD value would be used. Section 7 Advertisement of the additional information defined in this document that is false, e.g., an MSD that is incorrect, may result in a path computation failing, having a service unavailable, or calculation of a path that cannot be supported by the head-end (the node performing the imposition). In the analogous OSPF document we split out the case of a value that is too small and a value that is too large, to describe the different consequences. I would also suggest rewording to something like "calculation by the head-end of a path that cannot be supported" to avoid the mis-parsing "(calculation of a path) (that cannot be supported by the head-end)". |
|
2018-09-26
|
17 | Benjamin Kaduk | Ballot comment text updated for Benjamin Kaduk |
|
2018-09-26
|
17 | Benjamin Kaduk | [Ballot comment] The shepherd writeup is silent about the WG's discussion of the IPR disclosure (but the corresponding ospf draft says this sort of thing … [Ballot comment] The shepherd writeup is silent about the WG's discussion of the IPR disclosure (but the corresponding ospf draft says this sort of thing is typical for LSR drafts). Section 3 The link MSD sub-TLV is defined for TLVs 22, 23, 25, 141, 222, and 223 to carry the MSD of the interface associated with the link. MSD Please add the appropriate qualifier (IS-IS?) before the list of TLV numbers. MSD-Value is a number in the range of 0-255. For all MSD-Types, 0 represents lack of the ability to support SID stack of any depth; any other value represents that of the link. It's unclear that there's a referent for "that of the link" to attach to. That is, is it better to say "represents the maximum SID depth supported by the link" (or similar)? Section 6 As discussed in the secdir review, this section needs to include guidance to the Experts to check that the meaning of the absence of an MSD type is specified. Given the text in draft-ietf-ospf-segment-routing-msd that attempts to place a similar requirement on future MSD types (but for OSPF vs. IS-IS usage thereof), hopefully this guidance can be phrased in an appropriately general fashion so as to apply to all places where the registered MSD value would be used. Section 7 Advertisement of the additional information defined in this document that is false, e.g., an MSD that is incorrect, may result in a path computation failing, having a service unavailable, or calculation of a path that cannot be supported by the head-end (the node performing the imposition). In the analogous OSPF document we split out the case of a value that is too small and a value that is too large, to describe the different consequences. I would also suggest rewording to something like "calculation by the head-end of a path that cannot be supported" to avoid the mis-parsing "(calculation of a path) (that cannot be supported by the head-end)". |
|
2018-09-26
|
17 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
|
2018-09-26
|
17 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
|
2018-09-26
|
17 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
|
2018-09-26
|
17 | Les Ginsberg | New version available: draft-ietf-isis-segment-routing-msd-17.txt |
|
2018-09-26
|
17 | (System) | New version approved |
|
2018-09-26
|
17 | (System) | Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg … Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg <ginsberg@cisco.com> |
|
2018-09-26
|
17 | Les Ginsberg | Uploaded new revision |
|
2018-09-26
|
16 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
|
2018-09-26
|
16 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
|
2018-09-25
|
16 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
|
2018-09-25
|
16 | David Waltermire | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: David Waltermire. Sent review to list. |
|
2018-09-24
|
16 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
|
2018-09-24
|
16 | Alvaro Retana | Ballot writeup was changed |
|
2018-09-23
|
16 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
|
2018-09-23
|
16 | Les Ginsberg | New version available: draft-ietf-isis-segment-routing-msd-16.txt |
|
2018-09-23
|
16 | (System) | New version approved |
|
2018-09-23
|
16 | (System) | Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg … Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg <ginsberg@cisco.com> |
|
2018-09-23
|
16 | Les Ginsberg | Uploaded new revision |
|
2018-09-23
|
15 | Warren Kumari | [Ballot comment] Thank you for a well written, clear and easy to understand document. Also thanks to Zitao Wang for the OpsDir review ( https://mailarchive.ietf.org/arch/msg/ops-dir/GT5r_8_OukxlqMb1NFdsbNysJIw … [Ballot comment] Thank you for a well written, clear and easy to understand document. Also thanks to Zitao Wang for the OpsDir review ( https://mailarchive.ietf.org/arch/msg/ops-dir/GT5r_8_OukxlqMb1NFdsbNysJIw ) While reviewing it I found some minor nits - these are not blocking comments, but please consider addressing them to make the document even better: 1: Section 1: " Path Computation Element Protocol (PCEP) SR extensions" I think this would read better as "The Path Computation ..." (Hey! I did say they were nits :-)) 2: Section 2. Node MSD Advertisement "Type: 23 (allocated by IANA via the early assignment process)" Comment: Thank you for mentioning here that this is an early allocation - it makes it much easier on the reviewer than flipping to the back of the document to check, flipping forward, etc.! 3: Section 3. Link MSD Advertisement "MSD values may be learned via a hardware API or may be provisioned." I don't quite get what a "hardware API" is -- perhaps "an API which talks directly to the hardware"? Or just drop API (or hardware)? 4: Section 6. IANA Considerations "Per TLV information where Link MSD sub-TLV can be part of: TLV 22 23 25 141 222 223 --- -------------------- yyyyyy Figure 5: TLVs where LINK MSD Sub-TLV can be present" I understand what this is trying to say, but I don't think it does a very good job of doing so. Perhaps remove the figure and just say "The LINK MSD Sub-TLV can be in TLVs 22, 23, 25,141, 222 or 223" or similar.... |
|
2018-09-23
|
15 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
|
2018-09-19
|
15 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
|
2018-09-12
|
15 | Cindy Morgan | Placed on agenda for telechat - 2018-09-27 |
|
2018-09-12
|
15 | Alvaro Retana | IESG state changed to IESG Evaluation from Waiting for Writeup |
|
2018-09-12
|
15 | Alvaro Retana | Ballot has been issued |
|
2018-09-12
|
15 | Alvaro Retana | [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana |
|
2018-09-12
|
15 | Alvaro Retana | Created "Approve" ballot |
|
2018-09-12
|
15 | Alvaro Retana | Ballot writeup was changed |
|
2018-09-12
|
15 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
|
2018-09-10
|
15 | Min Ye | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Julien Meuric. |
|
2018-09-10
|
15 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
|
2018-09-10
|
15 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-isis-segment-routing-msd-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-isis-segment-routing-msd-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 are three actions which we must complete. First, in the Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY TLV) registry on the IS-IS TLV Codepoints registry page located at: https://www.iana.org/assignments/isis-tlv-codepoints/ The early assignment for Value 23: Value Description Reference ----- --------------- ------------- 23 Node MSD [draft-ietf-isis-segment-routing-msd] will be made permanent and the reference changed to [ RFC-to-be ]. Second, in the Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 (Extended IS reachability, IS Neighbor Attribute, L2 Bundle Member Attributes, inter-AS reachability information, MT-ISN, and MT IS Neighbor Attribute TLVs) registry also on the IS-IS TLV Codepoints registry page located at: https://www.iana.org/assignments/isis-tlv-codepoints/ The early assignment for value 15: Value Description Reference ----- --------------- ------------- 15 Link MSD [draft-ietf-isis-segment-routing-msd] will be made permanent and the reference changed to [ RFC-to-be ]. Third, a new registry is to be created called the IGP MSD Types registry. The new registry will be located on the Interior Gateway Protocol (IGP) Parameters registry page located at: https://www.iana.org/assignments/igp-parameters/ The registration procedure is "Expert Review" as defined in [RFC8126]. Types are an unsigned 8 bit number with values from 0 to 255. There are initial values in the new registry as follows: Value Name Reference ----- --------------------- ------------- 0 Reserved [ RFC-to-be ] 1 Base MPLS Imposition MSD [ RFC-to-be ] 2-250 Unassigned [ RFC-to-be ] 251-254 Experimental [ RFC-to-be ] 255 Reserved [ RFC-to-be ] The IANA Functions Operator understands that these are the only actions 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 |
|
2018-09-10
|
15 | Zitao Wang | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Zitao Wang. Sent review to list. |
|
2018-09-06
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
|
2018-09-06
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
|
2018-09-05
|
15 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Zitao Wang |
|
2018-09-05
|
15 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Zitao Wang |
|
2018-08-30
|
15 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to David Waltermire |
|
2018-08-30
|
15 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to David Waltermire |
|
2018-08-29
|
15 | Min Ye | Request for Last Call review by RTGDIR is assigned to Julien Meuric |
|
2018-08-29
|
15 | Min Ye | Request for Last Call review by RTGDIR is assigned to Julien Meuric |
|
2018-08-29
|
15 | Les Ginsberg | New version available: draft-ietf-isis-segment-routing-msd-15.txt |
|
2018-08-29
|
15 | (System) | New version approved |
|
2018-08-29
|
15 | (System) | Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg … Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg <ginsberg@cisco.com> |
|
2018-08-29
|
15 | Les Ginsberg | Uploaded new revision |
|
2018-08-29
|
14 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
|
2018-08-29
|
14 | Cindy Morgan | The following Last Call announcement was sent out (ends 2018-09-12):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: draft-ietf-isis-segment-routing-msd@ietf.org, chopps@chopps.org, … The following Last Call announcement was sent out (ends 2018-09-12):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: draft-ietf-isis-segment-routing-msd@ietf.org, chopps@chopps.org, aretana.ietf@gmail.com, Christian Hopps <chopps@chopps.org>, lsr-chairs@ietf.org, lsr@ietf.org Reply-To: ietf@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-isis-segment-routing-msd-14.txt> (Signaling MSD (Maximum SID Depth) using IS-IS) to Proposed Standard The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'Signaling MSD (Maximum SID Depth) using IS-IS' <draft-ietf-isis-segment-routing-msd-14.txt> as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-09-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a way for an Intermediate System to Intermediate System (IS-IS) Router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular SID stack can be supported in a given network. This document only defines one type of MSD maximum label imposition, but defines an encoding that can support other MSD types. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3037/ https://datatracker.ietf.org/ipr/3255/ |
|
2018-08-29
|
14 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
|
2018-08-29
|
14 | Alvaro Retana | Requested Last Call review by RTGDIR |
|
2018-08-29
|
14 | Alvaro Retana | Last call was requested |
|
2018-08-29
|
14 | Alvaro Retana | Ballot approval text was generated |
|
2018-08-29
|
14 | Alvaro Retana | Ballot writeup was generated |
|
2018-08-29
|
14 | Alvaro Retana | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
|
2018-08-29
|
14 | Alvaro Retana | Last call announcement was generated |
|
2018-08-19
|
14 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2018-08-19
|
14 | Les Ginsberg | New version available: draft-ietf-isis-segment-routing-msd-14.txt |
|
2018-08-19
|
14 | (System) | New version approved |
|
2018-08-19
|
14 | (System) | Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg … Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg <ginsberg@cisco.com> |
|
2018-08-19
|
14 | Les Ginsberg | Uploaded new revision |
|
2018-08-15
|
13 | Alvaro Retana | === AD Review of draft-ietf-isis-segment-routing-msd-13 === (https://mailarchive.ietf.org/arch/msg/lsr/FJEl9YBq9a19CsF7dXyEijQbojI) Dear authors: I just finished reading this document. I have several comments and concerns that I … === AD Review of draft-ietf-isis-segment-routing-msd-13 === (https://mailarchive.ietf.org/arch/msg/lsr/FJEl9YBq9a19CsF7dXyEijQbojI) Dear authors: I just finished reading this document. I have several comments and concerns that I included inline below. One item that I want to highlight here is the lack of specific procedures defined to handle the cases of multiple advertisements (in both §2 and §3). Please take a look at my specific comments below -- in short, a clear specification is required for proper interoperability. I will wait for (at least) this item to be addressed before starting the IETF LC. Thanks! Alvaro. [The line numbers came from the idnits output.] ... 76 1. Introduction ... 95 links in the network MSD is relevant, MSD capabilites should be 96 advertised by every IS-IS router in the network. [nit] s/capabilites/capabilities ... 109 or SIDs associated with another dataplane e.g., IPv6. Although MSD 110 advertisements are associated with Segment Routing, the 111 advertisements MAY be present even if Segment Routing itself is not 112 enabled. [minor] Given that you're using Normative language... It would be nice if you expanded on the use of the MSD in a non-SR network. Something simple such as "a SID and a label are the same thing" would be enough. 114 1.1. Conventions used in this document 116 1.1.1. Terminology [minor] Except for BMI/MSD, the other terms are not definitions, just expansions. Some of the abbreviations are already included in the RFC Editor Abbreviations List [1]. In general, it would be better to just expand on first use (BGP-LS, for example, is used *before* this section) than to have this section with expansions. [1] https://www.rfc-editor.org/materials/abbrev.expansion.txt ... 147 2. Node MSD Advertisement ... 156 0 1 157 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Type | Length | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | MSD-Type | MSD Value | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 // ................... // 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | MSD-Type | MSD Value | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 Figure 1: Node MSD Sub-TLV 171 Type: 23 (allocated by IANA via the early assignment process) 173 Length: variable (minimum of 2, multiple of 2 octets) and represents 174 the total length of value field. [nit] ...in octets (?). 176 Value: field consists of one or more pairs of a 1 octet MSD-Type and 177 1 octet MSD-Value. [nit] There is no "Value" field illustrated above. You might want to reword a little. [nit] The figure says "MSD Value", but the text talks about "MSD-Value". ... 191 If there exist multiple Node MSD advertisements for the same MSD-Type 192 originated by the same router, the procedures defined in [RFC7981] 193 apply. [major] Does this text refer to multiple node MSD sub-TLVs (inside the same, or different, IS-IS Router CAPABILITY TLV), or to the same MSD-Type (included multiple times in a node MSD sub-TLV), or both? [major] The only relevant text I can find in rfc7981 is this: Where a receiving system has two copies of an IS-IS Router CAPABILITY TLV from the same system that have conflicting information for a given sub-TLV, the procedure used to choose which copy shall be used is undefined. I then don't know how to handle the multiple advertisements. Please point me in the right direction. 195 3. Link MSD Advertisement 197 The link MSD sub-TLV is defined for TLVs 22, 23, 25, 141, 222, and 198 223 to carry the MSD of the interface associated with the link. MSD 199 values may be learned via a hardware API or may be provisioned. [nit] A reference to the appropriate RFCs would be nice. 201 0 1 202 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Type | Length | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | MSD-Type | MSD Value | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 // ................... // 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | MSD-Type | MSD Value | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 Figure 2: Link MSD Sub-TLV 216 Type: 15 (allocated by IANA via the early assignment process) 218 Length: variable (minimum of 2, multiple of 2 octets) and represents 219 the total length of value field. [nit] ...in octets (?). 221 Value: consists of one or more pairs of a 1 octet MSD-Type and 1 222 octet Value. [nit] There is no "Value" field illustrated above. You might want to reword a little. [nit] The figure says "MSD Value", but the text talks about "Value". ... 235 If multiple Link MSD advertisements for the same MSD Type and the 236 same link are received, the procedure used to select which copy is 237 used is undefined. [major] Does this text refer to multiple link MSD sub-TLVs (inside the same, or different, IS-IS Router CAPABILITY TLV), or to the same MSD-Type (included multiple times in a link MSD sub-TLV), or both? [major] Without a procedure "it is unlikely that multiple implementations of the specification would interoperate" [2]. [2] https://www.ietf.org/blog/discuss-criteria-iesg-review/ 239 4. Using Node and Link MSD Advertisements [major] After reading this section, I still don't know how do use the advertisements. What should a receiver do with the values? Maybe the use is constrained to a controller...maybe the exact operation is our of the scope of this document. Either way, please say something. 241 When Link MSD is present for a given MSD type, the value of the Link 242 MSD MUST take preference over the Node MSD. When a Link MSD type is 243 not signalled but the Node MSD type is, then the Node MSD type value 244 MUST be considered as the MSD value for that link. [nit] s/signalled/signaled ... 258 5. Base MPLS Imposition MSD 260 Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS 261 labels a node is capable of imposing, including all 262 service/transport/special labels. 264 Absence of BMI-MSD advertisements indicates solely that the 265 advertising node does not support advertisement of this capability. [major] The MSD Types are applicable for both nodes and links, right? The description above only talks about nodes -- what about links? 267 6. IANA Considerations 269 This document requests IANA to allocate a sub-TLV type for the new 270 sub TLV proposed in Section 2 of this document from IS-IS Router 271 Capability TLV Registry as defined by [RFC7981]. [minor] The registry is called "Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY TLV)". [3] [3] https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-242 ... 303 This document requests creation of an IANA managed registry under a 304 new category of "Interior Gateway Protocol (IGP) Parameters" IANA 305 registries to identify MSD types as proposed in Section 2 and 306 Section 3. The registration procedure is "Expert Review" as defined 307 in [RFC8126]. Suggested registry name is "IGP MSD Types". Types are 308 an unsigned 8 bit number. The following values are defined by this 309 document [nit] s/under a new category/under the category [major] This creation of the registry needs to include the "required documentation and review criteria, giving clear guidance to the designated expert" -- please see §4.5 in rfc8126. 311 Value Name Reference 312 ----- --------------------- ------------- 313 0 Reserved This document [major] 0 is not Reserved, but has a specific meaning (from §2 and §3). 314 1 Base MPLS Imposition MSD This document 315 2-250 Unassigned This document 316 251-254 Experimental This document 317 255 Reserved This document 319 Figure 6: MSD Types Codepoints Registry 321 7. Security Considerations 323 Security considerations as specified by [RFC7981] are applicable to 324 this document. 326 Advertisement of the additional information defined in this document 327 that is false, e.g., an MSD that is incorrect, may result in a path 328 computation failing, having a service unavailable, or instantiation 329 of a path that can't be supported by the head-end (the node 330 performing the imposition). [major] rfc7981 says that "specifications based on this mechanism need to describe the security considerations around the disclosure and modification of their information". I think that the paragraph above applies also to modification. What about disclosure? ... 364 10.2. Informative References [major] rfc8126 should be Normative. ... 390 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 391 Writing an IANA Considerations Section in RFCs", BCP 26, 392 RFC 8126, DOI 10.17487/RFC8126, June 2017, 393 <https://www.rfc-editor.org/info/rfc8126>. |
|
2018-08-15
|
13 | Alvaro Retana | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
|
2018-08-14
|
13 | Alvaro Retana | IESG state changed to AD Evaluation from Publication Requested |
|
2018-08-14
|
13 | Alvaro Retana | Notification list changed to Christian Hopps <chopps@chopps.org>, aretana.ietf@gmail.com from Christian Hopps <chopps@chopps.org> |
|
2018-08-13
|
Jenny Bui | Posted related IPR disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-isis-segment-routing-msd | |
|
2018-07-24
|
13 | Jeff Tantsura | New version available: draft-ietf-isis-segment-routing-msd-13.txt |
|
2018-07-24
|
13 | (System) | New version approved |
|
2018-07-24
|
13 | (System) | Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg … Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg <ginsberg@cisco.com> |
|
2018-07-24
|
13 | Jeff Tantsura | Uploaded new revision |
|
2018-06-16
|
12 | Christian Hopps | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? A Standards Track RFC is being requested and is indicated in the title page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes IS-IS protocol extensions to disseminate Segment Routing Maximum Segment Depth (MSD) information. The initial and only MSD type specified is "Label Imposition MSD", i.e., the maximum number of labels that can be imposed for a link or router (minimum of all links). An analogous OSPF document exists as well. Working Group Summary: Good consensus, and no controversy. Document Quality: This document has been a WG document for over a year (and has existed for over 2 yars) and has been regularly revised and well reviewed. Personnel: Shepherd: Christian Hopps AD: Alvaro Retana (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. I have personally reviewed this document, and provided comments that led to the final revision which is being submitted to the IESG. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes, https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-isis-segment-routing-msd (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? Strong consensus from vendors and operators. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No Nits. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Reviewed, also as expert review for earlier code-point allocation. New registry is OK. (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. An IGP agnostic registry "MSD types" with Expert Review is being created with an initial single entry along with some reserved values. Any of the standard IS-IS experts would be good choices as experts here (Les (also doc author), myself (co-chair), Hannes), but also another OSPF focused expert my be useful e.g., Acee or Peter Psenak? (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. N/A |
|
2018-06-16
|
12 | Christian Hopps | Responsible AD changed to Alvaro Retana |
|
2018-06-16
|
12 | Christian Hopps | IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead |
|
2018-06-16
|
12 | Christian Hopps | IESG state changed to Publication Requested |
|
2018-06-16
|
12 | Christian Hopps | IESG process started in state Publication Requested |
|
2018-06-16
|
12 | Christian Hopps | Changed document writeup |
|
2018-06-16
|
12 | Christian Hopps | Changed document writeup |
|
2018-06-13
|
12 | Christian Hopps | Changed document writeup |
|
2018-06-13
|
12 | Christian Hopps | Changed document writeup |
|
2018-06-13
|
12 | Christian Hopps | Changed document writeup |
|
2018-06-13
|
12 | Christian Hopps | Notification list changed to Christian Hopps <chopps@chopps.org> |
|
2018-06-13
|
12 | Christian Hopps | Document shepherd changed to Christian Hopps |
|
2018-05-16
|
12 | Les Ginsberg | New version available: draft-ietf-isis-segment-routing-msd-12.txt |
|
2018-05-16
|
12 | (System) | New version approved |
|
2018-05-16
|
12 | (System) | Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg … Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg <ginsberg@cisco.com> |
|
2018-05-16
|
12 | Les Ginsberg | Uploaded new revision |
|
2018-05-10
|
11 | Les Ginsberg | New version available: draft-ietf-isis-segment-routing-msd-11.txt |
|
2018-05-10
|
11 | (System) | New version approved |
|
2018-05-10
|
11 | (System) | Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg … Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg <ginsberg@cisco.com> |
|
2018-05-10
|
11 | Les Ginsberg | Uploaded new revision |
|
2018-04-09
|
10 | Jeff Tantsura | New version available: draft-ietf-isis-segment-routing-msd-10.txt |
|
2018-04-09
|
10 | (System) | New version approved |
|
2018-04-09
|
10 | (System) | Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg … Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg <ginsberg@cisco.com> |
|
2018-04-09
|
10 | Jeff Tantsura | Uploaded new revision |
|
2018-02-25
|
09 | Christian Hopps | Moving this to LSR. |
|
2018-02-25
|
09 | Christian Hopps | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
|
2018-02-25
|
09 | Christian Hopps | Notification list changed to none |
|
2018-02-25
|
09 | Christian Hopps | Changed group to Link State Routing (LSR) from IS-IS for IP Internets (ISIS) |
|
2018-01-10
|
09 | Les Ginsberg | New version available: draft-ietf-isis-segment-routing-msd-09.txt |
|
2018-01-10
|
09 | (System) | New version approved |
|
2018-01-10
|
09 | (System) | Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg … Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg <ginsberg@cisco.com> |
|
2018-01-10
|
09 | Les Ginsberg | Uploaded new revision |
|
2018-01-05
|
08 | Jeff Tantsura | New version available: draft-ietf-isis-segment-routing-msd-08.txt |
|
2018-01-05
|
08 | (System) | New version approved |
|
2018-01-05
|
08 | (System) | Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg … Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg <ginsberg@cisco.com> |
|
2018-01-05
|
08 | Jeff Tantsura | Uploaded new revision |
|
2017-12-20
|
07 | Christian Hopps | Extra time due to common PTO patterns. |
|
2017-12-20
|
07 | Christian Hopps | IETF WG state changed to In WG Last Call from WG Document |
|
2017-12-20
|
07 | Christian Hopps | Changed consensus to Yes from Unknown |
|
2017-12-20
|
07 | Christian Hopps | Intended Status changed to Proposed Standard from None |
|
2017-12-04
|
07 | Jeff Tantsura | New version available: draft-ietf-isis-segment-routing-msd-07.txt |
|
2017-12-04
|
07 | (System) | New version approved |
|
2017-12-04
|
07 | (System) | Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg … Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg <ginsberg@cisco.com> |
|
2017-12-04
|
07 | Jeff Tantsura | Uploaded new revision |
|
2017-11-29
|
06 | Jeff Tantsura | New version available: draft-ietf-isis-segment-routing-msd-06.txt |
|
2017-11-29
|
06 | (System) | New version approved |
|
2017-11-29
|
06 | (System) | Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg … Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg <ginsberg@cisco.com> |
|
2017-11-29
|
06 | Jeff Tantsura | Uploaded new revision |
|
2017-11-29
|
05 | Jeff Tantsura | New version available: draft-ietf-isis-segment-routing-msd-05.txt |
|
2017-11-29
|
05 | (System) | New version approved |
|
2017-11-29
|
05 | (System) | Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg … Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg <ginsberg@cisco.com> |
|
2017-11-29
|
05 | Jeff Tantsura | Uploaded new revision |
|
2017-07-26
|
Naveen Khan | Posted related IPR disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-isis-segment-routing-msd | |
|
2017-06-04
|
04 | Jeff Tantsura | New version available: draft-ietf-isis-segment-routing-msd-04.txt |
|
2017-06-04
|
04 | (System) | New version approved |
|
2017-06-04
|
04 | (System) | Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg … Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg <ginsberg@cisco.com> |
|
2017-06-04
|
04 | Jeff Tantsura | Uploaded new revision |
|
2017-03-27
|
03 | Jeff Tantsura | New version available: draft-ietf-isis-segment-routing-msd-03.txt |
|
2017-03-27
|
03 | (System) | New version approved |
|
2017-03-27
|
03 | (System) | Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg … Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg <ginsberg@cisco.com> |
|
2017-03-27
|
03 | Jeff Tantsura | Uploaded new revision |
|
2017-03-02
|
02 | Uma Chunduri | New version available: draft-ietf-isis-segment-routing-msd-02.txt |
|
2017-03-02
|
02 | (System) | New version approved |
|
2017-03-02
|
02 | (System) | Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg … Request for posting confirmation emailed to previous authors: Sam Aldrin <aldrin.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Uma Chunduri <uma.chunduri@huawei.com>, Les Ginsberg <ginsberg@cisco.com> |
|
2017-03-02
|
02 | Uma Chunduri | Uploaded new revision |
|
2017-03-02
|
01 | Jeff Tantsura | New version available: draft-ietf-isis-segment-routing-msd-01.txt |
|
2017-03-02
|
01 | (System) | New version approved |
|
2017-03-02
|
01 | (System) | Request for posting confirmation emailed to previous authors: Uma Chunduri <uma.chunduri@gmail.com>, isis-chairs@ietf.org, Jeff Tantsura <jefftant.ietf@gmail.com> |
|
2017-03-02
|
01 | Jeff Tantsura | Uploaded new revision |
|
2016-11-15
|
00 | Hannes Gredler | This document now replaces draft-tantsura-isis-segment-routing-msd instead of None |
|
2016-11-15
|
00 | Jeff Tantsura | New version available: draft-ietf-isis-segment-routing-msd-00.txt |
|
2016-11-15
|
00 | (System) | WG -00 approved |
|
2016-11-15
|
00 | Jeff Tantsura | Set submitter to "Jeff Tantsura <jefftant.ietf@gmail.com>", replaces to draft-tantsura-isis-segment-routing-msd and sent approval email to group chairs: isis-chairs@ietf.org |
|
2016-11-15
|
00 | Jeff Tantsura | Uploaded new revision |