Subject: [sfc] Question on NSH nesting

From: "Browne, Rory" <[email-masked]>
Date: Thu, 24 Mar 2016 15:11:27 +0000

Hi

I have a question on NSH operation

1. We have flow X enter the SFC classifier,
2. This is identified for MD=0x1 as it carries mandatory info to upstream VNFs
3. An external application wants to tag flow X as MD=0x2 for some other reason (performance reporting for example)
4. We would expect the classifier to priorities MD1 and return an error to entity requesting MD2

My question is that surely there will exist cases whereby you need both the mandatory context to be carried and MD2 information simultaneously. Could we use NSH nesting to resolve this. i.e. MD=3 means that 1st header is MD1 mandatory data, next proto points to MD2 data?

BR Rory
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263

This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 24 Mar 2016 11:35:18 -0400

The intention is that any information that can be carried in any MD-1 
encoding will also have a type code for carrying it in MD-2.  Therefore, 
in terms of information carriage, if what you want to do does not fit in 
MD-1, you just use MD-2.  There is no case I know of where the 
information require both MD-1 and MD-2 at the same time.

Yours,
Joel

On 3/24/16 11:11 AM, Browne, Rory wrote:
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 24 Mar 2016 17:06:59 +0000

I am sure everyone but me knows this. Why does MD=1 have a minimum of
four context headers?

Stewart

On 24/03/2016 15:35, Joel M. Halpern wrote:
> encoding will also have a type code for carrying it in MD-2. 
> Therefore, in terms of information carriage, if what you want to do 
> does not fit in MD-1, you just use MD-2.  There is no case I know of 
> where the information require both MD-1 and MD-2 at the same time.
>
> Yours,
> Joel
>
>> 3. An external application wants to tag flow X as MD=0x2 for some 
>> other reason (performance reporting for example)
>> My question is that surely there will exist cases whereby you need 
>> both the mandatory context to be carried and MD2 information 
>> simultaneously. Could we use NSH nesting to resolve this. i.e. MD=3 
>> means that 1st header is MD1 mandatory data, next proto points to MD2 
>> data?
>>
>>
>>
>> BR Rory

---

From: "Browne, Rory" <[email-masked]>
Date: Thu, 24 Mar 2016 17:30:12 +0000

Thanks Joel

For example. Let's say we want to carry subscriber information in the chain - context A  but we also want to carry chain performance data - context B 

How do we structure the header such that upstream VNFs can read or act on context A and/or B.

BR Rory

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, March 24, 2016 3:35 PM
To: Browne, Rory <[email-masked]>; [email-masked]
Subject: Re: [sfc] Question on NSH nesting

The intention is that any information that can be carried in any MD-1 encoding will also have a type code for carrying it in MD-2.  Therefore, in terms of information carriage, if what you want to do does not fit in MD-1, you just use MD-2.  There is no case I know of where the information require both MD-1 and MD-2 at the same time.

Yours,
Joel

On 3/24/16 11:11 AM, Browne, Rory wrote:
> 1. We have flow X enter the SFC classifier, 2. This is identified for 
> MD=0x1 as it carries mandatory info to upstream VNFs 3. An external 
> application wants to tag flow X as MD=0x2 for some other reason 
> (performance reporting for example) 4. We would expect the classifier 
> to priorities MD1 and return an error to entity requesting MD2
>
> Intel Research and Development Ireland Limited Registered in Ireland 
> Registered Office: Collinstown Industrial Park, Leixlip, County 
> Kildare Registered Number: 308263
>
>
> This e-mail and any attachments may contain confidential material for 
> the sole use of the intended recipient(s). Any review or distribution 
> by others is strictly prohibited. If you are not the intended 
> recipient, please contact the sender and delete all copies.

---

From: Dave Dolson <[email-masked]>
Date: Thu, 24 Mar 2016 17:32:13 +0000

Actually, it specifies *exactly* four context headers, although some might be left empty.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Thursday, March 24, 2016 1:07 PM
To: Joel M. Halpern; Browne, Rory; [email-masked]
Subject: Re: [sfc] Question on NSH nesting

Stewart

On 24/03/2016 15:35, Joel M. Halpern wrote:
>> the sole

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 24 Mar 2016 14:33:15 -0400

The reason it specifies that it carries a 16 byte metadata field is so 
that the header is of fixed length.  Whwther that is sufficiently 
clearly stated in the NSH draft is clearly in the eyes of the reader.

