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

[Donald Eastlake <[e-mail]>]

Hi Olen,

On Wed, Dec 19, 2012 at 1:19 PM, Olen Stokes
<[e-mail]> wrote:

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

Yes, I think think this is inherited, insofar as it is applicable, by
the fine grained labeling draft since it updates RFC 6325; a similar
statement could be included in that draft.

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

Pruning based on FGL (or VL) and Inner.MacDA of a TRILL Data packet is
a reasonable strategy and would have the characteristics you suggest.
I believe there are current implementations of TRILL that look deeper
into the frames and, if the TRILL Data packet is carrying an IPv4 or
IPv6 packet, prune based on the VL and IP destination address.  I
would assume that such implementations are likely to be extended to
work for FGL.

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

Ethertypes are a finite resource so it seems best to avoid using a new
one unless necessary. Because the information after the FGL has the
usual Ethernet Ethertype/LLC type labeling, if someone has gone
outside the bounds of the TRILL documents and put one or more S and/or
C tags after an FGL, it seems to me that it can unambiguously parsed.

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

Well, the draft, sort of by definition, can't say much about what is
out of scope... Since the use of VLANs and FGLs is all configured, I
would think that a network manager who wanted to encode a bit or two
of information about the remainder of the frame could encode that in
the FGL. But also, as I said above, I think any known tags pre-fixing
the remainder of the frame would be unambiguously pareseable.

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

That is true if all ports are configured as FGL ports.

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

Appointed forwarders only have to do with native frames. Within TRILL
as specified in the existing RFCs and the FGL draft, native frames can
only be either untagged or tagged with a C-VLAN. A native frame with
other tagging would, in my opinion, be out of scope. AF has no effect
at all on the handling of TRILL Data packets.

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

> 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/