Subject: Re: Questions about hierarchy

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Tue, 6 Oct 1998 15:56:01 -0400 (EDT)

One quick aside. No modern spec? Is it usual to have
a working group discussing a protocol in which there's
no good spec? Does this working group want to write one?
Is it not a problem for some reason?
*******************
Back to hierarchy:

I'm not sure people understood what I wrote before, which
'm not sure people understood what I wrote before, which
isn't surprising since I think it really takes a few
pictures and I hate these little ASCII pictures, both
drawing them and trying to figure them out.

If there's any interest, I could give a short presentation
on it at the working group meeting at IETF. Are there other
things to discuss there?

But quickly, let me make a few points.
a) Again, the notion of only injecting "*" into "level 1" is
an artifact of CLNP, where level 1 routing was drastically
different from level 2, since it was based on a different part
of the address, and was exact match rather than longest prefix.
With IP, there's no reason to treat "level 1" any differently
than any other level. If some boundary router to an area claimed
it could reach all addresses that started with 792*, the IP level
1 routers in that area would just route towards that boundary
router (presuming that all IP destinations are advertised as
[address,mask] or [prefix length,prefix]).

b) I don't understand "level skipping". These things sound like
constrained special cases, and therefore more complex. The thing
I was saying was that any boundary router can be configured to
advertise any prefix. If you are attached to something which is
37*, but the addresses of the form 378* are closer to one boundary
router and 379* to a different boundary router in the same area,
then you could have one router advertise both 37* and 378* and the other
one advertise both 37* and 379*. And there's no reason you can't
hook a "level 2" thing into a "level 7" thing. Routers would
be completely unaware about what "levels" they are. You just decide
what address ranges to advertise, on a per-boundary router basis.

c) If the above makes you hide under your table at the configuration
required, there should be an "area address", which is the set of
prefixes that summarize that area. If people assign area addresses
correctly, meaning that all the addresses in the area correspond to
the area address, then there's no configuration beyond that. The
boundary routers advertise the prefix for the area address into
adjacent areas.

Radia

---

From: Tony Li <[email-masked]>
Date: Tue, 6 Oct 1998 13:24:34 -0700 (PDT)

|  One quick aside. No modern spec? Is it usual to have
|  a working group discussing a protocol in which there's
|  no good spec? Does this working group want to write one?
|  Is it not a problem for some reason?

There's a fine spec from '92.

This working group does NOT get to superceed ISO on writing the spec, tho
I'm told that we are welcome to submit contributions as a liason
organization.  

|  *******************
|  Back to hierarchy:
|  
|  I'm not sure people understood what I wrote before, which
|  isn't surprising since I think it really takes a few
|  pictures and I hate these little ASCII pictures, both
|  drawing them and trying to figure them out.
|  
|  If there's any interest, I could give a short presentation
|  on it at the working group meeting at IETF. Are there other
|  things to discuss there?

There will be many.

|  b) I don't understand "level skipping". 

Perhaps that should be one of them.  ;-)

|  c) If the above makes you hide under your table at the configuration
|  required, there should be an "area address", which is the set of
|  prefixes that summarize that area. If people assign area addresses
|  correctly, meaning that all the addresses in the area correspond to
|  the area address, then there's no configuration beyond that. The
|  boundary routers advertise the prefix for the area address into
|  adjacent areas.

That's exactly what level skipping is out to prevent, as that causes
localized suboptimality.

Tony

---

From: Mike Shand <[email-masked]>
Date: Wed, 07 Oct 1998 08:12:46 +0100

>I'm told that we are welcome to submit contributions as a liason

ISO has a draft for V2 of 10589. I've glanced at it and it is full of
errors, both editorial and much more worryingly, technical. I'm not sure if
we could/should still base 'integrated' IS-IS on the old V1 spec if the V2
spec gets approved, but we need to make sure we can either ignore it
completely or do something to fix it.

	Mike

---

From: Tony Li <[email-masked]>
Date: Wed, 7 Oct 1998 00:31:27 -0700 (PDT)

|  ISO has a draft for V2 of 10589. I've glanced at it and it is full of
|  errors, both editorial and much more worryingly, technical. I'm not sure if
|  we could/should still base 'integrated' IS-IS on the old V1 spec if the V2
|  spec gets approved, but we need to make sure we can either ignore it
|  completely or do something to fix it.

I've heard about this, but not yet seen it.  My hope is that we will get a
copy of it and we will be allowed to make a 'liason organization
contribution' to its development.

It's clear that the existing integrated IS-IS text is based on the old V1
spec and we can presumably can continue to work on top of that if V2 is not
acceptable.

Tony

---

From: Antoni Przygienda <[email-masked]>
Date: Thu, 08 Oct 1998 00:45:06 -0400

> spec and we can presumably can continue to work on top of that if V2 is not

fixing/extending/documenting V1 version would be a good thing before
worrying about 
V2 too much. If they have bugs there, we'd need them fixed before
working of it at all, 
I cannot imagine IETF publishing OSI erratas ;-) 

		thanks 

		---- tony