Subject: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh

From: Loa Andersson <[email-masked]>
Date: Sun, 17 Apr 2016 15:27:41 +0800

Working Group, authors,

I'm reading draft-ietf-sfc-nsh-04 (sorry to not have been able to read
it before now) and have a question on how the TLV concept is understood
in the draft.

For example in LDP TLV were defined as Type, Length Value, e.g. (from
RFC 5036 section 3.3):

    LDP uses a Type-Length-Value (TLV) encoding scheme to encode much of
    the information carried in LDP messages.

    An LDP TLV is encoded as a 2 octet field that uses 14 bits to specify
    a Type and 2 bits to specify behavior when an LSR doesn't recognize
    the Type, followed by a 2 octet Length field, followed by a variable
    length Value field.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |U|F|        Type               |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                             Value                             |
    ~                                                               ~
    |                                                               |
    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In draft-ietf-sfc-nsh-04 the TLV structure seems a bit more complicated
and I'm struggling a bit to understand if the "name" TLV should be used.

 From draft-ietf-sfc-nsh-04

         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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          TLV Class            |C|    Type     |R|R|R|   Len   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                      Variable Metadata                        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 6: Variable Context Headers

The draft is not entirely clear in this respect, but I think this is 
what you call a TLV.

Should I understand this way?

Type = TLV Class + C + Type (24 bits)
Length = len (5 bits)
Value = Variable Metadata

A convention we used in MPLS when we have variable length fields is
to use a ~ instead of the |, like this:.

         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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          TLV Class            |C|    Type     |R|R|R|   Len   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ~                      Variable Metadata                        ~
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I suggest that this is a good practice that could be adopted here also.

Two more questions:

If the metadata does not align exactly with the 32 bit/4 byte structure,
what is the rules for padding?

A last, but a bit different question, do you need indicators like the U
and F flags in an to indicate what should happen if the node does not
recognize the (TLV Class, C, Type)-field?

/Loa

PS

I will also have a few more editorial comments that will be sent to
the authors within a day or two.

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Azhar Sayeed <[email-masked]>
Date: Mon, 18 Apr 2016 10:33:31 -0400

Loa,

+1 Agree and not just LDP, but BFD TLV or any of the ISIS TLVs have the same structure - This should also be consistent..the question then is can the current TLV structure in draft-~nsh-04 be re-configured to align with all the other TLV’s structure? 

Azhar

> On Apr 17, 2016, at 3:27 AM, Loa Andersson <[email-masked]> wrote:
> 
> Working Group, authors,
> 
> The draft is not entirely clear in this respect, but I think this is what you call a TLV.
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: Dave Dolson <[email-masked]>
Date: Mon, 18 Apr 2016 14:58:38 +0000

