Subject: Re: [Isis-wg] draft-hermelin-ext-lsp-frags-00.txt

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Tue, 16 Jan 2001 16:32:49 -0500 (EST)

Draft seems very good.

Re Jonathan's question...we don't need this mechanism for getting
beyond the 255 adjacencies. I believe there was an email discussion
on this about 2 years ago(?). The 255 adjacency limit is easier to
fix, since all that matters for the pseudonode ID is that it be
a 7-byte number unique in the area, so a router with ID x can
general pseudonodes x.1 through x.255, but also can use ID y (provided
nobody else in the area is using ID y) and x can claim adjacencies
to y.1 through y.255. There's no reason for the first 6 bytes of
the pseudonode ID to be the same as the DR's ID...it's just a convenient
way of ensuring a unique 7-byte ID.

Comment on section 3.2.1, yeah, the 2-way check would be a problem,
but might it be necessary to have IS neighbors in the extended LSP
if not all the neighbors fit into 255 fragments (like if you're on
a multiaccess medium with thousands of IS neighbors, maybe)? Wasn't
there talk at some point of doing away with the 2-way check? Is it
useful? Is it more of a performance problem than its benefit warrants?

Section 3.2.2...I'm sorry, but I read it several times and I don't
understand that entire section. (But it's only 4 sentences, so
clarifying it wouldn't be too time consuming).
Are you saying ES Neighbors TLV can appear in an
extended LSP or can NOT appear?  And I don't understand "an ES
neighbor TLV with the router's system-ID be inserted in its LSPs". Maybe
I don't understand it because I don't know what "its" refers to. At
any rate, this is probably only a CLNP thing, right?

As for hop counting, I assume that's something totally internal to
an implementation. At any rate, hop counting was never part of the
design of the protocol. So, if it's just a heuristic that some
implementations do for their own purposes, and it's not necessary
for all routers to do the same...perhaps some words about how
a zero-cost link should not count as a "hop" in any such calculation
(presumably the same problem occurs with a pseudonode looking like
an extra hop?).

Radia

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

---

From: "Amir H." <[email-masked]>
Date: Wed, 17 Jan 2001 16:18:20 -0000

> Draft seems very good.

Thanks.

> way of ensuring a unique 7-byte ID.

I agree.

> a multiaccess medium with thousands of IS neighbors, maybe)?

You'd actually need tens of thousands to overflow. I don't think any
implementation would support that many anyway.

> Wasn't there talk at some point of doing away with the 2-way check? Is it

Two of the main considerations here are:
1) To be backwards compatible.
2) To allow previous implementations to use the extended information.
So, adjacencies should be specified only in the original LSPs for the second
goal to be achieved. It is possible to form adjacencies with other systems
using extended system-ids, and therefore advertise these adjacencies in
extended LSPs. This would satisfy the 2-way check, but then a zero-cost
adjacency in BOTH directions must be inserted between the original and
extended LSP. And that might not achieve the first goal (zero-cost dijkstra
loops).

As for removing the 2-way check, IMHO it is useful, and I believe this was
only discussed when advertising uni-directional links, such as FA-LSPs.

> any rate, this is probably only a CLNP thing, right?

Point taken. Bad wording on my part. 10589 section 7.3.7 specifies inserting
an ESN TLV in L1 LSPs, with the system ID of the router. What I meant was
that in extended LSPs the ESN should be generated using the extended
system-id. I'll fix that paragraph. Anyway, you're right, this is only a
CLNP thing.

> (presumably the same problem occurs with a pseudonode looking like

No, I didn't mean anything implementation related, but rather applications
(maybe future ones) external to the IS-IS protocol. For example, a TE
application computing tunnels to a destination x, based on the shortest hop
count. If x would be advertised in an extended LSP, that application might
favor a different path to x because it would believe x is one hop farther,
going through that LSP, than it really is.
These applications should know not to count pseudonode links. They should
also ignore the hop count on the adjacencies to extended LSPs. I just felt I
should put in a word of warning.

> Radia

Thanks again.

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