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

[Donald Eastlake <[e-mail]>]

Hi Olen,

On Thu, Nov 29, 2012 at 11:53 AM, Olen Stokes
<[e-mail]> wrote:
> I am not opposed to the concept, but it does seem to violate the base protocol.

That's right. Anything that changes the base protocol "violates"
provisions of the base protocol. Saying that 0x893B can occur after
the Inner.MacSA violates the base protocol specification. That's a
common purpose of drafts that update or replace earlier documents. The
upper left of the title page of this draft says it updates RFC 6325.

However, I do think of FGL capabilities as optional. If it is not
clear in the draft, a statement should be added that a VL TRILL switch
conformant to RFC 6325 (as updated by RFC 6327 and the Clarifications
and Corrections draft) is still a valid implementation of the TRILL
protocol.

> I believe that Section 4.6.2.4 of RFC 6325 would tell an egress VL RBridge to discard such a packet.

Correct with the exception, as I pointed out in a previous message, if
the Inner.MacDA was unicast because the multi-destination frame being
serially unicast was an unknown unicast frame.

> 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?

Given that this is an FGL draft, it would be reasonable to make that
clear. The provisions are in sub-sections that are about ingressing,
transiting, and egressing FGL TRILL data frames.

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

I have no problem with adding some material along those lines, but not
a lot of material.

It seems to me that the decision whether to use a distribution tree or
to serially unicast, in cases where there is more than one destination
TRILL switch, and the basis for such a decision should be beyond the
scope of this draft. Similar examples are the decision of which TRILL
switches, if any, to designate as appointed forwarders for which VLANs
on a link or where to configure roots for your distribution trees are
decisions outside the scope of the TRILL standard. Because the number
of factors that could influence making such decisions in an optimal
way is essentially unbounded and could extend to specific knowledge of
application behavior on specific data sets and the like.

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

> 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
>>
>>