Simplified Extension of Link State PDU (LSP) Space for IS-IS
draft-ietf-isis-wg-extlsp-05

[Ballot comment]
I'd suggest adding "For general security considerations for IS-IS see
[RFC5304]" to the Security Considerations text (as was done in
e.g. RFC 5302).

IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignments in the "TLV Codepoints Registry" at
http://www.iana.org/assignments/isis-tlv-codepoints

Name Value IIH LSP SNP Status/Reference
----------------------------------- ----- ---- --- ---- --------
IS Neighbor Attribute 23 n y n
[RFC-isis-wg-extlsp-03]
IS Alias ID 24 n y n
[RFC-isis-wg-extlsp-03]
MT IS Neighbor Attribute 223 n y n
[RFC-isis-wg-extlsp-03]

We understand the above to be the only IANA Action for this
document.

PROTO writeup by Chris Hopps:

PROTO Questionnaire and Write-up for: draft-ietf-isis-wg-extlsp-03.txt
Shepherding WG-Chair: Chris Hopps (chopps@rawdofmt.org)

Questionnaire

    Q1) Have the chairs personally reviewed this version of the
    Internet Draft (ID), and in particular, do they believe
    this ID is ready to forward to the IESG for publication?

A1) Yes.

    Q2) Has the document had adequate review from both key WG
    members and key non-WG members? Do you have any concerns
    about the depth or breadth of the reviews that have been
    performed?

A2) Adequately reviewed.

    Q3) Do you have concerns that the document needs more review
    from a particular (broader) perspective (e.g., security,
    operational complexity, someone familiar with AAA, etc.)?

A3) No concerns.

    Q4) Do you have any specific concerns/issues with this
    document that you believe the ADs and/or IESG should be
    aware of? For example, perhaps you are uncomfortable with
    certain parts of the document, or have concerns whether
    there really is a need for it. In any event, if your issues
    have been discussed in the WG and the WG has indicated it
    that it still wishes to advance the document, detail those
    concerns in the write-up.

A4) No concerns.

    5) 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?

A5) Strong Consensus.

    6) Has anyone threatened an appeal or otherwise indicated
    extreme discontent? If so, please summarise the areas of
    conflict in separate email to the Responsible Area Director.

A6) No.

    7) Have the chairs verified that the document adheres to
    all of the ID Checklist items ?

A7) Yes.

    8) Is the document split into normative and informative
    references?  Are there normative references to IDs, where
    the IDs are not also ready for advancement or are otherwise
    in an unclear state? (note here that the RFC editor will
    not publish an RFC with normative references to IDs, it
    will delay publication until all such IDs are also ready
    for publication as RFCs.)

A8) The reference to draft-ietf-isis-wg-multi-topology should be changed
    to RFC5120. Otherwise all OK.  (note, I have added an RFC editor's
    note to the tracker -- Ross)

    9) What is the intended status of the document? (e.g.,
    Proposed Standard, Informational?)

A9) Proposed Standard.

*** Write-up

** Technical Summary

IS-IS has limitations on the amount of state that one router may
advertise into a routing domain. The limit of concern here is that only
256 fragments may be advertised by any one router. These fragments
generally must be less than or equal to 1492 bytes.

As more and more information (e.g., traffic engineering information)
is added to the state advertised by a router a mechanism is required
to extend this limit. This specification does just this by greatly
increasing the number of LSP fragments a router may advertise.

** Working Group Summary

There consensus was strong for this specification. The specification
replaces an earlier specification that was deemed overly complex
by the working group, and this was accepted as a replacement with
no controversy.

** Protocol Quality

There are currently no implementations of this specification.  As
this document will replace another conflicting specification it is
important to have it published prior to most vendors implementing the
specification that it replaces. Currently the functionality this
(and the being replaced) specification describe is not yet required
by operators; however, it is anticipated that it soon will be required
and so a solution needs to be in place for vendors to implement.