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

[Donald Eastlake]

There is actually one other reason to mandate use of the Extended IS
Reachability TLV: In the protocol specification provisions related to
ports configured as "access ports", it says that if an RBridge detects
adjacency to another RBridge on an access port, it should "not report"
that adjacency to avoid TRILL data frames being routed that way. The
ability to "not report" an adjacency you have detected seems like a
much bigger change than to just say that, for access ports, report
adjacencies as having metric 2**24 - 1. The Extended IS Reachability
TLV specification provides that links with that exact maximum cost
value MUST NOT be used in shortest path first calculations, thus
achieving the desired effect of being sure that TRILL data frames will
not be routed over them. This facility is not available with the
original narrow metric TLV.

Thanks,
Donald

On Wed, Feb 25, 2009 at 12:25 PM, James Carlson <james.d.carlson at sun.com> wrote:
> mike shand writes:
>> <br>
>> I don't see the benefit of using the narrow metrics, especially when
>> you take into account the not inconsiderable pain of moving to wide
>> metrics as and when it becomes necessary. Since this is effectively
>> starting with a clean sheet, I would have thought it much better to
>> mandate wide metrics and stick to them. I don't know of anybody who has
>> wanted to migrate back from wide metrics to narrow metrics. <br>
>> <br>
>> &nbsp;&nbsp;&nbsp; Mike<br>
>
> I don't see it as an issue of migrating -- that's something that
> deployers need to determine, and is described in some detail in RFC
> 3787 -- but rather whether it's _necessary_ for TRILL
> interoperability.
>
> If there were some reason that TRILL would fail to function correctly
> with all nodes using the old 6-bit default metric, then that'd be a
> good reason to outlaw its use.  However, merely observing that there's
> a new metric that everyone "should" be using doesn't actually mean
> that it _must_ be used in order to achieve interoperability.
>
> --
> 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