Subject: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt

From: "Manral, Vishwas" <[email-masked]>
Date: Tue, 23 Apr 2002 05:06:28 -0400

Hi Amir/Stefano/Mike,

I read thru ur draft and had an alternate idea in mind. I wanted to know
what you thought of it.

Using the LSP number a 32 bit(or 16 bit as desired) quantity in TLV: -

The idea is to have a new TLV, which tells the actual LSP number. The LSP
number in the psudonode-id is not used. The changes required are minimum. We
anyway scan thru TLV's for authentication information, we can find the LSP
number TLV then. We instead use this TLV. 

To migrate to such a method all we need to do is to, use same LSP numbers in
the header and the TLV, and once all routers recognize the TLV, we actually
can use different numbers. This does not create any backward compatibility
issues and so we dont need two methods. In this case we do not need to worry
about Attached bit, Partition repair bit or change to SPF calculations etc.
The solution also seems a logical extension, to the constraint caused by 8
bit LSP number value. Rather than a solution that has multiple system id's
which is like fooling the IS to believe all the systems are the same.

Thanks,
Vishwas
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg

---

From: mike shand <[email-masked]>
Date: Tue, 23 Apr 2002 13:43:28 +0100

I'm not sure I fully understand this proposal. I assume that when you 
actually start using extended numbers you still need to invent additional 
system ID's for the extra "fragments" so that the update process can 
distinguish them. In which case it is semantically identical to the current 
scheme.

Or are you proposing changing the update process so that it looks at the 
new TLV? I guess that must be what you have in mind. This has fairly 
serious consequences if you have migrated to extended numbers, but you then 
introduce a router which doesn't understand the new update process. I 
thought we had already considered and rejected solutions of this type.

         Mike

---

From: "Manral, Vishwas" <[email-masked]>
Date: Tue, 23 Apr 2002 11:21:28 -0400

Hi Mike,

Thanks for the reply.

I do not understand if we have migrated to a bigger LSp number, why we would
bring in a router that still uses a smaller LSP number, even when we know it
could create problems. This problem can occur in all cases of migration
a) to domain wide
b) wide metrics

I do not see why we should introduce a two pronged method to do something
which we can do pretty easily with just a TLV change, when similar
approaches have been taken for other cases. Even in domain wide if a router
came in which did not use external reachability in cases of L1 area the same
problem would occur. I do not find the reason convincing enough to be
rejected. ;-)

Thanks,
Vishwas

-----Original Message-----
From: mike shand [mailto:[email-masked]]
Sent: Tuesday, April 23, 2002 6:13 PM
To: Manral, Vishwas
Cc: [email-masked]'
Subject: Re: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt

         Mike

---

From: "Manral, Vishwas" <[email-masked]>
Date: Wed, 24 Apr 2002 10:07:47 -0400

Hi folks,

As I have not got the reply to my mail, I will try and restate(I guess I
wasn't clear) what the proposal is.

The idea is to have a new TLV called LSP Number TLV, which contains a 32 bit
LSP number. The new TLV is propagated in all LSP's and overrides the LSP
Number field in the header.

To migrate to this scheme, as long as all the routers in the network do not
support the new TLV, we use the same value in LSP number field in the header
as well as the TLV. Once all the routers in the network support the new TLV,
we can actually use the value of the LSP number TLV and ignore the LSP
number field in the header.

The solution in this scheme seems to be a logical extension to the limit
caused by an 8 bit LSP number field, using a 32 bit sequence number, rather
than the scheme where we need multiple system id's and then equating the
ID's.

The advantages of the scheme relative to the other scheme is: -

a) We use a simple migration scheme rather than a two step highly complex
scheme.
b) We need not worry about any change to routing table calculations. 
c) No taking care of attached bit.
d) No taking care of partition bit.
e) We need not worry about which links use what system id(as in the other
scheme) and hence a lot of configuration.
f) The amount of code changes are minimal.

Regarding Mike's comment(I hope I got it right, Mike?) what happens when a
new router that does not support the functionality comes up. Although the
assumption with the other drafts like domain-wide and wide metrics is that
once we migrate to a scheme, we will not try and bother about the older
scheme, the same problem would occur in the other draft too if a new router
came up after we had migrated to method 2, and someone did not understand
the ISIS Alias TLV described there. Routing loops could very easily occur
there.

Any comments/criticism invited.

Thanks a lot,
Vishwas

-----Original Message-----
From: Manral, Vishwas [mailto:[email-masked]]
Sent: Tuesday, April 23, 2002 8:51 PM
To: 'mike shand'
Cc: [email-masked]'
Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt

Hi Mike,

Thanks for the reply.

Thanks,
Vishwas

-----Original Message-----
From: mike shand [mailto:[email-masked]]
Sent: Tuesday, April 23, 2002 6:13 PM
To: Manral, Vishwas
Cc: [email-masked]'
Subject: Re: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt

         Mike

---

