Subject: [rbridge] TRILL base protocol -15 to -16, changes to Section 4

From: Donald Eastlake <[email-masked]>
Date: Sat, 20 Feb 2010 00:11:57 -0500

Changes to Section 4 of version -15

{1} Confidence level mechanism rational

Comment originally from the Routing Directorate:
>   The document should explain the philosophy and usage of confidence
>   level with respect to the {port, VLAN, MAC address} tuples.

Add the following, probably to Section 4.8, and edit so it fits
smoothly:

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

{2} MTU

Add to Section 4.8.1: "Native frames that, after TRILL encapsulation,
exceed the MTU of a link on which they would be sent will generally be
discarded."

{3} Distribution Tree Selection

Add to 4.5 that methods by which a ingress RBridge choosse a
distribution tree or trees are beyond the scope of the draft but, if
other factors are equal, choosing a tree whose root is least cost from
the ingress RBridge is generally a good choice.

{4} Nits

Page 44, Section 4.2.6, first full paragraph, replace "RBridges ,"
with "RBridges," and "next hop" with "next hop".

Page 46, Section 4.4.1, third paragraph, replace "completely
independently of whether they are padded or not" with "even though
they are not padded".

Page 48, Section 4.4.2, first full paragraph, capitalize or somehow
denote the "Appointed-Forwarders TLV" and reference "[layer2]".

Page 52, Section 4.4.5, first paragraph, replace "permitted to a"
with "permitted on a".

Page 59, Section 4.5.5, first bullet, replace "nickanme1"
with "nickname1".

Page 67, Section 4.8, restructure first sentence to
not be one continuous stream of consciousness:

Change it to start as follows:

  RBridges have to learn the MAC addresses and VLANs of their locally
  attached end stations for link/VLAN pairs for which they are the
  appointed forwarders. Learning this enables them to do the
  following:

And then convert the two main bullet points into separate sentences.

Page 70, Section 4.8.3, first bullet, replace "who's" with "whose"
consistent with this usage.

Page 72, Section 4.9.1, first full paragraph, replace "to the left in
the this list" with "to the left of the other bit in this list".

Page 75. Section 4.9.3.2, second paragraph, replace "in the first set"
with "in the lower priority set".

{5} Sender Nickname Omission

In Section 4.4.2, add sender Nickname to the fields that MUST be
present in TRILL-Hellos.
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 22 Feb 2010 09:05:49 -0500

On Sat, Feb 20, 2010 at 12:11 AM, Donald Eastlake <[email-masked]> wrote:

> ...

{2} MTU
> ...

The Section reference above should have been 4.3.1, not 4,8,1.

Donald

---

From: Michael Kantowski <[email-masked]>
Date: Mon, 22 Feb 2010 06:39:37 -0800 (PST)

Would rbridges send back any icmp or other type messages in order to help facilitate pmtud?  Do you foresee any issues with pmtu in general with this additional encapsulation?  Or would we continue to rely on routers for this messaging, business as usual...?

(I am likening this the situation found with IPsec tunnels over ethernet where you need to set the mtu on tunnel interfaces to something like 1400 in order to keep the packet sizes below the ethernet mtu.)

thanks!

Mike Kantowski

________________________________
From: Donald Eastlake <[email-masked]>
To: [email-masked]
Sent: Mon, February 22, 2010 8:05:49 AM
Subject: Re: [rbridge] TRILL base protocol -15 to -16, changes to Section 4

{2} MTU

Donald