[rbridge] Adopt draft-eastlake-trill-rbridge-fine-labeling-02.txt as WG document

Tue Nov 15 22:06:53 PST 2011

Hi David

TRILL allow VLAN based pruning. 6326bis draft already have added
fine-grain labeling capability. This allow devices to prune based on
fine label. Which in turn will limit the broadcast and ARP issue you
brought up in point #3. 

On point #2. Having two 12 bit tags is a common scenario. Since we are
limiting the interpretation of these two tags within the TRILL cloud and
only within the cloud it is fine. Why ? Because TRILL link header is
what 802.3 layer sees. Inner payload is for all practical purpose just
like IP payload on a Ethernet encapped IP packet. Hence how the inner
payload is treated should treated as a TRILL specific forwarding
behavior not any shape violating 802.3.

Thanks
Tissa

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of David Allan I
Sent: Tuesday, November 15, 2011 6:49 PM
To: Erik Nordmark; rbridge at postel.org
Subject: Re: [rbridge] Adopt
draft-eastlake-trill-rbridge-fine-labeling-02.txt as WG document

I think I was the only person in the room to indicate disapproval for WG
adoption....so I figure it is appropriate to offer my rationale...

It is a slightly expanded version of my comments minuted at IETF 81...

1) This is solving a TRILL design problem in the Ethernet layer.

2) It is non standard from an Ethernet point of view, and although
implementations exist that may stack more than one tag, processing them
as a concatenation of tags IMO is still likely new and inconsistent, so
this is dependent on a proprietary and non-standard feature. Similarly
inferring a tag stack from a single received tag is a new behavior as
well as the re-mapping of the dual tag to single tag or untagged frame
at the egress.

3) It actually has limited utility as it does not offer any improved
broadcast containment beyond egress filtering as it is nested inside the
rbridge header (assuming implementations can filter on a concatentated
tag stack). So it adds no value in additional scoping for MDTs for
flooding and ARP.

So I personally would suggest if you are going to require/mandate
silicon modifications, they would be better off applied to the TRILL
header itself vs. blurring the distinction between TRILL and 802.1 and
introducing a discontinuity in standard compliant implementations. IEEE
802 has already provided a multi-sdo liaison a couple of years ago on
how simultaneous multiple tag operations at a single hop is considered
to be an architectural violation when proposals akin to this kind of
abuse emerged during the GELS discussions.

So I have no issue with TRILL finding a way to support a larger VLAN
space, I just do not agree with the proposed approach...it IS
interfering with someone elses standard and how companies would
implement that standard, and these days that is a really bad precedent.

I hope this helps
Dave

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Erik Nordmark
Sent: Wednesday, November 16, 2011 9:14 AM
To: rbridge at postel.org
Subject: [rbridge] Adopt
draft-eastlake-trill-rbridge-fine-labeling-02.txt as WG document

At the TRILL WG meeting Tuesday there were several comments that the
fine-grained label work is important and needs to be prioritized by the
WG. There was also a rough consensus in the room in favor of adopting
the document, as there was in Quebec City, but there were only about
half as many people in the room that indicated they had read the
document as at the last meeting. This is to confirm that it should be a
WG document and ask people to read and comment.

   Erik and Donald
_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge