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) <[email protected]> wrote:
> 
> Hi Suresh, 
> 
> From: Suresh Krishnan <[email protected] 
> <mailto:[email protected]>>
> Date: Thursday, August 31, 2017 at 10:06 AM
> To: Acee Lindem <[email protected] <mailto:[email protected]>>
> Cc: The IESG <[email protected] <mailto:[email protected]>>, 
> "[email protected] 
> <mailto:[email protected]>" 
> <[email protected] 
> <mailto:[email protected]>>, "[email protected] 
> <mailto:[email protected]>" <[email protected] 
> <mailto:[email protected]>>, OSPF WG List <[email protected] 
> <mailto:[email protected]>>
> 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) <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>> Hi Suresh, 
>> 
>> On 8/30/17, 10:49 PM, "Suresh Krishnan" <[email protected] 
>> <mailto:[email protected]>> 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
> 

_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf

Reply via email to