Subject: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt

From: Alex Zinin <[email-masked]>
Date: Wed, 4 Aug 2004 16:51:16 -0700

A few comments I raised at the mic today:

1. One of the reasons that was mention was exhaustion of the TLV type
   space. Given that we have only 36 allocations in the registry now,
   I doubt this will be a problem any time soon.

2. Another reason was the size of the TLV. If this becomes a problem,
   my first question would be whether this is a good idea to announce
   such info in ISIS and/or whether it is properly encoded. This is not
   to say that we could never end up with having to announce something
   bigger than 255, but I'd like to see an example of where this becomes
   a problem we can't get around.

3. Naming mentioned in his slides that backwards-compatible deployment
   is possible. I wasn't sure it was. Now that I re-read the draft, I'm
   sure it is not possible. Routers not implementing this feature will
   encounter a TLV parsing error, since the what they believe is the 1-octet
   length field will contain wrong value for TLVs bigger than 255 octets.

-- 
Alex
http://www.psg.com/~zinin

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

---

From: mike shand <[email-masked]>
Date: Thu, 05 Aug 2004 01:59:14 +0100

>    I doubt this will be a problem any time soon.

I agree. And not only that, we have sub-TLVs for things that need a lot of 
code points.

>    a problem we can't get around.

I agree. This seems to be a somewhat Draconian solution to a problem which 
we don't know we have yet, and which IF we do have may well be solvable by 
simpler techniques (such as defining the contents of TLVs to be additive, 
in the same way that we can have more prefixes than will fit in a single 
TLV by repeating the TLV and "adding" the prefixes together; I agree it is 
not quite as simple as that in some case, but that seems to me to be a less 
disruptive way of addressing the problem should it ever arise; and I 
sincerely hope it doesn't:-)

>    length field will contain wrong value for TLVs bigger than 255 octets.

We well it does "work", but it doesn't buy you anything. Although the 
backwards compatibility lets you use long format TLVs before everyone 
understands them you can't have them longer than 255 octets.

So the only use for this would be to extend the TLV code space, and we have 
already agreed that is not a problem in our lifetime!

         Mike

---

From: Naiming Shen <[email-masked]>
Date: Thu, 05 Aug 2004 16:35:41 -0700

Alex,

 ] A few comments I raised at the mic today:
 ] 
 ] 1. One of the reasons that was mention was exhaustion of the TLV type
 ]    space. Given that we have only 36 allocations in the registry now,
 ]    I doubt this will be a problem any time soon.

Agreed. But this code point is a side effect of the draft. I think anyone
would agree that if we take the trouble to change the length field,
the code field better to be changed at the same time.

 ] 
 ] 2. Another reason was the size of the TLV. If this becomes a problem,
 ]    my first question would be whether this is a good idea to announce
 ]    such info in ISIS and/or whether it is properly encoded. This is not
 ]    to say that we could never end up with having to announce something
 ]    bigger than 255, but I'd like to see an example of where this becomes
 ]    a problem we can't get around.

Ok, let me list some of the reasoning here, others can contribute too,

 - network transition is not easy, it can takes years to finish, for
   all the boxes converge into the same capabilities.

 - a pure historical note: at the time we desgined the Multi-Topology
   IS-IS, there was a choice to use the existing TLV 22 and 135. But the
   major concern at the time was if there were multiple topologies using
   TE (not even talking about GMPLS), then the 255 bytes of the TLV would
   be a serious limitation and we could not make such a choice. Thus we
   now have the TLV 222 and 235.

 - as Dimitri yesterday mentioned, in gmpls application usage, the
   tlv limitation is a concern.

 - diffServ TE usage for isis, 'clasic TE' is only a special case in
   diffsrv TE. diffserv TE can contain a lot more data.

 - when we have something like isis capability tlv, there will be various
   'features'/ 'capabilities' a system needs to announce, they could be
   split into multiple tlvs. then there is a concern how to keep track
   of the versions of the 'capability' changes if they spread over
   multiple tlvs/packets. it would be much easier, if the capability
   tlvs are kept within the same tlv, then there will be no mistake
   how to read the newer/older version of changes. (this was heavily
   discussed among the isis cap draft co-authors, and it was the trigger
   for me(us) to revisit this isis tlv limitation issue)

i don't believe that we don't have a problem currently. we may not
have a hard limit problem at hand right now, but why we are willing
to live with this limitation for isis, and why not create the capability
when the problem is still in a 'soft' state ?

 ] 
 ] 3. Naming mentioned in his slides that backwards-compatible deployment
 ]    is possible. I wasn't sure it was. Now that I re-read the draft, I'm
 ]    sure it is not possible. Routers not implementing this feature will
 ]    encounter a TLV parsing error, since the what they believe is the 1-octet
 ]    length field will contain wrong value for TLVs bigger than 255 octets.

during transitional tlv mode, a system is not allowed to generate this
extended tlv larger than the 255 octets. this is mentioned in the network
transition section of the draft. this is no different from the TE metric
transition, the wide metric can not have the value over 63. this is why
if we are going to move to this new scheme, better to do it long before when
the >255 octect is really needed.

thanks.

 ] 
 ] -- 
 ] Alex
 ] http://www.psg.com/~zinin
 ] 
 ] 
 ] _______________________________________________
 ] Isis-wg mailing list
 ] [email-masked]
 ] https://www1.ietf.org/mailman/listinfo/isis-wg

- Naiming