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

From: <[email-masked]>
Date: Mon, 18 Sep 2017 15:20:11 +0000

Suresh,

Thanks for the review and comments.
Please see inline [Bruno]

> From: Suresh Krishnan [mailto:[email-masked]]
 > Sent: Thursday, August 31, 2017 4:50 AM
> 
 > 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
 > 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/
 > 
 > 
 > 
 > ----------------------------------------------------------------------
 > 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?
 
[Bruno] Would the following change works for you?

OLD:
        This Sub-TLV of type 2 is defined in Section 3.4.1 "Protocol Type
        sub-TLV" of <xref target="I-D.ietf-idr-tunnel-encaps"/> from a
        syntactic, semantic, and usage standpoint.

NEW:
        This Sub-TLV type is 2. The syntax, semantic, and usage of its value field is defined in Section 3.4.1 "Protocol Type
        sub-TLV" of <xref target="I-D.ietf-idr-tunnel-encaps"/>.

 > ----------------------------------------------------------------------
 > COMMENT:
 > ----------------------------------------------------------------------
 > 
 > * IANA considerations
 > 
 > Looks like the value 65535 is included both as experimental and reserved. Suggest changing
 > 
 > OLD:
 > 65500-65535    Experimental                              This document
 > 
 > NEW:
 > 65500-65534    Experimental                              This document
 > 

[Bruno] Good catch. Thanks for the careful review. Fixed as per you suggestion in -07 https://tools.ietf.org/rfcdiff?url2=draft-ietf-ospf-encapsulation-cap-07.txt

--Bruno

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 18 Sep 2017 16:21:44 -0400

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-masked]> wrote:
> 
> Hi Suresh, 
> 
> From: Suresh Krishnan <[email-masked] <mailto:[email-masked]>>
> Date: Thursday, August 31, 2017 at 10:06 AM
> To: Acee Lindem <[email-masked] <mailto:[email-masked]>>
> Cc: The IESG <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, OSPF WG List <[email-masked] <mailto:[email-masked]>>
> 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-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Suresh, 
>> 
>> On 8/30/17, 10:49 PM, "Suresh Krishnan" <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
>> https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/ <https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/>
>> 
>> 
>> 
>> 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
>

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 18 Sep 2017 16:24:42 -0400

Hi Bruno,
  Thanks for the changes.

> On Sep 18, 2017, at 11:20 AM, <[email-masked]> <[email-masked]> wrote:
> 
> Suresh,
> 

Excellent. That would address my concerns. I checked the new version of the draft and this fix addresses all of the instances of this issue. I will clear.

> [Bruno] Good catch. Thanks for the careful review. Fixed as per you suggestion in -07 https://tools.ietf.org/rfcdiff?url2=draft-ietf-ospf-encapsulation-cap-07.txt <https://tools.ietf.org/rfcdiff?url2=draft-ietf-ospf-encapsulation-cap-07.txt>

Great.

Regards
Suresh