Routing Bridges (RBridges): Base Protocol Specification
draft-ietf-trill-rbridge-protocol-16

[Ballot discuss]
I think this is important and good work. I would also like to thank the authors for completing the last call in the IS-IS working group and adding a normative reference to draft-ietf-isis-layer2.

Regarding two interoperable implementations: I have cleared based on the IESG discussion.

[Ballot comment]
Please close on the minor comments and nits raised in Acee Lindem's
Routing Area Directorate review.

Please fix Radia's coordinates as her email currently bounces.

[Ballot discuss]
Discuss updated after telechat.

This is a mammoth piece of work with a lot of carefully checked detail. Thanks for taking the time to check back with the IS-IS working group.

I have three (now only two) issues for Discussion. The first is
targetted only at the Int ADs.

---

This point is withdrawn after discussion with the IESG

> 1. Implementation
>
> If this work was in the Routing Area I would consider it sufficiently
> large to require two independent implementations and would hope for
> evidence of interoperability. However, it is not, so this Discuss point
> is to ask the Int ADs to consider whether this work should really go
> onto the Standards Track with (according to the proto-writeup) no
> implementations of the current revision. Implementation is not just a
> proof of the correctness of the specification, but is a good indicator
> of whether there is actually a desire for the work.

---

2. Scope

I think that, not withstanding the reference to RFC 5556 at the very end
of Section 1, I would like to see a clear statement that this document
anticipates that the protocol deployment is limited to LANs, and that
wider deployment is for further study.

---

3. Usage of confidence levels

Per the Routing Area Directorate review by Acee Lindem, one major issue
seems to be still open.

>  The document should explain the philosophy and usage of confidence
>  level with respect to the {port, VLAN, MAC address} tuples. This
>  discussion should also tie in the confidence configuration in
>  section 5.1.

Donald Eastlake suggested...

Well, how about something like the following new text:

  The confidence level mechanism allows an RBridge campus manager to
  cause certain address learning sources to prevail over others. In a
  default configuration, without the optional ESADI protocol,
  addresses are only learned from observing local native frames and
  the decapsulation of received TRILL data frames. Both of these
  sources default to confidence level 0x20 so, since learning at an
  equal or high confidence overrides previous learning, the learning
  in such a default case mimics default 802.1 bridge learning.

  While RBridge campus management policies are beyond the scope of
  this document, here are some example types of policies that can be
  implemented with the confidence mechanism and the rational for
  each:

  o  Locally received native frames might be considered more reliable
      than decapsulated frames received from remote parts of the
      campus. To stop MAC addresses learned from such local frames
      from being usurped by remotely received forged frames, the
      confidence in locally learned addresses could be increased or
      that in addresses learned from remotely sourced decapsulated
      frames decreased.

  o  MAC address information learned through a cryptographically
      authenticated Layer 2 registration protocol, such as 802.1X with
      a cryptographically based EAP method, might be considered more
      reliable than information learned through the mere observation
      of data frames. When such authenticated learned address
      information is transmitted via the ESADI protocol, the use of
      authentication in the TRILL EASDI LSP frames could make
      tampering with it in transit very difficult. As a result, it
      might be reasonable to announce such authenticated information
      via the ESADI protocol with a high confidence, so it would
      override any alternative learning from data observation.

  Manually configured address information is generally considered
  static and so defaults to a confidence of 0xFF while no other
  source of such information can be configured to a confidence any
  higher than 0xFE. However, for other cases, such as where the
  manual configuration is just a starting point which the Rbridge
  campus manager wishes to be dynamically overrideable, the
  confidence of such manually configured information may be
  configured to a lower value.

[Ballot comment]
Please close on the minor comments and nits raised in Acee Lindem's
Routing Area Directorate review.

Please fix Radia's coordinates as her email currently bounces.

[Ballot discuss]
This is a mammoth piece of work with a lot of carefully checked detail. Thanks for taking the time to check back with the IS-IS working group.

I have three issues for Discussion. The first is targetted only at the Int ADs.

---

1. Implementation

If this work was in the Routing Area I would consider it sufficiently
large to require two independent implementations and would hope for
evidence of interoperability. However, it is not, so this Discuss point
is to ask the Int ADs to consider whether this work should really go
onto the Standards Track with (according to the proto-writeup) no
implementations of the current revision. Implementation is not just a proof of the correctness of the specification, but is a good indicator of whether there is actually a desire for the work.

---

