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

[Olen Stokes <[e-mail]>]

No hang-ups on "pruning" versus "filtering".  I just wanted to use the same term as Radia had used since I was responding to her email.

>From below:

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

It would seem possible that each edge RBridge could use a unique/different algorithm to determine whether or not it should serially send multi-destination traffic.  Therefore, to me, the indication that we are discussing is one that says that a particular edge RBridge is currently using serial transmission.  In other words, it says that it **IS** using serial transmissions as opposed to saying that it **CAN**use serial transmission.  

An individual transit RBridge could then optimize its pruning resources by detecting whether any edge RBridge has indicated interest in a FGL and has also indicated that it is not using serial transmission of multi-destination packets.  This would avoid having to elect a RBridge for controlling the transmission technique to be used for a particular FGL (as well as what to do when the elected RBridge disappears).

Based on your discussion, as the number of RBridges interested in a FGL increases, one or more edge RBridges may decide to switch from serial transmission to the use of normal D-Tree multi-destination transmission.  At that point they would change their usage indication.  The transit RBridges would have to detect the change in settings and react accordingly.

Cheers,
Olen


-----Original Message-----
From: Donald Eastlake [mailto:[e-mail]] 
Sent: Friday, November 30, 2012 12:32 AM
To: Olen Stokes
Cc: [e-mail]
Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

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