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

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

> 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).

Les -
	Thanks - that's what I missed.  

	Interesting Datastructure problem, though I suppose nothing too
fancy is required here.  We could simply keep track of the lowest missing
LSPID, as they whole list is comming around again.  

	So the pacing dictated by 10589 is strong enough that we don't worry
about determanistic PDU loss? 
(The helper is so much faster that the helpee always drops the 6th
packet...)

- jeff parker

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

---

From: Jeff Parker <[email-masked]>
Date: Fri, 20 Jun 2003 10:45:20 -0400

To return to the example provided.  Let's assume that all three of hannes'
CSNPs arrive.  Can we conclude that we have a full set?

I don't see any numbering scheme, and I don't see any interlocking scheme
that would tell us that there is nothing between 1111.1111.1111.00-01 and
2222.2222.2221.FF-FF (and likewise the gap between 2 and 3.)  How do I know
that the second CSNP is the second, and not the fifth?

One way to make this reliable would be to add an optional "csnp sequence
number" tlv.  Thus it we have the numbers from 1 to k, and k has an end
LSPID of all 1s, then we have a complete set.

- jeff parker

> >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

Should that read as below?
         CSNP #3 4444.4444.4444.00-00 -> ffff.ffff.ffff.ff-ff

> >/hannes

---

From: mike shand <[email-masked]>
Date: Fri, 20 Jun 2003 16:17:15 +0100

Jeff,
         I don't understand the issue. 10589 is quite clear that

A complete set of CSNPs is a set whose Start LSPID
and End LSPID ranges cover the complete possible
range of LSPIDs. (i.e. there is no possible LSPID value
which does not appear within the range of one of the
CSNPs in the set).

So while you still have gaps in the range, you have not received a complete 
set.

I don't see why you need a sequence number.

         Mike

---

From: Jeff Parker <[email-masked]>
Date: Fri, 20 Jun 2003 11:34:23 -0400

> It costs an implementation nothing to make sure that the 
> range is covered completely i.e. no additional PDUs are 
> required, you simply have to change the start ID on the 
> second CSNP to be:
> 
> CSNP #2 1111.1111.1111.00-01 -> 3333.3333.3333.00-00
> 
> (or extend the end range of CSNP #1).
 
> > > >      CSNP #3 4444.4444.4444.00-00 -> ffff.ffff.ffff.00-00

Les -
	Great.  That was what I took to be "interlocking" that I thought you
had ruled out in an earlier mail.  

Looking at 10589, section 9.10
 
   9.10 Level 1 complete sequence
   ... 
   - Start LSP ID - the LSP ID of first LSP in the range covered by this
Complete Sequence Numbers PDU.
   - End LSP ID - the LSP ID of last LSP in the range covered by this
Complete Sequence Numbers PDU.

I read this yesterday to mean the LSP ID of real LSPs in the CSNP, rather
than the LSP ID of a hypothetical LSP that could exist.  Rereading it now, I
agree that could be read as you suggest.

I have looked at one implementation that does not seem to do the right thing
here. 

Is this worth adding to the Interoperability draft? 

- jeff parker

---

From: Les Ginsberg <[email-masked]>
Date: Fri, 20 Jun 2003 08:46:40 -0700

Here is what 10589 says in 7.3.15.3

A complete set of CSNPs is a set whose Start LSPID and End LSPID ranges 
cover the complete possible range of LSPIDs. (i.e. there is no possible 
LSPID value which does not appear within the range of one of the CSNPs in 
the set). Where more than one CSNP is transmitted on a broadcast circuit, 
they shall be separated by an interval of at least 
minimumBroadcast-LSPTransmissionInterval.

Note in particular the phrase:

(i.e. there is no possible LSPID value which does not appear within the 
range of one of the CSNPs in the set)

I don't think there is ANY ambiguity here nor any need for further 
clarification.

    Les

---

From: mike shand <[email-masked]>
Date: Sat, 21 Jun 2003 20:44:07 +0100

Thanks, Jeff.

Just one comment on the concept of overlapping ranges. Although this 
perhaps meets the requirements in a strict sense, it is somewhat perverse 
and I would think it would be a bad idea, since the most obvious 
implementation for the receiver of a CSNP is to set SRMflags for any LSP 
which it holds which is within the bound of a received CSNP, but not 
otherwise mentioned (i.e. the sender doesn't have it). If a receiver 
happened to have an LSP which corresponded to the overlap, then it would 
get sent twice (assuming the CSNP "fragments" arrived sufficiently far 
apart for the LSP to have been transmitted. Obviously not a problem, but 
perhaps not a terribly good idea.

I see no reason whatsoever to use overlapping CSNP ranges.

         Mike

At 14:28 21/06/2003 -0400, Jeff Parker wrote:
>Since I opened this can of worms, I should try to get the worms back in the
>can.  Thanks to Mike and Les for sorting this out for me.
>
>As you noted, this does not cover the range from 00....00 to FF.....FF.  If
>there is a LAN client X that is not the DIS is holding LSP
>1111.1111.1112.0000, X would not be forced to flood the missing LSP.
>
> > 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;
> >
> >      CSNP #2 1111.1111.1111.00-00 -> 3333.3333.3333.00-00
> >      CSNP #3 3333.3333.3333.00-00 -> ffff.ffff.ffff.00-00
> >
> > /hannes
>
>This meets the requirements from 7.3.15.3:
>
>         A complete set of CSNPs is a set whose Start
>         LSPID and End LSPID ranges cover the complete
>         possible range of LSPIDs. (i.e. there is no
>         possible LSPID value which does not appear
>         within the range of one of the CSNPs in the set).
>
>However, it is possible to meet this condition without repeating an LSP ID,
>so receivers cannot depend on seeing the overlaps to decide if the sequence
>is complete.
>
>One such abutting sequence increments the last LSPID in the previous CSNP
>fragment, as below.
>
>CNSP #1 0000.0000.0000.00-00 -> 1111.1111.1111.00-00
>CSNP #3 3333.3333.3333.00-01 -> ffff.ffff.ffff.ff-ff
>
>- jeff parker
>

---

From: Jeff Parker <[email-masked]>
Date: Mon, 23 Jun 2003 10:43:08 -0400

> and of course there is no guarantee that (or rather 
> requirement) that you receive the CSNPs in the same 
> order they have been sent which could put you 
> into hot water anyway if you start
> to rely on an overlap.
> 
>     - tony

The issue of unordered CNSPs makes an interesting 
case.  However, I think the difficulty
here has nothing to do with the issue of using 
overlapping LSP IDs vs. abutting LSP IDs.  It is not
much more difficult to test that two IDs are 
adjacent than it is to test if they are equal.  

As Mike pointed out in private mail, overlapping
LSP IDs could introduce extra traffic, by causing
retransmissions of the LSP whose ID was duplicated.

I don't see any advantage to using overlapping LSP IDs.  

- jeff parker