RE: GMPLS TLV Format

["Drake, John E" <John.E.Drake2@boeing.com>]

Indeed 

>-----Original Message-----
>From: Lou Berger [mailto:lberger@labn.net] 
>Sent: Monday, March 10, 2008 1:38 PM
>To: Adrian Farrel
>Cc: ccamp@ops.ietf.org
>Subject: Re: GMPLS TLV Format
>
>Just to avoid any possible silence:
>
>I think fixing RFC 4420 *quickly* would be best.
>
>Lou
>
>At 04:02 PM 3/10/2008, Adrian Farrel wrote:
>>Hi,
>>
>>In today's meeting, we discussed again the issue of TLV formats in:
>>
>>- RFC 3209 and RFC 3471
>>- RFC 4420
>>- draft-ietf-ccamp-ethernet-traffic-parameters-03.txt
>>
>>The current position is:
>>- Base RSVP-TE and GMPLS carry the full length of the
>>  TLV in the Length field
>>- OSPF carries the length of the Value field only in the
>>  TLV
>>- RFC 4420 follows the OSPF form. This was an error
>>   that was not intended.
>>- draft-ietf-ccamp-ethernet-traffic-parameters followed
>>   RFC 4420 (assuming that the WG had made a deliberate
>>   change)
>>
>>The bottom line is that it is not helpful to implementers that one 
>>protocol has two different ways to encode TLVs.
>>
>>We must choose between three options.
>>1. All TLVs are encoded as per RFC 3209.
>>    RFC 4420 would need to be fixed.
>>   draft-ietf-ccamp-ethernet-traffic-parameters would
>>    need to be changed.
>>2. All TLVs *except* those in RFC 4420 use the
>>    RFC 3209 format. RFC 4420 remains an anomaly.
>>3. All old TLVs remain as per RFC 3209. All new
>>    TLVs (starting from RFC 4420) use the RFC 4420
>>    format.
>>
>>The meeting seemed to prefer option 1, but this is contingent on 
>>existing implementations. If there are too many existing and deployed 
>>implementations (too many == 1 ?) we may have to pick to option 2.
>>
>>So...
>>
>>How would you feel if we did an update to RFC 4420 that fixed the TLV 
>>encoding to be conformant with RFC 3209? Would this cause any 
>of you a 
>>problem?
>>
>>Reply on-list or to me in private if there is a confidentiality issue.
>>
>>It would be helpful to have opinions on both sides. Please 
>don't leave 
>>silence to mean anything specific.
>>
>>Thanks,
>>Adrian
>>
>>
>>
>
>
>