Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

[Donald Eastlake <[e-mail]>]

Hi Olen,

Thanks for the comments. See responses below.

On Sun, Nov 18, 2012 at 12:27 PM, Olen Stokes
<[e-mail]> wrote:
>
> Comparing the -01 and the -02 versions of this draft shows some very
> important changes.

I agree.

>                     I understand the desire to finalize this draft.
> However, I am concerned that the changes in the -02 version may have
> created some inconsistencies in the document.  There may also be
> opportunities to more clearly state some of the implications of the
> changes.

I don't think there are any inconsistencies. However, it is certainly
possible that some clarifications and/or editorial changes would
improve the draft.

> Section 1.1 still defines a FGL RBridge as a "TRILL switch that
> support[s] both FGL and VL".  However, Section 9 states, "no TRILL
> data frames can be exchanged between VL and FGL RBridges".  It would
> be helpful to better describe scenarios where a FGL RBridge needs to
> support a VL mode of operation if a FGL RBridge cannot exchange
> packets with a VL RBridge.

Yes, an FGL RBridge must support Fine Grained Labeling (FGL) and
support VLAN Labeling (VL) as the inner data label. In other words, an
FGL RBridge must be able to ingress a native frame to an FGL TRILL
data frame, handle an FGL TRILL data frame as a transit switch, and
egress an FGL TRILL data frame to a native frame. In addition, an FGL
RBridge must be able to ingress a native frame to a VL TRILL data
frame, handle a VL TRILL data frame as a transit switch, and egress a
VL TRILL data frame as a native frame, all this VL stuff as described
in the TRILL base protocol RFC 6325.

So an FGL RBridge can safely handle VL data traffic. But if you give
an FGL data frame to a VL RBridge, it is very likely to be mishandled.
This problem with VL RBridges, which by definition are FGL ignorant,
is the reason for not allowing TRILL data traffic between FGL and VL
RBridges.

> Section 3 states that the default port configuration for a FGL
> RBridge port is VL.  A scenario where this is utilized would also be
> helpful.

Here are three uses that come to mine immediately:

- If you are upgrading a campus from VL to FGL RBridges, it might be
  some time, if ever, before you configured connectivity between all
  end stations to make use of FGL. In the mean time, you would want VL
  to continue working.

- It would be possible to standardize data connection between VL and
  FGL RBridges if it was specified how to do multi-topology. You could
  then have one topology with just FGL RBridges and a second topology
  with all RBridges. As long as FGL frames were limited to the FGL
  topology and that topology was fully connected, all would be
  well. Requiring FGL RBridges to support VL maintains this as a
  future possibility by merely adding multi-topology. Otherwise you
  would have to both add multi-topology and retro-fit VL support.

- Due to the way TRILL works, it appears that it will be desirable to
  have a maintenance VLAN in which all RBridges in a campus indicate
  interest (see, for example, draft-ietf-trill-oam-framework). You
  could, I suppose, have a maintenance FGL but it might as well work
  the same way for a VL campus as for an FGL campus.

> Otherwise, if a FGL RBridge does not have to support a VL mode of
> operation, a specific statement to that effect would be appropriate.

The current FGL draft, just like all previous versions of the FGL WG
and preceeding personal draft, does require support of VL by FGL
RBridges. Since you specifically talk about -01 to -02 changes, you
might not it is not a change that just appeared in the current
version.

> Section 7, Item 2, only discusses "Silicon Considerations" from an
> ingress/egress point of view.  It does not discuss it from a transit
> RBridge perspective.

Good point, transit processing should be mentioned briefly in Section
7, Item 2. However, the items in Section 7 are parallel with the same
number items in Section 2.1 and are just intended to discuss the
extent to which the goals in 2.1 are met, not to be a complete
discussion or summary of the named topics... Perhpas "Silicon
Considerations" should be replaced with "Silicon Goal".

> However, there appears to be several statements in the draft that
> could have important effects on how existing silicon could be used
> for transit FGL RBridge operation.  Section 5.1 states:
>
> "An FGL ingress RBridge MAY serially TRILL unicast a
> multi-destination TRILL Data frame to the relevant egress TRILL
> switches after encapsulating it as a TRILL known unicast data frame
> (M=0)".
>
> This would appear to allow silicon that can TRILL forward unicast
> FGL packets to operate as a TRILL transit FGL node regardless of
> whether it can TRILL forward FGL multi-destination packets.  If that
> is the intent, it would be helpful to state that in Section 7, Item
> 2.

Your statement seems a odd to me.  I don't understand what you mean
when you say "regardless of whether it can TRILL forward FGL
multi-destination packets". If it can't do that, I don't think it is
an FGL RBridge.

An FGL RBridge is required to be able to forward known unicast data
that is TRILL unicast (M=0), multi-destination data that is TRILL
multicast (M=1), and, due to the text you quote, multi-destination
data that is TRILL unicast (M=0).  Since your specifically talk about
-01 to -02 changes, you might note that this has been required in all
previous versions of the FGL WG draft and preceeding personal draft.
It is not a change that just appeared in the current -02 version.

> Section 5.2.2 states:
>
> "Pruning is an optimization. If a transit TRILL switch does less
> pruning than it could, there may be greater link utilization than
> strictly necessary but the campus will still operate correctly."
>
> This would appear to allow silicon that can TRILL forward FGL
> multi-destination packets to operate as a TRILL transit FGL node
> regardless of whether it can prune FGL packets.  If that is the
> intent, it would be helpful to state that in Section 7, Item 2.

Pruning is a SHOULD in the base TRILL protocol standard and it is the
same here. The provisions here are similar to those in the base
standard for VL pruning. I don't see any problem adding something to
clarify although I don't think Section 7, Item 2, is the best place.
How about just adding, at the end of the last sentence in Section
5.2.2, the following words "or not prune FGL frames at all"?

> Section 5.2.2 also discusses pruning based only on the High Part or
> the Low Part of a FGL.  A statement about silicon that can prune
> based only on half of a FGL would also be helpful in Section 7, Item
> 2.

But the whole point is that, since pruning is just a SHOULD
optimization, the silicon could prune on whatever subset of FGL bits
it feels like and still be conformant. For example, it could prune on
just the highest order bit or just the highest order byte of the FGL
or something. How about, including the addition above, changing

"For example, a transit TRILL switch could prune based on only part of
the FGL such as only the High Part or only the Low Part."

to

"A transit TRILL switch could prune based on an arbitrary subset of
the FGL label bits, such as only the High Part or only the Low Part,
or not prune FGL frames at all."

Actually an RBridge could adopte even more strange or exotic pruning
methods, although I can't see why it would want to. For example, it
could prune based on the data label value modulo some arbitrary
integer divisor less than the maximum label value...sort of a
ridiculous thing to do but frames would still be routed correctly so I
believe such behavior is allowed.

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

> Thanks for any consideration of these items.
>
> Cheers,
> Olen
>
>
>
> On 11/6/12 3:42 PM, "Donald Eastlake" <[e-mail]> wrote:
>
>>Hi,
>>
>>As announced at the TRILL WG meeting today, this starts a two week WG
>>Last Call on draft-ietf-trill-fine-labeling ending 19 November.
>>
>>Thanks,
>>Donald
>>=============================
>> Donald E. Eastlake 3rd   [phone] (cell)
>> 155 Beaver Street, Milford, MA 01757 USA
>> [e-mail]