2. Scope

I think that, not withstanding the reference to RFC 5556 at the very end
of Section 1, I would like to see a clear statement that this document
anticipates that the protocol deployment is limited to LANs, and that
wider deployment is for further study.

---

3. Usage of confidence levels

Per the Routing Area Directorate review by Acee Lindem, one major issue
seems to be still open.

>  The document should explain the philosophy and usage of confidence
>  level with respect to the {port, VLAN, MAC address} tuples. This
>  discussion should also tie in the confidence configuration in
>  section 5.1.

Donald Eastlake suggested...

Well, how about something like the following new text:

  The confidence level mechanism allows an RBridge campus manager to
  cause certain address learning sources to prevail over others. In a
  default configuration, without the optional ESADI protocol,
  addresses are only learned from observing local native frames and
  the decapsulation of received TRILL data frames. Both of these
  sources default to confidence level 0x20 so, since learning at an
  equal or high confidence overrides previous learning, the learning
  in such a default case mimics default 802.1 bridge learning.

  While RBridge campus management policies are beyond the scope of
  this document, here are some example types of policies that can be
  implemented with the confidence mechanism and the rational for
  each:

  o  Locally received native frames might be considered more reliable
      than decapsulated frames received from remote parts of the
      campus. To stop MAC addresses learned from such local frames
      from being usurped by remotely received forged frames, the
      confidence in locally learned addresses could be increased or
      that in addresses learned from remotely sourced decapsulated
      frames decreased.

  o  MAC address information learned through a cryptographically
      authenticated Layer 2 registration protocol, such as 802.1X with
      a cryptographically based EAP method, might be considered more
      reliable than information learned through the mere observation
      of data frames. When such authenticated learned address
      information is transmitted via the ESADI protocol, the use of
      authentication in the TRILL EASDI LSP frames could make
      tampering with it in transit very difficult. As a result, it
      might be reasonable to announce such authenticated information
      via the ESADI protocol with a high confidence, so it would
      override any alternative learning from data observation.

  Manually configured address information is generally considered
  static and so defaults to a confidence of 0xFF while no other
  source of such information can be configured to a confidence any
  higher than 0xFE. However, for other cases, such as where the
  manual configuration is just a starting point which the Rbridge
  campus manager wishes to be dynamically overrideable, the
  confidence of such manually configured information may be
  configured to a lower value.

[Ballot discuss]
I think this is important and good work. I would also like to thank the authors for completing the last call in the IS-IS working group and adding a normative reference to draft-ietf-isis-layer2.

I would like to discuss during the telechat whether or not we should require two interoperable implementations prior to proposed standard status on a protocol that is this complex. I would be fine with experimental status, or with waiting for two implementations before publishing as proposed standard.

[Ballot discuss]
This is a mammoth piece of work with a lot of carefully checked detail. Thanks for taking the time to check back with the IS-IS working group.

I have three issues for Discussion. The first is targetted only at the Int ADs.

---

1. Implementation

If this work was in the Routing Area I would consider it sufficiently
large to require two independent implementations and would hope for
evidence of interoperability. However, it is not, so this Discuss point
is to ask the Int ADs to consider whether this work should really go
onto the Standards Track with (according to the proto-writeup) no
implementations of the current revision. Implementation is not just a proof of the correctness of the specification, but is a good indicator of whether there is actually a desire for the work.

---

2. Scope

I think that, not withstanding the reference to RFC 5556 at the very end
of Section 1, I would like to see a clear statement that this document
anticipates that the protocol deployment is limited to LANs, and that
wider deployment is for further study.

---

3. Usage of confidence levels

Per the Routing Area Directorate review by Acee Lindem, one major issue
seems to be still open.

>  The document should explain the philosophy and usage of confidence
>  level with respect to the {port, VLAN, MAC address} tuples. This
>  discussion should also tie in the confidence configuration in
>  section 5.1.

Donald Eastlake suggested...

