Subject: Re: [Isis-wg] draft-isis-pseudo-perlman-roy-thomas-00.txt

From: [email-masked]
Date: Tue, 04 Mar 2008 14:02:24 -0800

Hi Dave,

In the case of TRILL, there's no "not backwardly compatible" issue, because there is no IS-IS for TRILL
deployed, so if we put this in, all RBridges would implement it.

50% more nodes in what will become an increasingly more common topology (all bridges replaced by RBridges)
is not trivial.

Requiring configuration to sort out which ports are pt-to-pt and which aren't is also not trivial.

The proposal though, does seem to be technically trivial (R1 and R2 report links to each other instead of
to a pseudonode in the 2-RBridge case), especially if it's only implemented in the TRILL context, and therefore
there is no issue of backward compatibility (though the advertisement of this capability means, I think, that
backward compatility isn't a problem even in the non-TRILL case.

Radia

----- Original Message -----
From: Dave Katz <[email-masked]>

> 
> There was a proposal a few months back for a stripped down OSPF 
> that  
> was supposed to be so much easier to implement, except that it was 
> 
> incompatible with the existing protocol (which everyone has to  
> implement anyhow) and was probably an utterly pointless exercise 
> even  
> if it *was* backward compatible due to the costs to the industry 
> of  
> implementation.  But it was more "efficient."

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: mike shand <[email-masked]>
Date: Wed, 05 Mar 2008 07:51:45 +0000

[email-masked] wrote:

Hi Dave,

Radia,

Why do you think it is not trivial? 50% (and that is an upper bound) of
"not a lot" is less than "not a lot".

In memory it is insignificant compared to the rest of the link state
database, and in computation it amount to perhaps a millisecond of
compute even in quite large networks.

Matthew has already said that the aim of this is NOT to improve
performance, and that seems very reasonable, since the performance
gains ARE trivial.

So why would we bother with this? It seems to me that the complexity of
the solution (and I agree it isn't MUCH complexity) far out ways any
benefit.

Dave's point is very well taken. The cost of ANY change, is very high
in terms of modifying and testing existing implementations. There has
to be a very good reason to embark on that path, and I don't see one
here.

As I said right at the beginning. "If it ain't broke, don't fix it."

Mike

Radia