From: mike shand <[email-masked]>
Date: Wed, 24 Apr 2002 15:25:29 +0100

>the ISIS Alias TLV described there. Routing loops could very easily occur

Where do you put the extended numbers in xSNPs? Or are you proposing a new 
"extended" LSP entry TLV? What do you do for migration? send both?

Even if you do this, if you have a router which doesn't understand the new 
stuff and you are using the extended number space, you will get perpetual 
re-transmission if you have two LSPs with the same "natural" number but 
different extended numbers sent to a non-participating router. It will only 
ACK one of them. et.c etc.

         Mike

---

From: "Manral, Vishwas" <[email-masked]>
Date: Wed, 24 Apr 2002 14:37:05 -0400

Hi Mike,

Thanks a lot for the reply. That helped clarify a lot. I was actually
thinking things from the LSP aspect and forgot all about the xSNP thing
altogather. ;-)

> "extended" LSP entry TLV? What do you do for migration? send both?
I guess we need to send both, so it would actually be more than one(two) new
TLV's added because of the draft, agreed. 

> ACK one of them. et.c etc.
Though I do not understand what you mean by 

"with the same "natural" number but different extended numbers sent to a
non-participating router"

Well the ack with either of the TLV's can be treated as the ack for the
element. Or are you talking about a case after migrating we get a guy who
doesn't understand the new TLV? If thats the case I have already given the
instance of domain wide and wide metrics.;-)

Do you think the method is not worth it?(My view is that this seems the
logical extension and if the number of changes this way are lesser we could
as well go in for it) (any other changes you think would be required?);-)

Thanks,
Vishwas

---

From: "Manral, Vishwas" <[email-masked]>
Date: Thu, 25 Apr 2002 02:46:53 -0400

Hi Mike,

I actually thought over it, and simplified things a bit further, so that we
never have to send both entry TLV's at one time.

1. All routers use small LSP numbers at init time.
2. As routers with new functionality come up, they need to send the same
value in header and TLV LSP numbers. They need to be ready to accept the
"extended LSP entry TLV. We however still send the old LSP entry TLV.
3. Once all routers have the capability, we start using different values in
LSP number in the header and the TLV(extended LSP number) and use only
extended LSP entry TLV.

Does this sound ok? ;-)

Thanks,
Vishwas

-----Original Message-----
From: mike shand [mailto:[email-masked]]
Sent: Wednesday, April 24, 2002 7:55 PM
To: Manral, Vishwas
Cc: [email-masked]'
Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt

         Mike

---

From: mike shand <[email-masked]>
Date: Thu, 25 Apr 2002 08:01:51 +0100

>TLV's added because of the draft, agreed.

So this means we more than double the size of any xSNPs we send during the 
migration period (which probably needs to last a long time so that we can 
be SURE there will never be an old router anywhere). Even so I am very 
nervous about the catastrophe which would result if an old router 
subsequently crept in.

>non-participating router"

I mean that a router that doesn't understand the new TLVs receives two LSPs 
with the same LSP number in the header, but different LSP numbers in the 
new TLV. It will treat them as duplicates of the same LSP and so when it 
acknowledges the second one it will just send a normal PSNP and the 
originator will not be able to tell which one was being acknowledged. I 
haven't thought it through in detail, but it seems to me that for various 
scenarios you will get the possibility of perpetual retransmissions, and 
certainly loss of information.

>as well go in for it) (any other changes you think would be required?);-)

My view is that the update process is extremely subtle (but has been proved 
correct in its current form) and that changing it in any way is very risky. 
I would MUCH rather have a solution which left the update process unchanged.

---

From: "Manral, Vishwas" <[email-masked]>
Date: Thu, 25 Apr 2002 03:25:45 -0400

Mike,

Thanks a lot for the reply. My comments inline, prefixed by a VM>.

Thanks,
Vishwas

-----Original Message-----
From: mike shand [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 12:32 PM
To: Manral, Vishwas
Cc: [email-masked]'
Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt

VM> I guess we could do with just one TLV at a time, as in my previous mail.
Talking about problems. I guess there would be routing table problems in
case a new router came in after we migrated to method 2.

VM> Same answer as above. A similar thing could happen of the ext_lsp_frag
too if a router came without which did not understand the new TLV, it would
cause routing loops too.

VM> Mike, I think the only change to the update process would be to use new
TLV's. The Update process as such would not change much but treating both
the TLV's as the same. The point here is that we need to do the check only
at the time of migrating and not after we have migrated, and there is no
change once we have migrated.

I agree a big change to the Update process causes more problems than a
change to the SPF and a lot of extra configuration.

> > >number in the psudonode-id is not used. The changes required are
minimum.
> >We
> > >To migrate to such a method all we need to do is to, use same LSP
numbers
> >in
> > >The solution also seems a logical extension, to the constraint caused
by
>8

---

From: mike shand <[email-masked]>
Date: Thu, 25 Apr 2002 08:16:34 +0100

>LSP number in the header and the TLV(extended LSP number) and use only

I think you need a multi stage migration process.

1. Deploy new software everywhere which understands the new TLVs, and sends 
the same LSP number in both the LSP header and the extended TLV, but still 
only sends the old LSP entry TLV.

2. Once you have all routers with the new software, you can go to each 
router in turn and tell it to use new LSP entries instead of old.

3. Once you have all routers doing this, you can start using extended LSP 
numbers (i.e. different values in the TLV and the header).

It would probably be wise to include some capability bits in the IIHs to 
prevent forming adjacencies with old routers once you have started using 
extended LSP numbers.

But, note that this is a complex process and requires changes to all the 
update process code AND the SPF process code to recognize the additional 
LSP numbers, AND the hello processing code (if we want to make it 
reasonably safe).

I'd MUCH rather confine the changes to the SPF.

         Mike

---

From: "Manral, Vishwas" <[email-masked]>
Date: Thu, 25 Apr 2002 03:29:31 -0400

Maybe we could get someone elses views too, of what they feel. That would
help. ;-) 

