Subject: Re: Is HoldingMultiplier=10 a good value?/also up-down hierarchy bit

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Wed, 28 Apr 1999 20:22:54 -0400 (EDT)

Do we want to tell 10589 to change the HoldingMultiplier=constant 10
thing so that if someone wants to make two parameters, or make
the multiplier 3 they won't fail a conformance test?
****************************************************

Re Tony's reply to me about this:
	
	|  I'm also confused about how a router knows whether one area is up
	|  or down with respect to another.
	
	Relevant quote:
	
		If a prefix is redistributed from a higher level to a lower 
level
		(e.g. level two to level one), the bit shall be set to 1, to
		indicate that the prefix has travelled down the hierarchy.
	
	Is this not clear?

****************
What I'm confused about is how a router knows what level things are.
The 10589 spec also seems overly constrained in that you know you're
either level 1, level 2, or both. If you want arbitrary levels of
hierarchy, would you be configured to know that you're level 5? And
is the level per interface, or is a router a specific level?

The goal seems to be a mostly tree-like thing with arbitrary levels
of hierarchy. Flexibility would allow an area to connect to multiple
parents with no problem, and a single shortcut. You could pretty
much build whatever you want with this, and not get count-to-infinity
behavior.

I think what I'd recommend is that a router is allowed to be in
multiple areas, (kind of like the NLSP thing), where it's told that
these ports are area X, these are area Y, these are area Z, and then
it would be configured with an ordering for these. For instance, X is an
ancestor of Y,
X is an ancestor of Z, Y and Z are incomparable. That means that Y <-> Z is a 
shortcut, allowed in either direction, a lateral thing, whereas
X to Y or X to Z is "down". A lateral is allowed only when the flag is
clear, and it sets the flag. Down is always allowed (and sets the flag).
Up is only allowed when the flag is clear.

You don't want it to be the case that originally you have

           B
          / \
          A  C
where A anc D are at the same level, but then if someone makes more
levels under C the rules change.

Radia

---

From: Tony Li <[email-masked]>
Date: Wed, 28 Apr 1999 17:49:00 -0700 (PDT)

|  Do we want to tell 10589 to change the HoldingMultiplier=constant 10
|  thing so that if someone wants to make two parameters, or make
|  the multiplier 3 they won't fail a conformance test?

I don't want to tell anyone to do anything.  ;-)

|  What I'm confused about is how a router knows what level things are.

Well, a prefix is learned via an LSP.  That LSP is part of the link state
database for an area.  That area is at a particular level.

|  The 10589 spec also seems overly constrained in that you know you're
|  either level 1, level 2, or both. If you want arbitrary levels of
|  hierarchy, would you be configured to know that you're level 5? And
|  is the level per interface, or is a router a specific level?

IS-IS (as of the base spec) is quite consistent in that a router can
participate in multiple levels and is configured to know those levels.
More generally, I would expect us to constrain the router to operate in one
area at each level, and that all of the areas need to be contiguous.  This
would imply that a router couldn't participate in levels 1, 3, and 5.  

|  The goal seems to be a mostly tree-like thing with arbitrary levels
|  of hierarchy.

Correct.

|  Flexibility would allow an area to connect to multiple
|  parents with no problem, and a single shortcut. You could pretty
|  much build whatever you want with this, and not get count-to-infinity
|  behavior.

Dunno about the multiple parents, but yes, this proposal is not subject to
count-to-infinity.

|  I think what I'd recommend is that a router is allowed to be in
|  multiple areas, (kind of like the NLSP thing), where it's told that
|  these ports are area X, these are area Y, these are area Z, and then
|  it would be configured with an ordering for these. For instance, X is an
|  ancestor of Y,
|  X is an ancestor of Z, Y and Z are incomparable. That means that Y <-> Z
|  is a  
|  shortcut, allowed in either direction, a lateral thing, whereas
|  X to Y or X to Z is "down". A lateral is allowed only when the flag is
|  clear, and it sets the flag. Down is always allowed (and sets the flag).
|  Up is only allowed when the flag is clear.