Yours,
Joel

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 24 Mar 2016 18:37:43 +0000

Isn't that somewhat limiting?

I know that I keep mentioning MPLS but one of the most brilliant 
insights by it's inventors was to make it very simple but unlimited. 
According to legend there were long debates about how many labels to 
specify, but finenessing that problem was one of the things that made it 
so powerful.

Why are we placing this artificial limit on the NSH?

Stewart

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 24 Mar 2016 14:38:44 -0400

When you define your solution and realize that you need to carry a well 
defined piece or set of pieces of subscriber information and a well 
defined piece or set of pieces of performance information, you look at 
the data.

If it all fits in 4 32 bit fieslds, you can use MD-1.  If it does not 
fit, or you have other reasons that you want to use MD-2, then you make 
sure that there are type codes in the MD-2 type space for each piece of 
information.  I know that there will be a registered type code for 
subscriber ID.  I would expect that there will be a registered type code 
for timestamp.

You can see an initial set of such type codes in:
https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-00

One of the things we need to address is whether there needs to be a 
vendor TLV class to make it easy for vendors to create additional Type 
codes when they are not yet standardized.

Yours,
Joel

On 3/24/16 1:30 PM, Browne, Rory wrote:
> Thanks Joel
>
> For example. Let's say we want to carry subscriber information in the
> chain - context A  but we also want to carry chain performance data -
> context B
>
> -----Original Message----- From: Joel M. Halpern
> [mailto:[email-masked]] Sent: Thursday, March 24, 2016 3:35 PM
> To: Browne, Rory <[email-masked]>; [email-masked] Subject: Re:
> [sfc] Question on NSH nesting
>
> Yours, Joel
>> 1. We have flow X enter the SFC classifier, 2. This is identified
>> for MD=0x1 as it carries mandatory info to upstream VNFs 3. An
>> external application wants to tag flow X as MD=0x2 for some other
>> reason (performance reporting for example) 4. We would expect the
>> classifier to priorities MD1 and return an error to entity
>> requesting MD2
>>
>> means that 1st header is MD1 mandatory data, next proto points to
>> MD2 data?
>>
>>
>>
>> BR Rory
>> Intel Research and Development Ireland Limited Registered in
>> Ireland Registered Office: Collinstown Industrial Park, Leixlip,
>> County Kildare Registered Number: 308263
>>
>>
>> This e-mail and any attachments may contain confidential material
>> for the sole use of the intended recipient(s). Any review or
>> distribution by others is strictly prohibited. If you are not the
>> intended recipient, please contact the sender and delete all
>> copies. _______________________________________________ sfc mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/sfc
>>
> -------------------------------------------------------------- Intel
> Research and Development Ireland Limited Registered in Ireland

---

From: Joel Halpern Direct <[email-masked]>
Date: Thu, 24 Mar 2016 14:39:51 -0400

Yes, MD-1 is somewhat limiting.  That is why the specification also 
includes MD-2, which uses TLV encoded metadata and can carry an 
arbitrary set of such information (or none.)

Yours,
Joel

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 24 Mar 2016 18:45:32 +0000

I was of course wondering why you did not have a halfway house
with a number (deduced from the length) of fixed length elements?

Stewart

---

From: "Fedyk, Don" <[email-masked]>
Date: Thu, 24 Mar 2016 19:40:42 +0000

+1 

Others have commented that the MD types seem to be artificial.  I agree we could deduce most of it from the length field.  When I looked at the MD1 metadata drafts they were interpreting the fixed fields in a local context anyway so you could stick in TLVs just as easily. 

Cheers
Don 

> Sent: Thursday, March 24, 2016 2:46 PM
> To: Joel Halpern Direct <[email-masked]>; Dave Dolson
> <[email-masked]>; Browne, Rory <[email-masked]>;
> [email-masked]
> I was of course wondering why you did not have a halfway house with a
> number (deduced from the length) of fixed length elements?
> 
> Stewart
> 
> >> specify, but finenessing that problem was one of the things that made
> >> it so powerful.
> >>
> >>> I am sure everyone but me knows this. Why does MD=1 have a
> minimum
> >>> of four context headers?
> >>>
> >>> Stewart
> >>>
> >>>> The intention is that any information that can be carried in any
> >>>> MD-1 encoding will also have a type code for carrying it in MD-2.
> >>>> does not fit in MD-1, you just use MD-2.  There is no case I know
> >>>> of where the information require both MD-1 and MD-2 at the same
> time.
> >>>>
> >>>> Yours,
> >>>> Joel
> >>>>
> >>>>> simultaneously. Could we use NSH nesting to resolve this. i.e.
> >>>>> MD=3 means that 1st header is MD1 mandatory data, next proto
> >>>>> points to MD2 data?
> >>>>>
> >>>>>
> >>>>>
> >>>>> BR Rory
> >>>>> copies.

