Subject: [trill] Query on Interested VLANsand Spanning Tree Roots Sub-TLV in RFC6326

From: wenyu zou <[email-masked]>
Date: Sat, 25 Aug 2012 09:19:27 +0800

Hi Authors,
    I have a question about "AppointedForwarder Status Lost Counter"
in"Interested VLANs and Spanning Tree Roots Sub-TLV", as specified in
[RFC6326], Section 2.3.6. The counter is shared by VLANs from
VLAN.start toVLAN.end. But the counter for per-VLAN can easily be
different by configuration or topology change. When a port lost the
status of being an appointed forwarder for VLANx, the Sub-TLV should
be splited. So it maybe have so many Interested VLANs and Spanning
Tree Roots Sub-TLV in LSPs, and they have little chance to merge
again.
    Is it correct? Do you have some method to solve this problem?
Thanks.
Regards,
wenyu

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 24 Aug 2012 22:48:20 -0400

Hi Wenyu,

>     Is it correct? Do you have some method to solve this problem?

The Appointed Forwarder Status Lost Counter is a mechanism to optimize
data plane learning by trimming the expiration timer for learned
addresses per VLAN under some circumstances.
(1) If you don't care about that optimization and don't mind some time
outs being longer than they otherwise would be, you can just not
bother changing the counter, even if you are using data plane
learning. On the other hand, if you don't care about sone time outs
being shortened when they otherwise wouldn't, you could increment the
counter for multiple VLANs even you don't lose AF status on a port for
all those VLANS.
(2) If you are using ESADI or Directory Assist and not learning from
the data plane, the counter doesn't matter and there really isn't any
reason to increment it.
(3) If an RBridge port has been configured with the "disable end
station traffic" bit on (also known as the trunk bit), then it makes
no difference if that port is appointed forwarder or not. So there is
no reason to increment the counter if such a port loses Appointed
Forwarder status.
(4) If you are updating the counter, incrementing it by more than one
(even up to incrementing it by a couple of hundred), so that it
matches the counter for some other VLAN for the same RBridge would
have an extremely small probability of causing any sub-optimization
and if it did will just very rarely fail to specially decrease the
time out for some learned addresses.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]