Well, how about something like the following new text:

  The confidence level mechanism allows an RBridge campus manager to
  cause certain address learning sources to prevail over others. In a
  default configuration, without the optional ESADI protocol,
  addresses are only learned from observing local native frames and
  the decapsulation of received TRILL data frames. Both of these
  sources default to confidence level 0x20 so, since learning at an
  equal or high confidence overrides previous learning, the learning
  in such a default case mimics default 802.1 bridge learning.

  While RBridge campus management policies are beyond the scope of
  this document, here are some example types of policies that can be
  implemented with the confidence mechanism and the rational for
  each:

  o  Locally received native frames might be considered more reliable
      than decapsulated frames received from remote parts of the
      campus. To stop MAC addresses learned from such local frames
      from being usurped by remotely received forged frames, the
      confidence in locally learned addresses could be increased or
      that in addresses learned from remotely sourced decapsulated
      frames decreased.

  o  MAC address information learned through a cryptographically
      authenticated Layer 2 registration protocol, such as 802.1X with
      a cryptographically based EAP method, might be considered more
      reliable than information learned through the mere observation
      of data frames. When such authenticated learned address
      information is transmitted via the ESADI protocol, the use of
      authentication in the TRILL EASDI LSP frames could make
      tampering with it in transit very difficult. As a result, it
      might be reasonable to announce such authenticated information
      via the ESADI protocol with a high confidence, so it would
      override any alternative learning from data observation.

  Manually configured address information is generally considered
  static and so defaults to a confidence of 0xFF while no other
  source of such information can be configured to a confidence any
  higher than 0xFE. However, for other cases, such as where the
  manual configuration is just a starting point which the Rbridge
  campus manager wishes to be dynamically overrideable, the
  confidence of such manually configured information may be
  configured to a lower value.

[Ballot comment]
Stylistic quibbles with section 3:
(1) IMHO, the TRILL header figure should include the header Options field.
(2) Section 3.5 should be renamed "Op-length" and should focus on Op-length
(3) The bulk of the current 3.5 should be moved to a new section 3.8 "TRILL Header Options"
These changes would ensure that the figure 3.1 and subsequent list are parallel with
the remainder of section 3.

Non-stylistic quiblle with section 3: When the data link layer is IEEE [802.3], are there any
constraints on Op-length to ensure that the 64 alignment is maintained?
(Found the answer in section 4, but wonder if it should be mentioned earlier!)

Section 3.7.3, fourth bullet, first sentence:

Sorry to nitpick, but should we explicitly state that when the most significant bit is set to 1,
this indicates the nickname value was configured?

Section 4.1.1, first paragraph after Figure 4.2

Another Nit, but if RBridges are permitted to support a subset of the VLAN IDs, couldn't
we have a situation where two implementations supported disjoint ranges and were not
interoperable?  Or a I misreading that text?

Section 4.1.3, second paragraph first sentence.

Shouldn't this sentence state that TRILL framesforwarded by a transit RBridge use the
priority present in the Outer.VLAN tag as received?

[Ballot discuss]
This is a discuss-discuss: do we need to establish IANA registries for the Version (V) and
Reserved (R) bits in sections 3.2. and 3.3?  Since each field is only two bits, it seems important
to ensure that IETF standards action be required to allocate new values.

[Ballot comment]
Stylistic quibbles with section 3:
(1) IMHO, the TRILL header figure should include the header Options field.
(2) Section 3.5 should be renamed "Op-length" and should focus on Op-length
(3) The bulk of the current 3.5 should be moved to a new section 3.8 "TRILL Header Options"
These changes would ensure that the figure 3.1 and subsequent list are parallel with
the remainder of section 3.

Non-stylistic quiblle with section 3: When the data link layer is IEEE [802.3], are there any
constraints on Op-length to ensure that the 64 alignment is maintained?

Section 3.7.3, fourth bullet, first sentence:

Sorry to nitpick, but should we explicitly state that when the most significant bit is set to 1,
this indicates the nickname value was configured?

Section 4.1.1, first paragraph after Figure 4.2

Another Nit, but if RBridges are permitted to support a subset of the VLAN IDs, couldn't
we have a situation where two implementations supported disjoint ranges and were not
interoperable?  Or a I misreading that text?

[Ballot discuss]
This is a discuss-discuss: do we need to establish IANA registries for the Version (V) and
Reserved (R) bits in sections 3.2. and 3.3?  Since each field is only two bits, it seems important
to ensure that IETF standards action be required to allocate new values.

[Ballot comment]
Stylistic quibbles with section 3:
(1) IMHO, the TRILL header figure should include the header Options field.
(2) Section 3.5 should be renamed "Op-length" and should focus on Op-length
(3) The bulk of the current 3.5 should be moved to a new section 3.8 "TRILL Header Options"
These changes would ensure that the figure 3.1 and subsequent list are parallel with
the remainder of section 3.

