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

[Donald Eastlake <[e-mail]>]

Hi Somnath,

On Tue, Jul 3, 2012 at 8:36 AM, somnath chatterjee
<[e-mail]> wrote:
> Hi Authors,
>
> I have few queries regarding ESADI protocol as per
> draft-ietf-trill-esadi-00, base RFC 6325 and RFC 6165.
>
> 1>In base RFC 6325 Section 4.2.4.4  (5.4)
>
> "In addition, the LSP contains the following information on a per- VLAN basis:
>       5.4. Per-VLAN ESADI protocol participation flag, priority, and
> holding time.  If this flag is one, it indicates that the RBridge
> wishes to receive such TRILL ESADI frames"
>
> The per vlan ESADI protocol participation flag is send via "Interested
> VLANs and Spanning Tree Roots Sub-TLV" in TRILL LSP.The per vlan ESADI
> priority is send via "ESADI Parameter APPsub-TLV" in ESADI LSP 0. Is
> the "holding time" same as "CSNP time" field in "ESADI Parameter
> APPsub-TLV"?

Yes, that is the intent. This draft proposes changes to ESADI from the
specification in RFC 6325.

> 2>The Inner.VLAN tag for ESADI LSP indicates the  VLAN to which the
> ESADI-LSP applies, the vlan in MAC-Reachability TLV is unused.Why do
> not we use the MAC-Reachability TLV's vlan field ? If we use
> MAC-Reachability TLV's vlan field we can merge multiple ESADI-LSPs to
> one ESADI LSP and reduce number of ESADI LSPs. Currently if we have 4k
> VLANs enabled on an ESADI RBridge it has to send 4k ESADI LSPs. This
> can be reduced using the MAC-Reachability TLV's vlan field.

That's only true if the ESADI RBridge is participating in ESADI for
all of those VLANs. And there are two reasons (1)
draft-ietf-trill-rbridge-vlan-mapping, and (2) if there were
information in an ESADI-LSP PDU for  say, two different VLANs, only
one of these could appear at the VLAN ID in the Inner.VLAN so there is
no way to guarantee that the PDU would get to RBridges participating
in ESADI only for the other VLAN due to distribution tree pruning (see
your question 4 below).

> 3> What should be the deciding factor behind unicast-ing a ESADI LSP
> and sending it on a DTree? Should it be the number of ESADI RBridges
> in the campus?

The text related to this aspect of the current ESADI draft could
probably do with review and clarification. Obviously, all the
destination ESADI RBridges have to indicate that they support unicast
receipt. I would say that, to a first approximation, it is best to use
unicast if their is one intended recipient and a distribution tree if
there are multiple recipients. There being only one intended recipient
for a particular ESADI-LSP does not imply that there are only two
ESADI RBridges for that VLAN.

> 4> If DTrees are already pruned, it would be good to send ESADI LSPs
> on vlan pruned Dtree. Can we further prune these vlan pruned DTrees
> based on the RBridges participating in ESADI for a particular clan.

Since ESADI--LSP PDUs are treated by transit RBridges like any other
multi-destination TRILL Data packet, they will automatically use any
distribution tree VLAN pruning available. Further pruning those trees
based on ESADI participation is an obvious improvement that will work
fine whether it is implemented for all or some of the RBridges in a
campus. But this wasn't included in the TRILL specifications because
it did not, at the time, seem worth the additional complexity. It
seemed like that in a well configured network, either none of the
RBridges interested in a particular VLAN would be ESADI participants
for that VLAN or all or almost all of them would be. Pruning on ESADI
participation does no good in the none or all cases and probably helps
most somewhere in the middle.

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

> Thank you,
> Regards,
> Somnath