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

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:

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

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

Cheers,
Olen

From: Radia Perlman [mailto:radiaperlman@gmail.com]
Sent: Wednesday, November 28, 2012 7:49 PM
To: Thomas Narten
Cc: Olen Stokes; Donald Eastlake; trill@ietf.org
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 <narten@us.ibm.com<mailto:narten@us.ibm.com>> 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
trill@ietf.org<mailto:trill@ietf.org>
https://www.ietf.org/mailman/listinfo/trill