Subject: [sfc] O-bit behavior in NSH spec

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 15 Feb 2017 21:00:25 -0000

Hi,

I think it is right that the NSH spec only minimally describe OAM, but I want to
double check the intention of a couple of things here.

Section 3.2 says:

> O bit: Setting this bit indicates an Operations, Administration, and
> Maintenance (OAM) packet.  The actual packet format and processing of
> SFC OAM messages is outside the scope of this specification (see [I-
> D.ietf-sfc-oam-framework]).
>
> SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC
> OAM procedures, SHALL discard packets with O-bit set.

1. Isn't the first paragraph actually making a decision about the meaning 
   of the O bit? That is, it is saying that the packet is an OAM packet?
   Would it be better to defer this type of decisions and say something a 
   little more vague such as...

> O bit: Setting this bit indicates that the NSH packet contains Operations,
> Administration, and Maintenance (OAM) data.  The actual packet format
> and processing of SFC OAM data and how that data is carried in an NSH
> packet is outside the scope of this specification (see 
> [I-D.ietf-sfc-oam-framework]).

2. Do we really want OAM packets discarded rather than passed through?
    That substantially minimises the utility of any OAM.
    Surely we want to specify 

> SF/SFF/SFC Proxy/Classifier implementations, that do not support SFC
> OAM procedures, SHALL process and forward packets with the O bit set 
> as normal.

Thanks,
Adrian

---

From: Dave Dolson <[email-masked]>
Date: Wed, 15 Feb 2017 21:13:04 +0000

I prefer to think of the inverse:
If the O-bit is zero, no functions are required to search the packet for OAM information.
I.e., if O-bit is zero, an SFF may forward the packet on the basis of SPI/SI without checking next-protocol or searching metadata.

I wish the text would actually say that.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Wednesday, February 15, 2017 4:00 PM
To: [email-masked]
Subject: [sfc] O-bit behavior in NSH spec

Hi,

Thanks,
Adrian

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 15 Feb 2017 21:47:31 -0000

Well,

> I.e., if O-bit is zero, an SFF may forward the packet on the basis of SPI/SI
without
> checking next-protocol or searching metadata.

I can agree that.
O bit zero. No OAM.

> I wish the text would actually say that.

Ha!
And I am worried by what the text does say :-)

Adrian

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 15 Feb 2017 17:12:01 -0800

Hi Dave,
in "without checking next-protocol or searching metadata" you've expressed
common assumption that O-bit indicates two options:

   - message that immediately follows NSH is OAM message;
   - one of Variable Length Context Headers carries OAM message.

If that is in fact implicit common interpretation of O-bit, then I have
couple questions:

   - why there's need to use two mechanisms to carry OAM message;
   - how to avoid unnecessary search through metadata if the message
   immediately after NSH is OAM, e.g. BFD control message.

I think that it would be much simpler and cleaner if we interpret "OAM
packet" as "message that immediately follows NSH is OAM message" and
indicate this case in NSH Base Header (I prefer use OAM protocol type). And
what is carried in metadata conveyed through Metadata Class and Type in
Variable Context Header.

Regards,
Greg

On Wed, Feb 15, 2017 at 1:13 PM, Dave Dolson <[email-masked]> wrote:

> I.e., if O-bit is zero, an SFF may forward the packet on the basis of
> SPI/SI without checking next-protocol or searching metadata.
>

---

From: Dave Dolson <[email-masked]>
Date: Thu, 16 Feb 2017 02:00:56 +0000

Greg,
Multiple ideas have been discussed, and no one seems willing to put what OAM *is* in the NSH draft.

So I thought it might be more productive to say what it is not, and gain a performance benefit of checking a single bit to know whether slow-path processing is required.

-Dave

From: Greg Mirsky
Sent: Wednesday, February 15, 2017 8:12 PM
To: Dave Dolson
Cc: [email-masked]; [email-masked]
Subject: Re: [sfc] O-bit behavior in NSH spec

Hi Dave,
in "without checking next-protocol or searching metadata" you've expressed common assumption that O-bit indicates two options:

  *   message that immediately follows NSH is OAM message;
  *   one of Variable Length Context Headers carries OAM message.

