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

From: mike shand <[email-masked]>
Date: Tue, 26 Feb 2008 13:21:13 +0000

I am still not convinced that the mechanism proposed in this draft is a
good idea.

1. As I have said before, we already have the capability to describe a 2
node pt-pt "LAN" as pt-pt links, which not only removes the pseudonode,
but uses the pt-pt update process, no DR election etc. This is a manual
configuration, but I believe that is a benefit since it warns when a
third router is accidentally connected to what is supposed to be a pt-pt
LAN.

2. The proposed mechanism with hysteresis means that the representation
of the network is non-deterministic. i.e. the way the network looks
depends on its previous history.

3. Current network management tools which display the topology will be
unable to distinguish between a 3 node LAN and 3 nodes linked by pt to
pt links. This is exacerbated by the non-determinism.

4. The representation of a 3 node LAN as 3 separate pt-pt links may lead
bandwidth sensitive routing (e.g. the cSPF of MPLS TE) to make wrong
decisions. This is because the single interface onto the LAN will appear
in the link state database as two independent links.

5. The mechanism actually results in an increase in the number of LSPs
which need to be flooded as nodes are attached and removed from the LAN.

Consider the normal case. Going from 2 to 3, 3 to 4, 4 to 3 and 3 to 2
nodes requires 2, 2, 2 & 2 new LSPs respectively. i.e. in each case the
new LSP of the attached/detached node, and a new version of the
pseudonode LSP.

In the proposed case, using hysteresis, the same  sequence requires 3,
5, 2 and 3 (plus a purge of the pseudonode).

i.e. 8 changed LSPs for the normal case, and 14 for the proposed case.

All considered, this seems like additional complexity, both in terms of
implementation and in terms of manageability and impact on existing
mechanisms, for very little gain.

We need to very carefully assess with the wider community the full
ramifications of making this change to a widely deployed protocol
because there may be many other subtle dependencies of which we are not
yet aware.

    Mike

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 27 Feb 2008 00:40:22 -0800

I am in full agreement with Mike.

My sense of the proposal is that it is a "solution in search of a
problem".

I have read the draft carefully looking for a problem statement. The
closest I found was the following non-specific sentence in the
Introduction:

"It would be wasteful to represent such a link as a pseudonode."

What Mike has meticulously demonstrated in earlier discussion on this
topic on the trill mailing list and amended by his post below is that:

a)The set of cases in which the suggested protocol extension has any
efficiency gain (memory or SPF speed) is restricted to the 3 router case

b)The efficiency gain in the three router case is very small

c)The proposal increases complexity

d)The proposal introduces inefficiency in the transition cases

e)The proposal may break usage of the link for TE purposes

To justify consideration of the proposal it seems to me that it must be
compellingly demonstrated that the efficiency gain in the isolated case
where it exists actually addresses a real scalability problem in a
deployed network. Otherwise, we are simply tinkering - which introduces
risk without offering any substantive reward.

In short, there are multiple good reasons NOT to pursue this ("if it
ain't broke don't fix it", Occam's Razor...).

   Les

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Mike Shand (mshand)
> Sent: Tuesday, February 26, 2008 5:21 AM
> To: [email-masked]
> Subject: [Isis-wg] draft-isis-pseudo-perlman-roy-thomas-00.txt
> 
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Radia Perlman <[email-masked]>
Date: Wed, 27 Feb 2008 15:46:45 -0800

Interesting arguments, Mike.

As you said, this wouldn't be worth doing for the small advantage in the 
case of 3
routers. The primary advantage is in avoiding pseudonodes in the case of 
2 routers, and to do that in a way that avoids
configuration. This doesn't preclude configuration, and doing whatever 
is done today. But with IS-IS used, basically,
at layer 2 (in TRILL) there will be lots of pt-to-pt links, and more so 
the more than bridges are replaced.
People like the minimal configuration of bridges. And having a topology 
with mostly pt-to-pt links, where someone
does not want to bother configuring every port, default to having a 
pseudonode for every link, would be significantly wasteful.

As for counting the number of LSPs -- you're counting the maximum number 
of LSPs, whereas with hysteresis you'd
seldom switch from pseudonode to non-pseudonode.

Here are a couple of compromise proposals:

a) Start with "no pseudonode". If there are *ever* 3 routers, switch to 
pseudonode, and don't switch back, if you, as DR, ever remember
there having been 3 routers.

b) As with the original proposal, but have the threshold be "1" and "3". 
In other words, if you are the only router, don't create
a pseudonode (which you don't now, unless someone issues an ES-IS Hello, 
right?). If you have one neighbor, then don't
create a pseudonode until you wind up with 3 routers (2 neighbors), in 
which case you create a pseudonode. If one of them
goes down, you keep it a pseudonode. Until both of your neighbors die, 
in which case you stop reporting the link at all, so
therefore, no pseudonode.

Radia

---

From: mike shand <[email-masked]>
Date: Thu, 28 Feb 2008 12:07:06 +0000

