Re: [OSPF] Suresh Krishnan's Discuss on draft-ietf-ospf-encapsulation-cap-06: (with DISCUSS and COMMENT)

[Suresh Krishnan <[e-mail]>]

Hi all,
  Just closing the loop on this. Acee and I had a phone call to discuss this issue. It looks like Acee was thinking that I was talking about the value in the TLV while I was talking about the type and the length (as per my DISCUSS text). We agreed that the type and length will be encoded as per this document and the value as per the referred documents. The new text from Bruno resolves my issues.

Regards
Suresh

> On Aug 31, 2017, at 10:39 AM, Acee Lindem (acee) <[e-mail]> wrote:
> 
> Hi Suresh, 
> 
> From: Suresh Krishnan <[e-mail] <mailto:[e-mail]>>
> Date: Thursday, August 31, 2017 at 10:06 AM
> To: Acee Lindem <[e-mail] <mailto:[e-mail]>>
> Cc: The IESG <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, OSPF WG List <[e-mail] <mailto:[e-mail]>>
> Subject: Re: Suresh Krishnan's Discuss on draft-ietf-ospf-encapsulation-cap-06: (with DISCUSS and COMMENT)
> 
> Hi Acee,
>   Thanks for the quick reply. Please find comments inline.
> 
>> On Aug 31, 2017, at 5:50 AM, Acee Lindem (acee) <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Hi Suresh, 
>> 
>> On 8/30/17, 10:49 PM, "Suresh Krishnan" <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Suresh Krishnan has entered the following ballot position for
>> draft-ietf-ospf-encapsulation-cap-06: Discuss
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/ <https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/>
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> * There seems to be an difference between this document's definition of
>> sub-TLVs (with 2 octet types and lengths) and those of RFC5512 (with 1 octet
>> types and lengths). So I am surprised to see the document point to the RFC5512
>> based TLVs for both syntax and semantics (Sections 5.1, 5.2, 5.3 ...) . Can you
>> please explain how these sub-TLVs are encoded on the wire to be compatible with
>> this draft?
>> 
>> I can answer this one since I specifically told the authors to use this format. If you look at RFC 7770, you’ll see that all OSPF Router Information (RI) LSA TLVs and Sub-TLVs have 2 octet types and lengths. 
>> 
>> 2.3. OSPF Router Information LSA TLV Format
>> 
>> The format of the TLVs within the body of an RI LSA is the same as
>> the format used by the Traffic Engineering Extensions to OSPF [TE].
>> The LSA payload consists of one or more nested Type/Length/Value
>> (TLV) triplets. The format of each TLV is:
>> 
>>  0 1 2 3
>>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Type | Length |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Value... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> 
>> Figure 3. TLV Format
>> 
>> 
>> Additionally, if you look at https://www.ietf.org/id/draft-ietf-idr-tunnel-encaps-07.txt <https://www.ietf.org/id/draft-ietf-idr-tunnel-encaps-07.txt> (which obsoletes RFC 5512), you’ll see that the 1 octet length with insufficient. 
>> 
>>    Each sub-TLV consists of three fields: a 1-octet type, a 1-octet or
>>    2-octet length field (depending on the type), and zero or more octets
>>    of value.  A sub-TLV is structured as shown in Figure 2:
>> 
>>                    +-----------------------------------+
>>                    |      Sub-TLV Type (1 Octet)       |
>>                    +-----------------------------------+
>>                    |     Sub-TLV Length (1 or 2 Octets)|
>>                    +-----------------------------------+
>>                    |     Sub-TLV Value (Variable)      |
>>                    |                                   |
>>                    +-----------------------------------+
>> 
>>                Figure 2: Tunnel Encapsulation Sub-TLV Format
>> 
>>    o  Sub-TLV Type (1 octet): each sub-TLV type defines a certain
>>       property about the tunnel TLV that contains this sub-TLV.
>> 
>> 
>> 
>> 
>> 
>> Rosen, et al.           Expires January 18, 2018                [Page 7]
>> ?
>> Internet-Draft       Tunnel Encapsulation Attribute            July 2017
>> 
>> 
>>    o  Sub-TLV Length (1 or 2 octets): the total number of octets of the
>>       sub-TLV value field.  The Sub-TLV Length field contains 1 octet if
>>       the Sub-TLV Type field contains a value in the range from 1-127.
>>       The Sub-TLV Length field contains two octets if the Sub-TLV Type
>>       field contains a value in the range from 128-254.
>> 
>>    o  Sub-TLV Value (variable): encodings of the value field depend on
>>       the sub-TLV type as enumerated above.  The following sub-sections
>>       define the encoding in detail.
> I did read the draft-ietf-idr-tunnel-encaps-07 draft (following it from the references) and I do understand why the document made the switch to 2 octets for the length. The part that threw me off is that this document (ospf-encapsulation) mandates *2 Octet* sub-TLV types which are not even mentioned in draft-ietf-idr-tunnel-encaps-07. Similarly this document mandates 2 octet lengths without nuancing the length based on sub-TLV type (>127 or not). And then it states that the syntax is specified in the documents that use 1 octet types. This is the discrepancy that needs addressing.
> 
> No it doesn’t…  The OSPF RI TLVs and Sub-TLVs have uniform 2 octet types and lengths as specified in RFC 7770. If all the routing protocols had exactly the same encodings, we’d only have one ;^) 
> 
> Thanks,
> Acee 
> 
> 
> Thanks
> Suresh
>