Subject: [Isis-wg] Help needed

From: "Vamsi K" <[email-masked]>
Date: Wed, 25 Apr 2001 16:40:58 +0530

Hi ,
  In the ISO/IEC 10589: 1992(E) document, the section 7.3.4.4 is a bit
confusing. Here i am quoting  the exact words.

Once a particular adjacency has been assigned to a particular LSP number, it
is desirable that it not be moved to another LSP number.
This is because moving an adjacency from one LSP to another can cause
temporary loss of connectivity to that system. This can occur if the
new version of the LSP which orginally contained information about the
adjacency (which now doesnot contain information) is propagated before the
new version of the other LSP ( which now contains the information about the
adjacency).

Here my doubt is  what is the need for attaching the specific LSP number
(not the sequence number) for a particular adjacency. The field
"Intermediate system Neighbours" in the LSP PDU  contains the neighbour id
field which indicates the particular adjacency, the information is
pertaining to.

Can anybody clear my doubt regarding this.

Thanks in advance
vamsi.P

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

---

From: Micah Bartell <[email-masked]>
Date: Wed, 25 Apr 2001 13:34:35 -0500

If for instance you have LSPA-FRAG3 that contains adjacency Z.  A whole 
bunch of circuits are restored, and the LSPA-FRAG3 contains these new 
adjacencies and adjacency Z gets moved to LSPA-FRAG4.  When LSPA-FRAG3 is 
flooded, other IS's will receive this and see that adjacency Z is no longer 
there.  So they remove it for their SPF.  However, shortly after, 
LSPA-FRAG4 would arrive with adjacency Z and it would be restored.  This 
could cause the temporary loss of connectivity.

When a link goes down, you don't repack everything as densely as possible, 
the recommendation is that the number of LSPs generated be within 10% of 
the optimal number of LSPs if they were densely packed.  When new 
adjacencies come up, you add them into the lowest LSP with available space, 
which will optimize the number of LSPs vs amount of information being sent.

/mpb

Full Quote of 7.3.4.4 & Note and Footnote:

7.3.4.4 Once a particular adjacency has been assigned to a particular LSP 
Number, it is desirable that it not be moved to another LSP Number. This is 
because moving an adjacency from one LSP to another can cause temporary 
loss of connectivity to that system. This can occur if the new version of 
the LSP which originally contained information about the adjacency (which 
now does not contain that information) is propagated before the new version 
of the other LSP (which now contains the information about the adjacency).

NOTE 25 An implementation is recommended to ensure that the number of LSPs 
generated for a particular system is within approximately 10% of the 
optimal number which would be required if all LSPs were densely packed with 
neighbour options. Where possible this should be accomplished by re-using 
space in LSPs with a lower LSP Number for new adjacencies.

If it is necessary to move an adjacency from one LSP to another, the 
SRMflags (see 7.3.15) for the two new LSPs shall be set as an atomic action.1)

1) If the two SRMflags are not set atomically, a race condition will exist 
in which one of the two LSPs may be propagated quickly, while the other 
waits for an entire propagation cycle.  If this occurs, adjacencies will be 
falsely eliminated from the topology and routes may become unstable for 
periods of time potentially as large as maximumLSPGenerationInterval.

---

From: Jeff Learman <[email-masked]>
Date: Wed, 25 Apr 2001 14:58:58 -0400

Vamsi,

>(not the sequence number) for a particular adjacency.

For example, let's say
adjacency A is currently in LSP segment 2, and is moved to LSP
segement 3.  Both LSP segments' (independent) sequence numbers
get incremented, and both segments get transmitted.  Now, if
segment 3 gets dropped due to noise on an Ethernet, segment 2
gets flooded first.  All the routers that get segment 2 and not
segment 3 will assume that there is no adjacency A.

Note that this could also happen if the segments simply arrive
in the obvious order  (2 first, then 3), if the receiving
implementation has a hold-down timer on running SPF.  If it
weren't for the "don't move" rule, we wouldn't be able to have hold-down
timers on running SPF, which can be useful especially in embedded
systems like SONET NEs, where routing is not the system's principal
concern.

Regards,
Jeff