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:20 AM, Olen Stokes
<[e-mail]> wrote:
> It would seem that in order for an “inner” or transit-only RBridge
> to improve its scaling by not including the “filtering” for a
> certain FGL, it would have to either:

I prefer calling it "pruning", the term that, I believe, is
consistently used in the TRILL standard documents, rather than
"filtering" which may have other meanings to some people. Note that
this aspect of optimization is not something I brought up in
connection with serial unicast but something that Radia brought up. I
think it is justified based on link utilization, traffic spreading,
and latency considerations but saving on pruning state at transit
TRILL switches is an additional justification which, as you point out
below, probably requires some additional mechanism.

> 1)      Know which FGLs are being sent using multi-destination packets and
> which are being sent using multiple unicast packets, or
>
> 2)      Use a cache driven design which traps on unknown FGL labels and
> installs “filtering” only when a FGL is seen for the first time.  This
> approach also opens up the discussion about knowing when to remove inactive
> “filters”.

Technique 2 seems way too complex to me.

Technique 1 is the way I have been thinking about doing it but
requires per data label announcement of whether serial multicast is
being used for multi-destination traffic and/or per data label
announcement by some elected TRILL switch for a data label that all
TRILL switches MUST use serial multi-cast for multi-destination for
the data label or the like.

> I believe that the Interested Labels and Spanning Tree Roots sub-TLV
> in RFC6326bis should use a reserved bit to indicate whether
> multi-destination packets or multiple unicast packets will be used
> with the indicated label(s).

Exactly. That's the right place for capability/command information for
this sort of thing for FGL and the Interested VLANs sub-TLV for VL
data labels.

You also want to prune the set of serial unicast transmissions to be
made at the source so each possible source for the data label needs to
know the multicast listener situation. But it is wasteful of link
state space to flood that information everywhere. So you want to
distribute it through ESADI if all the TRILL switches interested in a
data label are capable of serial unicast and ESADI participants for
that data label.

So my inclination is to put little about this in the FGL draft and
most of this into the ESDAI draft. The current ESADI draft already has
material in it about a capability bit for serially unicasting ESADI
PDUs which could be generalized to a broader capability for serially
unicating multi-destination frames.

Since the FGL draft is about FGL, I think the best it should do is as
it presently does: FLG TRILL switches MUST be able to receive serially
unicast multi-destination FGL frames, MAY transmit such frames, and
SHOULD so transmit multi-destination frames if there is only one
relevant destination TRILL switch.

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

> Cheers,
> Olen
>
>
>
> From: Radia Perlman [mailto:[e-mail]]
> Sent: Wednesday, November 28, 2012 7:49 PM
> To: Thomas Narten
> Cc: Olen Stokes; Donald Eastlake; [e-mail]
>
>
> Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt
>
>
>
> 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