[rbridge] two minor issues with the isis-02 draft

[Donald Eastlake]

Jim,

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
> here.
>
> (I was unable to find anything in protocol-11 that supported the need
> for this particular restriction, though it's possible I missed
> something.)

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
> missing:
>
>      6.6 Per VLAN appointed forwarder status lost counter (see Section
>          4.6.2).
>
> 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"
> sub-TLV.

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
that transfer.

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

Thanks,
Donald
--
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3 at gmail.com