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

From: somnath chatterjee <[email-masked]>
Date: Tue, 3 Jul 2012 18:06:46 +0530

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

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.

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?

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

Thank you,
Regards,
Somnath

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 3 Jul 2012 15:53:00 -0400

Hi Somnath,

> the "holding time" same as "CSNP time" field in "ESADI Parameter

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

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

> and sending it on a DTree? Should it be the number of ESADI RBridges

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.

> 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   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]