On the point of rules for padding, I raised this some time ago
(first bullet in https://mailarchive.ietf.org/arch/msg/sfc/Ag5JBto2inEbAuYInyUh2kK3VYg)

It would be more useful to have length specified in bytes, with padding to 4-byte alignment.
Otherwise, I guess variable metadata must have a second length field within it?

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Sunday, April 17, 2016 3:28 AM
To: [email-masked]; [email-masked]
Subject: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh

Working Group, authors,

     0                   1                   2                   3

         0                   1                   2                   3

         0                   1                   2                   3

Two more questions:

/Loa

PS

--

---

From: <[email-masked]>
Date: Tue, 19 Apr 2016 07:48:05 +0000

Dear Loa, all, 

Thank you for raising this point about the encoding of the optional context information.  

I agree that the use of TLV term is confusing. What about using another term, e.g., "Information Elements", "Options", or "Context Element"? 

As an input to this discussion, below a proposal for an encoding that achieves the following goals:

* Shorten the encoding of the Class field.
* Allow for more type code points.
* Avoids requiring padding for the sake of compact headers.
* Allows to include the ID of the entity that injected the context information (OPTIONAL). 
* Inherit rich registries such as IPFIX.

NOTE: This proposal does not include a dedicated flag bit to indicate whether the context element is mandatory-to-process or optional-to-process because further discussion/text specification is required: e.g.,
* Wouldn't be sufficient to supply that information using the control plane?
* If that information is supplied in both the context element and configured to a SFC-aware function, how conflicts are managed?
* What is the behavior for processing mandatory-to-process elements (particularly, when it is not supported)?  
* Is it required to recommend an ordering of supplying the mandatory-to-process or optional-to-process elements?
* Is it required to preserve the same ordering when forwarding a packet?

==PROPOSAL====  

Base version
        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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Class  |            Type               | FLAGS |     Length    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      //                           Data (Variable)                    //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version with Originator ID:
        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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Class  |            Type               | Flags |     Length    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      //Originator Len|     Originator ID (Variable)(Optional)       //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      //                           Data (Variable)                    //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The description of the fields is as follows:

      Class:  In order to foster service innovation, this field
         allows to inherit from existing code point registries that are
         likely to be useful in a SFC context.  The following values are
         reserved by this specification:
         0:  See IANA section.
         1:  IPFIX [IPFIX].

      Type:  Indicates the code point of the context element.  If
         "Class" field is non-null, the interpretation of this field MUST
         conform to the one defined for that specific class registry. See IANA section.

      Flags:  The Flags field comprises a set of 4 flags:

             +-+-+-+-+
             |S|r|r|r|
             +-+-+-+-+

             where "rrr" are reserved bits for future assignment as
             additional flag bits. r bits MUST each be sent as zero and MUST be
             ignored on receipt.

             When set, the S-flag indicates that an Originator ID field is
             present in the context element.  This flag is set by default to 0, meaning
             there is no Originator ID field present in the element.

      Originator ID (Optional):  Conveys the identifier of the entity that injected
         this context element in the NSH header (e.g., a service
         function identifier, a classifier, etc.).  This document does
         not make any assumption about the structure of the information
         carried in this field because this is deployment-specific.
         This information is used by SFC-aware elements to enforce
         policies such as: process a context information if and only if
         it was supplied by a given entity.  This information can be
         used as a safeguard against misbehaving nodes that inject
         illegitimate data in the NSH header.

         This field MUST be included only if S-bit is set.     

      Length:  Indicates, in octets, the length of the data carried in
         the context element.

      Data (Variable):  The semantics of this field depend on the
         "Class" and "Type" fields.
===============

Opinions?

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[email-masked]] De la part de Loa Andersson
> Envoyé : dimanche 17 avril 2016 09:28
> À : [email-masked]; [email-masked]
> Objet : [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on
> TLVs in draft-ietf-sfc-nsh
> 
> Working Group, authors,
>

---

From: Azhar Sayeed <[email-masked]>
Date: Tue, 19 Apr 2016 16:16:34 -0400

Hi Med,

You can still encode this as a TLV by re-arranging the fields with Type first, length and then value - In the value portions you can a mandatory bytes that encode the flags, class, originator id and then variable metadata

So here is an option.

Type - 16 bits
Length - 16 bits
Value:
Flags - 4 bits
Class - 4 bits
Originator Length - 8 bits
Originator ID - Variable
Data Variable

+1 to the idea of originator id.

Azhar

> On Apr 19, 2016, at 3:48 AM, [email-masked] wrote:
> 
> Dear Loa, all, 
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 20 Apr 2016 02:35:17 +0000

Hi, Loa,

Good analysis on the format of these information elements.

My sense is that a hierarchical syntax (such as the Class/Type-Length-Value) provides much more flexibility than a flat Type-Length-Value alone.

We’ve built quite a number of protocols with this structure and allocation scheme. For example, RSVP (https://tools.ietf.org/html/rfc3209#section-7.2), L2TPv3 (https://tools.ietf.org/html/rfc3931#section-5.1), ICMP Multi-Part Extensions (https://tools.ietf.org/html/rfc4884#section-8).

Regardless of what we call the fields (e.g., Class and Type, or Type and Sub-Type, or …), there are clear technical advantages to this, including the ability to delegate allocation, vendor types, etc.

In regards to the U/F bits in LDP, I think the C-bit in NSH TLVs achieves what’s really needed for an SFC Encap.

Lastly, you call out padding and 32-bit-word alignment. This is a great point.

The way things seems structured now, there’s a Len field measured in 32-bit words. It’s not clear what happens when the Metadata (Value) itself is not 32-bit-word-aligned. This needs fixing.

Looking at the Length definition:

   Length: Length of the variable metadata, in 4-byte words.  A value of
   0x0 or higher can be used.  A value of 0x0 denotes a TLV header
   without a Variable Metadata field.

Comments:
* First, instead of “4-byte” words, this needs to be “4-octet” or “32-bit” words. Byte is strictly machine dependent (7 bits, 8 bits, etc).
* Second, “a value of 0x0 or higher” for an unsigned value does not say much.

Hope these help.

Thanks,

— Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 20 Apr 2016 02:41:52 +0000

Azhar,

-1 :-)

Within the IETF-specified protocols, we can certainly find examples of most syntax and structures, from the simple to the too creative ones. Finding a protocol with a specific TLV structure does not mean that that’s the best for every protocol use.

You say: "This should also be consistent”.

However, just to understand your point, what is the technical reason for NSH TLV structs having to match BFD structs and ISIS structs? And why not, say, RSVP’s or ICMP Multipart’s or L2TPv3’s (which, incidentally, use a Class/Type-length-value format)?

When you say “ to align with all the other TLV’s structure” — I ask: why?

If we think of the goal of flexibility (main goal of Type 2) in the context of most flexible allocation, a hierarchical scheme is a technical answer. Given the rich ecosystem of vendors and open source projects, the proposed structure, in my humble opinion, future proofs the design.

— Carlos.

> On Apr 18, 2016, at 10:33 AM, Azhar Sayeed <[email-masked]> wrote:
> 
> Loa,
>

---

From: <[email-masked]>
Date: Wed, 20 Apr 2016 05:44:41 +0000

Hi Azhar, 

Thank you for the feedback and the support for the originator ID. 

The re-arranging of the fields you propose is indeed another option, but it does not allow a compact header, e.g., 16 bits for the length is too much for the cases I'm aware of + it is not optimal if no originator ID is to be supplied for instance. 

Having the class, type, flags, and length in the first 32 bits would lead to a compact header. 

Cheers,
Med

> De : Azhar Sayeed [mailto:[email-masked]]
> Envoyé : mardi 19 avril 2016 22:17
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Loa Andersson; [email-masked]; [email-masked]
> Objet : Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions
> on TLVs in draft-ietf-sfc-nsh
> 
> Hi Med,
> 
> You can still encode this as a TLV by re-arranging the fields with Type
> first, length and then value - In the value portions you can a mandatory
> bytes that encode the flags, class, originator id and then variable
> metadata
> 
> So here is an option.
> 
> Type - 16 bits
> Length - 16 bits
> Value:
> Flags - 4 bits
> Class - 4 bits
> > I agree that the use of TLV term is confusing. What about using another
> term, e.g., "Information Elements", "Options", or "Context Element"?
> >
> > NOTE: This proposal does not include a dedicated flag bit to indicate
> whether the context element is mandatory-to-process or optional-to-process
> because further discussion/text specification is required: e.g.,
> > * If that information is supplied in both the context element and
> configured to a SFC-aware function, how conflicts are managed?
> > * What is the behavior for processing mandatory-to-process elements
> (particularly, when it is not supported)?
> >>        |                      Variable Metadata
> |
> >>        ~                      Variable Metadata
> ~

---

From: <[email-masked]>
Date: Wed, 20 Apr 2016 06:30:02 +0000

Hi all, 

I agree with Carlos that a hierarchical structure is more flexible, but I have the following comments: 

* Almost all the RFCs quoted by Carlos do not claim to use a TLV structure or the TLV term. It is reasonable to update the nsh spec to use a term that does not lead to confusion. I see that Carlos is using "information element". It is also in my favorite list (with a preference for context element). 
* Some of these RFCs use a bit that is similar to the C-bit, but they rightfully don't mix it with the ID of the attribute. 
* Some of these RFCs specify (e.g., Section 5.2 of RFC3931) in details the behavior when the "C-bit"-like is set. 

The NSH spec still need more work. 

Cheers,
Med

> De : sfc [mailto:[email-masked]] De la part de Carlos Pignataro
> (cpignata)
> Envoyé : mercredi 20 avril 2016 04:35
> À : Loa Andersson
> Cc : [email-masked]; [email-masked]
> My sense is that a hierarchical syntax (such as the Class/Type-Length-
> Value) provides much more flexibility than a flat Type-Length-Value alone.
> 
> We’ve built quite a number of protocols with this structure and allocation
> scheme. For example, RSVP (https://tools.ietf.org/html/rfc3209#section-
> 7.2), L2TPv3 (https://tools.ietf.org/html/rfc3931#section-5.1), ICMP
> Multi-Part Extensions (https://tools.ietf.org/html/rfc4884#section-8).
> 
> Regardless of what we call the fields (e.g., Class and Type, or Type and
> Sub-Type, or …), there are clear technical advantages to this, including
> the ability to delegate allocation, vendor types, etc.
> 
> The way things seems structured now, there’s a Len field measured in 32-
> bit words. It’s not clear what happens when the Metadata (Value) itself is
> not 32-bit-word-aligned. This needs fixing.
> 
> * First, instead of “4-byte” words, this needs to be “4-octet” or “32-bit”
> words. Byte is strictly machine dependent (7 bits, 8 bits, etc).

---

From: Loa Andersson <[email-masked]>
Date: Wed, 20 Apr 2016 15:51:19 +0800

Carlos,

Thanks for this, I don't think we are too far apart, and I have a
suggestion that I hope resolve this.

> My sense is that a hierarchical syntax (such as the Class/Type-Length-Value) provides much more flexibility than a flat Type-Length-Value alone.

I tend to agree with that, but that is an argument on if the flexibility
is needed. I think it is for the NSH.

My point is that TLV is "named" for its structure, if an element does
notm have that structure it is simply not a TLV.

On the highest level I do not have a problem with the layout of the
Variable Context Headers, but currently it is not clear why we call
it a TLV. It could be made clear though.
> We’ve built quite a number of protocols with this structure and allocation scheme. For example, RSVP (https://tools.ietf.org/html/rfc3209#section-7.2), L2TPv3 (https://tools.ietf.org/html/rfc3931#s…
Indeed, but of the three documents you refer to only the L2TPv3
document mention TLV, and only on a very high level in the terminology
section.

> Regardless of what we call the fields (e.g., Class and Type, or Type and Sub-Type, or …), there are clear technical advantages to this, including the ability to delegate allocation, vendor types, e…
My point was that what we call things matter.

> In regards to the U/F bits in LDP, I think the C-bit in NSH TLVs achieves what’s really needed for an SFC Encap.
This is the response I expected, though I'm still not entirely
comfortable, e.g. what do you do if you don't recognize the class
and the C bit is not set?

> * Second, “a value of 0x0 or higher” for an unsigned value does not say much.

Agree to changing to "octet".

Actually the Len field is 5 bits, gives us 32 variants, zero means
"none", while 31 means 31 x 4 = 124 octets.

What I suggest that we add (we can continue to discuss sizes of the 
differnt fields). I've not look closely where my text would fit
exactly.

3.5.1. Optional Variable Length Metadata

   Optional variable length metadata are encoded as Variable Context
   Header TLVs The Variable Context Headers TLV has the same structure
   as TLVs defined in e.g. the LDP and BFD protocols, Type, Length and
   Value.

   However in the Variable Context Header TLV the Type field have an
   internal structure TLV Class, C-bit and Type.

    The format of the optional variable length context header TLVs, is as
    described below.

         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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          TLV Class            |C| TLV-Type    |R|R|R|   Len   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                      Variable Metadata                        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type: The type field has three sub-fields, TLV Class, TLV Type and
    Len, the TLV-Type and Len fields have an internal structure.

      TLV Class: The TLV Class field is 16 bits and describes the scope
      of the "Type" field.  In some cases, the TLV Class will identify a
      specific vendor, in others, the TLV Class will identify specific
      standards body allocated types.  A new IANA registry will be
      created for TLV Class type.

      Type: The TLV-Type field is 8 bits and the specifies the type of
      information carried in the Variable Metadata field, within the
      scope of a given TLV Class.  Value allocation is the responsibility
      of the TLV Class owner.

      The Critical bit (C-bit); 1 bit, encoding the criticality of the
      TLV-type. The C-bit is part of the TLV-Type field and is
      consistent with IPv6 option types. The C-bit (the most significant
      bit of the TLV-Type field) indicates whether the TLV is mandatory
      for the receiver to understand/process.  This effectively allocates
      TLV-Type values 0 to 127 for non-critical options and Type values
      128 to 255 for critical options.  Figure 7 below illustrates the
      placement of the Critical bit within the Type field.

      +-+-+-+-+-+-+-+-+
      |C|     Type    |
      +-+-+-+-+-+-+-+-+

         Figure 7: Critical Bit Placement Within the TLV Type Field

      If a receiver receives an encapsulated packet containing a TLV with
      the Critical bit set to 0x1 in the Type field and it does not
      understand how to process the Type, it MUST drop the packet.
      Transit devices MUST NOT drop packets based on the setting of this
      bit.

      Length: The length field is 8 bits are reserved, three most
      significant bits (R) are reserved for future use. The length field
      indicates the length of the variable metadata, in 4-octet words. A
      value of 0x0 or higher can be used. A value of 0x0 denotes a
      Variable Context Header TLV without a Variable Metadata field.

Note: as always when I write English a grammar review is necessary!

Hope I did not screw this up too badly.

/Loa

---

From: <[email-masked]>
Date: Wed, 20 Apr 2016 08:09:43 +0000

Dear Loa, 

Thank you for drafting a NEW text that is better to the one in -04. Nevertheless, I still have issues with it but I will focus only on one item that it is related to this text: 

"This effectively allocates
      TLV-Type values 0 to 127 for non-critical options and Type values
      128 to 255 for critical options."

Do you have an example of an optional context information that is "critical" in all deployments, all chains? Wouldn't this be left to the taste of the entity administrating an SFC-enabled domain?

Thank you.

Cheers,
Med

> Envoyé : mercredi 20 avril 2016 09:51
> À : Carlos Pignataro (cpignata)
> > We’ve built quite a number of protocols with this structure and
> allocation scheme. For example, RSVP
> (https://tools.ietf.org/html/rfc3209#section-7.2), L2TPv3
> (https://tools.ietf.org/html/rfc3931#section-5.1), ICMP Multi-Part
> Extensions (https://tools.ietf.org/html/rfc4884#section-8).
> >
> > In regards to the U/F bits in LDP, I think the C-bit in NSH TLVs
> achieves what’s really needed for an SFC Encap.
> >
> > * First, instead of “4-byte” words, this needs to be “4-octet” or “32-
> bit” words. Byte is strictly machine dependent (7 bits, 8 bits, etc).

---

From: Azhar Sayeed <[email-masked]>
Date: Wed, 20 Apr 2016 10:18:44 -0400

Carlos,

We agree to disagree …

My argument was fairly simple - if you call this a TLV then I gave you an option to align to a TLV structure without breaking the proposed structure too much…you can call it what you want - call it an informational element, call it a metadata structure or call it some thing else - just don’t call it a TLV…in which case we are squared

The difference between what I am stating and what you are arguing is not much…I am not proposing to take away the class field or to take away the flags - (although I would argue why do you need a class field when you already have a type - if you make type 16 bits then it covers both class and type as proposed originally)

I can see Med’s point that we want the header to be compact in which case you can shrink the length or the type field or both…If you move the flags around then the structure does conform to TLV - If you are not calling it a TLV but calling this a metadata spec then ignore my comments

Azhar

> On Apr 19, 2016, at 10:41 PM, Carlos Pignataro (cpignata) <[email-masked]> wrote:
> 
> Azhar,
> 
> -1 :-)
>

---

From: Azhar Sayeed <[email-masked]>
Date: Wed, 20 Apr 2016 10:25:38 -0400

You have a point - perhaps shortening the length and type will help..however, here is my rationale for longer length field

8 bits I feel is too little for metadata - just about twice as many in a tweet :-)

Azhar

> On Apr 20, 2016, at 1:44 AM, [email-masked] wrote:
> 
> Hi Azhar, 
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 20 Apr 2016 14:33:28 +0000

Hi, Med,

To clarify part of my comment, I cited some RFCs that came to mind that provide a hierarchical structure. It is not an exhaustive list, nor a sample to extrapolate too far on other fields. What we should look for is what’s most useful for this use.

Thanks!

— Carlos.

> On Apr 20, 2016, at 2:30 AM, [email-masked] wrote:
> 
> Hi all,
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 20 Apr 2016 14:36:35 +0000

Hi, Azhar,

You wrote “the question then is can the current TLV structure in draft-~nsh-04 be re-configured to align with all the other TLV’s structure”, and I interpreted that, likely misinterpreted, as “let’s shuffle all bits-on-the-wire to have only a single flat Type, a length, and a value. If instead you meant “we can rename things”, that’s different. Note I said “information element” to most generically refer to a protocol element which provides information.

Thanks,

— Carlos.

> On Apr 20, 2016, at 10:18 AM, Azhar Sayeed <[email-masked]> wrote:
> 
> Carlos,
> 
> We agree to disagree …
>

---

From: Loa Andersson <[email-masked]>
Date: Wed, 20 Apr 2016 22:46:00 +0800

Med,

> Do you have an example of an optional context information that is "critical" in all deployments, all chains? Wouldn't this be left to the taste of the entity administrating an SFC-enabled domain?
No not really, I took that part of the content from the original draft,
but you have a point, I remember that I had a note while reading the
draft for wglc, whether it was like we have 127 types where the C-bit
could be set or net. The text however says that there will be 256 types,
and if the most significant bit is it is dritical.

Maybe worth asking the authors the question you asked me?

/Loa

---

From: <[email-masked]>
Date: Wed, 20 Apr 2016 15:17:57 +0000

Re-,

Ok, thank you. 

256 bytes is by far sufficient for all the metadata types I'm aware of. 

Cheers,
Med

> Envoyé : mercredi 20 avril 2016 16:26
> You have a point - perhaps shortening the length and type will
> help..however, here is my rationale for longer length field
> 
> > The re-arranging of the fields you propose is indeed another option, but
> it does not allow a compact header, e.g., 16 bits for the length is too
> much for the cases I'm aware of + it is not optimal if no originator ID is
> to be supplied for instance.
> >
> >>> * Is it required to recommend an ordering of supplying the mandatory-
> to-
> >> process or optional-to-process elements?
> >>>        conform to the one defined for that specific class registry.
> See
> >> IANA section.
> >>>
> >>>            present in the context element.  This flag is set by
> default
> >> to 0, meaning
> >>>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-
> >> +
> >>>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-
> >> +
> >>>>       |                      Variable Metadata
> >> |
> >>>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-
> >> +
> >>>>
> >>>>
> >>>>
> >>>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-
> >> +
> >>>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-
> >> +
> >>>>       ~                      Variable Metadata
> >> ~
> >>>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-
> >> +
> >>>>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 20 Apr 2016 17:07:27 +0100

In designing this, it is not matter so much what we can think of today, 
but whether we have made adequate provision for what others might 
reasonably wish to do at some point in the near future.

So, the question becomes, might you need to use more that 256 bytes in 
describing why you sent a packet somewhere, and I suspect that you 
might, for example if you needed to provide the  rule set for the 
selection of the packet.

Stewart

---

From: Loa Andersson <[email-masked]>
Date: Thu, 21 Apr 2016 11:44:03 +0800

Carlos,

> You wrote “the question then is can the current TLV structure in draft-~nsh-04 be re-configured to align with all the other TLV’s structure”, and I interpreted that, likely misinterpreted, as “let’…
Whether you misunderstood/misinterpreted Azhar or not the text I
proposed does not "shuffle bits around", it is only the description
of the field(s) that changes.

If we don't want to do this type of change, we should not use the
TLV name.

/Loa

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 21 Apr 2016 03:46:15 +0000

Hi, Loa,

I very much agree with renaming the fields, and in particular I really like your naming proposal! Subsequently, the field descriptions need to be updated as well.

Thanks,

— Carlos.

> On Apr 20, 2016, at 11:44 PM, Loa Andersson <[email-masked]> wrote:
> 
> Carlos,
>

---

From: <[email-masked]>
Date: Thu, 21 Apr 2016 07:11:26 +0000

Hi Stewart, all,

This is a very good point.

(Please note that the proposal to have 256 bytes is doubling what is currently in the NSH spec: 4*2^5=128 bytes)

I think the base context information won't exceed the 256 bytes, but the example you mentioned is an emblematic one.

If there is really a need to define large context elements, I may suggest an idea that is close to the TCP scaling window: use one of the reserved bits to shift the length by a number that the WG will agrees on (scale factor bit).

Your point touched on aspects that lead to discuss the following technical points: 

* What is the trade-off between provisioning information directly to SFC-aware nodes (e.g., selection rules) vs. convey them in-band? 
* What is the trade-off between provisioning information directly together with an ID to SFC-aware nodes (e.g., selection rules) + convey an ID in-band?
* What is the trade-off between computing and installing a path (e.g., using PCEP) + convey an ID using NSH?
* How context information can be communicated in-band without EXACERBATING fragmentation, and therefore ensure a COMPACT header?
* What is the maximum RECOMMENDED size of a context information that can be supplied while processing it does not ALTER (by a %, drastically) the performance of intermediate SFC-aware nodes, does not degrade the overall one-way transfer delay when crossing an SFC-enabled domain, does not exhaust SFF/SF resources, etc.? 
* Shouldn't the specification include some sort of RECOMMENDATIONS for specifying a context information vs. associate a meaning with a reserved flag (see an example below for including a source router)?

=======Example to illustrate the usage of an NSH flag:
=======Include an RSP

3.1.  RSP

   If the E-flag is set, a "Explicit Source Routed SFP" field MUST be present in
   the NSH Header.  This field MUST be positioned right after
   the "Service Index" field.  

        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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      //                 (Optional) Locators[1..n] (Variable)        //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure xxx

   The optional "Source Routed SFP" field is structured as a vector of
   SFF/SF locators (whereas a SFF/SF locator could be an IP address, a MAC
   address or a FQDN, for example).

   A SFP Source Route is said to be "strict" when the exact set of all
   the SFF/SF instances that need to be invoked along the SFP is explicitly
   and exhaustively mentioned in the field.  Each locator in the list is
   encoded as follows:

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Locator Len |           Locator (Variable)                   //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure xx

   A SFP Source Route is said to be "loose" when only a subset of the SF/SFF
   instances, that need to be invoked in the context of a given service
   function chain, is mentioned in the field.  The other SFFs/SFs that need
   to be invoked will be set to "ANY" in the field, meaning that SFF are
   free to forward the packet towards the next SF instance that needs to
   be invoked as per the SFC instructions and according to SFC next hop
   resolution procedure or a result of load-balancing scheme.  "ANY"
   corresponds to "Locator Len" set to "0" and no "Locator" field.

   A locator in the list set to 'ANY' is an indication that the
   selection of the exact SF instance to invoke is left to the SFF or to
   some kind of SF load-balancing mechanism.

   The Source Routed SFP field of the NSH header MUST NOT include a list of
   locators that are all set to "ANY".
=============================
 
Thank you.

Cheers,
Med

> De : Stewart Bryant [mailto:[email-masked]]
> Envoyé : mercredi 20 avril 2016 18:07
> À : BOUCADAIR Mohamed IMT/OLN; Azhar Sayeed
> Cc : [email-masked]; [email-masked]; Loa Andersson
> >> 8 bits I feel is too little for metadata - just about twice as many in
> a
> >> tweet :-)
> >>
> >> Azhar
> >>
> >>>>> As an input to this discussion, below a proposal for an encoding
> that
> >>>> achieves the following goals:
> >>>>> * Wouldn't be sufficient to supply that information using the
> control
> >>>> plane?
> +-+
> +-+
> >>>>>      //                           Data (Variable)
> //
> +-+
> +-+
> +-+
> +-+
> >>>>>      //                           Data (Variable)
> //
> +-+
> >>>>>             additional flag bits. r bits MUST each be sent as zero
> and
> >>>> MUST be
> >>>>>             ignored on receipt.
> >>>>>
> >>>>>             When set, the S-flag indicates that an Originator ID
> field
> >>>> is
> >>>>>> Objet : [sfc] WG last call for draft-ietf-sfc-nsh-04.txt -
> Questions
> >> on
> >>>>>>    LDP uses a Type-Length-Value (TLV) encoding scheme to encode
> much
> >> of
> >>>>>>    |U|F|        Type               |            Length
> >>>>>>    |                             Value
> >>>>>>         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
> >>>>>>        |          TLV Class            |C|    Type     |R|R|R|
> Len
> >>>> |
> >>>>>>         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
> >>>>>>        |          TLV Class            |C|    Type     |R|R|R|
> Len
> >>>> |
> >>>>>> A last, but a bit different question, do you need indicators like
> the
> >> U

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Fri, 22 Apr 2016 18:59:51 +0000

Hello Loa,

Loa,

You raise an interesting point wrt naming.  In fact, this isn't a true TLV, rather, a structure for variable length metadata.  Perhaps, it would be clearer to simply label it as such.  The structure can remain the same but it would help readers understand that there are "extra" non T, L or V fields present.  Some further comments below.

Thanks
Paul

>   the Type, followed by a 2 octet Length field, followed by a variable

PQ>  In some ways, but as you point out this might be confusing and leads to an implied overload.  In reality, the class "scopes" the type. 

> to use a ~ instead of the |, like this:.

PQ>  I'm happy to, assuming everyone else is as well.

> what is the rules for padding?

PQ>  We can provide explicit pad with zero guidance.

> recognize the (TLV Class, C, Type)-field?

PQ>  In general, we've implied that if a node doesn't understand the TLV it simply ignores it.

Thanks again!
Paul

---

From: Loa Andersson <[email-masked]>
Date: Sat, 23 Apr 2016 17:02:43 +0800

Paul,

Thanks for response, I think we are converging. I have 
suggestions/questions below in
- naming
- on dropping packets when the variable length metadata is not
   recognized.
- padding
- and (a new one) on section 14.2.3.

> You raise an interesting point wrt naming.  In fact, this isn't a true TLV, rather, a structure for variable length metadata.  Perhaps, it would be clearer to simply label it as such.  The structur…

OK - I like naming thing "Variable Length Metadata (VLM)" would work
for me, you need to put that into the definition (and maybe terminology)
and replace all occurrences of TLV.

> PQ>  We can provide explicit pad with zero guidance.

Thanks, that would be great. Are we sure that the metadata does not 
start and stop with zero?

Let us say that one metadata has the format:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 1 1 0 1 0 1 0 1 0 1 1 0 0 1 1 1 1 0 0 0 1 0 0              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and another one the format
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 1 1 0 1 0 1 0 1 0 1 1 0 0 1 1 1 1 0 0 0 1 0 0 0 0          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

post padding would make them come out the same.

Similar

If one metadata has the format:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                0 1 1 0 1 0 1 0 1 0 1 1 0 0 1 1 1 1 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and another one the format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              0 0 1 1 0 1 0 1 0 1 0 1 1 0 0 1 1 1 1 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Pre-padding will make them come out the same.

> PQ>  In general, we've implied that if a node doesn't understand the TLV it simply ignores it.

As far as I can see you only talk about it the type is not recognized,
you probably need to make a statement about Class also.

In the IANA section there is a Section 14.2.3 that says

14.2.3.  TLV Class Registry

    IANA is requested to set up a registry of "TLV Types".  These are 16-
    bit values.  Registry entries are assigned by using the "IETF Review"
    policy defined in RFC 5226 [RFC5226].

Apart from changing TLV to VLM, it is odd to name this registry "VLM
Types it should be "VLM Classes", right? We are talking about a registry
for the Classes that goes in the 16 bit field.

Then I think you need a registry for the type field (8 bits) also, at
least for the types defined by IETF, this registry should indicate
whether the C bit is set or not.

/Loa

/Loa

/Loa