Restart Signaling for IS-IS
draft-ietf-lsr-isis-rfc5306bis-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-02-21
|
09 | (System) | RFC Editor state changed to AUTH48-DONE |
2020-02-11
|
09 | (System) | RFC Editor state changed to TI from AUTH48 |
2020-02-03
|
09 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-11-07
|
09 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-10-18
|
09 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Joel Jaeggli was marked no-response |
2019-09-26
|
09 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2019-09-26
|
09 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2019-09-26
|
09 | Tero Kivinen | Assignment of request for Last Call review by SECDIR to Daniel Gillmor was marked no-response |
2019-09-25
|
09 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-09-20
|
09 | (System) | RFC Editor state changed to EDIT |
2019-09-20
|
09 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-09-20
|
09 | (System) | Announcement was received by RFC Editor |
2019-09-20
|
09 | (System) | IANA Action state changed to In Progress |
2019-09-20
|
09 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-09-20
|
09 | Amy Vezza | IESG has approved the document |
2019-09-20
|
09 | Amy Vezza | Closed "Approve" ballot |
2019-09-20
|
09 | Alvaro Retana | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2019-09-20
|
09 | Alvaro Retana | Ballot approval text was generated |
2019-09-19
|
09 | Les Ginsberg | New version available: draft-ietf-lsr-isis-rfc5306bis-09.txt |
2019-09-19
|
09 | (System) | New version approved |
2019-09-19
|
09 | (System) | Request for posting confirmation emailed to previous authors: Paul Wells , Les Ginsberg |
2019-09-19
|
09 | Les Ginsberg | Uploaded new revision |
2019-09-19
|
08 | Benjamin Kaduk | [Ballot comment] Thanks for addressing my Discuss points and comments! |
2019-09-19
|
08 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2019-09-19
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-09-19
|
08 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-09-19
|
08 | Les Ginsberg | New version available: draft-ietf-lsr-isis-rfc5306bis-08.txt |
2019-09-19
|
08 | (System) | New version approved |
2019-09-19
|
08 | (System) | Request for posting confirmation emailed to previous authors: Paul Wells , Les Ginsberg |
2019-09-19
|
08 | Les Ginsberg | Uploaded new revision |
2019-09-19
|
07 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2019-09-19
|
07 | Roman Danyliw | [Ballot comment] Thank you for addressing my COMMENTs. |
2019-09-19
|
07 | Roman Danyliw | Ballot comment text updated for Roman Danyliw |
2019-09-19
|
07 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2019-09-19
|
07 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2019-09-18
|
07 | Benjamin Kaduk | [Ballot discuss] Section 3.2 notes that "the presence of [the Restart] TLV indicates that the sender supports the functionality defined in this document". But, while … [Ballot discuss] Section 3.2 notes that "the presence of [the Restart] TLV indicates that the sender supports the functionality defined in this document". But, while that was true for RFC 5306, I don't see how it can be true for the extended functionality that's new in this document. It seems on first look that the need for a PR to be acknowledged by a PA means that the routers in question will be able to properly determine full feature support at runtime, in which case this is essentially an editorial issue, but I would like to make sure it's received enough thought, so am raising it as a Discuss point to get the needed discussion. (We will still need to change this text to reflect reality, though.) It's also unclear to me if we need to give more description of the behavior when a router planning to restart does not receive (all) the necessary PAs -- does it cancel the planned restart? Fall back to the regular RR usage? It looks like there's an internal inconsistency between Section 3.2 ("[w]hen transmitting a TLV multiple flags MUST NOT be set.") and Section 3.3.2 ("the IIH is retransmitted with both RR and SA bits set"). |
2019-09-18
|
07 | Benjamin Kaduk | [Ballot comment] Abstract Four paragraphs is perhaps pushing it a bit, for RFC style. It might also be nice to avoid starting two sentences with … [Ballot comment] Abstract Four paragraphs is perhaps pushing it a bit, for RFC style. It might also be nice to avoid starting two sentences with "This document additionally describes", e.g., as Barry suggests. It also seems a little mismatched to me to differentiate between "restart while maintaining forwarding plane state" and "restarting", since in Section 2 we make the convention that "restarting" means that forwarding state is maintained definitionally. Section 1 In the case of a restarting router process, the first of these is highly undesirable, but the second is essential in order to ensure synchronization of the LSP database. Is the convention introduced in section 2 about preserving forarding state intended to apply here? Section 3.2.3 Neighbors of the router which has signaled planned restart SHOULD maintain the adjacency in a planned restart state until it receives an IIH with the RR bit set, receives an IIH with both PR and RR bits clear, or the adjacency holding time expires - whichever occurs first. When might a router want to ignore the SHOULD (and how so)? c. on a Point-to-Point circuit, transmission of LSPs, CSNPs, and PSNPs MAY be suppressed. It is expected that the PDUs will not be received. Are there any security considerations here (e.g., a spoofed PR flag would cause suppression of updates and potentially DoS)? Section 4.1 I'm a little surprised to see "RX PA" under the "Running Router" table, since I thought the "running" categorization was supposed to imply that it was not going to restart (which would be a "restarting router"). If the categorizations are exclusive, then receiving PA would be an error condition. Section 6 I think we should go a bit further about the false-IIH with PR bit set, since there is not a protocol mechanism to apply any sanity check to the hold time that the recipient is obligated to apply (overriding local policy). Such spoofed values could be unreasonably large, and it may be prudent to have a policy filter that rejects implausible values. Even if such a policy is present, it seems that a series of spoofed IIHs with PR set could force an adjacency to be maintained (absent topology changes), by cancelling the PR-bit and then sending a new PR-bit in quick succession. Relatedly, Section 3.2.1's description of the RR/RA bits notes that: "This procedure allows the restarting router to cause the neighbor to maintain the adjacency long enough for restart to successfully complete, while also preventing repetitive restarts from maintaining an adjacency indefinitely." It doesn't seem that this property (preventing repetitive restarts from maintaining an adjacency indefinitely) still holds for PR/PA with a neighbor router that is (mis)behaving in a certain way. Explicitly noting this disparity seems reasonable to me. |
2019-09-18
|
07 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2019-09-18
|
07 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-09-18
|
07 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2019-09-18
|
07 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2019-09-18
|
07 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-09-18
|
07 | Les Ginsberg | New version available: draft-ietf-lsr-isis-rfc5306bis-07.txt |
2019-09-18
|
07 | (System) | New version approved |
2019-09-18
|
07 | (System) | Request for posting confirmation emailed to previous authors: Paul Wells , Les Ginsberg |
2019-09-18
|
07 | Les Ginsberg | Uploaded new revision |
2019-09-18
|
06 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2019-09-18
|
06 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2019-09-18
|
06 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-09-18
|
06 | Roman Danyliw | [Ballot comment] (1) Section 3.1. The two “NOTE” statements in this section seem to conflict: -- NOTE: These timers are NOT applicable to a router … [Ballot comment] (1) Section 3.1. The two “NOTE” statements in this section seem to conflict: -- NOTE: These timers are NOT applicable to a router which is preparing to do a planned restart. -- NOTE: The timer T3 is only used by a restarting router. (2) Per the definition of the “Remaining Time” field, when is it the “remaining holding time” vs. “recommended holding time" (3) Editorial Nits: -- Multiple places. s/signalling/signaling/g |
2019-09-18
|
06 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2019-09-18
|
06 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2019-09-17
|
06 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-09-17
|
06 | Les Ginsberg | New version available: draft-ietf-lsr-isis-rfc5306bis-06.txt |
2019-09-17
|
06 | (System) | New version approved |
2019-09-17
|
06 | (System) | Request for posting confirmation emailed to previous authors: Paul Wells , Les Ginsberg |
2019-09-17
|
06 | Les Ginsberg | Uploaded new revision |
2019-09-17
|
05 | Martin Vigoureux | [Ballot comment] Hello, thank you for this document. What is the expected behaviour, if any needing to be described, when the neighbor of a router … [Ballot comment] Hello, thank you for this document. What is the expected behaviour, if any needing to be described, when the neighbor of a router planning to restart decides to also plan a restart? Thank you |
2019-09-17
|
05 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-09-16
|
05 | Warren Kumari | [Ballot comment] Thank you for writing / updating this, it's really useful. I do have some comments though: 1: "2. It sets SRMflags on its … [Ballot comment] Thank you for writing / updating this, it's really useful. I do have some comments though: 1: "2. It sets SRMflags on its own LSP database on the adjacency concerned." There are a number of instances throughout this document where acronyms / terms are used without expansion - this being just one instance. I think that the right reference here is RFC1142, but it sure would make reading the doc easier if these were cited / expanded. I get that this is a -bis, so perhaps just a "Familiarity with IS-IS and RFC 1142, ... ... is assumed"? 2: Section 3.1. Timers "A typical value is 3 seconds." -- for this, and other timers, you list a "typical" value - typical implies "not universal / fixed", so *who* should be twiddling it? Is it defined to be 3? Should vendors choose the right number or should this be user configurable (I assume the latter, but...) 3: I'm assuming I'm missing something really obvious here, but: "The RA bit is sent by the neighbor of a (re)starting router to acknowledge the receipt of a restart TLV with the RR bit set." -- and then what / why? Let's say I'm a restarting router, and I ** don't ** get a receipt from a neighbor, does that mean I hold off on restarting? Do I resend until I *do* get a RA response? 4: "... the first time the router has started, copies of LSPs generated by this router in its previous incarnation may exist in the LSP databases of other routers in the network." No action needed, I just wanted to mention that I really liked the use of "incarnation" here. I'm not sure if this came from the original or -bis, but it was good... 5: "NOTE: Receipt of an IIH with PA bit set indicates to the router planning a restart that the neighbor is aware of the planned restart and - in the absence of topology changes as described below - will maintain the adjacency for the "remaining time" included in the IIH with PA set." -- Sounds good, but as I understand it, Remaining Time can be up to 65535 seconds -- this is (I think) 18 hours, which feels way too long to be reasonable. I realize this gets into bikeshedding on what *reasonable* is, but should this be defined, or configurable? 6: "On a LAN circuit, if the router in planned restart state is the DIS at any supported level, the adjacency(ies)" -- another unexpanded acronym. |
2019-09-16
|
05 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-09-16
|
05 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2019-09-14
|
05 | Mirja Kühlewind | [Ballot comment] For the record, I only reviewed the new/changed text. |
2019-09-14
|
05 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-09-13
|
05 | Barry Leiba | [Ballot comment] Thanks for this well written document, which I’ve found easy to read and mostly clear. I have some editorial comments below, a few … [Ballot comment] Thanks for this well written document, which I’ve found easy to read and mostly clear. I have some editorial comments below, a few related to clarity. I realize that some of these apply to text that was in RFC 5306, and I ask you to please consider them, but I understand if you want to minimize changes from 5306. — Abstract — This is entirely an editorial style comment, and no response is needed; just do what you think best, and if that is to leave it as it is, then that’s fine. I find the “This document… This document additionally… This document additionally…” to be awkward, and suggest this instead: NEW This document obsoletes RFC 5306 and describes a set of mechanisms that can improve neighbor reconfiguration when a router restarts. Using these mechanisms: 1. A restarting router can signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization. 2. A router can signal its neighbors that it is preparing to initiate a restart while maintaining forwarding plane state. This allows the neighbors to maintain their adjacencies until the router has restarted, but also allows the neighbors to bring the adjacencies down in the event of other topology changes. 3. A restarting router can determine when it has achieved Link State Protocol Data Unit (LSP) database synchronization with its neighbors and can optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. END — Section 1 — This document describes a mechanism for a restarting router to signal that it is restarting to its neighbors, and allow them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization. As this is written, (1) “to its neighbors” is misplaced (it is not “restarting to its neighbors”) and (2) it sounds like the restarting router is allowing them to do the reestablishment, but it’s the signal that is. I suggest this: NEW This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting. The signal allows them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization. END — Section 3.1 — An instance of the timer T2 is maintained for each LSP database (LSPDB) present in the system, i.e., for a Level 1/2 system, there will be an instance of the timer T2 for Level 1 and an instance for Level 2. Do you really mean “i.e.” here? Is this the only possible situation, or is it an example (for which you would want “e.g.”)? I think it’s the latter, in which case I would avoid the Latin, use English, and start a new sentence: NEW An instance of the timer T2 is maintained for each LSP database (LSPDB) present in the system. For example, for a Level 1/2 system, there will be one instance of the timer T2 for Level 1 and another instance for Level 2. END This is initialized to 65535 seconds, but is set to the minimum of the remaining times of received IIHs containing a restart TLV with the Restart Acknowledgement (RA) set and an indication that the neighbor has an adjacency in the "UP" state to the restarting router. I found that quite confusing, because the long clause after “minimum of” is hard to follow (maybe it’s not an issue for readers who are versed in IS-IS). I don’t understand what it’s set to (and when it’s set to it, after the initial value of 65535), and I can’t suggest a rephrasing because I don’t understand. Can you try re-wording this (and maybe splitting it into two sentences)? — Section 3.2 — A new TLV is defined to be included in IIH PDUs. The presence of this TLV indicates that the sender supports the functionality defined in this document and it carries flags that are used to convey information during a (re)start. The antecedent of “it” isn’t formally clear from the wording. I suggest this: NEW A new TLV is defined to be included in IIH PDUs, which carries flags that are used to convey information during a (re)start. The presence of this TLV indicates that the sender supports the functionality defined in this document. END The functionality associated with each of the defined flags (as described in the following sections) is mutually exclusive with any of the other flags. Therefore, it is expected that at most one flag will be set in a TLV. Received TLVs which have multiple flags set MUST be ignored. Is there a reason not to say, “Therefore senders MUST NOT set more than one flag in a Restart TLV.”? Why aren’t we forbidding it, if the TLV will be ignored (MUST be ignored) on receipt otherwise? — Section 3.2.1 — b. immediately (i.e., without waiting for any currently running timer interval to expire, but with a small random delay of a few tens of milliseconds on LANs to avoid "storms") Then it’s not “immediately”, right? Might “promptly” be an appropriate characterization? Or is “immediately but with a small random delay” a common meaning of “immediately” in this context? (Similar comment for Section 3.2.3.) |
2019-09-13
|
05 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2019-09-09
|
05 | Amy Vezza | Placed on agenda for telechat - 2019-09-19 |
2019-09-09
|
05 | Alvaro Retana | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2019-09-09
|
05 | Alvaro Retana | Ballot has been issued |
2019-09-09
|
05 | Alvaro Retana | [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana |
2019-09-09
|
05 | Alvaro Retana | Created "Approve" ballot |
2019-09-09
|
05 | Alvaro Retana | IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup |
2019-09-09
|
05 | Alvaro Retana | Ballot writeup was changed |
2019-08-27
|
05 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-08-26
|
05 | Min Ye | Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Manav Bhatia. |
2019-08-23
|
05 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2019-08-23
|
05 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-lsr-isis-rfc5306bis-03. 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-lsr-isis-rfc5306bis-03. 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 TLV Codepoints Registry on the IS-IS TLV Codepoints registry page located at: https://www.iana.org/assignments/isis-tlv-codepoints/ the existing codepoint: Type Description ---- ------------------------------ 211 Restart TLV will have its reference changed from [RFC5306] to [ RFC-to-be ]. 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-08-16
|
05 | Les Ginsberg | New version available: draft-ietf-lsr-isis-rfc5306bis-05.txt |
2019-08-16
|
05 | (System) | New version approved |
2019-08-16
|
05 | (System) | Request for posting confirmation emailed to previous authors: Paul Wells , Les Ginsberg |
2019-08-16
|
05 | Les Ginsberg | Uploaded new revision |
2019-08-15
|
04 | Russ Housley | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Russ Housley. Sent review to list. |
2019-08-15
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Russ Housley |
2019-08-15
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Russ Housley |
2019-08-15
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Daniel Gillmor |
2019-08-15
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Daniel Gillmor |
2019-08-14
|
04 | Min Ye | Request for Last Call review by RTGDIR is assigned to Manav Bhatia |
2019-08-14
|
04 | Min Ye | Request for Last Call review by RTGDIR is assigned to Manav Bhatia |
2019-08-13
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2019-08-13
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2019-08-13
|
04 | Les Ginsberg | New version available: draft-ietf-lsr-isis-rfc5306bis-04.txt |
2019-08-13
|
04 | (System) | New version approved |
2019-08-13
|
04 | (System) | Request for posting confirmation emailed to previous authors: Paul Wells , Les Ginsberg |
2019-08-13
|
04 | Les Ginsberg | Uploaded new revision |
2019-08-13
|
03 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2019-08-13
|
03 | Cindy Morgan | The following Last Call announcement was sent out (ends 2019-08-27): From: The IESG To: IETF-Announce CC: draft-ietf-lsr-isis-rfc5306bis@ietf.org, uma.chunduri@huawei.com, aretana.ietf@gmail.com, lsr-chairs@ietf.org, Uma … The following Last Call announcement was sent out (ends 2019-08-27): From: The IESG To: IETF-Announce CC: draft-ietf-lsr-isis-rfc5306bis@ietf.org, uma.chunduri@huawei.com, aretana.ietf@gmail.com, lsr-chairs@ietf.org, Uma Chunduri , lsr@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Restart Signaling for IS-IS) to Proposed Standard The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'Restart Signaling for IS-IS' 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-08-27. 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 describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization. This document additionally describes a mechanism for a router to signal its neighbors that it is preparing to initiate a restart while maintaining forwarding plane state. This allows the neighbors to maintain their adjacencies until the router has restarted, but also allows the neighbors to bring the adjacencies down in the event of other topology changes. This document additionally describes a mechanism for a restarting router to determine when it has achieved Link State Protocol Data Unit (LSP) database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. This document obsoletes RFC 5306. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5306bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5306bis/ballot/ No IPR declarations have been submitted directly on this I-D. |
2019-08-13
|
03 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2019-08-13
|
03 | Alvaro Retana | Requested Last Call review by RTGDIR |
2019-08-13
|
03 | Alvaro Retana | Last call was requested |
2019-08-13
|
03 | Alvaro Retana | Ballot approval text was generated |
2019-08-13
|
03 | Alvaro Retana | Ballot writeup was generated |
2019-08-13
|
03 | Alvaro Retana | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2019-08-13
|
03 | Alvaro Retana | Last call announcement was generated |
2019-08-10
|
03 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-08-10
|
03 | Les Ginsberg | New version available: draft-ietf-lsr-isis-rfc5306bis-03.txt |
2019-08-10
|
03 | (System) | New version approved |
2019-08-10
|
03 | (System) | Request for posting confirmation emailed to previous authors: Paul Wells , Les Ginsberg |
2019-08-10
|
03 | Les Ginsberg | Uploaded new revision |
2019-08-02
|
02 | Alvaro Retana | === AD Review of draft-ietf-lsr-isis-rfc5306bis-02 === https://mailarchive.ietf.org/arch/msg/lsr/5SQk0bUJdlRAR8OAM6oaBdkZvyo |
2019-08-02
|
02 | Alvaro Retana | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2019-08-01
|
02 | Alvaro Retana | Notification list changed to Uma Chunduri <umac.ietf@gmail.com>, aretana.ietf@gmail.com from Uma Chunduri <umac.ietf@gmail.com> |
2019-08-01
|
02 | Alvaro Retana | IESG state changed to AD Evaluation from Publication Requested |
2019-06-05
|
02 | Amy Vezza | Changed consensus to Yes from Unknown |
2019-06-05
|
02 | Amy Vezza | Intended Status changed to Proposed Standard from None |
2019-06-04
|
02 | Acee Lindem | (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? … (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? The Intended Status is 'Proposed Standard'. This is an approprtate status as the mechanism defined in this documnet should be interoperable. The type of RFC is properly 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 an additional mechanism to IS-IS Graceful restart functionality (RFC 5306) so that planned restart by operator can happen with the support of the neighboring nodes. Working Group Summary There is no much working group discussion on the enhancement presented in the bis document. But, the draft has been presented in the LSR WG meeting(s). The draft adoption and progress has received good support from the WG. No major concerns have been raised. The draft is ready for publication Few review comments discussed in the list for this write have been fully addressed by authors. Document Quality The draft has yet to go through routing directorate review. Proposed enhancements have been proto typed/implemented by 1 vendor-os/implementation. Personnel Uma Chunduri is the Document Shepherd. Alvaro Retana is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The draft has been thoroughly reviewed by the Shepherd. Comments and review feedback has been discussed in the LSR mailing list and duly addressed. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? N/A. (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. N/A (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. N/A (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. Every author has confirmed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes. The authors have been asked (and they answered) on the WG list about IPR in the LC process. There haven't been any concerns raised on the list. (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? The draft adoption and progress had received reasonable support from the WG. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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. There are still some editorial comments that need to be addressed. From idnits: Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- Warning about ISO10859 has to be ignored (tool issue). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A For Yang updates one of the co-chair's response: "I have been working with an IS-IS developer who has worked on our native YANG models and we are considering a separate draft which augments the operational state for IS-IS adjacencies to include more information". (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 (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. This document obsoletes RFC 5306 - "Restart Signaling for IS-IS" (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). N/A (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. N/A (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 |
2019-06-04
|
02 | Acee Lindem | Responsible AD changed to Alvaro Retana |
2019-06-04
|
02 | Acee Lindem | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2019-06-04
|
02 | Acee Lindem | IESG state changed to Publication Requested from I-D Exists |
2019-06-04
|
02 | Acee Lindem | IESG process started in state Publication Requested |
2019-06-04
|
02 | Uma Chunduri | (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? … (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? The Intended Status is 'Proposed Standard'. This is an approprtate status as the mechanism defined in this documnet should be interoperable. The type of RFC is properly 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 an additional mechanism to IS-IS Graceful restart functionality (RFC 5306) so that planned restart by operator can happen with the support of the neighboring nodes. Working Group Summary There is no much working group discussion on the enhancement presented in the bis document. But, the draft has been presented in the LSR WG meeting(s). The draft adoption and progress has received good support from the WG. No major concerns have been raised. The draft is ready for publication Few review comments discussed in the list for this write have been fully addressed by authors. Document Quality The draft has yet to go through routing directorate review. Proposed enhancements have been proto typed/implemented by 1 vendor-os/implementation. Personnel Uma Chunduri is the Document Shepherd. Alvaro Retana is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The draft has been thoroughly reviewed by the Shepherd. Comments and review feedback has been discussed in the LSR mailing list and duly addressed. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? N/A. (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. N/A (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. N/A (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. Every author has confirmed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes. The authors have been asked (and they answered) on the WG list about IPR in the LC process. There haven't been any concerns raised on the list. (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? The draft adoption and progress had received reasonable support from the WG. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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. There are still some editorial comments that need to be addressed. From idnits: Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- Warning about ISO10859 has to be ignored (tool issue). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A For Yang updates one of the co-chair's response: "I have been working with an IS-IS developer who has worked on our native YANG models and we are considering a separate draft which augments the operational state for IS-IS adjacencies to include more information". (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 (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. This document obsoletes RFC 5306 - "Restart Signaling for IS-IS" (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). N/A (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. N/A (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 |
2019-06-02
|
02 | Les Ginsberg | New version available: draft-ietf-lsr-isis-rfc5306bis-02.txt |
2019-06-02
|
02 | (System) | New version approved |
2019-06-02
|
02 | (System) | Request for posting confirmation emailed to previous authors: Paul Wells , Les Ginsberg |
2019-06-02
|
02 | Les Ginsberg | Uploaded new revision |
2019-05-30
|
01 | Uma Chunduri | Notification list changed to Uma Chunduri <umac.ietf@gmail.com> from Uma Chunduri <uma.chunduri@futurewei.com> |
2019-05-30
|
01 | Uma Chunduri | (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? … (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? The Intended Status is 'Proposed Standard'. This is an approprtate status as the mechanism defined in this documnet should be interoperable. The type of RFC is properly 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 an additional mechanism to IS-IS Graceful restart functionality (RFC 5306) so that planned restart can happen with the support of the neighboring nodes. Working Group Summary There is no working group discussion on the enhancement presented in the bis document. But, the draft has been presented in the LSR WG meeting(s). The draft adoption and progress has received good support from the WG. No major concerns have been raised. The draft is ready for publication (pending agreed updates in the LSR list discussions). Few comments are sent in a separate document/email to be addressed by authors. Document Quality The draft has yet to go through routing directorate review. Proposed enhancements have been prototyped/implemented by 1 vendor-os/implementation (yet to be shipped). Personnel Uma Chunduri is the Document Shepherd. Alvaro Retana is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The draft has been thoroughly reviewed by the Shepherd. Comments and review feedback has been discussed in the LSR mailing list and waiting to see the updated (02) version. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Expecting IESG directorate reviews else the answer to this question is N/A. (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. N/A (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. N/A (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. Every author has confirmed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes. The authors have been asked (and they answered) on the WG list about IPR in the LC process. There haven't been any concerns raised on the list. (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? The draft adoption and progress had received reasonable support from the WG. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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. There are still some editorial comments that need to be addressed. From idnits: Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 13, 2018) is 166 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Some of the above would be taken care on 02 version and warning about ISO10859 has to be ignored. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A For Yang updates one of the co-chair's response: "I have been working with an IS-IS developer who has worked on our native YANG models and we are considering a separate draft which augments the operational state for IS-IS adjacencies to include more information". (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 (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. This document obsoletes RFC 5306 - "Restart Signaling for IS-IS" (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). N/A (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. N/A (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 |
2019-05-30
|
01 | Uma Chunduri | Notification list changed to Uma Chunduri <uma.chunduri@futurewei.com> from Uma Chunduri <uma.chunduri@huawei.com> |
2019-04-09
|
01 | Acee Lindem | Notification list changed to Uma Chunduri <uma.chunduri@huawei.com> |
2019-04-09
|
01 | Acee Lindem | Document shepherd changed to Uma Chunduri |
2019-04-09
|
01 | Acee Lindem | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2018-12-13
|
01 | Les Ginsberg | New version available: draft-ietf-lsr-isis-rfc5306bis-01.txt |
2018-12-13
|
01 | (System) | New version approved |
2018-12-13
|
01 | (System) | Request for posting confirmation emailed to previous authors: Paul Wells , Les Ginsberg |
2018-12-13
|
01 | Les Ginsberg | Uploaded new revision |
2018-12-08
|
00 | Min Ye | Request for Early review by RTGDIR Completed: Ready. Reviewer: Manav Bhatia. |
2018-11-25
|
00 | Min Ye | Request for Early review by RTGDIR is assigned to Manav Bhatia |
2018-11-25
|
00 | Min Ye | Request for Early review by RTGDIR is assigned to Manav Bhatia |
2018-11-14
|
00 | Min Ye | Request for Early review by RTGDIR is assigned to Loa Andersson |
2018-11-14
|
00 | Min Ye | Request for Early review by RTGDIR is assigned to Loa Andersson |
2018-11-13
|
00 | Min Ye | Request for Early review by RTGDIR is assigned to IJsbrand Wijnands |
2018-11-13
|
00 | Min Ye | Request for Early review by RTGDIR is assigned to IJsbrand Wijnands |
2018-11-13
|
00 | Acee Lindem | Requested Early review by RTGDIR |
2018-10-02
|
00 | Acee Lindem | This document now replaces draft-ginsberg-isis-rfc5306bis instead of None |
2018-10-02
|
00 | Les Ginsberg | New version available: draft-ietf-lsr-isis-rfc5306bis-00.txt |
2018-10-02
|
00 | (System) | WG -00 approved |
2018-10-01
|
00 | Les Ginsberg | Set submitter to "Les Ginsberg ", replaces to draft-ginsberg-isis-rfc5306bis and sent approval email to group chairs: lsr-chairs@ietf.org |
2018-10-01
|
00 | Les Ginsberg | Uploaded new revision |