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

[Olen Stokes <[e-mail]>]

Comparing the -01 and the -02 versions of this draft shows some very
important changes.  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.
 

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.
 

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.
 

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

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.
 

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.
 

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.
 

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.
 

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]
>_______________________________________________
>trill mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/trill