Radia Perlman wrote:

I'm not sure I consider an extra 50 or so bytes per link as
*significantly* wasteful.

And if there really are mostly pt-pt links why wouldn't you have the
default configuration to be pt-pt LAN, which removes the periodic CSNP
as well?

Then the only configuration would be if you had a rare case of multiple
routers on a LAN.

Yes, that's true. But if you DO have to switch, the LSP churn is
greater than normal. I'm just trying to show how slim an optimization
this really is.

Always having a psuedonode for n=3 (and above) would remove the
ambiguity about exactly what topology you have. I'd still be a l;ittle
concerned about historical dependency.

But I still think this is all not worth the very small optimization it
gives you.

Mike

Radia

mike shand wrote:

Mike

---

From: Radia Perlman <[email-masked]>
Date: Fri, 29 Feb 2008 13:20:28 -0800

If it's mostly pt-to-pt links, then 50% more nodes does not seem like 
trivial overhead. It's not just bytes. It's also
computation time.

And if people don't want to configure things, what would you want an 
RBridge to do if a 3rd RBridge shows up? If the
answer is, adapt and revert to pseudonode, then it's basically what I'm 
proposing. If it's "always act like fully connected pt-to-pt links
in that case", then things will work, but I worry about the transition 
time when people have very large bridged networks and without
configuration you might wind up with 15-node fully connected topologies.

It's really not complicated to just start with pt-to-pt and then switch 
over when there's more routers, especially if it avoids
configuration.

Radia

mike shand wrote:
> Then the only configuration would be if you had a rare case of 
> multiple routers on a LAN.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 29 Feb 2008 13:53:14 -0800

Radia -

If you cannot guarantee that all LANs will be able to operate in Pt-Pt
mode, then the easy answer to the no configuration requirement is to
operate all LANs in normal mode.

The extra cost of doing so in both the 2 neighbor and 3 neighbor case
has been demonstrated by Mike to be very small (both in memory and CPU)
- a point which you consistently fail to acknowledge - despite your
profuse thanks to Mike for doing the calculations.

   Les

Behalf
> Of Radia Perlman
> Sent: Friday, February 29, 2008 1:20 PM
> To: Mike Shand (mshand)
> Cc: [email-masked]
> Subject: Re: [Isis-wg] draft-isis-pseudo-perlman-roy-thomas-00.txt
>

---

From: James Carlson <[email-masked]>
Date: Fri, 29 Feb 2008 16:51:37 -0500

> trivial overhead. It's not just bytes. It's also

I think this case is interesting because it very likely occurs with a
fully-deployed TRILL network.  In the case of TRILL, because each node
is behaving as a layer 2 bridge, and because 10BASE-[25] are pretty
dead, the links will almost certainly all be connected point-to-point
but (again because this is bridging) using 802 broadcast-type media.

And because this is bridging, and TRILL is meant to replace existing
bridges which generally default to useful settings, zero-configuration
is very highly desirable.  Thus we can't rule out accomodating
occasional (but rare) links that are connected to repeaters or
old-style bridges and thus have three or more nodes on them.

The result is that you very likely get into a case where you've got
almost all point-to-point connections among a large number of nodes
using broadcast-type interfaces.  Each of those (without special
configuration) requires an extra pseudonode, which is (as Radia's
pointing out) a waste of everyone's time, bandwidth, cycles, and
memory.

Perhaps the real argument here is that because the motivation behind
this is tied to artifacts of TRILL deployment, it ought not be made
generic, and instead be made part of the special IS-IS variant used
for TRILL (and any other case where all your Ethernet ports end up
being just point-to-point).

-- 
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
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Dave Katz <[email-masked]>
Date: Fri, 29 Feb 2008 14:47:31 -0800

I missed the beginning of this exchange, but I'm curious as to what  
the *real* (as in "seconds" and "dollars" and "gigabytes" and  
"megabits") costs are that are trying to be optimized.

Last I heard, computational capacity and memory and bandwidth were  
perilously close to being free, so the win has to be really big (in  
real COGS in a real product, or a measurable percentage of bandwidth,  
or a noticeable number of milliseconds in time) to make additional  
complexity worthwhile, especially when traded off against the real  
dollar costs of modifying and testing existing implementations.

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

I'm also reminded of all of the effort put into various partial SPF  
optimizations.  They may make 100,000 node networks work better, but  
SPF isn't the problem in a 100,000 node network.

And heck, a bunch of the complexity in OSPF itself is due to  
optimizations for things that didn't matter a whole lot in 1989 and  
sure don't matter now.  I suppose it kept out the riffraff though.

I have a rule of thumb in coding that says that if the gain isn't  
better than linear, it doesn't really help scaling.

Anyhow, "50%" sounds like a big number, but what does this mean in  
bytes and milliseconds for typical deployments?

--Dave

On Feb 29, 2008, at 1:51 PM, James Carlson wrote:

> James Carlson, Solaris Networking              <[email-masked] 
> >