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

["Acee Lindem (acee)" <[e-mail]>]

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
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?

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 (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