Subject: [Isis-wg] draft-ietf-isis-restart-03.txt - Designated Restart Assistant

From: Jeff Parker <[email-masked]>
Date: Sat, 28 Jun 2003 12:37:03 -0400

I'm looking at draft-ietf-isis-restart-03.txt, and thinking about 
generating a set of CSNPs on a LAN interface, and the task of
selecting a Temporary DIS (TDIS), discussed in clause c) below.  

My issue is how much we need to consider the kind of anomaly 
where not all IS's on a LAN can peer with each other.  

Page 4 to 5

   When the neighbor of a (re)starting router receives an IIH with the 
   restart TLV having the RR bit set, if there exists on this interface 
   an adjacency in state "Up" with the same System ID, and in the case 
   of a LAN circuit, with the same source LAN address ....

  c) if the corresponding interface is a Point-to-Point interface, or 
     if the receiving router has the highest LnRouterPriority (with 
     highest source MAC address breaking ties) among those routers 
     whose IIHs contain the restart TLV, excluding the transmitting 
     router (note the actual DIS is NOT changed by this process.), 
     initiate the transmission over the corresponding interface of a 
     complete set of CSNPs, and set SRMflags on the corresponding 
     interface for all LSPs in the local LSP database. 

Consider the following corner case

	R is a restarting router running IP
	A is a low-priority router running IP
	B is a high-priority router running ISO only

	All are sending the Restart TLV

The problem is that in the best of circumstances, B will 
not have an adjacency with R or A, and R will be the DIS
on the IP subnetwork on the LAN.  

If you find this a long shot, replace the mismatch over
protocol with mismatches due to authentication, IP network 
matching, Area, etc.

I can see the following readings of the clause above

	Since B did not have an adjacency with R before 
	reboot, it will not send any CSNPs

	From A's point of view, B is a better candidate.
	(B is sending the Restart TLV, has higher priority)
	so A will not send any CSNPs

The outcome that we want is for A to become the TDIS, as 
B's CSNPs are useless.  If this is a real problem, here
are 3 potential 'solutions':

	1) The "restart TLVs" in the clause above must be
	restart TLVs with RA bit set.  

This allows us to restrict our selection to routers that
respond.  There are at least two problems:

  A) It introduces a new synchronization phase, while A waits
  to see if B responds, delaying R's return

  B) This does not deal correctly with the case that we have
  IS's R.IP and R.ISO rebooting at the same time: B will 
  respond to R.ISO, though this is no help to R.IP.  This is
  even less likely, though possible.   

Another attack is as follows

	2) IS A must consider the possibility of peering between
	potential TDIS and restarting router

This is asking a great deal of A, as it may be hard to
predict the rules that B or R would use in checking
adjacency.  We could use the list of A's peers to select
the TDIS from, but peering isn't a transitive relation.  

And the third choice is:

	3) This is a case that is not dealt with.
	The restarting router will get information on
	his other interfaces, and A can still maintain 
	his adjacency.  

I had been planning to implement the test "those routers 
whose IIHs contain the restart TLV" as a bit in A's list 
of adjacencies.  Each time A gets a Hello from an IS, this
bit is reset.  This allows rapid generation of the CSNP
set, though it may lead to silence sometimes: A peers
with B, but R does not, so B does not send.  The mirror
image is the case that A and B both peer with R, but not
with each other.  In that case, both will send CSNPs.  

A fourth choice would be to have on of R's old peers 
send the CSNPs after a period of silence, but this 
introduces new states and new difficulties, and another
lag at the start of things.    

- jeff parker
- axiowave networks

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Les Ginsberg <[email-masked]>
Date: Sat, 28 Jun 2003 19:05:22 -0700

Jeff -

The major theme to what you have below is:

If routers on a LAN do not perform DIS election in a consistent manner 
(whether due to protocol support, authentication, or other issues) then 
problems arise.

The answer to this is: "Of course!". But this has nothing to do with 
restart - and it is unreasonable to expect the restart draft to deal with this.

A quick summary of the state of the protocol on this issue:

