IS-IS Multi-Instance
draft-ietf-isis-mi-08

[Ballot discuss]
s2.3: I'm curious if authentication is used on one ITID MUST it be used on all?  I could read the last sentence as:

If authentication is used then all ITID MUST also use authentication, but different authentication methods can used on the ITIDs but it's never no authentication.
or
Different ITIDs can have different authentication mechanisms (i.e., some have none some use 5304).

[Ballot comment]
+1 to Barry's comment: Good usage of 2119. Just one comment along those lines:

2.4:

  The following sub-sections describe the additional rules
  an MI-RTR MUST follow when establishing adjacencies.

I think this might be confusing to implementers. The next subsections contain one "SHOULD NOT" and some other guidance, but it's not clear what protocol requirement (i.e., "MUST") an implementer is REQUIRED to follow. I suggest replacing the sentence with:

  The following sub-sections describe additional procedures
  to follow when an MI-RTR establishes adjacencies.

There are a few instances of your caps-lock key getting stuck. :-)

In 2.1, change "BE" to "be" in two places.
In 2.6.2, change "NOT" to "not" in two places.

[Ballot discuss]
I have no objection to the publication of this, but just a point needing response from the document shepherd.  This should be très easy to sort out.  From the shepherd writeup:

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

    A7) Unaware of any IPR disclosures or requirements for such.

The question doesn't ask what you're aware of, but what the authors have confirmed.  Did you ask the authors to confirm their conformance, and did each author confirm?

[Ballot comment]
A couple of non-blocking comments, which I'd like the authors to please consider (and chat with me about if it helps):

You have isis-genapp as a normative reference, but the only citation of it is as an example use case in the introduction.  Why is it normative?  If it is, shouldn't there be a citation when the normative bit comes up later?

-- Section 2 --

  This MAY
  also imply IID/ITID specific routing calculations and IID/ITID
  specific routing and forwarding tables.  However, this aspect is
  outside the scope of this specification.

I think this is not a 2119 "MAY" (one huge clue is the second sentence).  I suggest changing it to "might".  Kudos on what seems to be very crisp use of 2119 language in the rest of the document.

-----
And, finally a totally trivial point: the last paragraph of the introduction says this:

  The above are examples of how MI-IS-IS might be used.  The
  specification of uses of MI-IS-IS is outside the scope of this
  document.

That seems self-contradictory.  How about "Full specification of uses..."?

IANA has reviewed draft-ietf-isis-mi-06 and has the following comments:

IANA has questions about this document.

IANA understands that there is a single IANA action that is required to be
completed upon approval of this document.

In the TLV Codepoints Registry contained in the IS-IS TLV Codepoints registry
located at:

http://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xml

a new TLV Codepoint is to be registered as follows:

Type Description IIH LSP SNP Purge Reference
---- --------------------- --- --- --- ----- ----------------
7 Instance Identifier y y y y [ RFC-to-be ]

Currently the IS-IS TLV Codepoint registry is maintained through expert review
as defined in RFC 5226.

IANA Question -> has the document been reviewed by the IS-IS TLV Codepoint
registry expert?

Also, IANA notes that in Section 2.6.1 on Interoperability Issues on Broadcast
Circuits, the following text appears: "An MI-RTR will use the AllL1IS and
AllL2IS ISIS MAC layer addresses (as defined in [IS-IS]) when sending ISIS PDUs
for the standard instance (IID #0). An MI-RTR will use two new (TBD) dedicated
layer 2 multicast addresses (one for each level) when sending IS-IS PDUs for
any non-zero IID."

IANA Question --> is there an IANA registration requirement for the two
dedicated layer 2 multicast addresses that are currently marked "(TBD)?"

IANA understands that the TLV Codepoint action, above, is the only explicit
IANA action required 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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (IS-IS Multi-Instance) 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 Multi-Instance'
  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 2012-09-04. 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 draft describes a mechanism that allows a single router to share
  one or more circuits among multiple Intermediate System To
  Intermediate System (IS-IS) routing protocol instances.

  Multiple instances allow the isolation of resources associated with
  each instance.  Routers will form instance specific adjacencies.
  Each instance can support multiple topologies.  Each topology has a
  unique Link State Database (LSDB).  Each Protocol Data Unit (PDU)
  will contain a new Type Length Value (TLV) identifying the instance
  and the topology(ies) to which the PDU belongs.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-isis-mi/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-isis-mi/ballot/


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

PROTO Questionnaire and Write-up for: draft-ietf-isis-mi-06.txt

Shepherding WG-Chair: Chris Hopps (chopps@rawdofmt.org)

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

A1) Proposed Standard. The document describes protocol changes that are
being normatively referenced.

    (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 specification provides for a method for a single router to share one or
more circuits among multiple IS-IS routing protocol instances. This allows for
the isolation of resources into distinct instances.

Working Group Summary:

The consensus was strong for this specification. While there was healthy
discussion and development over multiple revisions of the draft, no strong
objections were present during the development process.

Document Quality:

There are no known current implementations of the draft; however, there has been
a large interest expressed in the WG by both vendors and operators for this
specification to be completed.

Who is the Document Shepherd? Chris Hopps (chopps@rawdofmt.org)

Who is the Responsible Area Director? XXX

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

A3) A full review of the document has been performed by the shepherd.

    (4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

A4) No. The document has been in development for quite a while and has
been very well reviewed by the WG.

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

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

A6) No concerns.

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

A7) Unaware of any IPR disclosures or requirements for such.

    (8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.

A8) Unaware of any IPR disclosures being filed.

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

A9) Strong concensus of active members of 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.)

A10) No threats of appeal or extreme discontent.

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

A11) No ID nits.

    (12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type reviews.

A12) Unaware of any required extra formal review.

    (13) Have all references within this document been identified as either
    normative or informative?

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

A14) There is one normative reference to a draft-ietf-isis-genapp-04.txt.
    This genapp draft is being held in the RFC-ED queue on MISREF
    awaiting this (the MI) draft. So publication of this draft will
    clear both missed references.

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

A15) No downward normative references.

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

A16) Does not modify the status of any existing RFCs.

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

A17) A single code-point is being reserved in an existing IANA
    registry in the document. It is clearly identified.

    Additionally though there is a requirement for the allocation of 2
    new multicast 48-bit MAC addresses. In the document these are
    currently indicated as TBD. I believe the authors were unaware of
    the IANA registry that has these values available. So moving
    forward we need to make a slight edit to the document to add the 2
    value allocation to the IANA section.

    The registry is "IANA MAC ADDRESS BLOCK"
    The sub-registry is: "IANA Multicast 48-bit MAC Addresses"
    As per RFC5342 we would allocate a 2**1 allocation from this block.

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

A18) No new registries are being created.

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

A19) No additional checks or reviews were required.