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

[Olen Stokes <[e-mail]>]

I am not opposed to the concept, but it does seem to violate the base protocol.  I believe that Section 4.6.2.4 of RFC 6325 would tell an egress VL RBridge to discard such a packet.  Given that a FGL RBridge is supposed to be able to forward both VL and FGL packets, should the description indicate that this behavior is to be used only with FGL packets?

I agree with Tom that this example should be included in the draft.  

Cheers,
Olen

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

Hi,

In addition to Radia's comment about reducing pruning state, see below:

On Wed, Nov 28, 2012 at 10:38 AM, Olen Stokes <[e-mail]> wrote:
>
> Thanks.  I understand that.  I am trying to understand under what 
> circumstances it is being proposed that multiple unicast packets be 
> sent instead of a single multi-destination packet?  In other words,
> **WHY** would an RBridge use this unicast method rather than use the 
> existing multi-destination D-Tree method?

Consider a large TRILL campus in which, say, 100 end stations are in some particular FGL data label.

At one extreme, if all 100 end stations were attached to a single TRILL switch, then no other TRILL switch would be advertising interest in that FGL and likely a multidestination (say broadcast) frame from one such end station would, even if put on a distribution tree, because of pruning, not get sent any another TRILL switch.

At the other extreme, assume the 100 end stations are attached, one each, to 100 different end stations; in that case you are almost certainly better off using a distribution tree because if you tried to serially unicast you would cause much higher link utilitization, probably have to output some multiple copies through the same port, etc.

But what if these 100 end stations are connected to exactly two TRILL switches, say 75 to one and 25 to the other. Using unicast TRILL Data frames between these TRILL switches is better because they will follow least cost paths, possibly with such traffic spread over an arbitrary number of equal cost least cost paths. On the other hand, if one or more distribution trees were used, each frame would be constrained to the tree used for that frame and would likely follow a more circuitous route, depending on where the tree roots are. That's why the draft says "SHOULD" use unicast if there exactly two TRILL switches involed.

It's a more complex decision whether to use a distribution tree or serial unicast if the end stations are connected to a "small" number of TRILL switches greater than two. So the draft just says "MAY" in that case.

> Cheers,
> Olen

On Wed, Nov 28, 2012 at 10:53 AM, Thomas Narten <[e-mail]> wrote:
> Olen's original comment was about the following text in the document:
>
>> "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)".
>
> Does the base TRILL spec forbid the above behavior?

While I do not think it has a statement explicitly prohibiting such behavior, it implicitly prohibits it by mandating that multidestination frames be encoded into TRILL Data frames with a TRILL Header having M=1 and sent on the distribution tree indicated by the egress nickname.

There is also the corresponding egress statement that requires FGL TRILL switches to be able to egress such multi-destination inner frames encoded with M=0:

"FGL TRILL switches MUST accept multi-destination TRILL Data frames that are sent to them as TRILL unicast frames, that is, frames that may have a multicast or broadcast Inner.MacDA (or are being sent to an unknown unicast Inner.MacDA) and the TRILL Header M bit = 0."

(Actually, the current standard in effect requires all TRILL switches to be able to egress unknown unicast frames when encoded that way. That's because a destination MAC and VLAN can be known to the ingress TRILL switch, which then encodes the TRILL Data frame with M=0 and unicasts it to the egress, but then turn out to be unknown to that egress switch because its tables of attached MACs have overflowed or the entry has timds out or it has re-booted or whatever.)

> Is this sentence even needed? Can we just remove it? (FWIW, it seems 
> to me to be unnecessary.)

What do you mean by "needed"? It is an intentional change in TRILL; as such it does something, causing significant improvement in some cases as in my response to Olen above. But it is just a matter of efficiency so FGL TRILL would still work without it.

> Thomas

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

On Wed, Nov 28, 2012 at 7:48 PM, Radia Perlman <[e-mail]> wrote:
> Even if the base spec doesn't preclude doing serial unicast, it might 
> be worth mentioning the possiblity here because if there is a huge 
> campus with so many different FGLs in use that the inner RBridges have 
> trouble filtering, and there's only a few edge guys participating in 
> the FGL, it might wind up being more optimal for the ingress switch to 
> do serial unicast.  So saying MAY just gives an implementer the hint 
> that it might be a good thing to allow.
>
> At any rate, I don't think it hurts to have that sentence in the FGL spec.
>
> Radia
>
>
>
>
> On Wed, Nov 28, 2012 at 4:53 PM, Thomas Narten <[e-mail]> wrote:
>>
>> Olen's original comment was about the following text in the document:
>>
>> > "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)".
>>
>> Does the base TRILL spec forbid the above behavior?
>>
>> Is this sentence even needed? Can we just remove it? (FWIW, it seems 
>> to me to be unnecessary.)
>>
>> Thomas
>>
>> _______________________________________________
>> trill mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/trill
>
>