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

From: James Carlson <[email-masked]>
Date: Thu, 19 Feb 2009 15:11:11 -0500

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

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.

-- 
James Carlson, Solaris Networking              <[email-masked]>
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
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 25 Feb 2009 00:09:45 -0500

Jim,

Thanks for review this. See below...

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

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

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

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 25 Feb 2009 11:33:22 -0500

Hi Jim,

On Wed, Feb 25, 2009 at 11:16 AM, James Carlson <[email-masked]> wrote:
> Donald Eastlake writes:
>>...
> That's a great argument for why one *should* use the newer metric
> scheme.  What's the argument for an effective "must"?

OK, unless other people speak up, it should be changed to SHOULD.

>...

Thanks,
Donald

---

From: James Carlson <[email-masked]>
Date: Wed, 25 Feb 2009 11:16:00 -0500

> adjacency is 11 bytes long so 23 will fit into a TLV for either.

OK; maybe "wasteful" is too strong.  "Needless" is better.

> draft-ward-l2isis draft. I'll check that this is being included in

OK; thanks.  That sounds good.

---

From: mike shand <[email-masked]>
Date: Wed, 25 Feb 2009 17:09:07 +0000

Donald Eastlake wrote:

Hi Jim,

Donald Eastlake writes:

...

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.

Mike

...

Thanks,
Donald

---

From: James Carlson <[email-masked]>
Date: Wed, 25 Feb 2009 12:25:40 -0500

mike shand writes:
> <br>
> 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.

---

From: Radia Perlman <[email-masked]>
Date: Wed, 25 Feb 2009 10:45:28 -0800

Actually, I agree with Mike. Just seems complicated and an opportunity 
for noninteroperability to have
two formats for metrics. I have long regretted doing the narrow metrics 
in the first place.
TRILL for IS-IS is an opportunity to get rid of things that, in the 
wisdom of 25 years, we would
have decided differently.

Radia

---

From: James Carlson <[email-masked]>
Date: Wed, 25 Feb 2009 13:59:31 -0500

> have decided differently.

It still seems like an unnecessary restriction for job at hand, but if
that's the general consensus, then my complaint really is a fairly
minor one, and I'd be ok with leaving it as-is.  (For what it's worth,
I doubt that anyone's writing IS-IS from scratch to do this, so the
"opportunity" really is just at the spec level.  Implementations will
almost certainly be carrying around ancient luggage for some time to
come.)

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 25 Feb 2009 14:48:53 -0500

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

---

From: James Carlson <[email-masked]>
Date: Wed, 25 Feb 2009 15:10:55 -0500

> adjacencies as having metric 2**24 - 1. The Extended IS Reachability

That's what I was looking for.  Yes, that's a clear reason to mandate
the use of the newer TLV.  (It wouldn't be bad to cite that case as a
rationale in whatever future document ends up holding this text.)

---

From: James Carlson <[email-masked]>
Date: Wed, 25 Feb 2009 13:59:31 -0500