If that is in fact implicit common interpretation of O-bit, then I have couple questions:

  *   why there's need to use two mechanisms to carry OAM message;
  *   how to avoid unnecessary search through metadata if the message immediately after NSH is OAM, e.g. BFD control message.

I think that it would be much simpler and cleaner if we interpret "OAM packet" as "message that immediately follows NSH is OAM message" and indicate this case in NSH Base Header (I prefer use OAM protocol type). And what is carried in metadata conveyed through Metadata Class and Type in Variable Context Header.

Regards,
Greg

On Wed, Feb 15, 2017 at 1:13 PM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:
I prefer to think of the inverse:
If the O-bit is zero, no functions are required to search the packet for OAM information.
I.e., if O-bit is zero, an SFF may forward the packet on the basis of SPI/SI without checking next-protocol or searching metadata.

-----Original Message-----
From: sfc [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Adrian Farrel
Sent: Wednesday, February 15, 2017 4:00 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [sfc] O-bit behavior in NSH spec

Hi,

Thanks,
Adrian

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 15 Feb 2017 18:20:50 -0800

Hi Dave,
I propose to deprecate O-bit all together and return it in Reserved pool.We
had discussion whether checking value of one bit long flag is more
efficient then checking multi-bit field for particular value. The
conclusion, as I recall, was that there's no significant advantage of
former over the latter, if any advantage at all.

Regards,
Greg

On Wed, Feb 15, 2017 at 6:00 PM, Dave Dolson <[email-masked]> wrote:

> So I thought it might be more productive to say what it is not, and gain a
> performance benefit of checking a single bit to know whether slow-path
> processing is required.
>
> -Dave
>
>
> *From: *Greg Mirsky
> *Sent: *Wednesday, February 15, 2017 8:12 PM
> *To: *Dave Dolson
> *Cc: [email-masked]; [email-masked]
> *Subject: *Re: [sfc] O-bit behavior in NSH spec
>
> Hi Dave,
> in "without checking next-protocol or searching metadata" you've
> expressed common assumption that O-bit indicates two options:
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 16 Feb 2017 09:41:09 -0000

So a high-level question is:
Will you ever want to include OAM in an NSH packet that also contains user data?
 
My impression was that there was some desire for this.
 
That would certainly change:
- the use of "next protocol" to indicate OAM (unless OAM had a recursive next protocol?)
- how a node that did not support OAM found the user data
 
It would make of the O flag more useful.
 
A
 
From: Greg Mirsky [mailto:[email-masked]] 
Sent: 16 February 2017 02:21
To: Dave Dolson
Cc: [email-masked]; [email-masked]
Subject: Re: [sfc] O-bit behavior in NSH spec
 
Hi Dave,
I propose to deprecate O-bit all together and return it in Reserved pool.We had discussion whether checking value of one bit long flag is more efficient then checking multi-bit field for particular value. The conclusion, as I recall, was that there's no significant advantage of former over the latter, if any advantage at all.
 
Regards,
Greg

 
-Dave

From: Greg Mirsky
 
Hi Dave, 
 
Regards,
Greg

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Wednesday, February 15, 2017 4:00 PM
To: [email-masked]
Subject: [sfc] O-bit behavior in NSH spec

Hi,

Thanks,
Adrian

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 16 Feb 2017 09:06:55 -0800

Hi Adrian,
the proposed Overlay OAM header
<https://tools.ietf.org/html/draft-ooamdt-rtgwg-ooam-header-01> has Length
field that reflects the length of the OAM message and Next Protocol field.
I believe that Overlay OAM Header supports all scenarios for OAM, with and
without user data, in simple consistent manner.

Regards,
Greg

On Thu, Feb 16, 2017 at 1:41 AM, Adrian Farrel <[email-masked]> wrote:

> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* 16 February 2017 02:21
>
> *To:* Dave Dolson
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [sfc] O-bit behavior in NSH spec
>
>
>
> Hi Dave,
>
> I propose to deprecate O-bit all together and return it in Reserved
> pool.We had discussion whether checking value of one bit long flag is more

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 16 Feb 2017 09:20:15 -0800

Hi Adrian,
but we can re-word text in NSH document. Alternative, as I see it, would be
to embed OAM in NSH.

Regards,
Greg

On Thu, Feb 16, 2017 at 9:16 AM, Adrian Farrel <[email-masked]> wrote:

> Except that it requires a node that does not support OAM to act as
> currently described in the NSH spec and drop packets containing OAM.
>
> I think this is a draw-back
>
>
>
> Adrian
>
>
>
> *Sent:* 16 February 2017 17:07
> *To:* Adrian Farrel
> *Cc:* Dave Dolson; [email-masked]
>
> <https://tools.ietf.org/html/draft-ooamdt-rtgwg-ooam-header-01> has
> Length field that reflects the length of the OAM message and Next Protocol
> field.
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 16 Feb 2017 17:16:29 -0000

Except that it requires a node that does not support OAM to act as currently described in the NSH spec and drop packets containing OAM.
I think this is a draw-back
 
Adrian
 
From: Greg Mirsky [mailto:[email-masked]] 
Sent: 16 February 2017 17:07
To: Adrian Farrel
Cc: Dave Dolson; [email-masked]
Subject: Re: [sfc] O-bit behavior in NSH spec
 
Hi Adrian,
the proposed Overlay OAM header <https://tools.ietf.org/html/draft-ooamdt-rtgwg-ooam-header-01>  has Length field that reflects the length of the OAM message and Next Protocol field.
I believe that Overlay OAM Header supports all scenarios for OAM, with and without user data, in simple consistent manner.
 
Regards,
Greg

 

A

To: Dave Dolson
 
Hi Dave,
 
Regards,
Greg

 
-Dave

From: Greg Mirsky
 
Hi Dave, 
 
Regards,
Greg

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Wednesday, February 15, 2017 4:00 PM
To: [email-masked]
Subject: [sfc] O-bit behavior in NSH spec

Hi,

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 16 Feb 2017 17:47:19 -0000

Yes, Greg,
 
That's where this conversation started: looking at the text in the current NSH spec about how to process an O-bit.
But I would also like a receiver of an NSH packet (as described in the NSH spec) to know how to step over any OAM and find the payload data.
 
That either requires one of the following:
- describing the OAM presence (between NSH and payload) in the NSH spec
- banning OAM in packets that carry payload
- making it OK for OAM packets to be discarded at (i.e. not pass through) transit nodes
- putting the OAM in metadata
 
Adrian

From: Greg Mirsky [mailto:[email-masked]] 
Sent: 16 February 2017 17:20
To: Adrian Farrel
Cc: Dave Dolson; [email-masked]
Subject: Re: [sfc] O-bit behavior in NSH spec
 
Hi Adrian,
but we can re-word text in NSH document. Alternative, as I see it, would be to embed OAM in NSH.
 
Regards,
Greg

Adrian

 
Hi Adrian,
 
Regards,
Greg

 

A

To: Dave Dolson
 
Hi Dave,
 
Regards,
Greg

 
-Dave

From: Greg Mirsky
 
Hi Dave, 
 
Regards,
Greg

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Wednesday, February 15, 2017 4:00 PM
To: [email-masked]
Subject: [sfc] O-bit behavior in NSH spec

Hi,

Thanks,
Adrian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 16 Feb 2017 12:58:20 -0500

Just to clarify:

An NSH Supporting SF which does not support in-Situ OAM would receive 
packets with an NSH header with a next header value of OAM.

Would not such an SF either discard the packet or get very confused?
Particularly since our current approach to conventional OAM for SFPs is 
not to involve the SFs, as we are not trying to monitor applications 
with data plane measurement.

Yours,
Joel

On 2/16/17 12:06 PM, Greg Mirsky wrote:
> Length field that reflects the length of the OAM message and Next
> Protocol field.
> I believe that Overlay OAM Header supports all scenarios for OAM, with
> and without user data, in simple consistent manner.
>
> Regards,
> Greg
>
> On Thu, Feb 16, 2017 at 1:41 AM, Adrian Farrel <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     So a high-level question is:____
>
>     Will you ever want to include OAM in an NSH packet that also
>     contains user data?____
>
>     __ __
>
>     My impression was that there was some desire for this.____
>
>     __ __
>
>     That would certainly change:____
>
>     - the use of "next protocol" to indicate OAM (unless OAM had a
>     recursive next protocol?)____
>
>     - how a node that did not support OAM found the user data____
>
>     __ __
>
>     It would make of the O flag more useful.____
>
>     __ __
>
>     A____
>
>     __ __
>
>     *From:*Greg Mirsky [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     *Subject:* Re: [sfc] O-bit behavior in NSH spec____
>
>     __ __
>
>     Hi Dave,____
>
>     pool.We had discussion whether checking value of one bit long flag
>     is more efficient then checking multi-bit field for particular
>     value. The conclusion, as I recall, was that there's no significant
>     advantage of former over the latter, if any advantage at all.____
>
>     __ __
>
>     Regards,____
>
>     Greg____
>
>     __ __
>
>     On Wed, Feb 15, 2017 at 6:00 PM, Dave Dolson <[email-masked]
>     <mailto:[email-masked]>> wrote:____
>
>     Greg,____
>
>     Multiple ideas have been discussed, and no one seems willing to put
>     what OAM *is* in the NSH draft.____
>
>     __ __
>
>     So I thought it might be more productive to say what it is not, and
>     gain a performance benefit of checking a single bit to know whether
>     slow-path processing is required.____
>
>     __ __
>
>     -Dave____
>
>     __ __
>
>     __ __
>
>     *From: *Greg Mirsky____
>
>     *Sent: *Wednesday, February 15, 2017 8:12 PM____
>
>     *To: *Dave Dolson____
>
>     *Cc: [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>____
>
>     *Subject: *Re: [sfc] O-bit behavior in NSH spec____
>
>     __ __
>
>     Hi Dave, ____
>
>     expressed common assumption that O-bit indicates two options:____
>
>       * message that immediately follows NSH is OAM message;____
>       * one of Variable Length Context Headers carries OAM message.____
>
>     If that is in fact implicit common interpretation of O-bit, then I
>     have couple questions:____
>
>       * why there's need to use two mechanisms to carry OAM message;____
>       * how to avoid unnecessary search through metadata if the message
>         immediately after NSH is OAM, e.g. BFD control message.____
>
>     I think that it would be much simpler and cleaner if we interpret
>     "OAM packet" as "message that immediately follows NSH is OAM
>     message" and indicate this case in NSH Base Header (I prefer use OAM
>     protocol type). And what is carried in metadata conveyed through
>     Metadata Class and Type in Variable Context Header.____
>
>     __ __
>
>     Regards,____
>
>     Greg____
>
>     __ __
>
>     On Wed, Feb 15, 2017 at 1:13 PM, Dave Dolson <[email-masked]
>     <mailto:[email-masked]>> wrote:____
>
>     I.e., if O-bit is zero, an SFF may forward the packet on the basis
>     of SPI/SI without checking next-protocol or searching metadata.
>
>     I wish the text would actually say that.____
>
>
>
>     From: sfc [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Adrian Farrel
>     To: [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/sfc>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/sfc>____
>
>     __ __
>
>     __ __
>
>
>
>

---

From: Ron Parker <[email-masked]>
Date: Thu, 16 Feb 2017 18:05:46 +0000

I'd really like to hold the option open to support OAM that includes the NSH-aware SF, too, even if initially we define OAM that is terminated by the SFF, primarily.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, February 16, 2017 12:58 PM
To: Greg Mirsky <[email-masked]>
Cc: Dave Dolson <[email-masked]>; [email-masked]
Subject: Re: [sfc] O-bit behavior in NSH spec

Just to clarify:

An NSH Supporting SF which does not support in-Situ OAM would receive packets with an NSH header with a next header value of OAM.

Would not such an SF either discard the packet or get very confused?
Particularly since our current approach to conventional OAM for SFPs is not to involve the SFs, as we are not trying to monitor applications with data plane measurement.

Yours,
Joel

---

From: <[email-masked]>
Date: Fri, 17 Feb 2017 07:21:48 +0000

Hi Adrian, 

FWIW:
* The first part of the text you quoted is the outcome of the discussion related to this ticket: https://www.ietf.org/mail-archive/web/sfc/current/msg03447.html
* The full text included as it appears in -11 was agreed in this thread: https://mailarchive.ietf.org/arch/msg/sfc/wafNWPiS0_ROfy_pJZmSZhlu0fU 

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[email-masked]] De la part de Adrian Farrel
> Envoyé : mercredi 15 février 2017 22:00
> À : [email-masked]
> Objet : [sfc] O-bit behavior in NSH spec
> 
> Hi,
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 17 Feb 2017 16:41:13 -0000

Med,

Thanks for the pointers. It's really helpful to see where this text came from
and why.

I realise it must be aggravating to have someone come along 8 months later and
ask questions, but there we go.

In fact, I find that in addition to my previous points I see another problem

   SF/SFF/SFC Proxy/Classifer implementations MAY support a configurable
   parameter to enable forwarding received SFC OAM packets unmodified to
   the next element in the chain. 

You cannot both have "MUST do X" and "MAY be configured to do Y"
Possibly s/SHALL/SHOULD/
But also, if there is a configuration option it becomes a question of defaults
and so...
OLD
MAY support a configurable parameter to enable forwarding received SFC OAM 
NEW
MAY forward received SFC OAM subject to local policy and configuration
END

Furthermore
   For non OAM packets, the O-bit MUST be cleared and MUST NOT be
   modified along the SFP.
which is not (I hope) to imply that the O bit can be modified on an OAM packet.

In short, the text around the O bit is in need of some work.

Thanks,
Adrian

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: 17 February 2017 07:22
> To: [email-masked]; [email-masked]
> Subject: RE: [sfc] O-bit behavior in NSH spec
> 
> Hi Adrian,
> 
> FWIW:
> * The first part of the text you quoted is the outcome of the discussion
related to
> this ticket: https://www.ietf.org/mail-archive/web/sfc/current/msg03447.html
> * The full text included as it appears in -11 was agreed in this thread:
> https://mailarchive.ietf.org/arch/msg/sfc/wafNWPiS0_ROfy_pJZmSZhlu0fU
> 
> Cheers,
> Med
>

---

From: <[email-masked]>
Date: Mon, 20 Feb 2017 07:43:55 +0000

Re-,

Please see inline.

Cheers,
Med

> De : Adrian Farrel [mailto:[email-masked]]
> Envoyé : vendredi 17 février 2017 17:41
> À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> Objet : RE: [sfc] O-bit behavior in NSH spec
> 
> Med,
> 

[Med] Having fresh eyes to double check the text is really valuable and encouraged. 

> You cannot both have "MUST do X" and "MAY be configured to do Y"

[Med] The initial SHALL is the default behavior. Adding "by default" wouldn't be sufficient? 

> which is not (I hope) to imply that the O bit can be modified on an OAM

[Med] That's not the intent.  

> In short, the text around the O bit is in need of some work.

[Med] I won't be the one who will complain about a better proposal here. 

> > > I think it is right that the NSH spec only minimally describe OAM, but
> I
> > > want to

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 26 Feb 2017 17:31:08 -0000

Hi,

> [Med] The initial SHALL is the default behavior. Adding "by default" wouldn't
be
> sufficient?

Then you mean "SHOULD" in the first paragraph and "MAY" in the second. I would
rewrite as...
    SF/SFF/SFC Proxy/Classifer implementations that do not support SFC
    OAM procedures SHOULD discard packets with O-bit set, but MAY
    support a configurable parameter to enable forwarding received SFC
    OAM packets unmodified to the next element in the chain.

> [Med] That's not the intent.

So...
The O-bit MUST be set for OAM packets and MUST NOT be set for non-OAM
packets. The O-bit MUST NOT be modified along the SFP.

Thanks,
Adrian

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 26 Feb 2017 11:47:12 -0800

Hi Adrian,
I think that there's one more definition related to O-bit and OAM we ought
to chisel - what OAM packet is. It could be:

   - specifically constructed message for the purpose of OAM encapsulated
   in NSH and proper underlay.

But that may leave open question whether hybrid OAM, which embeds OAM
message into user data packets, supported and if it is, then how we
identify it with O-bit.
Appreciate your comments.

Regards,
Greg

---

From: <[email-masked]>
Date: Mon, 27 Feb 2017 06:40:00 +0000

Hi Adrian,

> Envoyé : dimanche 26 février 2017 18:31

[Med] OK, then. 

> > > which is not (I hope) to imply that the O bit can be modified on an
> OAM
> > > packet.
> >

[Med] Works for me.