Subject: [Isis-wg] Re: New Internet-Draft

From: "Amir H." <[email-masked]>
Date: Thu, 18 Jan 2001 14:39:02 -0000

Tony,

I see your point. The way I see it there are two possibilities:
1. Either not advertise adjacencies in extended LSPs, and then we might run
out of fragments in situations of numerous adjacencies with various
information attached to them.
2. Change the text to allow advertisements of adjacencies in extended LSPs,
but also insert a zero-cost adjacency between the original and its extended
LSP in BOTH directions (something the first option can avoid). It was
pointed out that some implementations might not behave well with these
zero-cost dijkstra loops.

I prefer the second option, but included only the first in the text, because
backwards compatibility is IMHO an important issue here. If others can
comment on the problems zero-cost loops might introduce, it would help.

Thanks.

--
Amir Hermelin   mailto:[email-masked]
Charlotte Networks Inc.   http://www.cwnt.com

----- Original Message -----
From: "Tony Li" <[email-masked]>
To: "Amir H." <[email-masked]>
Sent: Thursday, January 18, 2001 7:18 AM
Subject: Re: New Internet-Draft

>
> Amir,
>
> This makes sense if you can guarantee that all adjacencies are advertised
under
> the original system ID.  Isn't there an issue here if there are many TE
> adjacencies, each of which is consuming a full TLV?  Let's say you manage
to put
> 250 bytes per adjcency into the LSP.  Then each fragment holds 6
adjacencies.
> Seems like you still run out of fragments.
>
> Tony
>
>
> "Amir H." wrote:
>
> > Tony,
> >
> > I hope I understood the problem correctly. This could indeed be a real
> > problem, so the document suggests not using the extended system-ids for
any
> > hello advertisements. So, taking your example, C would never form an
> > adjacency to V, only to B, and it would not know, in fact, that V and B
are
> > the same physical router. The only one advertising an adjacency to V
would
> > be B then ( I think I should mention that in the text - good point ).
Hence,
> > the SPF would run correctly.
> >
> > Thanks,
> >     Amir.
> >
> > --
> > Amir Hermelin   mailto:[email-masked]
> > Charlotte's Networks LTD.   http://www.cwnt.com
> >
> > ----- Original Message -----
> > From: "Tony Li" <[email-masked]>
> > To: "Tony Przygienda" <[email-masked]>
> > Cc: "Amir H." <[email-masked]>; "Antoni Przygienda" <[email-masked]>
> > Sent: Friday, January 12, 2001 9:38 AM
> > Subject: Re: New Internet-Draft
> >
> > >
> > >
> > > I agree.  Please proceed.
> > >
> > > I see one gotcha, I think.  Please check this:
> > >
> > > I believe that you want a metric of zero, not max metric when going
from
> > the virtual
> > > system back to the primary.  Thought experiment:  Suppose that we have
> > routers A, B, C
> > > and virtual router V off of B.  Suppose that the topology is:
> > >
> > >         A --- B --- C
> > >
> > > Suppose that C shows up as an adjacency for V.  How does C SPF back to
A?
> > >
> > > Tony
> > >
> > >
> > > Tony Przygienda wrote:
> > >
> > > > "Amir H." wrote:
> > > >
> > > > > Abstract
> > > > >
> > > > >    This document describes a mechanism to allow a system to
originate
> > > > >    more than 256 LSP fragments, a limit set by the original
> > Intermediate
> > > > >    System to Intermediate System (IS-IS) Routing protocol, as
> > described
> > > > >    in ISO 10589.  This mechanism can be used in IP-only, OSI-only,
and
> > > > >    dual routers.
> > > >
> > > > gave it a quick look-over and
> > > > looks good to me. If Tony's happy with it, we can make it actually a
> > workgroup
> > > > draft since it looks relevant and hacky enough ;-))  Seriously, yes,
> > it's something
> > > > we could run into and it's optional so it can't hurt to document it.
> > > >
> > > >     -- tony
> > >
> > >
> > >
>

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Tony Li <[email-masked]>
Date: Thu, 18 Jan 2001 22:59:17 -0800 (PST)

| I see your point. The way I see it there are two possibilities:
 | 1. Either not advertise adjacencies in extended LSPs, and then we might run
 | out of fragments in situations of numerous adjacencies with various
 | information attached to them.

I see this as not solving the issue that needs to be solved.  If you're not
putting adjacencies in those LSPs, then what are you putting there?  I
think we all know that loading them up with routes isn't exactly going to
scale well.

 | 2. Change the text to allow advertisements of adjacencies in extended LSPs,
 | but also insert a zero-cost adjacency between the original and its extended
 | LSP in BOTH directions (something the first option can avoid). It was
 | pointed out that some implementations might not behave well with these
 | zero-cost dijkstra loops.
 | 
 | I prefer the second option, but included only the first in the text, because
 | backwards compatibility is IMHO an important issue here. If others can
 | comment on the problems zero-cost loops might introduce, it would help.

