Re: [trill] [rbridge] Query on draft-ietf-trill-esadi-00

[Donald Eastlake <[e-mail]>]

Hi,

On Fri, Jul 13, 2012 at 5:51 AM, Abhinav Bhatia <[e-mail]> wrote:
> Hi Authors,
>
>
> I have query regarding  “The ESADI (End Station Address Distribution
> Information) Protocol” as per  “draft-ietf-trill-esadi-00”
>
>
> According to draft in Section 5.2 Forgetting End Station Addresses
>
>
>    If RBridge RBn participating in the TRILL ESADI protocol for VLAN-x
>    is no longer appointed forwarder for VLAN-x on any port where it is
>    providing end station service, it ceases to participate in ESADI
>    after sending a final ESADI-LSP nulling out its ESADI-LSP
>    information.
>
>
> Above will remove/flush the learned L2 entries for that ESADI Rbridge for
> that vlan and also remove the neighbor ESADI instance entry.
>
>
> Q) What does “nulling out” its ESADI-LSP information mean? Does it means
> removing the macs and sending an empty MAC Reachability TLV or does it mean
> that the ESADI LSP
>      wont contain any MAC Reachability TLV at all?

I don't see how it makes any difference. Since the RBridge doing this
is going to drop out of the ESADI instance anyway, the MAC
Reachability information it was originating is going to be ignored or
discarded soon anyway. I think sending out this final "empty" LSP
information just gets the word out a little faster.

> Q) In case if ESADI rbridge is AF for a vlan-x and  the only  End Station
> which was connected earlier, is removed now, then what will be sent in
> ESADI-LSP to flush L2 entries for that
>     vlan-x, will it be without MAC Reachability TLV? Please bear in mind
> that the RBridge has not lost AF for that particular vlan, but has no End
> Station to send in MAC Reachability
>     TLV.

Again, I don't see how it makes any difference whether it sends an
empty MAC Reachability TLV or send no MAC Reacability TLVs. Why can't
implementations do whichever is most convenient? (I suppose not
sending any MAC Reachability TLVs saves a tiny number of bytes...)

>     Please let me know for an ESADI RBridge  how to distinguish between
>
> 1>     when to remove learned L2 entries and

The way I look at it, an RBridge has number of sources of "MAC&VLAN ->
egress nickname" mapping entries. There are entries it has learned
from the data plane (possibly empty if data plane learning has been
disabled) or from Layer 2 registration protocols. There may be entries
in its ESADI state for various VLANs if it is participating in ESADI.
There can be manually configured mappings.

When any of these sources of mapping change, the RBridge makes the
appropriate change in its forwarding tables. You "remove learned L2
entries" on a different basis for different sources. For data plane
learning, it is timeout. For ESADI, it is state flooding. Etc.

> 2>     when to remove ESADI instance neighbor on receiving ESADI-LSP?

I think the mechanisms for recognizing ESADI instance neighbors in the
current draft are too complicated and can probably be simplified as
well as clarified.

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

> Thanks,
> Abhinav