---

From: Sumandra Majee <[email-masked]>
Date: Thu, 24 Mar 2016 21:22:32 +0000 (UTC)

As per nsh-04 draft MD Type 1 can have optional TLV. For the case Rory mentioned, which is pretty valid IMHO it would go over custom TLV type.  The latest draft did remove that option and I think it will make design quite complicated in some cases.
If the design requires MD=1 context data + other optional data then one has to translate the original context headers to list of TLVs and then add a new TLV. 
We may not see the use case today but often that could be our limitation of not knowing what we don't.  

    On Thursday, March 24, 2016 8:11 AM, "Browne, Rory" <[email-masked]> wrote:

 Hi

BR Rory

---

From: "Bottorff, Paul" <[email-masked]>
Date: Thu, 24 Mar 2016 21:41:32 +0000

Hi Sumandra:

Below,

Cheers,

Paul

From: sfc [mailto:[email-masked]] On Behalf Of Sumandra Majee
Sent: Thursday, March 24, 2016 2:23 PM
To: Browne, Rory <[email-masked]>; [email-masked]
Subject: Re: [sfc] Question on NSH nesting

As per nsh-04 draft MD Type 1 can have optional TLV. For the case Rory mentioned, which is pretty valid IMHO it would go over custom TLV type.
PB> What draft is nsh-04? The draft-ietf-sfc-nsh-04 disallows optional TLVs following the fixed context headers for MD Type 1.

The latest draft did remove that option and I think it will make design quite complicated in some cases.
PB>Agreed. Even though there is concern that hardware needs fixed headers, IMHO adding opaque TLVs following the fixed headers would not cause hardware implementation problems as long as they did not contain information needed for hardware forwarding.

On Thursday, March 24, 2016 8:11 AM, "Browne, Rory" <[email-masked]<mailto:[email-masked]>> wrote:

Hi

BR Rory

[email-masked]<mailto:[email-masked]>

---

From: Sumandra Majee <[email-masked]>
Date: Thu, 24 Mar 2016 21:56:10 +0000 (UTC)

>From draft-quinn-sfc-nsh-04 - Network Service Header
|   |
|   |   |   |   |   |
| draft-quinn-sfc-nsh-04 - Network Service Header[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR] Versions: (draft-quinn-nsh) 00 01 02 03 04 05 06 07 draft-ietf-sfc-nsh  |
|  |
| View on tools.ietf.org | Preview by Yahoo |
|  |
|   |

3.4. NSH MD-type 1
 When the base header specifies MD Type 1, NSH defines four 4-byte mandatory context headers, as per figure 4. These headers must be present and the format is opaque as depicted in figure 5.Quinn, et al. Expires June 18, 2015 [Page 10] 
Internet-Draft           Network Service Header            December 2014

     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=0x1  | Next Protocol |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Service Path ID                      | Service Index |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Mandatory Context Header                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Mandatory Context Header                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Mandatory Context Header                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Mandatory Context Header                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~           Optional Variable Length Context Headers            ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 4: NSH MD-type=0x1

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Context data                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    On Thursday, March 24, 2016 2:41 PM, "Bottorff, Paul" <[email-masked]> wrote:

 #yiv4657302476 #yiv4657302476 -- _filtered #yiv4657302476 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv4657302476 {font-family:Courier;panose-1:2 7 4 9 2 2 5 2 4 4;} _filtered #yiv4657302476 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv4657302476 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv4657302476 #yiv4657302476 p.yiv4657302476MsoNormal, #yiv4657302476 li.yiv4657302476MsoNormal, #yiv4657302476 div.yiv4657302476MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv4657302476 a:link, #yiv4657302476 span.yiv4657302476MsoHyperlink {color:blue;text-decoration:underline;}#yiv4657302476 a:visited, #yiv4657302476 span.yiv4657302476MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv4657302476 span.yiv4657302476EmailStyle17 {color:#1F497D;}#yiv4657302476 .yiv4657302476MsoChpDefault {font-size:10.0pt;} _filtered #yiv4657302476 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv4657302476 div.yiv4657302476WordSection1 {}#yiv4657302476 Hi Sumandra:    Below,    Cheers, 