Seems quite complicated.

|  You don't want it to be the case that originally you have
|  
|  
|             B
|            / \
|            A  C
|  where A anc D are at the same level, but then if someone makes more
|  levels under C the rules change.

I think you mean A and C.  ;-)

Of course, if C is level 1, you have an issue.

Tony

---

From: Henk Smit <[email-masked]>
Date: Thu, 29 Apr 1999 16:59:33 +0200 (MET DST)

Radia,

> What I'm confused about is how a router knows what level things are.

  It is manually configured to know in which areas is has to perform.
 Just like today with 2 levels.

> hierarchy,

  We don't want arbitrary levels, we want just 8 levels.

> would you be configured to know that you're level 5? And

  Both.

> of hierarchy.

  As we explained you before, yes, that is the goal.
 The goal is not an arbitrary connection of areas with DV between them.
 NLSP has proven that that is a bad idea.

> Flexibility would allow an area to connect to multiple
> parents with no problem,

  Correct.

> and a single shortcut.

  If you mean by shortcut, the ability to inject the IP prefixes
 of another area at the same level: there can be shortcuts with
 an arbitrary number of other areas at the same level.

> You could pretty much build whatever you want with this,

  Basically the topology is still hierarchical, but the shortcuts
 allow for a little more flexibility. I think the network designs
 that will follow from these limitations will still be powefull
 and flexible enough to build good networks.

> and not get count-to-infinity behavior.

  Indeed, avoiding count-to-infinity is a design goal.

> multiple areas,

  ISO 10589 says that each router must be in exactly one level-1 area.
 But of course a router can be in two levels. If you see the L2
 backbone as just another area, then you are right.
 Of course an implementor is free to implement multiple virtual
 level-1 routers in different level-1 areas in one physical box.

> (kind of like the NLSP thing), where it's told that
> these ports are area X, these are area Y, these are area Z,

  Just like ISO 10589 allows a router to have its interfaces
 configured in level-1-only, level-2-only or level-1-2 mode.

> and then it would be configured with an ordering for these.
> For instance, X is an ancestor of Y, X is an ancestor of Z,
> Y and Z are incomparable. That means that Y <-> Z is a 

  I agree with Tony, this explanation seems a bit complex.
 Just configure routers and interfaces to be in any of the 8 possible
 levels. That's enough.

    Radia,

  When I read ISO 10589 the first time (about 3 years ago), I noticed
 how easy IS-IS could be adjusted to multiple levels. All you need
 to do is:

   cat iso10589.txt | sed 's/level-2/level-3/' \
                    | sed 's/level-1/level-2/' \
                    | sed 's/level-1-2/level-2-3/' > three-levels.txt

  Poof, and you're done. All text makes sense. The attached bit in
 level-2 LSPs gets a meaning. TLV types stay the same.
 The only thing that requires a little attention is the fact
 that 10589 and rfc1195 do not allow certain TLVs in level-1 LSPs,
 but this mostly affects CLNS routing, not IP routing. We can just
 say that all TLVs that are allowed in level-2, are also allowed
 in higher levels. And then we need new packet numbers for L3 LSPs,
 L3 IIHs, L4 LSPs, etc. As Tony Li has said, we (the IS-IS IETF WG)
 can just pick those numbers when we need them.

  When we came up with the up/down bit in draft-ietf-isis-traffic-00.txt
 we intentionally did it in a way that it could be used with more
 then 2 levels. We did the same in draft-ietf-isis-domain-wide-01.txt.

  I am a little amazed that you, as one of the people who contributed
 to 10589, do not see that 10589 was already written to be expanded to
 multiple levels. If you look at the circuit-type in the IIHs, those
 are already defined as 8 bits. The PDU type has enough bits reserved
 to allow for enough packets for 8 levels. Only the is-type in the
 LSPs has 2 bits. For the rest the protocol seems ready for 8 levels.

  So IMHO we don't need much discussion on how to do more then 2 levels
 of hierarchy. It speaks for itself. All that is needed now are
 implementations.

    Kind regards,

        Henk.