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

[Radia Perlman <[e-mail]>]

So I think Olen, you are saying that it's useful for an edge RB in FGL #x
to say "I'm planning on using serial unicast when transmitting to FGL #x.
If all the edge RBs in FGL x say that, then the core RBs don't have to
bother storing pruning state about FGL x, since they will never see
multidestination frames for FGL x.  I don;'t think the draft currently says
that, and it does sound useful.

Another topic...suppose a transit RB ignores all tags on unicast...in other
words, it forwards based solely on the "egress nickname" in the TRILL
header...then it seems like it ought to be able to work fine for FGLs that
are transmitted as serial unicast. I'd assume all RBs behave that way today
(not looking for VLAN tags inside when forwarding TRILL unicast). So it
might be another strategy for mixed VL/FGL campuses for FGL edge RBs to
MUST serial unicast if there are any transit VL RBs.

And furthermore, if an implementation of a transit RB were to be "lazy"
about pruning, and not bother looking for VLAN tags, and only transmit on
the tree, then it ought to work fine as a transit RB, even if it doesn't
know how to parse FGL. Might there be implementations that could more
trivially be upgraded to indicate this behavior than to be upgraded to
parse FGL?

Or if it looked for a VLAN tag, couldn't find it (because there was an
FGL), and it decides, because it sees this weird unknown tag, to forward it
anyway rather than drop it, then it also would work fine as a transit RB.
Do we know how current VL implementations behave if they can't find a VLAN
tag?  If they all happen to behave in this way (forward frames with no VLAN
tag on the tree), then again, it seems like we can say it's fine to have VL
RBs as transit.

I suppose if it's trivial to upgrade all the current RBs to parse FGL, then
it probably doesn't matter...

Radia




On Fri, Nov 30, 2012 at 9:42 PM, Olen Stokes <[e-mail]>wrote:

> 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
> _______________________________________________
> trill mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trill
>