a)We have RFC 1195 which says that an IP only router and an OSI only router 
which are adjacent is an unsupported topology.
b)We have the multi-topology draft which says you should form an adjacency 
with all routers on the LAN regardless of what protocols/topologies they 
support.
c)We have the auto encapsulation draft which (along w the ITU) says you 
must only form an adjacency if you have a protocol in common
d)We have real world implementations which sometimes add on other 
requirements, most notably having a common IP subnet.

Now, if you think that we would be better off resolving this issue, I 
applaud your sentiments. But don't ask the restart draft to solve it. We 
have neither invented the problem nor made it any worse. We make the 
assumption that the set of eligible routers participating in what you have 
called the TDIS election are all following the same rules - as does the 
normal DIS election.

Some more specific comments inline.

    Les

>         reboot, it will not send any CSNPs

This is indeed true. The requirement that applies to 4.2.1a,b,c is that the 
neighbor have an adjacency to the restarting router in the UP state. If it 
does not, even though the neighbor is restart capable it will not adhere to 
paragraph "c". The draft says:
"Otherwise (i.e. if there was no adjacency in the "UP" state to the
    system ID in question), process the IIH as normal by reinitializing
    the adjacency, and setting the RA bit in the returned IIH."

>         so A will not send any CSNPs

In your mismatched protocol example, A will not have an adjacency with B in 
the UP state so A will not consider B as a candidate for TDIS (or for DIS 
for that matter).

>the TDIS from, but peering isn't a transitive relation.

The same problem exists in normal DIS election. If A has an adjacency to 
both B and R, then A assumes that transitivity on the LAN exists and so it 
can safely consider both B and R as candidates in its DIS election. If the 
transitive assumption proves false, we can have problems, but not because 
of restart.

>with each other.  In that case, both will send CSNPs.

Which would still work - it would just be less efficient. In actual 
practice, if no topology changes have happened during the time interval it 
took R to restart, then getting a set of CSNPs from only one neighbor on 
any circuit would prove sufficient - but of course R has no way to know 
which neighbor to choose, so we rely on all of our neighbors. In most cases 
it's overkill, but it is necessary to make the process reliable.

---

From: Jeff Parker <[email-masked]>
Date: Mon, 30 Jun 2003 10:21:54 -0400

> If routers on a LAN do not perform DIS election in a consistent manner
(whether due to protocol support, 
> authentication, or other issues) then problems arise.

> The answer to this is: "Of course!". 
> But this has nothing to do with restart - 
> and it is unreasonable to expect the restart draft to deal with this.

> In your mismatched protocol example, A will not have an adjacency 
> with B in the UP state so A will not consider B as a candidate 
> for TDIS (or for DIS for that matter).

Les -
	I agree that the draft cannot fix that which is broken
someplace else.  However, even your comment above refers to the 
"common sense" algorithm that I wanted to implement, but seemed 
ruled out by the text of the draft.

	The text suggests we must start with all routers on the LAN, 
while starting with the neighbors of A is a faster algorithm, and
more likely to reach the right result. 

	We could replace "among those routers" in the text below 

with "among those routers adjacent to the neighbor".  If we give
the assisting router a symbolic name (such as A above), this would 
be made clearer: "among those routers adjacent to the neighbor A."

- jeff parker

---

From: Les Ginsberg <[email-masked]>
Date: Mon, 30 Jun 2003 08:35:21 -0700

Jeff -

In the upcoming Version 4 of the draft this text has already been changed 
to read:
  among those routers to which the receiving router has an adjacency in 
state "Up" on this
  interface whose IIHs contain the restart TLV,

I think this is always what was intended but was not stated as explictly as 
it could have been i.e we never intended the "TDIS" election to include 
routers for which no adjacency in the UP state existed - whatever the reason.
.
Because your original mail discussed a variety of complex solutions, I 
didn't realize that all you were concerned about was a lack of explicitness 
in the text.

Hopefully this resolves the issue.

Thanx.

    Les

---

From: Jeff Parker <[email-masked]>
Date: Mon, 30 Jun 2003 12:44:05 -0400

state "Up" on this 
> interface whose IIHs contain the restart TLV,
 
Les -
	Thanks - that addresses my concern.

- jeff parker