Subject: [Isis-wg] CSNPs in draft-ietf-isis-restart-03.txt

From: Jeff Parker <[email-masked]>
Date: Thu, 19 Jun 2003 13:39:17 -0400

Mike, Les -

Reviewing the restart draft, I see the following paragraph on page 5.  

4.3.1      Adjacency reacquisition during restart

   ....

   When BOTH a complete set of CSNP(s) (for each active level, in the
   case of a pt-pt circuit) and an acknowledgement have been received
   over the interface, the timer T1 is cancelled.

Section 7.3.15.3 of ISO 10589 defines "complete set of CSNPs" and discusses
when they should be sent, but I don't see signs of an acceptance criteria
for complete sets in 10589.  Since CSNPs are not acknowledged and do not
need to be sent in order, how much care is needed here?  I can imagine an
implementation that keeps track of the ranges seen, and keeps sending IIH
with the RR bit sent, but I don't see a requirement on the "Helper" to
retransmit the CSNPs.  

If we see a CSNP with "End LSP ID" field of all 1s, can we declare that we
are done, or must we hold on until we have an interlocking set?  If we must
hold on, should we require the Helper to resend the CSNPs?

- jeff parker
- axiowave networks

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

---

From: Les Ginsberg <[email-masked]>
Date: Thu, 19 Jun 2003 10:50:36 -0700

>with the RR bit sent, but I don't see a requirement on the "Helper" to

According to Section 4.2.1c of the draft, the Helper is required to 
initiate transmission of a complete set of CSNPs every time it sees an IIH 
w RR set (assuming it is Pt-Pt or the appropriate system on the LAN).

>hold on, should we require the Helper to resend the CSNPs?

You must track the receipt of a complete set of CSNPs. If you do not, then 
you cannot be assured of database synchronization.
10589 never made the transmission of CSNPs reliable. One of the goals of 
the draft is to make the transmission reliable so that database 
synchronization can be reached quickly and deterministically.

    Les

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 20 Jun 2003 01:11:56 +0200

On Thu, Jun 19, 2003 at 10:50:36AM -0700, Les Ginsberg wrote:
| At 01:39 PM 6/19/2003 -0400, Jeff Parker wrote:
| >Mike, Les -
| >
| >Reviewing the restart draft, I see the following paragraph on page 5.
| >
| >4.3.1      Adjacency reacquisition during restart
| >
| >   ....
| >
| >   When BOTH a complete set of CSNP(s) (for each active level, in the
| >   case of a pt-pt circuit) and an acknowledgement have been received
| >   over the interface, the timer T1 is cancelled.
| >
| >Section 7.3.15.3 of ISO 10589 defines "complete set of CSNPs" and discusses
| >when they should be sent, but I don't see signs of an acceptance criteria
| >for complete sets in 10589.  Since CSNPs are not acknowledged and do not
| >need to be sent in order, how much care is needed here?  I can imagine an
| >implementation that keeps track of the ranges seen, and keeps sending IIH
| >with the RR bit sent, but I don't see a requirement on the "Helper" to
| >retransmit the CSNPs.
| 
| According to Section 4.2.1c of the draft, the Helper is required to 
| initiate transmission of a complete set of CSNPs every time it sees an IIH 
| w RR set (assuming it is Pt-Pt or the appropriate system on the LAN).
| 
| >If we see a CSNP with "End LSP ID" field of all 1s, can we declare that we
| >are done, or must we hold on until we have an interlocking set?  If we must
| >hold on, should we require the Helper to resend the CSNPs?
| 
| You must track the receipt of a complete set of CSNPs. If you do not, then 
| you cannot be assured of database synchronization.
| 10589 never made the transmission of CSNPs reliable. One of the goals of 
| the draft is to make the transmission reliable so that database 
| synchronization can be reached quickly and deterministically.

what would be the "right" mechanism to track down a missing CSNP ?

i.e. if i send the following CSNPs 

e.g. CNSP #1 0000.0000.0000.00-00 -> 1111.1111.1111.00-00
     CSNP #2 2222.2222.2222.00-00 -> 3333.3333.3333.00-00
     CSNP #3 4444.4444.4444.00-00 -> ffff.ffff.ffff.00-00

assume now #2 gets lost; - is there a way for the receiver to track that
#2 is missing ? IMHO not;

one way of solving that is to "chain" the CSNPs i.e. the end-LSP-id is
the start LSP-id of the next CSNP;

e.g. CNSP #1 0000.0000.0000.00-00 -> 1111.1111.1111.00-00
     CSNP #2 1111.1111.1111.00-00 -> 3333.3333.3333.00-00
     CSNP #3 3333.3333.3333.00-00 -> ffff.ffff.ffff.00-00

comments ?

/hannes

---

From: Les Ginsberg <[email-masked]>
Date: Thu, 19 Jun 2003 19:33:48 -0700

>#2 is missing ? IMHO not;

The receiver knows that some information is missing. How many CSNPs might 
be required to fill in the missing information is unknown. It depends on 
the distribution of system IDs and the number of LSPs generated by each of 
the missing systems.

>      CSNP #3 3333.3333.3333.00-00 -> ffff.ffff.ffff.00-00

I would expect that most implementations send the CSNPs in this order - 
though such behavior is not required. However, if you are suggesting that 
as part of the restart draft we should specify additional requirements on 
CSNP exchange, then I am against that.

    Les