Subject: [sfc] A problem with NSH TLV

From: Dave Dolson <[email-masked]>
Date: Mon, 11 Jul 2016 19:00:31 +0000

As specified in https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.5.1

This is the TLV format:
        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Metadata Class       |C|    Type     |R|R|R|   Len   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Variable Metadata                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Len is defined as number of 4-byte words.
The problem with this is that strings aren't always multiples of 4 bytes in length.

E.g., in https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01, this example is given:

   10.  Universal Resource Identifier (URI)

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         TLV Class = 0x0       |C|    Type=0xA |R|R|R|   L=var |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |UT(4)  |                URI                                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                        URI                                    ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Despite the confusing part about the first nybble being used for UT field (supposed to be an octet?),
if the URI is not a multiple of 4 bytes, how is it to be terminated?

Diameter (RFC6733) solves this problem nicely by making the length indicate a number of octets, while specifying padding to 4-octet alignment for the next element.

So my proposal is to recruit two of the 'R' bits into the 'L' field, and have it indicate number of octets; and also say that padding is to be inserted so that each TLV is a multiple of 4 octets in length.

David Dolson
Senior Software Architect, Sandvine Inc.

---

From: Ron Parker <[email-masked]>
Date: Mon, 11 Jul 2016 19:12:28 +0000

Hi, Dave.

I agree that valid length must be indicated even when not a multiple of 4 octets and agree with your solution.   A description of alignment within the 4 octets should be part of the text, as well - fields whose lengths are not multiples of 4 are "left justified" towards the lower octet numbers with zero-value padding inserted at the higher octet numbers.

Do you think this is justification to bump the version number of the NSH, since implementations are already fielded?    In v0, the length is interpreted as a 5-bit count of 4-octet units.   In v1, the length is interpreted as a 7-bit count of octets.

If the community is opposed to bumping the version, another approach would be to use bits 25 and 26 as a pad-length field.  Bits 27-31 would continue to be length in 4-octet units, but 25 and 26 specify how many of the bytes at the highest octet numbers are considered to be pad bytes (values 0..3).

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Monday, July 11, 2016 3:01 PM
To: [email-masked]
Subject: [sfc] A problem with NSH TLV

This is the TLV format:
        0                   1                   2                   3

David Dolson

---

From: Dave Dolson <[email-masked]>
Date: Mon, 11 Jul 2016 20:15:02 +0000

Ron,
I agree your solution to use bits 25-26 to indicate padding would be backwards compatible if anyone is concerned about backwards compatibility.
I'd be OK with that.

-Dave

From: Ron Parker [mailto:[email-masked]]
Sent: Monday, July 11, 2016 3:12 PM
To: Dave Dolson; [email-masked]
Subject: RE: A problem with NSH TLV

Hi, Dave.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Monday, July 11, 2016 3:01 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [sfc] A problem with NSH TLV

This is the TLV format:
        0                   1                   2                   3

David Dolson