Subject: more than 255 circuit ID's

From: [email-masked] (Christian E. Hopps)
Date: 18 Apr 1999 20:05:20 -0400

I'm trying to figure out what I need to do to support > 255
circuits.

Is it ok for a P2P's local Circuit ID's to overlap a lan's
ciruict ID?

For broadcast I'm confused by modification to the DIS election
process present in draft-ietf-isis-wg-255adj-00.txt.

Step (d) has been changed and the text about rerunning the DIS
election on reception of any IIH PDU (as long as the info used
for DIS election has changed) was removed.

I don't think this was the intended interpretation so I would
greatly appreciate it if someone could clarify this for me.

Also, it wasn't clear to me why someone would notice the change
to the LAN ID when you changed it.  It would make sense if the
LAN ID were a part of the noted information that caused DIS
election to be rerun on reception of the IIH (i.e., if the LAN ID
advertised by the your idea of the DIS changes rerun DIS
election).  Thats what I've done, and if thats the correct thing
to do it should probably be noted in the draft.

I suspect I may have missed something fundemantal, so please forgive
me if the answers are obvious.

Thanks,
Chris.

---

From: Antoni Przygienda <[email-masked]>
Date: Sun, 18 Apr 1999 22:22:09 -0400

> Is it ok for a P2P's local Circuit ID's to overlap a lan's

p2p circuit ID is not used really anywhere in the spec (well, 
it is but it doesn't matter, read section 2 carefully) & it's 
ok for those to be same on both sides & even 0. So you can use
anything for p2p circuit ID de-facto. Don't forget that for 
reliable detection of 2-way adjacency you want to have Dave's 
modification in it, that will give you larger circuit id field
as well. 

I never thought whether it's ok to overlap the p2p ids and 
lan ids. What I do de-facto is to pick one single value for 
p2p and one that is reserved for lan circuit id before election
and then take all the others for the procedure described 
in broadcast election. 

> process present in draft-ietf-isis-wg-255adj-00.txt.

basically what you do, as long you're not DIS, 
you show a 'pseudo'-unique circuit id to the 
lan since it's not used for anything unless you're DIS. In fact,
you're showing the very value I described above. Once you're DIS,
well, you have to really show a unique circuit ID since otherwise
you may confuse people due to the fact taht the circuit ID becomes
part of LAN ID and taht one is better unique!

> greatly appreciate it if someone could clarify this for me.

otherwise exhibit standard behavior basically means that you still
do what you did in D) before. I may have to massage the draft some. 

> to do it should probably be noted in the draft.

not sure I can follow you here. you don't change the LAN ID, you just 
become DIS so you'll be the one that will determine LAN ID. Since you
first have a non-unique circuit ID, you cannot use it to advertise the
LAN ID so what you do, you change the circuit ID but that makes you
de-facto go away for other routers. Section 3 tells you as well that 
you _shouldn't_ push out gratuitous empty hellos to advertise to people
taht you go away for the said "ripple"-effect, try it and you'll see 
what I mean (have all routers on the ether have the same preference 
in terms of being DIS).

> me if the answers are obvious.

hmm, any proposals to as wording could be improved?

BTW, I didn't answer your original question wheher p2p circuit id and 
lan circuit id can overlap and it is 

"I think so but I'm not that greedy ;-) so I don't do it, it's just one 
	value for p2p and I'm not sure I did think through all possible 
	corner cases for such optimization !"

	thanks 

	=== tony

---

From: [email-masked] (Christian E. Hopps)
Date: 18 Apr 1999 23:18:09 -0400

> what I mean (have all routers on the ether have the same preference 

I think this is where I may be confused.  From my reading of the
standard the local Circuit ID plays no part in the formation of
adjacencies.  IIH's contain a System ID and the LAN ID.  The LAN
ID is set by all routers intially to their System ID concatenated
with their local Circuit ID.  After iSISHelloTimer*2 seconds the router
runs the DIS election, and elects someone (perhaps itself). The
router then uses the LAN ID from the elected DIS in its own IIH PDUs.

The only things I can see that make an adjacency go down are:

        1) the System ID changes
        2) the MAC address changes
        3) the neighbours option fails to mention the receiving
           router
        4) lack of a received hello in Holding Time seconds.
           (this appears to be how items 1 and 2 are triggered,
            becuase the lookup for the adjacency will fail)

If all of this is indeed true, then any router R that was up
before the new DIS or at the same time will have received the IIH
with the non-unique local Circuit ID advertised in the LAN ID
field.  Router R will have already run the DIS election before
the new DIS has updated the LAN ID.

My question was since LAN ID isn't mentioned as one of the things
to watch for when determining if the DIS election needs to be
rerun, the router R from above would have no reason to notice the
change in LAN ID that the DIS has newly advertised.  As I
mentioned above, I actually consider a change in LAN ID by the
DIS as a reason to rerun the DIS election, this basically re-elects
the DIS and copies the new LAN ID.

Again, I suspect I've missed something.  By `go away' from other
routers do you mean that other routers consider their adjacency
with me no longer `up'?  If so why would this occur?

Thanks,
Chris.

---

From: Antoni Przygienda <[email-masked]>
Date: Mon, 19 Apr 1999 00:37:11 -0400

> with me no longer `up'?  If so why would this occur?

Christian, 

long time, no look @ code so let's drill now some into basics:

8.4.1 syas that you first send your SystemID and your local circuit ID 
	out when enabling the circuit. we're using the non-unique here

8.4.5 says what you said and yes, local circuit ID is meaningless for 
	_broadcast_ adjacencies. It says as well that you copy into
	you LANID field the DIS's LANID (not saying when) 
	or your own once you elected DIS. 

so,

