[rbridge] two minor issues with the isis-02 draft
d3e3e3 at gmail.com
Tue Feb 24 21:09:45 PST 2009
Thanks for review this. See below...
On Thu, Feb 19, 2009 at 3:11 PM, James Carlson <james.d.carlson at sun.com> wrote:
> The good news is that I'm done with this pass over our source code and
> the relevant TRILL documents, so you likely won't hear many more
> issues out of me for a while. There's light at the end of the
> tunneling protocol.
> First issue: why does isis-02 specify the following?
> 1. Information on reachable RBridge neighbors and the cost of the hop
> via the Extended IS Reachability TLV (Type #22) [RFC5305] (wide
> metric). TRILL IS-IS does not use the IS Reachability TLV (Type
> #2) (narrow metric).
> This restriction doesn't appear to be necessary, and for bridges that
> don't need the extended metrics, it seems slightly wasteful. If
> there's a purpose behind this (I have a bug filed against our code, as
> we're still using #2), it'd be helpful to spell that purpose out
> (I was unable to find anything in protocol-11 that supported the need
> for this particular restriction, though it's possible I missed
I don't think the Extended IS Reachability TLV is particularly
wasteful. In the common case, both the TLV #2 and #22 data for an
adjacency is 11 bytes long so 23 will fit into a TLV for either.
I think the primary motivation for the 24 bit metric per adjacency in
the Extended IS Reachability TLV is that you have only 6 bits of
default metric per adjacency in the original IS Reachability TLV (it's
an octet but one bit is used up to indicate internal/external and one
bit is now the up/down bit [RFC 2966]). A 6 bit integer metric (1 to
63) is very coarse and is insufficient to express the relative costs
of a 10 megabit versus a 1 gigabit link, let alone the existing 10
gigabit links and the 40 and 100 gigabit links under development. [RFC
3784] Given this problem, mandating the Extended IS Reachability TLV
seems reasonable to me do you can have a globally consistent link
speed derived metric.
> Second issue: the following mechanism from protocol-11 seems to be
> 6.6 Per VLAN appointed forwarder status lost counter (see Section
> The protocol draft doesn't seem to indicate how large this counter
> needs to be (is 8 bits enough or would more be better?), but I think
> this should be added into the existing "2.d VLANs and Bridge Roots"
Yes, draft-eastlake-trill-rbridge-isis is no longer being updated. The
plan is for all the TRILL IS-IS TLV and sub-TLVs to be added to the
draft-ward-l2isis draft. I'll check that this is being included in
> James Carlson, Solaris Networking <james.d.carlson at sun.com>
> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
Donald E. Eastlake 3rd +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3 at gmail.com
More information about the rbridge