Subject: Re: [sfc] #10 (nsh): O bit

From: <[email-masked]>
Date: Wed, 13 Apr 2016 07:47:59 +0000

Paul, 

I don't see how citing RFC 7498 (as suggested in your reply below) is related to this issue. 

Furthermore, I see this reply in the tracker: 

"Reserving a bit for OAM is acceptable, and done in other protocol specifications. OAM-specific drafts exist and will leverage the presence of the bit. Further, over time new OAM uses may arise, having the explicit ability to support them day-0 is key. The O bit was agreed upon by the WG during adoption, and there is no consensus to remove it. I propose that a reference be added to the OAM framework draft."

* I see that you suggest to add a reference to the OAM framework draft, but still there is no such change in the text. I agree with adding draft-ietf-sfc-oam-framework as an informative reference. Thanks.
* The text does not say what an implementer needs to. The text "MUST examine the payload and take appropriate action" is vague and underspecified. I suggest to make this change:

OLD: 

   O bit: when set to 0x1 indicates that this packet is an operations
   and management (OAM) packet.  The receiving SFF and SFs nodes MUST
   examine the payload and take appropriate action (e.g. return status
   information).

   OAM message specifics and handling details are outside the scope of
   this document.

NEW:

   O bit: when set to 0x1 indicates that this packet is an operations
   and management (OAM) packet.  It is out of scope of this document
   to define the behaviors of SFFs and SF for processing this bit.  
   OAM message specifics and handling details are outside the scope of
   this document. The reader may refer to [I-D.ietf-sfc-oam-framework]
   for an OAM SFC framework. 

   This bit is set by default to 0x0. 

   Intermediate SFFs and SFs MUST NOT change the value of this bit when
   forwarding the packet to the next hop.

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[email-masked]] De la part de sfc issue tracker
> Envoyé : vendredi 26 février 2016 22:45
> À : [email-masked]; [email-masked]
> Cc : [email-masked]
> Objet : Re: [sfc] #10 (nsh): O bit
> 
> #10: O bit
> 
> Changes (by [email-masked]):
> 
>  * status:  new => closed
>  * resolution:   => wontfix
> 
> 
> Comment:
> 
>  Reply: The current version of the draft states:  "A short reference is
>  included below, RFC 7498 [RFC7498], provides a
>  more comprehensive review of the SFC Problem Statement."  That seems like
>  a reasonable approach, and propose marking this item as resolved.
> 
> --
> -------------------------------------+------------------------------------
> -
>  Reporter:                           |       Owner:  draft-ietf-sfc-
>   [email-masked]       |  [email-masked]
>      Type:  defect                   |      Status:  closed
>  Priority:  major                    |   Milestone:
> Component:  nsh                      |     Version:
>  Severity:  -                        |  Resolution:  wontfix
>  Keywords:                           |
> -------------------------------------+------------------------------------
> -
> 
> Ticket URL: <https://trac.tools.ietf.org/wg/sfc/trac/ticket/10#comment:1>
> sfc <https://tools.ietf.org/sfc/>
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 13 Apr 2016 12:18:16 +0000

WG,

> On Apr 13, 2016, at 3:47 AM, [email-masked] wrote:
> 
> Paul,
> 

I do not feel there’s a problem with OLD.

However, I can propose a new NEW (since I’ve been looking at the OAM side):

~~~
  O bit: Setting this bit indicates an Operations,
  Administration, and Maintenance
  (OAM) packet.  The actual format and processing of SFC OAM messages
  is outside the scope of this specification (see [I-D.ietf-sfc-oam-framework]).

  For data (i.e., not OAM) packets, the O bit MUST be cleared and MUST NOT
  be modified along the SFP.
~~~

This is still probably more restrictive than needed, but would accommodate all the concerns.

What do you think?

Thanks,

— Carlos.

---

From: <[email-masked]>
Date: Wed, 13 Apr 2016 12:41:12 +0000

Re-,

The NEW text you are proposing is what I'm looking for. 

Deal!

Cheers,
Med

> De : Carlos Pignataro (cpignata) [mailto:[email-masked]]
> Envoyé : mercredi 13 avril 2016 14:18
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : sfc issue tracker; [email-masked]; Paul Quinn
> (paulq); [email-masked]
> > "Reserving a bit for OAM is acceptable, and done in other protocol
> specifications. OAM-specific drafts exist and will leverage the presence
> of the bit. Further, over time new OAM uses may arise, having the explicit
> ability to support them day-0 is key. The O bit was agreed upon by the WG
> during adoption, and there is no consensus to remove it. I propose that a
> reference be added to the OAM framework draft."
> >
> > * I see that you suggest to add a reference to the OAM framework draft,
> but still there is no such change in the text. I agree with adding draft-
> ietf-sfc-oam-framework as an informative reference. Thanks.
> > * The text does not say what an implementer needs to. The text "MUST
> examine the payload and take appropriate action" is vague and
> underspecified. I suggest to make this change:
> >
> > OLD:
> >
> >> Ticket URL:
> <https://trac.tools.ietf.org/wg/sfc/trac/ticket/10#comment:1>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Apr 2016 10:30:29 -0400

That text works for me.
Yours,
Joel