[sfc] draft-ietf-sfc-nsh-tlv-02 - Network Service Header TLVs

["Carlos Pignataro (cpignata)" <[e-mail]>]

Hi, Wei, SFCers,

I hope this email finds you well!

I thought it would be useful to send not only specific comments but also text proposals on this draft
https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/?include_text=1

Here they go:


                      Network Service Header TLVs
                       draft-ietf-sfc-nsh-tlv-02


The title is a bit of a misnomer. It’s not NSH TLVs. This should be titled “Network Service Header Metadata Type 2 Variable-Length Context Headers”


Abstract

   This draft describes Network Service Header (NSH) MD-Type 2 metadata
   TLVs that can be used within a service function path.


—> "This draft describes Network Service Header (NSH) Metadata (MD) Type 2 variable-length context headers that can be used within a service function path (SFP).”



1.  Introduction

   Network Service Header (NSH) [RFC8300] is the Service Function
   Chaining (SFC) encapsulation protocol used to create Service Function
   Chains.


This reads redundant. Instead:

   Network Service Header (NSH) [RFC8300] is the Service Function
   Chaining (SFC) encapsulation protocol required to support the SFC
   architecture.


As such, NSH provides two key elements:

   1.  Service Function Path identification

   2.  Metadata



This is inconsistent with RC 8300, which says:

   The NSH is composed of the following elements:

   1.  Service Function Path identification.

   2.  Indication of location within a Service Function Path.

   3.  Optional, per-packet metadata (fixed-length or variable).


   [RFC8300] further defines two metadata formats (MD Types): 1 and 2.
   MD Type 1 defines fixed length, 16 bytes-long metadata, whereas MD
   Type 2 defines a variable-length TLV format for metadata.  This draft
   defines some common TLVs for use with NSH MD Type 2.


s/bytes/octets/

Also, strictly, MD Type 2 does not use “TLVs”. It uses “MD Class, MD Type, Length, Value”. As such I recommend removing all mentions of TLV.

“ variable-length TLV format” —> “ variable-length metadata format"



2.1.  Terminology


Add:

"This document uses the terminology defined in the SFC Architecture [RFC 7665] and the Network Service Header [RFC 8300]”.


3.  NSH Type 2 Format


This is “NSH MD Type 2”


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Ver|O|C|R|R|R|R|R|R|   Length  |    MD Type    | Next Protocol |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


TTL missing, should be:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Ver|O|U|    TTL    |   Length  |U|U|U|U|MD Type| Next Protocol |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   where

      Metadata Class (MD Class): Defines the scope of the Type field to
      provide a hierarchical namespace.

      Type - Indicates the explicit type of metadata being carried.  The
      value is one from the Network Service Header (NSH) TLV Type


[...]

Please remove this as it is from RFC 8300.


4.  NSH Type 2 TLVs


Should be “NSH MD Type 2 Context Headers”



4.1.  Forwarding Context

   This TLV carries a network-centric forwarding context, used for
   segregation and forwarding scope.  Forwarding context can take
   several forms depending on the network environment.  Commonly used
   data includes VXLAN/VXLAN- GPE VNID, VRF identification or VLAN.


Extraneous space in VXLAN- GPE


       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 = 0x0000    |  Type = 0x01  |U|  Length = 8 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   CT  |             Reserved                                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Tenant ID                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


First, I recommend for now change all the Types to TBAs. For example 0x01 to TBA1. Note this would otherwise collide with other documents being advanced.

I was thinking about this format, and the proposal from Greg Mirsky to do away from CT and instead use the length. I thought that was a good idea. However, on second thoughts, and in looking at the values defined:


         0x0 - 24 bits-long VXLAN/LISP virtual network identifier (VNI)

         0x1 - 32 bits-long MPLS VPN label

         0x2 - VLAN


* An MPLS Label is actually 20 bits.
* A VLAN identifier (VID) is 12 bits.

Neither of those can be expressed as a Length in octets.

So, we need a CT Field. However, change to:

         0x0 - 24-bits VXLAN/LISP virtual network identifier (VNI)

         0x1 - 20-bits MPLS VPN label

         0x2 - 12-bit VLAN identifier


4.3.  Content Type

   Provides explicit information about the content being carried, for
   example, type of video or content value for billing purposes.

       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 = 0x0000    |  Type = 0x03  |U|  Length = 4 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Content Type                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 5: Content Type


This does not seem to be adequately defined. What is Content Type: 0xCAFECACA?

In fact I wonder if what wants to be defined here is an Application ID: https://tools.ietf.org/html/draft-penno-sfc-appid-05


4.4.  Ingress Network Information

   This data identifies the ingress network node, and, if required,
   ingress interface.

       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 = 0x0000    |  Type = 0x04  |U|  Length = 8 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Node ID                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Source Interface/Port                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 6: Ingress Network Information


As per previous comment from Greg Mirsky, I agree it would make sense to split this into two elements, one from Node ID, one for Interface.


7.  IANA Considerations

   IANA is requested to create a new "Network Service Header (NSH) TLV
   Type" registry according to Table 1.


These are not “TLV Types”. They are "Network Service Header (NSH) MD Type 2 context header metadata types” for example.


   This document defines the following new values (Table 2) in the
   Network Service Header (NSH) TLV Type registry:


This should have “TBAs”.

And these need subsections:

* Context Type (CT)
* Tenant Type (TT)
* Group Type (GT)
* URI Type

Here’s some text:

7.1. Context Type

IANA is requested to create and maintain the “ Forwarding Context Variable Length Context Header, Context Type” registry, with the following initial allocation:

         0x0 - 24-bits VXLAN/LISP virtual network identifier (VNI)
         0x1 - 20-bits MPLS VPN label
         0x2 - 12-bit VLAN identifier
         0x3-0xE - Unassigned
         0xF - Reserved

7.2. Tenant Identifier

IANA is requested to create and maintain the “ Tenant Identifier Variable Length Context Header, Tenant Type” registry, with the following initial allocation:

      *  0x0 - 32 bits-long Tenant ID
      *  0x1 - 64 bits-long Tenant ID

7.3. Group Type

IANA is requested to create and maintain the "Source and/or Destination Groups Context Header, Group Type” registry, with the following initial allocation:

      *  0x0 - Reserved
      *  0x1 - Group Based Policy (GBP) end point group (EPG)
      *  0x2-0xE - Unassigned
      *  0xF - Reserved



Thanks!

Carlos.