Subject: Re: [sfc] A problem with NSH TLV

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 11 Jul 2016 20:51:23 +0000

Why does it need to be backward compatible? If you had (or have) this problem now you would not be able to make it work anyway.

We solved this some time back by specifying the following for strings that do not finish on proper boundaries.

   SF Type:  A string representing the SF type padded to a 4-byte
      boundary and encoded with UTF-8.  Service types can be found and
      registered in [I-D.penno-sfc-yang<https://tools.ietf.org/html/draft-penno-sfc-trace-03#ref-I-D.penno-sfc-yang>].

From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of Dave Dolson <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 11, 2016 at 5:15 PM
To: Ron Parker <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] A problem with NSH TLV

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]<mailto:[email-masked]>
Subject: RE: A problem with NSH TLV

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]<mailto:[email-masked]>
Subject: [sfc] A problem with NSH TLV

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 20:59:05 +0000

Reinaldo,

Regarding backward compatibility, this was a question to the community, not a statement.   Thanks for providing your answer.

For strings, NULL termination and padding makes sense, but we would want to be explicit that strings always included the NULL.

For small native types (1 octet, 2 octet), there could also be explicit language about how to map into the 4 octet field.

But, for arbitrary octet strings, only an octet oriented length (or the octet pad length) would suffice.   I feel that type 2 metadata should include the ability to carry octet strings.

   Ron

From: Reinaldo Penno (repenno) [mailto:[email-masked]]
Sent: Monday, July 11, 2016 4:51 PM
To: Dave Dolson <[email-masked]>; Ron Parker <[email-masked]>; [email-masked]
Subject: Re: [sfc] A problem with NSH TLV

Ron,

-Dave

Hi, Dave.

   Ron

This is the TLV format:
        0                   1                   2                   3

David Dolson

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 11 Jul 2016 21:02:01 +0000

From: Ron Parker <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 11, 2016 at 5:59 PM
To: Reinaldo Penno <[email-masked]<mailto:[email-masked]>>, Dave Dolson <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [sfc] A problem with NSH TLV

Reinaldo,

[RP] Right, if the minimum size is 4 octets for example.

   Ron

From: Reinaldo Penno (repenno) [mailto:[email-masked]]
Sent: Monday, July 11, 2016 4:51 PM
To: Dave Dolson <[email-masked]<mailto:[email-masked]>>; Ron Parker <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] A problem with NSH TLV

Ron,
I’d be OK with that.

-Dave

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.

   Ron

This is the TLV format:
        0                   1                   2                   3

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.

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

---

From: Dave Dolson <[email-masked]>
Date: Mon, 11 Jul 2016 21:09:17 +0000

I feel that binary data should be supported. (I believe Ron is saying the same by "octet strings")
I.e., strings with nulls in them.
Hence, without length it would not be known whether null padding is part of the data or not.

From: Reinaldo Penno (repenno) [mailto:[email-masked]]
Sent: Monday, July 11, 2016 5:02 PM
To: Ron Parker; Dave Dolson; [email-masked]
Subject: Re: [sfc] A problem with NSH TLV

Reinaldo,

   Ron

Ron,

-Dave

Hi, Dave.

   Ron

This is the TLV format:
        0                   1                   2                   3

David Dolson

---

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

Yes, by octet strings I was meaning binary (as opposed to UTF-8/ASCII type strings).

Thanks.

   Ron

From: Dave Dolson [mailto:[email-masked]]
Sent: Monday, July 11, 2016 5:09 PM
To: Reinaldo Penno (repenno) <[email-masked]>; Ron Parker <[email-masked]>; [email-masked]
Subject: RE: [sfc] A problem with NSH TLV

From: Reinaldo Penno (repenno) [mailto:[email-masked]]
Sent: Monday, July 11, 2016 5:02 PM
To: Ron Parker; Dave Dolson; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] A problem with NSH TLV

Reinaldo,

   Ron

Ron,

-Dave

Hi, Dave.

   Ron

This is the TLV format:
        0                   1                   2                   3

David Dolson

---

From: Sumandra Majee <[email-masked]>
Date: Tue, 12 Jul 2016 00:06:05 +0000

>>But, for arbitrary octet strings, only an octet oriented length (or the octet pad length) would suffice.   I feel that type 2 metadata should include the ability to carry octet strings

Yeah, I agree that it is better to represent LEN as number of octets. I believe the current LEN is set as number of 4 byte/octet because it makes it consistent with the main NSH header length. But I agree that individual TLV len should be represented as number of octets.

From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of Ron Parker <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 11, 2016 at 1:59 PM
To: "Reinaldo Penno (repenno)" <[email-masked]<mailto:[email-masked]>>, Dave Dolson <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] A problem with NSH TLV

But, for arbitrary octet strings, only an octet oriented length (or the octet pad length) would suffice.   I feel that type 2 metadata should include the ability to carry octet strings