I would be very impressed to find such an implementation (that's not to say
that there isn't one... ;-).  To cause a loop within the SPF, the
implemenation would have to be confused as to whether the extended LSP and
its parent were still candidates or on the tree.  Most implementations are
quite explicit about this.

Such an implementation is likely to fall over with even one zero cost
adjacency, IMHO.

I'm fairly sure that I can point to three implementations that won't have
this problem.  ;-) ;-) ;-)

Tony

---

From: "Amir H." <[email-masked]>
Date: Sun, 21 Jan 2001 14:52:34 -0000

> this problem.  ;-) ;-) ;-)

I can point to another one ;-)

So, if no one has an objection (like I said, I certainly don't), then I'll
change the text to enable inclusion of adjacencies in extended LSPs and zero
cost loops. I simply was under the, apparently mistaken, assumption that
implementations could fail over this.

Thanks.

---

From: Mike Shand <[email-masked]>
Date: Mon, 22 Jan 2001 10:47:46 +0000

>implementations could fail over this.

So if we assume that all implementations deal correctly with zero cost 
loops and non-pseudonode zero cost links, don't we still have a problem 
with the backwards connectivity check on non-pseudonode adjacencies? Or are 
you intending that somehow we advertise the extended ID in the pt-pt hellos 
and hence get the neighbor to claim an adjacency to the extended ID and not 
to the original ID.

---

From: "Amir H." <[email-masked]>
Date: Mon, 22 Jan 2001 14:33:04 -0000

> and hence get the neighbor to claim an adjacency to the extended ID and
not

Yes, that's the idea. Currently the text forbids advertising the extended id
in order to satisfy the two-way check; advertising adjacencies in extended
LSPs would have this restriction removed. Note, that it still stays
backwards compatible; a neighbor doesn't have to know what other system ids
you're using, as long as you advertise an lsp for the system-id he knows
you're using.

---

From: Naiming Shen <[email-masked]>
Date: Wed, 24 Jan 2001 22:55:08 -0800

You will at least have problems for ECMP in some cases if there
exists zero metric p2p links between systems. The behaviour of Dijkstra
would be non-deterministic in terms of load sharing.

	Look at a simple example below:
 
    +------+                 +--------+
    |      | x               |        |
    |      +-----------------+   B    |-- r1
    |      |                 |        |
    |  A   |                 |========|
    |      | y               |        |
    |      +-----------------+   B"   |-- r2
    |      |                 |        |
    +------+                 +--------+
 
        A and B are connected with p2p links with equal cost on x and y.
If B" is the same as B, then the prefixes r1 and r2 belong to the same
LSP set as you called it. For A to reach r1 or r2, it will use both x and
y. In the case of B" is B's extended system and there is a zero metric
link between B and B", the load sharing is non-deterministic. It depends
on whether B or B" is put onto the PATH first. If B is put on the PATH
first, then A only uses x to reach r1, but will use x and y to reach r2.
On the other hand, if B" is put on PATH before B, then A only uses y to
reach r2, but will use x and y to reach r1.

thanks.

 ]>
 ]> I would be very impressed to find such an implementation (that's not to
 ]say
 ]> that there isn't one... ;-).  To cause a loop within the SPF, the
 ]> implemenation would have to be confused as to whether the extended LSP and
 ]> its parent were still candidates or on the tree.  Most implementations are
 ]> quite explicit about this.
 ]>
 ]> Such an implementation is likely to fall over with even one zero cost
 ]> adjacency, IMHO.
 ]>
 ]> I'm fairly sure that I can point to three implementations that won't have
 ]> this problem.  ;-) ;-) ;-)
 ]>
 ]> Tony
 ]
 ]I can point to another one ;-)
 ]
 ]So, if no one has an objection (like I said, I certainly don't), then I'll
 ]change the text to enable inclusion of adjacencies in extended LSPs and zero
 ]cost loops. I simply was under the, apparently mistaken, assumption that
 ]implementations could fail over this.
 ]
 ]Thanks.
 ]
 ]--
 ]Amir Hermelin   mailto:[email-masked]
 ]Charlotte Networks Inc.   http://www.cwnt.com
 ]
 ]
 ]_______________________________________________
 ]Isis-wg mailing list  -  [email-masked]
 ]http://external.juniper.net/mailman/listinfo/isis-wg

- Naiming

---

From: mike shand <[email-masked]>
Date: Thu, 25 Jan 2001 10:22:00 +0000

>would be non-deterministic in terms of load sharing.

Its not just non-deterministic, its broken. i.e. where you SHOULD get both 
path splits, you only get one (and which one you get is non-deterministic).