The idea of extended option in IIH is good, and may be nice for the
exp_lsp_fragment draft too(and same with domain wide etc too). 

Thanks again,
Vishwas

-----Original Message-----
From: mike shand [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 12:47 PM
To: Manral, Vishwas
Cc: [email-masked]'
Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt

         Mike

minimum.
numbers
by

---

From: "Amir Hermelin" <[email-masked]>
Date: Sun, 28 Apr 2002 18:25:53 +0300

Manral,

Let me relate to some points mentioned in this dialogue.
* WRT extended capabilities TLV: this new TLV was included in draft-hermelin-ext-lsp-frags-02.txt, but was removed in subsequent versions due to lack of need. I can re-add it to the draft, or maybe a separate draft would be better. Lets have opinions from the group.
* We have previously considered your option of using same sys-id and frag-num, add new tlv in body. I withdrew from that mainly due to the numerous problems it introduces, most of which have been pointed out by Mike. I guess for the sake of brevity he didn't outline all of them - but it does change the update process, to my knowledge significantly. If you've mentioned code-changes, I believe your method would impose significant code changes in multiple processes.
* You've referred to the two modes in the draft - note that they are completely independent. Furthermore, mode 1 imposes no changes whatsoever to the spf process, and is completely compatible with older routers.
* WRT transitioning: note section 7 of the draft, first paragraph:
"it is possible to not upgrade every router in the network,
   if the extended information is not routing information, but rather
   data that is of use to only a subset of routers (e.g. optical
   switches using ISIS could carry optical-specific information in
   extended LSPs)"
This isn't possible with the other method.
* Again note section 7. It lists a very easy (and safe) method of transitioning the network.
* WRT partition repair and att bit: this is only a suggestion, and doesn't have any serious consequences whether you follow it or not.
* And finally, WRT SPF changes: Mode 2 of the draft doesn't pose any real changes to SPF, only to way LSPs are "grouped". In that regard, this is exactly the same as in your proposition.

I very much welcome your comments (especially since they livened up the discussion :-).

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

> Sent: Thursday, April 25, 2002 10:30 AM
> To: 'mike shand'
> > >The idea is to have a new TLV called LSP Number TLV, which 
> contains a 32
> >bit
> > >To migrate to this scheme, as long as all the routers in 
> the network do
> not
> > >support the new TLV, we use the same value in LSP number 
> field in the
> >header
> > >as well as the TLV. Once all the routers in the network 
> support the new
> >TLV,
> > >caused by an 8 bit LSP number field, using a 32 bit 
> sequence number,
> rather
> > >Regarding Mike's comment(I hope I got it right, Mike?) 
> what happens when
> a
> > >assumption with the other drafts like domain-wide and wide 
> metrics is
> that
> > >scheme, the same problem would occur in the other draft 
> too if a new
> router
> > >I do not understand if we have migrated to a bigger LSp 
> number, why we
> >would
> > >bring in a router that still uses a smaller LSP number, 
> even when we know
> >it
> > >approaches have been taken for other cases. Even in domain 
> wide if a
> router
> > >came in which did not use external reachability in cases 
> of L1 area the
> >same
> > >serious consequences if you have migrated to extended 
> numbers, but you
> then
> > > >I read thru ur draft and had an alternate idea in mind. 
> I wanted to
> know
> > > >what you thought of it.
> > > >
> > > >The idea is to have a new TLV, which tells the actual 
> LSP number. The
> LSP
> > > >anyway scan thru TLV's for authentication information, 
> we can find the
> >LSP
> > > >the header and the TLV, and once all routers recognize 
> the TLV, we
> >actually
> > > >issues and so we dont need two methods. In this case we 
> do not need to
> > >worry
> > > >about Attached bit, Partition repair bit or change to 
> SPF calculations
> >etc.
> > > >bit LSP number value. Rather than a solution that has 
> multiple system
> >id's