Routing Bridges (RBridges): Appointed Forwarders
draft-ietf-trill-rbridge-af-05

Received changes through RFC Editor sync (changed abstract to 'The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called "RBridges" (Routing Bridges).

TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. Where multiple RBridges are attached to a link, native traffic to and from end stations on that link is handled by a subset of those RBridges called "Appointed Forwarders", with the intent that native traffic in each VLAN (Virtual LAN) be handled by at most one RBridge. The purpose of this document is to improve the documentation of the Appointed Forwarder mechanism; thus, it updates RFC 6325. [STANDARDS-TRACK]')

[Ballot discuss]
In Section 3:

>      It is safe to
        configure this inhibition time to the settling time of an
        attached bridged LAN. For example, if it is known that Rapid
        Spanning Tree Protocol (RSTP [802.1Q]) is running throughout
        the attached bridged LAN, it should be safe to configure this
        inhibition time to 4 seconds.

Why 4 seconds? Should not this value be 3 x Hello Timer which is 6 seconds?

[Ballot comment]
"If the appointment includes VLAN IDs 0x000 or 0xFFF, they are ignored
but any VLAN other VLAN IDs are still effective."

I think that there are one too many "VLAN"s in the sentence.

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: Appointed Forwarders) 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: Appointed Forwarders'
  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-09-13. 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


  The IETF TRILL (TRansparent Interconnection of Lots of Links)
  protocol provides least cost pair-wise data forwarding without
  configuration in multi-hop networks with arbitrary topology, safe
  forwarding even during periods of temporary loops, and support for
  multipathing of both unicast and multicast traffic. TRILL
  accomplishes this by using IS-IS (Intermediate System to Intermediate
  System) link state routing and by encapsulating traffic using a
  header that includes a hop count. Devices that implement TRILL are
  called RBridges.

  TRILL supports multi-access LAN (Local Area Network) links that can
  have multiple end stations and RBridges attached. Where multiple
  RBridges are attached to a link, native traffic to and from end
  stations on that link is handled by a subset of those RBridges called
  Appointed Forwarders, with the intent that native traffic in each
  VLAN (Virtual LAN) be handled by at most one RBridge.  The purpose of
  this document is to improve the documentation of the Appointed
  Forwarder mechanism.





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

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


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

(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 is the Document Shepherd.
I have reviewed the document and believe it is ready.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members?

I believe the review has been good. Earlier versions of the document
received good comments from both TRILL and IS-IS WG participants (we
cc'ed the last call to the IS-IS WG).

(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? Has an IPR disclosure
related to this document been filed?

No specific concerns. No IPR disclosure has been filed for this
document.

(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 consensus for the document is solid.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

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/). Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes. idnits reports 4 warnings related to the TRILL and IS-IS having
been issued as RFCs, and the ID hasn't been updated since then.

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

References are split into normative and informative. Normative
references include IEEE and ISO standards.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document?

Yes. (No IANA actions are needed.)

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

Technical Summary

TRILL supports multi-access LAN (Local Area Network) links that can
have multiple end stations and RBridges attached. Where multiple
RBridges are attached to a link, native traffic to and from end
stations on that link is handled by a subset of those RBridges called
Appointed Forwarders, with the intent that native traffic in each
VLAN (Virtual LAN) be handled by at most one RBridge. The purpose of
this document is to improve the documentation of the Appointed
Forwarder mechanism.

Working Group Summary

There was consensus in the document to advance this document after
previous versions had elicited requests for clarifications and
changes from both TRILL and IS-IS.

Document Quality

There are interoperable 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.