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

From: [email-masked]
Date: Wed, 12 Dec 2012 08:25:56 -0800

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/

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 12 Dec 2012 11:29:20 -0500

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   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Wed, Dec 12, 2012 at 11:25 AM,  <[email-masked]> wrote:
> _______________________________________________
> trill mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trill

---

From: Olen Stokes <[email-masked]>
Date: Wed, 19 Dec 2012 10:19:30 -0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of Donald Eastlake
Sent: Wednesday, December 12, 2012 11:29 AM
To: [email-masked]
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   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA  [email-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 23 Dec 2012 23:44:23 -0500

Hi Olen,

On Wed, Dec 19, 2012 at 1:19 PM, Olen Stokes
<[email-masked]> 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