This is a pathological case of the more general problem introduced by zero 
cost arcs. When we first introduced them FROM pseudonodes (to avoid the 
double cost) we solved that problem simply by requiring that pseudonodes be 
given priority over otherwise equal cost nodes when choosing the lowest 
cost from TENT for putting into PATHS, (and in the context of the present 
hack we would hope that implementations give the same treatment to ANY node 
which has zero cost links in its LSPs, though I'm skeptical as to whether 
an implementation would have the foresight to do that -- or was the 
intention that these  would always be pseudonodes in the sense that the 
pseudonode identifier is non-zero?).

However that simple fix was based on the assumption (correct at the time) 
that you would never have a zero cost arc both into and out of the same 
node.  It is that fundamental assumption which is broken by this proposed 
change. Its a chicken and egg situation. We both need to give B' priority 
in putting it into PATHS so that we can explore its potential zero cost 
links, AND make sure that we have explored any zero cost links TO it BEFORE 
we put it in PATHS.

I imagine that we could modify the SPF algorithm to deal with this (e.g. by 
selectively permitting additions to the adjacency set of nodes already on 
PATHS, or by unwrapping the zero cost links onto TENT, while keeping track 
of possible loops), but that is not the point. The whole rationale for this 
proposal is that we can allow certain nodes to expand their LSP set WITHOUT 
requiring any changes in the other nodes, and in particular any changes to 
their SPFs.

So I guess the question is, do we care about the failure to make use of 
potential path splits? I think we do.

         Mike

---

From: Tony Li <[email-masked]>
Date: Thu, 25 Jan 2001 10:03:15 -0800 (PST)

| I imagine that we could modify the SPF algorithm to deal with this (e.g. by 
 | selectively permitting additions to the adjacency set of nodes already on 
 | PATHS, or by unwrapping the zero cost links onto TENT, while keeping track 
 | of possible loops), but that is not the point. The whole rationale for this 
 | proposal is that we can allow certain nodes to expand their LSP set WITHOUT 
 | requiring any changes in the other nodes, and in particular any changes to 
 | their SPFs.
 | 
 | So I guess the question is, do we care about the failure to make use of 
 | potential path splits? I think we do.

I concur.  And I agree that a solution that required no changes to existing
systems would be preferable.  Any suggestions?

Tony

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 25 Jan 2001 09:34:10 -0800

> systems would be preferable.  Any suggestions?

that's shortcut thinking here possibly but why can't we make sure that ALL
the links to a specific node are being advertised by the same 'fake'-node in
the implementations of the draft ?  Actaully, it's probably nuff to say that
ALL THE LINKS TO SAME NODE WITH SAME COST have to be included in the TLVs
of the same 'fake'-node.
Yes, it's quite a restriction for a specific implementation of the "hack" but doable and
would not affect the old-style nodes.

    hope I'm clear enough and didn't jump the fence
    before my first morning coffee here ;-)

    --- tony

---

From: Naiming Shen <[email-masked]>
Date: Thu, 25 Jan 2001 12:22:04 -0800

it does not help. as long as there exists equal cost paths from A to B,
A and B does not have to be directly connected, it can have other nodes
between them, it will have the same problem just as they are directly
linked.

 ]Tony Li wrote:
 ]
 ]>  | I imagine that we could modify the SPF algorithm to deal with this (e.g.
 by
 ]>  | selectively permitting additions to the adjacency set of nodes already o
n
 ]>  | PATHS, or by unwrapping the zero cost links onto TENT, while keeping tra
ck
 ]>  | of possible loops), but that is not the point. The whole rationale for t
his
 ]>  | proposal is that we can allow certain nodes to expand their LSP set WITH
OUT
 ]>  | requiring any changes in the other nodes, and in particular any changes 
to
 ]>  | their SPFs.
 ]>  |
 ]>  | So I guess the question is, do we care about the failure to make use of
 ]>  | potential path splits? I think we do.
 ]>
 ]> I concur.  And I agree that a solution that required no changes to existing
 ]> systems would be preferable.  Any suggestions?
 ]
 ]that's shortcut thinking here possibly but why can't we make sure that ALL
 ]the links to a specific node are being advertised by the same 'fake'-node in
 ]the implementations of the draft ?  Actaully, it's probably nuff to say that
 ]ALL THE LINKS TO SAME NODE WITH SAME COST have to be included in the TLVs
 ]of the same 'fake'-node.
 ]Yes, it's quite a restriction for a specific implementation of the "hack" but
 doable and
 ]would not affect the old-style nodes.
 ]
 ]    hope I'm clear enough and didn't jump the fence
 ]    before my first morning coffee here ;-)
 ]
 ]    --- tony
 ]
 ]
 ]

- Naiming