1) what I said about "going away" was not smart, I kind of thought about 
the stuff that way since first I was good citizen & pushed out empty
hellos when changing circuit ID. Not smart, but hey, inventing stuff 
is not particularly easy & I learned as a child that you have to be 
curteous when you cheat ;-)  Empty hellos were leading to the "ripple" effect 
and so I'm not sending empty hellos but just on-the-fly change the 
circuit id now. So the adjacencies don't "go-away" anymore, sorry ...

2) now to the implementation details, I'm running the DIS election each tiem 
anyone has a different opinion on what the LANID should be compared to
mine (the receiver's) opinion. I consider that to be part of "f) the set of 
Intermediate system adjacency states;" per 8.4.5 since for me someone's 
choice of LANID is a part of state of the adjacency. That includes the 
circuit id embedded within the LANID ;-). Rather subtle I admit and the 
whole thing is "belts-and-suspenders" interpretation of the spec. I ran tests
with major ISIS implementations and it all worked but hey, it's just my
word here ... 

=> I hope we're in sync now & short answer would be: "yes, you need to take
   LANID change in a hello as something to run DIS election on"
   If someone doesn't than the only safe thing would be to push the empty
   hello out & let the LAN reconverge. More painfull ... Actually, I'm not even 
   sure what will happen, if people miss the circuit ID update in LAN ID. Did you
   think whether that would hurt ? 

	thanks 

	-=-= tony

---

From: [email-masked] (Christian E. Hopps)
Date: 19 Apr 1999 13:21:11 -0400

>    think whether that would hurt ? 

Yeah, I believe that we are doing the same thing.  As to the
problems, I'm just now implementing the DB so I haven't thought
too much about this. :)  Here are my quick thoughts:

Since the LAN ID doesn't effect the DIS election the lan's idea
of which router is DIS won't change.  The only place the LAN ID
appears to be used is in setting the lxCircuitID for that
circuit.  So if the change isn't noticed the circuit will look
disconnected (i.e., the Pseudonode LSP will claim connection to
the routers but the other routers won't claim connection to the
Pseudonode.)

In section 8.4.5 second to last paragraph: ``The LAN ID field in
the LAN IIH PDUs transmitted by this system shall be set to the
value of the LAN ID field reported in the LAN IIH PDU (for the
appropriate level) received from the system which this system
consdiers to be the DIS.  This value shall also be passed to the
Update Process, as the Pseudonode ID, to enable LSPs ..''

I think the standard is sufficiently ambiguous here.  Since thie
paragraph comes right after the talk of DIS election its not
clear that it applies at other times.

However, if people have implemented this such that any change in
LAN ID by the DIS is passed to the Update process then there
appears to be no big problems.  What can happen is that an IS first
originates a new LSP with a connection to the non-unique
Pseudonode ID.  Then it notices that the LAN ID has changed and
will reissue its LSP.  So the only bad thing is that LSPs may be
reved more than once.

My way (and it sounds like your way) of making sure this change
gets passed to the Update Process is simply to rerun DIS
election when the DISs LAN ID is changed.  

So in summary I think, if an IS fails to notice a LAN ID change by the
DIS (i.e., it only notes this at DIS election time), the IS
will become disconnected from the lan for an indefinite period of
time -- Basically until an adjacency state or advertised priority
changes.

I think there is an easy way to fix this.

        When receiving IIHs always note the LAN ID reported by
        the adjacency (I think everyone does this already for DIS
        election purposes)

        Upon electing oneself DIS, note the time, call it DIStime(c),
        that this occured for this circuit, .

        When sending a IIH to a lan that you are DIS for, and
        when creating the neighbour option, For each adjacency in
        the state `Up'

                If that Neighbour's noted LAN ID matches yours
                include the Neighbors SNPA in the option,

                If the first ID Length octets of that Neighbour's
                noted LAN ID doesn't match yours, include the
                SNPA in the option.  This allows new routers to
                come up before they have run the DIS election.

                Otherwise if DIStime(c) + dRISISHelloTimer *
                ISISHoldingMultiplier (*) is less than the current time,
                include that Neighbors SNPA in the option.  This
                allows ISs time to notice the change in the LAN
                ID and re-advertise it.

The standard requires a hello be sent if the previous one was
sent more than 1 seconds ago, and:

        1) The hello timer expired, or
        2) The information to be sent has changed (i.e., the lan ID), or
        3) The system has become or resigned as DIS.

For implementations that don't note the LAN ID, they will be
cycled fairly quickly (as the dRISISHelloTimer is fairly short),
in my implementation, using the default, this would be 10 seconds.

For non-standard implementations that don't implement items 2 and
3, but do note the LAN ID, they may be unecessarily cycled, but
only if their iSISHelloTimer value is sufficiently long.

For coforming implementations that note the LAN ID, they will
immediately (or within 1 second) send a new hello with the
appropriate LAN ID.  Thus they should never be affected.

This is really easy to implement and will cause the adjacency to
cycle if it fails to update its LAN ID (indicating that it failed
to notice that you changed it), rather than indefinitely using
the wrong value (and thus being disconnected from the lan in the
SPF calculation). It shouldn't affect conforming implementations
that note the LAN ID at all.

Do people think this would be a good addition to the draft?

Thanks,
Chris.

(*) Instead of using dRISISHelloTimer * ISISHoldingMultiplier one
could be really safe and use the adjacencies advertised
HoldingTime.  I didn't pick this initially becuase I don't have a
lot of experience with ISIS deployments and this time may be
unescessarily long.  Instead I chose to possibly cycle a
non-conforming implementation if it had a really long
iSISHelloTimer.  My intuition is that this won't be a problem,
perhaps someone with more OP experiance could comment.