Non-stylistic quiblle with section 3: When the data link layer is IEEE [802.3], are there any
constraints on Op-length to ensure that the 64 alignment is maintained?

[Ballot discuss]
This is a discuss-discuss: do we need to establish IANA registries for the Version (V) and
Reserved (R) bits in sections 3.2. and 3.3?  Since each field is only two bits, it seems important
to ensure that IETF standards action be required to allocate new values.

[Ballot comment]
Stylistic quibbles with section 3:
(1) IMHO, the TRILL header figure should include the header Options field.
(2) Section 3.5 should be renamed "Op-length" and should focus on Op-length
(3) The bulk of the current 3.5 should be moved to a new section 3.8 "TRILL Header Options"
These changes would ensure that the figure 3.1 and subsequent list are parallel with
the remainder of section 3.

Non-stylistic quiblle with section 3: When the data link layer is IEEE [802.3], are there any
constraints on Op-length to ensure that the 64 alignment is maintained?

[Ballot discuss]
I think this is important and good work. However, I think that the document needs to be last called in the IS-IS working group. Also, my understanding that this document is very closely related to and needs a normative reference to draft-ietf-isis-layer2.

[Ballot discuss]
I have reviewed draft-ietf-trill-rbridge-protocol-14, and have one
questions that I'd like to discuss before recommending approval of
the document:

Section 4.7 says "RBridges do not need to announce themselves as
listeners to the All-Snoopers multicast group (the group used for MRD
reports [RFC4541]), because the IP multicast address for that group is
in the range where all frames sent to that IP multicast addresses must
be broadcast."

Isn't this true only for IPv4, but not IPv6? (RFC 4541 seems to
broadcast 224.0.0.106, but not FF02::6A)

[Ballot discuss]
The Gen-ART Review by Pete McCann on 2010-01-08 raised some questions,
  and the WG Chair has proposed text to address them.  However, an
  updated document has not been posted yet.  I think the proposed
  changes are too big for RFC Editor notes.

IANA questions/comments:

QUESTION: Should the registry be more generically called "TRILL
Parameters" (instead of the proposed "TRILL Nicknames and Multicast
Address Registry") to include additional future sub-registries related
to TRILL?

QUESTION: Section 3.2 describes a version field. Should the version
numbers field be part of a registry?

QUESTION: Section 3.3 describes reserved bits. Should the reserved bits
field be part of a registry?

Upon approval of this document, IANA will create the following
registries at http://www.iana.org/assignments/TBD.

Registry Name: TRILL Nicknames
Registration Procedures:
RFC Required or IETF Review for single values
IETF Review for multiple values


Value Description Reference
------------- -------------------------------------
------------------------------------
0x0000 Reserved (no nickname specified)
[RFC-ietf-trill-rbridge-protocol-14]
0x0001-0xFFBF Dynamically allocated by the RBridges
[RFC-ietf-trill-rbridge-protocol-14]
within each RBridge campus
0xFFC0-0xFFFE Unassigned
0xFFFF Reserved
[RFC-ietf-trill-rbridge-protocol-14]


Registry Name: TRILL Multicast Address
Registration Procedures: IETF Review

Value Description Reference
------------------ -------------------------------
------------------------------------
01-80-C2-XX-XX-X0 All-RBridges
[RFC-ietf-trill-rbridge-protocol-14]
01-80-C2-XX-XX-X1 All-IS-IS-RBridges
[RFC-ietf-trill-rbridge-protocol-14]
01-80-C2-XX-XX-X2 All-ESADI-RBridges
[RFC-ietf-trill-rbridge-protocol-14]
01-80-C2-XX-XX-X3 to 01-80-C2-XX-XX-XF Unassigned

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

I, Erik Nordmark, TRILL Working Group co-chair, is the Document
Shepherd. I have have personally reviewed version 14 of the document and
I believes it is ready for forwarding to the IESG for publication.
(The document is of quite high technical and editorial quality - better than
any document of this size that I recall reading as an AD.)