Paul          From: sfc [mailto:[email-masked]]On Behalf Of Sumandra Majee
Sent: Thursday, March 24, 2016 2:23 PM
To: Browne, Rory <[email-masked]>; [email-masked]
Subject: Re: [sfc] Question on NSH nesting    As per nsh-04 draft MD Type 1 can have optional TLV. For the case Rory mentioned, which is pretty valid IMHO it would go over custom TLV type.   PB> What draft is nsh-04? The draft-ietf-sfc-nsh-04 disallows optional TLVs following the fixed context headers for MD Type 1.    The latest draft did remove that option and I think it will make design quite complicated in some cases. PB>Agreed. Even though there is concern that hardware needs fixed headers, IMHO adding opaque TLVs following the fixed headers would not cause hardware implementation problems as long as they did not contain information needed for hardware forwarding.   If the design requires MD=1 context data + other optional data then one has to translate the original context headers to list of TLVs and then add a new TLV.     We may not see the use case today but often that could be our limitation of not knowing what we don't.     On Thursday, March 24, 2016 8:11 AM, "Browne, Rory" <[email-masked]> wrote:    Hi

BR Rory

---

From: Sunil Vallamkonda <[email-masked]>
Date: Tue, 29 Mar 2016 20:25:29 +0000

+1

MDType1 could be type of TLV of MDType2 instead of having two types for same purpose can be avoided.
While fixed size headers has benefits, the support for MDType2 addresses use cases which may offset the benefit.

Thanks,
Sunil.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Fedyk, Don
Sent: Thursday, March 24, 2016 12:41 PM
To: Stewart Bryant <[email-masked]>; Joel Halpern Direct <[email-masked]>; Dave Dolson <[email-masked]>; Browne, Rory <[email-masked]>; [email-masked]
Subject: Re: [sfc] Question on NSH nesting

+1

Cheers
Don 

> >> According to legend there were long debates about how many labels 
> >> to specify, but finenessing that problem was one of the things that 
> >> made it so powerful.
> >>
> >>>> Therefore, in terms of information carriage, if what you want to 
> >>>> do does not fit in MD-1, you just use MD-2.  There is no case I 
> >>>> know of where the information require both MD-1 and MD-2 at the 
> >>>> same
> time.
> >>>>
> >>>> Yours,
> >>>> Joel
> >>>>
> >>>>> 1. We have flow X enter the SFC classifier, 2. This is 
> >>>>> identified for MD=0x1 as it carries mandatory info to upstream 
> >>>>> VNFs 3. An external application wants to tag flow X as MD=0x2 
> >>>>> for some other reason (performance reporting for example) 4. We 
> >>>>> would expect the classifier to priorities MD1 and return an 
> >>>>> error to entity requesting MD2
> >>>>>
> >>>>> My question is that surely there will exist cases whereby you 
> >>>>> need both the mandatory context to be carried and MD2 
> >>>>> information simultaneously. Could we use NSH nesting to resolve this. i.e.
> >>>>> This e-mail and any attachments may contain confidential 
> >>>>> material for the sole use of the intended recipient(s). Any 
> >>>>> review or distribution by others is strictly prohibited. If you 
> >>>>> are not the intended recipient, please contact the sender and 
> >>>>> delete all copies.

---

From: "Bottorff, Paul" <[email-masked]>
Date: Tue, 29 Mar 2016 21:27:46 +0000

+1

Agreed, we only need one format which includes both a fixed area and a TLV area. This can be done either by having the first TLV include a known fixed area or my adding TLVs past an initial fixed area.

Further the SPI/SI could also be inside a TLV at a fixed location.

Cheers,

Paul

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Sunil Vallamkonda
Sent: Tuesday, March 29, 2016 1:25 PM
To: Fedyk, Don <[email-masked]>; Stewart Bryant <[email-masked]>; Joel Halpern Direct <[email-masked]>; Dave Dolson <[email-masked]>; Browne, Rory <[email-masked]>; [email-masked]
Subject: Re: [sfc] Question on NSH nesting

+1

Thanks,
Sunil.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Fedyk, Don
Sent: Thursday, March 24, 2016 12:41 PM
To: Stewart Bryant <[email-masked]>; Joel Halpern Direct <[email-masked]>; Dave Dolson <[email-masked]>; Browne, Rory <[email-masked]>; [email-masked]
Subject: Re: [sfc] Question on NSH nesting

+1

Cheers
Don