Re: [trill] I-D Action: draft-ietf-trill-fine-labeling-03.txt

[Olen Stokes <[e-mail]>]

Thanks for the updated draft.  I think that the changes have been very worthwhile.  One thing that the changes made more clear to me is how tightly the draft ties fine grained labels (FGLs) to C-VLAN IDs.  Going back to RFC 6325, it states that:

"Use of [802.1ad] S-tags, also known as service tags, and use of stacked tags, are beyond the scope of this document."

I take that to mean that the use of S-Tags (or other stacked tags) is not prohibited, it is just not covered.  The encapsulation used in RFC6325 included the C-Tag which told every RBridge that received the TRILL packet that the encapsulated packet was a C-Tagged packet.  If someone wanted to extend RFC6325 to describe operation with S-Tagged packets, it would be straightforward for RBridges to determine that the encapsulated packet was a S-Tagged packet by seeing a 0x88A8 instead of a 0x8100.  The bottom line is that the information necessary to determine the packet type of the encapsulated packet was included in the TRILL packet.

With FGL, we appear to be losing the ability to determine the packet type of the encapsulated packet.  The draft in several places describes going between a FGL and a C-VLAN ID.  In other words, the original format of the encapsulated packet could appear to be limited to C-Tags.  It would seem to be appropriate to insure that FGL can be extendable to supporting S-Tags.  For example, the following two approaches come to mind:

1) Assume that Ethertype 0x893B indicates only the presence of a FGL and that it does not necessarily mean that the encapsulated packet is a native C-Tagged packet.  If pruning is based solely on the FGL and the DMAC of the encapsulated packet, then D-Tree pruning would not require an understanding of the format of the encapsulated packet.  As long as all edge RBridges advertising interest in a FGL agree on the format of the encapsulated packet, then data forwarding would work correctly.

2) Use a new Ethertype other than 0x893B to indicate that the FGL is for a S-Tagged (or stacked tag)  native packet.

Some indication of the approach that the authors have in mind would be very helpful when trying to understand the draft.

This leads to another aspect that became more clear to me in this version of the draft.  FGLs have global significance but C-VLAN IDs will now have only local significance.  It would seem possible that at the edge a DRB and a non-DRB could both announce VLAN ID 100 in their Hello's but be describing two different VLANs.  RFC 6325 assigned appointed forwarders based on C-VLAN IDs when C-VLAN IDs had global significance.  It would seem appropriate that FGL RBridges assign AFs based on FGLs since it will be FGLs that have global significance.
 
Cheers,
Olen

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Donald Eastlake
Sent: Wednesday, December 12, 2012 11:29 AM
To: [e-mail]
Subject: Re: [trill] I-D Action: draft-ietf-trill-fine-labeling-03.txt

This version has substantial editorial changes in response to comments on the list. It is not intended to make technical changes.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA  [e-mail]


On Wed, Dec 12, 2012 at 11:25 AM,  <[e-mail]> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.
>
>         Title           : TRILL: Fine-Grained Labeling
>         Author(s)       : Donald Eastlake
>                           Mingui Zhang
>                           Puneet Agarwal
>                           Radia Perlman
>                           Dinesh G. Dutt
>         Filename        : draft-ietf-trill-fine-labeling-03.txt
>         Pages           : 27
>         Date            : 2012-12-12
>
> Abstract:
>    The IETF has standardized TRILL (TRansparent Interconnection of Lots
>    of Links), a protocol for least cost transparent frame routing in
>    multi-hop networks with arbitrary topologies and link technologies,
>    using link-state routing with a hop count. The TRILL base protocol
>    standard supports labeling of TRILL data with up to 4K IDs. However,
>    there are applications that require more fine-grained labeling of
>    data. This document updates RFC 6325 and RFC 6327 by specifying
>    optional extensions to the TRILL base protocol to safely accomplish
>    this.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-trill-fine-labeling
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-trill-fine-labeling-03
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-trill-fine-labeling-03
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> trill mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trill
_______________________________________________
trill mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/trill