Skip to main content

IS-IS Minimum Remaining Lifetime
RFC 7987

Revision differences

Document history

Date Rev. By Action
2016-10-19
04 (System)
Received changes through RFC Editor sync (created alias RFC 7987, changed abstract to 'Corruption of the Remaining Lifetime field in a Link State Protocol …
Received changes through RFC Editor sync (created alias RFC 7987, changed abstract to 'Corruption of the Remaining Lifetime field in a Link State Protocol Data Unit (LSP) can go undetected.  In certain scenarios, this may cause or exacerbate flooding storms.  It is also a possible denial-of-service attack vector.  This document defines a backwards-compatible solution to this problem.', changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2016-10-19, changed IESG state to RFC Published)
2016-10-19
04 (System) RFC published
2016-10-18
04 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7987">AUTH48-DONE</a> from AUTH48
2016-09-28
04 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7987">AUTH48</a> from RFC-EDITOR
2016-08-30
04 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2016-08-22
04 (System) RFC Editor state changed to EDIT
2016-08-22
04 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2016-08-22
04 (System) Announcement was received by RFC Editor
2016-08-22
04 (System) IANA Action state changed to No IC from In Progress
2016-08-22
04 (System) IANA Action state changed to In Progress
2016-08-22
04 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2016-08-22
04 Cindy Morgan IESG has approved the document
2016-08-22
04 Cindy Morgan Closed "Approve" ballot
2016-08-22
04 Cindy Morgan Ballot approval text was generated
2016-08-19
04 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Rich Salz.
2016-08-18
04 Cindy Morgan IESG state changed to Approved-announcement to be sent from IESG Evaluation
2016-08-17
04 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2016-08-17
04 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2016-08-17
04 Les Ginsberg IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2016-08-17
04 Les Ginsberg New version available: draft-ietf-isis-remaining-lifetime-04.txt
2016-08-17
03 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2016-08-17
03 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2016-08-16
03 Alvaro Retana
[Ballot comment]
I have some comments related to the normative language in the document (and some other minor points later) — they don't raise to …
[Ballot comment]
I have some comments related to the normative language in the document (and some other minor points later) — they don't raise to the level of a DISCUSS, but I would like to see them addressed before publication.

1. There are several parts of the text where statements of fact, or normative requirements from other documents are reflected using rfc2119 language.  I think that use of rfc2119 is inappropriate and (in the case of references to ISO10589) inaccurate [*].  Please find a way to reflect the requirements without using rfc2119 language.  These are the pieces of text I'm referring to:

a. Section 1. (Problem Statement):  "…as the checksum field MUST NOT be altered…"
b. Section 2. (Solution): "[ISO10589] specifies that maximumLSPGenerationInterval MUST be…"
c. Section 2. (Solution):  "The pseudo-node LSPs generated by the previous DIS are no longer required and MAY be purged by the new DIS."  d. Section 3.3. (Impact of Delayed LSP Purging): "LSPs from a node which is unreachable (failure of the two-way-connectivity check) MUST NOT be used."


2. In Section 3.1. (Inconsistent Values for MaxAge): "Implementors of this extension MAY wish.."  Note that the "MAY" is modifying "wish", which is meaningless when talking about normative language.  Suggestion:  simply s/MAY/may  The "MUST" in the following sentence is enough.

3. In Section 3.2. (Reporting Corrupted Lifetime): "…an implementation MAY wish to retain the value of RemainingLifetime received…"  Similar to the previous comment; in this case the "MAY" is not even necessary because the behavior (to retain) is not needed for interoperability.  If you want to keep it, s/MAY wish to retain/MAY retain

4. There are several instances of "RemainingLifetime" -- that is fine, but you seem to be inconsistent with "Remaining Lifetime".  And there's even one "Lifetime" by itself…

5. s/w/with (Section 2).


[*] I haven't read ISO10598 in a while, but I'm pretty sure it doesn't use rfc2119 language…
2016-08-16
03 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2016-08-16
03 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2016-08-16
03 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2016-08-16
03 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2016-08-16
03 Ben Campbell
[Ballot comment]
I have just a few minor comments:

- 1, 2nd paragraph: "... the checksum
  field MUST NOT be altered..."

That sounds more …
[Ballot comment]
I have just a few minor comments:

- 1, 2nd paragraph: "... the checksum
  field MUST NOT be altered..."

That sounds more like a statement of fact than a normative requirement.

-1, paragraph 4:

I’m no expert here, but are where the originator might want to let the LSP expire before it becomes unreachable? (e.g. during a graceful shutdown?)

-2, 4th paragraph from end: "An additional
  action is added:
"
This document adds the additional action, or ISO10589 adds it?
2016-08-16
03 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2016-08-16
03 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Tim Wicinski.
2016-08-16
03 Joel Jaeggli
[Ballot comment]
Tim Wicinski, tjw.ietf@gmail.com performed the opsdir review, some nits that I haven't seen comment on yet.


Hi

I have reviewed this document as …
[Ballot comment]
Tim Wicinski, tjw.ietf@gmail.com performed the opsdir review, some nits that I haven't seen comment on yet.


Hi

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments
just like any other last call comments.

Document Reviewed:  draft-ietf-isis-remaining-lifetime-02

Status: Ready with nits

Spelling Nits:

Abstract:
  "Corruption of the Remainining Lifetime Field"

*Remaining*

2 (vi):

  not result in LSPDB inconsistency among routers in the newtork.

*network*

(vi):
  vi.  If the RemainingLifetime of the new LSP is less than MaxAge it
  is set to MaxAge

Period at end of sentence

It appears that you interchange 'Remaining Lifetime' and 'RemainingLifetime' (14 for the former, 19 for the latter).
I could not understand the pattern.  Was this intentional?

tim

_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir
2016-08-16
03 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2016-08-16
03 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2016-08-15
03 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2016-08-15
03 Mirja Kühlewind
[Ballot comment]
Two small comments:
1) Maybe explain briefly also in this doc what ZeroAgeLifetime is; that would be helpful!
2) You write:
„Retention of …
[Ballot comment]
Two small comments:
1) Maybe explain briefly also in this doc what ZeroAgeLifetime is; that would be helpful!
2) You write:
„Retention of stale LSPs therefore has no negative side effects other than requiring additional memory for the LSPDB.“
-> Can this lead to a memory exhaustion attack instead? Should this be discussed in the security section?
2016-08-15
03 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2016-08-15
03 Alia Atlas IESG state changed to IESG Evaluation from Waiting for Writeup
2016-08-15
03 Alia Atlas Ballot has been issued
2016-08-15
03 Alia Atlas [Ballot Position Update] New position, Yes, has been recorded for Alia Atlas
2016-08-15
03 Alia Atlas Created "Approve" ballot
2016-08-15
03 Alia Atlas Ballot writeup was changed
2016-08-15
03 (System) IESG state changed to Waiting for Writeup from In Last Call
2016-08-12
03 Alia Atlas Placed on agenda for telechat - 2016-08-18
2016-08-12
03 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2016-08-12
03 Sabrina Tanamal
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-isis-remaining-lifetime-01.txt, which is currently in Last Call, and has the following comments:

We understand that this …
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-isis-remaining-lifetime-01.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN
2016-08-08
03 Les Ginsberg New version available: draft-ietf-isis-remaining-lifetime-03.txt
2016-08-08
02 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Wicinski
2016-08-08
02 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Wicinski
2016-08-06
02 Christer Holmberg Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Christer Holmberg.
2016-08-04
02 Tero Kivinen Request for Last Call review by SECDIR is assigned to Rich Salz
2016-08-04
02 Tero Kivinen Request for Last Call review by SECDIR is assigned to Rich Salz
2016-08-03
02 Les Ginsberg New version available: draft-ietf-isis-remaining-lifetime-02.txt
2016-08-01
01 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2016-08-01
01 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2016-08-01
01 Amy Vezza IANA Review state changed to IANA - Review Needed
2016-08-01
01 Amy Vezza
The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
CC: isis-wg@ietf.org, chopps@chopps.org, akatlas@gmail.com, …
The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
CC: isis-wg@ietf.org, chopps@chopps.org, akatlas@gmail.com, "Christian Hopps" <chopps@chopps.org>, draft-ietf-isis-remaining-lifetime@ietf.org, isis-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-isis-remaining-lifetime-01.txt> (IS-IS Minimum Remaining Lifetime) to Proposed Standard


The IESG has received a request from the IS-IS for IP Internets WG (isis)
to consider the following document:
- 'IS-IS Minimum Remaining Lifetime'
  <draft-ietf-isis-remaining-lifetime-01.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 2016-08-15. 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


  Corruption of the Remainining Lifetime Field in a Link State PDU can
  go undetected.  In certain scenarios this may cause or exacerbate
  flooding storms.  It is also a possible denial of service attack
  vector.  This document defines a backwards compatible solution to
  this problem.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-isis-remaining-lifetime/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-isis-remaining-lifetime/ballot/