(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 unusually thorough review. There were two Working
Group Last calls, once on draft -10 and one on draft -13. (The biggest
technical change between -10 and -13 was to fix an MTU related problem
that was detected during testing of a software implementation of the
-10 draft by Jim Carlson.) The draft has been reviewed by the
active working group participants over an extended period of time. From
the nature of many of the questions and comments from the reviewers it is
clear that many of them are reviewing the document from the perspective of
an implementor wanting to ensure that things will work correctly and also
interoperate with other implementations. Such careful review bodes well
for future interoperability testing.

The WG last call was also explicitly sent to the IS-IS WG and the MTU
problem was resolved in consultation with participants in IS-IS.

In addition, as required by its Charter, the Working Group requested
that IEEE 802.1 review the draft. Their response included some
critical but non-specific comments on the draft. It also asserted that
TRILL is "incompatible" with 802.1 provider and provider backbone
bridging when it is just that TRILL does not supply these services. As
a result, the draft was clarified to emphasize that TRILL as described
in this base protocol document supplies only customer bridging
services, and does not supply provider or provider backbone services,
but that 802.1 provider or provider backbone bridges may be used to
interconnect parts of a TRILL campus.

Finally, the draft was thoroughly reviewed by two independent IETF
experts, Bernard Aboba and Dan Romascanu, as required by the TRILL
Charter. These expert comments have been resolved, resulting in the
bulk of the changes between version -13 and version -14.

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

I have no such concerns.

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

I do not have any specific concerns or issues with the document.

The only IPR disclosure related to this document is the original
disclosure by Sun Microsystems granting royalty free use of all Sun
IPR required to implement mandatory parts of the resulting standard on
a reciprocal bases as detailed here:
https://datatracker.ietf.org/ipr/439/

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

There is a solid consensus behind advancing 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.

There have been no threatened appeals (or actual appeals for that
matter).

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

I've run it through idnits. FWIW idnits confuses section numbers with IPv4
addresses and outputs:
tmp/draft-ietf-trill-rbridge-protocol-14.txt(3402): Found possible IPv4 address '4.6.1.2' in position 35; this doesn't match RFC3330's suggested 192.0.2.0/24 example address range, or the suggested 233.252.0.0/24 example multicast address range.
tmp/draft-ietf-trill-rbridge-protocol-14.txt(3441): Found possible IPv4 address '4.6.2.4' in position 63; this doesn't match RFC3330's suggested 192.0.2.0/24 example address range, or the suggested 233.252.0.0/24 example multicast address range.


No MIB doctor or other formal review criteria applies.

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

The references are split, there are no downward references, and no
normative references are to works in progress.

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

The IANA considerations sections exists and, consistent with the rest
of the document, creates two new registries. No code points in
existing IANA registries are allocated. The new registries do not use Expert
Review.

This document also has an IEEE registration considerations section, as
two Ethertype allocations are required. In addition, the allocation of a
block of 16 multicast MAC addresses is required. The working group
consensus was that these multicast addresses should be allocated under
the IEEE standards OUI rather than the IANA OUI. The IEEE Registration
Authority routinely allocates code points without charge for other
standards development organizations.

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

There are no such sections in this document.

(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

The TRILL protocol provides optimal pair-wise forwarding without
configuration, safe forwarding even during periods of temporary loops,
and support for multipathing of both unicast and multicast traffic. It
achieves these goals using IS-IS routing and encapsulation of traffic
with a header that includes a hop count. Devices implementing TRILL
are called RBridges or Routing Bridges.

RBridges are compatible with previous IEEE 802.1 customer bridges as
well as IPv4 and IPv6 routers and end nodes. They are as invisible to
current IP routers as bridges are and, like routers, they terminate
the bridge spanning tree protocol. As customer devices, RBridges do
not supply provider or provider backbone bridging services but
provider or provider backbone bridges may be used to interconnect parts
of an RBridge campus.

The design supports customer VLANs and optimization of the
distribution of multi-destination frames based on VLAN and IP derived
multicast groups.  It also allows unicast forwarding tables at transit
RBridges to be sized according to the number of RBridges (rather than
the number of end nodes), which allows these forwarding tables to be
substantially smaller than in conventional customer bridges.

  Working Group Summary

The working group process included two working group last calls (an
MTU problem was discovered by an implementor after the first WG last
call thus a second last call was done to make sure the MTU changes had
sufficient review) as well as the usual review by working group members.
In addition, the working group charter required special reviews by IEEE
802.1 and two reviews by independent IETF experts.  As the combined
result of all of these steps, the document received an unusually
thorough review.

  Document Quality

The document is high quality due to the unusually thorough reviews it
has been subject to. An earlier version was implemented by Sun
Microsystems and the lessons learned were incorporated. Independent
IETF experts Dan Romascanu and Bernard Aboba did particularly thorough
reviews and their comments were resolved. Several implementations are
underway although not publicly announced.