Subject: [Isis-wg] Doubts regarding extending LSP fragments beyond 256

From: "Narendra" <[email-masked]>
Date: Wed, 7 Nov 2001 10:44:56 +0800

Hi All,

Can anyone help me in clearing my doubts in <draft-hermelin-ext-lsp-frags-02.txt>
 for extending the number of IS-IS LSP fragments beyond 256 limit.
 
1.While Generating extended LSP, whether to generate extended LSP as soon as extended   System-ID is configured or when the Original LSP fragments reaches its maximum limit of 256?.

2. Either in operation mode 1 or in operation mode 2, adjacency with `Virtual System` will be established only by `Originating System`. is this correct?.
if so why it is said in section "forming Adjacencies"  that "if  a neighbour is to be included in extended LSP S`, then S`should be used as the system-id in IS Hellos and IS-IS Hellos when forming an adjacency with that neighbour". Does this mean that the originating
System in Mode 2 will send As many hellos as the number of extended System Ids it
uses ?

3. If there is space in Original LSP due to purging of some original LSP fragments, then do we need to regenerate both original LSP and extended LSP with moving some of LSP`s content from extended LSP to Original LSP.

4. Is it correct that there will be no changes to the PsudonodeLSPs of the
originating system as the virtual Systems are assumed to be on P2P links?

5. Are there any vendors/ ISIS implementions that  has implemented this draft? 

thanks in advance

Narendra G.H.

---

From: "Amir Hermelin" <[email-masked]>
Date: Thu, 8 Nov 2001 10:09:45 +0200

Narendra,
my answers inline. Also, a new version of the draft will be published
shortly.

--
Amir Hermelin                    <mailto:[email-masked]>
Charlotte's Web Networks Inc.     <http://www.cwnt.com>

> -----Original Message-----
> From: Narendra [mailto:[email-masked]]
> Sent: Wednesday, November 07, 2001 4:45 AM
> To: [email-masked]
> Cc: Narendra
> Subject: [Isis-wg] Doubts regarding extending LSP fragments beyond 256
> 
> 
> Hi All,
> 
> 1.While Generating extended LSP, whether to generate extended 
> LSP as soon as extended   System-ID is configured or when the 
> Original LSP fragments reaches its maximum limit of 256?.

IMO this is implementation-specific. While using extended LSPs before
the original LSP space is depleted, could result in cluttering the
network with un-needed 'virtual' systems, a vendor might choose to do
so, to reserve extra space in the original LSPs for whatever reason.
Furthermore, in Mode 2 this doesn't produce any additional overhead,
since the LS information has to be generated anyway.

> 2. Either in operation mode 1 or in operation mode 2, 
> adjacency with `Virtual System` will be established only by 
> `Originating System`. is this correct?.

That is not correct. Here's the text from section 7:
 " It should be noted, that an IS must use the system-id of the LSP that
   will include a neighbor, when forming an adjacency with that
   neighbor.  That is, if a neighbor is to be included in extended LSP
   S', then S' should be used as the system-id in IS Hellos [3] and IS-
   IS Hellos when forming an adjacency with that neighbor.  This is
   regardless of the Operational Mode.  Of course, in Mode 1 this means
   that only the original system-id will be used when sending hellos. "
What you said is correct for mode 1 - since only original LSPs include
ISN TLVs, then only original system-ids will be heard on hellos by the
other neighbors. However, in mode 2 it is possible to include ISNs in
Extended LSPs; say LSPs with Extended system-id S'. Then, this neighbor
must hear S' in the hellos, and not the original system-id (so it
advertises an adjacency to S', and bi-direct check will pass).> if so
why it is said in section "forming Adjacencies"  that 

> "if  a neighbour is to be included in extended LSP S`, then 
> S`should be used as the system-id in IS Hellos and IS-IS 
> Hellos when forming an adjacency with that neighbour". Does 
> this mean that the originating

This does not affect the number of hellos - only what system-id is
advertised in them.

> 3. If there is space in Original LSP due to purging of some 
> original LSP fragments, then do we need to regenerate both 
> original LSP and extended LSP with moving some of LSP`s 
> content from extended LSP to Original LSP.

If I understand correctly, you're asking about whether to 'compact' the
number of LSP sets in use. I think the same answer to 1 applies here.

> originating system as the virtual Systems are assumed to be 

That depends. If your'e running mode 2, and advertising an extended
system-id on a broadcast network, and you're the DIS on that network,
you can advertise the extended system-id in the pseudonode as well - no
limitation here. What's assumed to be p2p links are the connections
between the original and virtual systems in Mode 1 only - in Mode 2
these connections don't exist (see 4.2 of draft). Besides, there's no
real limitation that the pseudonode and DIS share the same system-id -
it's just a convenience.

> 5. Are there any vendors/ ISIS implementions that  has 
 
I'm aware of only one.

> thanks in advance

welcome. HTH

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