No IPR declarations have been submitted directly on this I-D.




2016-08-01
01 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2016-08-01
01 Amy Vezza Last call announcement was changed
2016-07-29
01 Alia Atlas Last call was requested
2016-07-29
01 Alia Atlas Last call announcement was generated
2016-07-29
01 Alia Atlas Ballot approval text was generated
2016-07-29
01 Alia Atlas Ballot writeup was generated
2016-07-29
01 Alia Atlas IESG state changed to Last Call Requested from Publication Requested
2016-05-25
01 Christian Hopps
PROTO Questionaire and Write-up for: draft-ietf-isis-remaining-life-01

    (1) What type of RFC is being requested (BCP, Proposed Standard, Internet
        Standard, …
PROTO Questionaire and Write-up for: draft-ietf-isis-remaining-life-01

    (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?

Proposed Standard

    (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:

    Relevant content can frequently be found in the abstract and/or introduction
    of the document. If not, this may be an indication that there are
    deficiencies in the abstract or introduction.

Corruption of the Remainining Lifetime Field in a Link State PDU can
go undetected.  In certain scenarios this may cause or exacerbate
flooding storms.  It is also a possible denial of service attack
vector.  This document defines a backwards compatible solution to
this problem.

    Working Group Summary:

    Was there anything in WG process that is worth noting? For example, was
    there controversy about particular points or were there decisions where the
    consensus was particularly rough?

Work progressed smoothly.

    Document Quality:

    Are there existing implementations of the protocol? Have a significant
    number of vendors indicated their plan to implement the specification? Are
    there any reviewers that merit special mention as having done a thorough
    review, e.g., one that resulted in important changes or a conclusion that
    the document had no substantive issues? If there was a MIB Doctor, Media
    Type or other expert review, what was its course (briefly)? In the case of a
    Media Type review, on what date was the request posted?

There is at least one implementation with others planned.

    Personnel:

    Who is the Document Shepherd? Who is the Responsible Area Director?

Shepherd: Christian Hopps
AD: Alia Atlas

    (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.

This document has been reviewed by the Shepherd.

    (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.

No.

    (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.

No.

    (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 in the WG.

    (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 found.

    (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).

No IANA considerations.

    (18) List any new IANA registries that require Expert Review for future
        allocations. Provide any public guidance that the IESG would find
        useful in selecting the IANA Experts for these new registries.

None.

    (19) Describe reviews and automated checks performed by the Document
        Shepherd to validate sections of the document written in a formal
        language, such as XML code, BNF rules, MIB definitions, etc.

None.
2016-05-25
01 Christian Hopps Responsible AD changed to Alia Atlas
2016-05-25
01 Christian Hopps IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2016-05-25
01 Christian Hopps IESG state changed to Publication Requested
2016-05-25
01 Christian Hopps IESG process started in state Publication Requested
2016-05-25
01 Christian Hopps Changed document writeup
2016-04-30
01 Les Ginsberg New version available: draft-ietf-isis-remaining-lifetime-01.txt
2016-04-30
00 Christian Hopps IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2016-03-19
00 Christian Hopps IETF WG state changed to In WG Last Call from WG Document
2016-03-01
00 Christian Hopps Notification list changed to "Christian Hopps" <chopps@chopps.org>
2016-03-01
00 Christian Hopps Document shepherd changed to Christian Hopps
2016-03-01
00 Christian Hopps This document now replaces draft-ginsberg-isis-remaining-lifetime instead of None
2016-03-01
00 Christian Hopps Changed consensus to Yes from Unknown
2016-03-01
00 Christian Hopps Intended Status changed to Proposed Standard from None
2016-01-26
00 Les Ginsberg New version available: draft-ietf-isis-remaining-lifetime-00.txt