Routing Bridges (RBridges): Adjacency
draft-ietf-trill-adj-07

[Ballot comment]
1) expand acronyms on first use
2) multiple sections 1.2
3) why does acknowledgements precede the table of contents? normally this is in the main body of the document.
4) in 2.2, terms that have specific meanings are being redefined in a way that I think could be confusing. "ingressing" and "egressing" are used to describe adding/removing TRILL-headers. It would seem more appropriate to use terms like "Trilling" and de-TRILLing" to describe this functionality.
5) in section 2.2, "tamed" is highlighted by quotes because it is taking an existing word and reusing in a trill-specific manner. Should this be included in terminology.

[Ballot discuss]
DISCUSS:
1) "In case of conflict between this document and [RFCtrill], this document prevails. " implies this updates RFCTrill. The header, abstract, and Introduction should explicitly state that this updates the other document.
2) I have a real concern that this document updates a Proposed Standard that hasn't even cleared the RFC Editor's queue yet. Why not simply modify the original? Why is this done as a separate document? It appears there are a number of documents in cluster 74 that are interdependent: rbridge-protocol depends on isis-trill, which depends on trill-adj, which UPDATES rbridge-protocol.
In other words, it appears to me that rbridge-adj is version 2 of trill-protocol; isis-trill normatively depends on version 2, and protocol version 1 depends on isis-trill; ergo version 1 normatively depends on version 2.  It is unclear to me how one could possibly develop a compliant interoperable implementation to rbridge-protocol (version 1) under these conditions.
I think the changes proposed in -adj- should be rolled into the rbridges-protocol document to resolve the dependency issues of the cluster.

[Ballot comment]
The state machines are given as (event,state) => (new state) tuples. I'm kind of missing the action part, presumably there are events that cause an action to be taken. Why is not the (event,state) => (action, new state) model not used here?

[Ballot discuss]
I must be missing something obvious, but I thought that the following statement in the draft was odd:

  Layer 3 packets are already "tamed" when they are originated by an
  end station: they include a hop count and layer 3 source and
  destination addresses. Furthermore, there is no requirement to
  preserve their outer layer 2 addressing and, at least for unicast
  packets, they are addressed to their first hop router.

First of all, not all IP packets have a real layer 3 source address. The unspecified address may be used in, say, ND packets. Secondly, preserving layer 2 addresses does seem to be important, at least if we expect ND and SLLA options to work. Can you clarify what you really meant with the above?

[Ballot comment]
I went and looked at what's holding up publishing RFCtrill and it's this document.  If -adj is updating RFCtrill wouldn't it be better to roll this on in to the base as opposed to having RFC XXXX be updated by RFC XXXX+2?  I know it happens, but I'm just saying...

If two do get published, is there a plan to  later combine the two?

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (RBridges: Adjacency) to Proposed Standard


The IESG has received a request from the Transparent Interconnection of
Lots of Links WG (trill) to consider the following document:
- 'RBridges: Adjacency'
  as a 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 2011-04-28. 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.

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

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-trill-adj/

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Erik Nordmark
I've read the most recent document, and it is ready for review.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

The document has had careful review by a number of TRILL and IS-IS WG
participants resulting in a number of editorial changes since January.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues 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. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

The existance of the document is a result of an IESG compromise, hence I
can't argue that it shouldn't be needed. The document contains details covering
the four areas that the IESG asked for.

  (1.e) 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 WG consensus is very strong. A number of editorial fixes have been made as
result of WG last call comments.

Everybody is fine with the document except one individual, who
has stated two remaining issues with the document:
1. That it should clarify the appointed forwarder mechanism, even though
this is outside of the 4 items the IESG asked us to clarify in this document.
2. He would like a different mechanism for announcing appointed
forwarders in draft-ietf-trill-rbridge-protocol, since he says the existing
mechanism is imperfect.

For #1, the WG has just accepted a separate document, which should be ready
for WG last call in a few weeks.

#2 is out of scope for this document. In any case,
asking for perfection in the TRILL protocol mechnism might have been appropriate
when draft-ietf-trill-protocol was last called 2 years ago, but changing the
protocol more than a year after the IESG approved it would only make sense
if the protocol was actually broken. In this case it is merely a case
of making it fit one persons desired way to evolve IS-IS, and he had plenty of
opportunity to raise those issues in 2009 (two TRILL WG last calls cc'ed to
the IS-IS WG, one extra WG last call in the IS-IS WG, an IETF last call, etc).
What is in draft-ietf-trill-rbridge-protocol works, even if this individual
would have designed it differently to fit his taste.

Thus I think we have far better than rough consensus for this document.


  (1.f) 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
        entered into the ID Tracker.)

No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

Yes.

  (1.h) Has the document split its references into normative and
        informative? 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
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

Yes, the references are split with no downward normative references.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

There is a section, but the document has no IANA actions. It is just clarifying
RFCtrill, adding state machines and the like.


  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

N/A

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

  TRILL supports multi-access LAN links that can have multiple end
  stations and RBridges attached. This document describes four aspects
  of the TRILL LAN Hello protocol used on such links, particularly
  adjacency, designated RBridge selection, and MTU and pseudonode
  procedures, with state machines. There is no change for IS-IS point-
  to-point Hellos used on links configured as point-to-point in TRILL.

    Working Group Summary

  This document was developed in the TRILL working group with significant
  review from participants in the IS-IS WG. The scope of the document
  is based on a list of four items where that the IESG wanted to see
  clarified for the TRILL LAN Hello protocol.

    Document Quality

    There are implementations of TRILL that were developed without the
    benefits of this additional document. The assumptions is that future
    implementors will benefit from the additional level of detail in
    this document.

----