Subject: [sfc] Does NSH OAM bit change the meaning of Next-Header field?

From: Dave Dolson <[email-masked]>
Date: Tue, 3 May 2016 15:35:05 +0000

I'd like to understand whether setting the OAM bit is intended to change the meaning of the NSH Next-Header field.
I.e., is OAM-Protocol in a different number space from Next-Header?

This is hinted at in https://tools.ietf.org/html/draft-yang-sfc-trace-issue-analysis-01, for example, where the field
does not have "Next Header" name, rather "OAM Protocol" as below.

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|1|C|R|R|R|R|R|R|   Length  |  MD-type=0x2  |  OAM Protocol | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|          Service Path ID                      | Service Index | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|                Mandatory Context Header                       | |S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F
|                Mandatory Context Header                       | |C
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|                Mandatory Context Header                       | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|                Mandatory Context Header                       | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <

If it is a distinct number space, is there any standard-track draft that defines how values are to be allocated?

David Dolson
Senior Software Architect, Sandvine Inc.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 3 May 2016 13:03:14 -0400

Good question.
I would tend to prefer that we use a single number space for that, so as 
to reduce implementation complexity and usage errors.

Yours,
Joel

On 5/3/16 11:35 AM, Dave Dolson wrote:
> I’d like to understand whether setting the OAM bit is intended to change
> the meaning of the NSH Next-Header field.
>
> This is hinted at in
> https://tools.ietf.org/html/draft-yang-sfc-trace-issue-analysis-01, for
> example, where the field
>
> does not have “Next Header” name, rather “OAM Protocol” as below.
>
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Dave Dolson <[email-masked]>
Date: Tue, 3 May 2016 17:39:05 +0000

One thing we could do assume a single number space, but also specify which values are valid per OAM setting.
E.g., Next-Header value of 1 means IPv4, and must only be used with OAM=0.

Does it make sense to start assigning OAM protocols from 128 ? 

Also, am I right in asking draft-ietf-sfc-nsh to address this?
(Nothing is said about how Next-Header values from 4 to 0xFD are to be assigned)

-Dave

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Tuesday, May 03, 2016 1:03 PM
To: Dave Dolson; [email-masked]
Subject: Re: [sfc] Does NSH OAM bit change the meaning of Next-Header field?

Good question.

Yours,
Joel

On 5/3/16 11:35 AM, Dave Dolson wrote:
> I'd like to understand whether setting the OAM bit is intended to change

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 3 May 2016 14:18:53 -0400

Given that the NSH draft defines the OAM bit, it seems sensible to note 
that the setting of this bit does not change the meaning of the 
next-protocol field.

I would prefer not to try to split the field protocol types between OAM 
and non-OAM.  I don't think there is any need to do so.

Yours,
Joel

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 3 May 2016 18:34:03 +0000

Hi Joel,
how to interpret the situation when the OAM bit is set and the value in the Next-protocol field is not any OAM protocol? Similar discussion we had in NVO3. This situation, in my view, requires clarification of the priority between OAM bit and the Next-protocol value to specify who gets to process the packet - OAM or the native processor of that protocol. Of course, we can state that if the OAM bit is set the Next-protocol MUST be OAM and anything else SHOULD be treated as error.

	Regards,
		Greg

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Tuesday, May 03, 2016 11:19 AM
To: Dave Dolson; [email-masked]
Subject: Re: [sfc] Does NSH OAM bit change the meaning of Next-Header field?

Given that the NSH draft defines the OAM bit, it seems sensible to note that the setting of this bit does not change the meaning of the next-protocol field.

I would prefer not to try to split the field protocol types between OAM and non-OAM.  I don't think there is any need to do so.

Yours,
Joel

On 5/3/16 1:39 PM, Dave Dolson wrote:
> I would tend to prefer that we use a single number space for that, so 
> as to reduce implementation complexity and usage errors.
>
> Yours,
> Joel
>
>> I'd like to understand whether setting the OAM bit is intended to 
>> change the meaning of the NSH Next-Header field.
>>
>> https://tools.ietf.org/html/draft-yang-sfc-trace-issue-analysis-01, 
>> for example, where the field
>>
>> If it is a distinct number space, is there any standard-track draft 
>> that defines how values are to be allocated?
>>
>>
>>
>>
>>
>> David Dolson
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 3 May 2016 14:59:37 -0400

It seems to me that the SFC OAM document needs to (and I expect will) 
describe the handling of packets with the OAM bit set.  That 
descriptionnecessarily includes what to do when the processing depends 
upon the next protocol field (frequent), and what happens when that 
field is needed and is not an OAM type.  Trying to write all of that in 
the NSH document would, it seems to me, end up folding the whole OAM 
document into the NSH document.  Which I consider undesirable.

Yours,
Joel

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 3 May 2016 19:01:44 +0000

Hi Joel,
wholeheartedly agree and am looking forward to more discussions.

	Regards,
		Greg

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Tuesday, May 03, 2016 12:00 PM
To: Gregory Mirsky; Dave Dolson; [email-masked]
Subject: Re: [sfc] Does NSH OAM bit change the meaning of Next-Header field?

It seems to me that the SFC OAM document needs to (and I expect will) describe the handling of packets with the OAM bit set.  That descriptionnecessarily includes what to do when the processing depends upon the next protocol field (frequent), and what happens when that field is needed and is not an OAM type.  Trying to write all of that in the NSH document would, it seems to me, end up folding the whole OAM document into the NSH document.  Which I consider undesirable.

Yours,
Joel

On 5/3/16 2:34 PM, Gregory Mirsky wrote:
>> (Nothing is said about how Next-Header values from 4 to 0xFD are to 
>> be
>> assigned)
>>
>>
>> -Dave
>>
>>
>>