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

[Olen Stokes <[e-mail]>]

Since the two emails below were written about a week ago, there has been a lot of discussion about the RBridge capabilities required to be classified as an FGL RBridge.  I am still unclear about one part of the exchange below.

There is a discussion about the implications of a TRILL ingress RBridge serially unicasting "a multi-destination TRILL Data frame to the relevant egress TRILL switches after encapsulating it as a TRILL known unicast data frame (M=0)". 

What is the use case envisioned when there is more than one "relevant egress FGL RBridge"?

FWIW, Donald noted below that this provision has been in all of the previous versions.  I agree.  I did not mean to imply otherwise. 

Cheers,
Olen


-----Original Message-----
From: Donald Eastlake [mailto:[e-mail]] 
Sent: Monday, November 19, 2012 8:19 PM
To: Olen Stokes
Cc: [e-mail]
Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

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]