Subject: Re: [sfc] Status of draft-ietf-sfc-nsh [Was: Meeting at IETF 99 in Prague]

From: Greg Mirsky <[email-masked]>
Date: Sat, 1 Jul 2017 12:39:38 -0700

Hi Joel, Adrian, et. al,
you'd expect that I'll look into OAM bit and wording on OAM packet first.
And so I had. I'm concerned that NSH refers to expired and, frankly,
stalled document that had not been discussed for too long. I believe the
NSH document should have or refer to clear definition of SFC OAM packet
before it defines interpretation of O-bit flag. draft-farrel-sfc-convent
correctly points that in current form O-bit indicates presence of OAM
information which can be either as metadata or as payload. I believe that
we must have more clear and deterministic definition of OAM packet as
current, in my opinion, may cause problems for HW-based SFC OAM support.

Regards,
Greg

On Thu, Jun 29, 2017 at 4:22 PM, Joel Halpern Direct <
[email-masked]> wrote:

> The -13 will be out in a few days with all the changes.
> That is what we will ask the WG to review.
> If we already had it out, we would have already asked for the WG to take a
> last look.
>
> Yours,
> Joel
>
>
> On 6/29/17 7:21 PM, Greg Mirsky wrote:
>
>> Hi Joel,
>> is the -12 the latest published version of the NSH draft? As I see, it is
>> missing TTL and all related changes:
>>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 1 Jul 2017 16:21:41 -0400

Greg, the editors are working on the revision of the OAM Framework 
document.

<chair hat on>
More importantly, we have been careful that the NSH document does not 
normatively depend upon the OAM specification.  This was discussed with 
the working group several times, and the OAM wording in -13 is the 
result of that discussion.
</chair hat on>
<chair hat off>
Are you really asking that we hold up RFC publication of the NSH 
document until we have agreement on all of the complex OAM issues (such 
as in-situ, etc.)  I observe a steady rate of new OAM proposals, with 
new behaviors.  That seems to indicate that such ahold-up would be 
almost indefinite.
</chair hat off>

Yours,
Joel M. Halpern

On 7/1/17 3:39 PM, Greg Mirsky wrote:
> Hi Joel, Adrian, et. al,
> you'd expect that I'll look into OAM bit and wording on OAM packet 
> first. And so I had. I'm concerned that NSH refers to expired and, 
> frankly, stalled document that had not been discussed for too long. I 
> believe the NSH document should have or refer to clear definition of SFC 
> OAM packet before it defines interpretation of O-bit 
> flag. draft-farrel-sfc-convent correctly points that in current form 
> O-bit indicates presence of OAM information which can be either as 
> metadata or as payload. I believe that we must have more clear and 
> deterministic definition of OAM packet as current, in my opinion, may 
> cause problems for HW-based SFC OAM support.
> 
> Regards,
> Greg
> 
> On Thu, Jun 29, 2017 at 4:22 PM, Joel Halpern Direct 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     If we already had it out, we would have already asked for the WG to
>     take a last look.
> 
>     Yours,
>     Joel
> 
> 
>         is the -12 the latest published version of the NSH draft? As I
>         see, it is missing TTL and all related changes:
> 
> 
> 
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 1 Jul 2017 14:02:30 -0700

Hi Joel,
by all means, I'm not asking to hold NSH document until SFC OAM solutions
progress. But NSH refers to OAM packet and, in my view, it is too ambiguous
term. Please consider, OAM packet may be:

   - control message of active SFC OAM protocol carried as payload;
   - control message of active SFC OAM protocol carried as metadata;
   - control information and/or measurement results of hybrid SFC OAM
   protocol carried as metadata

If work on OAM framework is progressing, perhaps all the OAM related
discussion as well as allocation of the O-bit itself can be moved there.

As co-author of several SFC OAM drafts I'd note that none of them has
dependency on where OAM information must be placed, metadata or payload.
But clear and unambiguous definitionsof OAM packet and interpretation of
O-bit are very much needed and will help to progress SFC OAM solutions.

Regards,
Greg

On Sat, Jul 1, 2017 at 1:21 PM, Joel M. Halpern <[email-masked]> wrote:

> normatively depend upon the OAM specification.  This was discussed with the
> working group several times, and the OAM wording in -13 is the result of
> that discussion.
> </chair hat on>
> <chair hat off>
> Are you really asking that we hold up RFC publication of the NSH document
> until we have agreement on all of the complex OAM issues (such as in-situ,
> etc.)  I observe a steady rate of new OAM proposals, with new behaviors.
> That seems to indicate that such ahold-up would be almost indefinite.
> </chair hat off>
>
> Yours,
> Joel M. Halpern
>
>> [email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 1 Jul 2017 17:02:18 -0400

Joel and Greg,

I for one am looking forward to seeing what -13 says about this as well as
other things that have been discussed on the list. Regard the O-bit flag,
-13 should have clear wording on what an implementation should do with the
bit at this time (on both sending and receiving) given that we expect its
publication prior to any publication of OAM-related RFCs. It can always be
updated by a future OAM RFC.

Cheers,
Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 1 Jul 2017 17:11:39 -0400

The definition of the O bit in the document is:

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
    [oam-frame]).

    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.  Forwarding OAM
    packets unmodified by SFC elements that do not support SFC OAM
    procedures may be acceptable for a subset of OAM functions, but can
    result in unexpected outcomes for others, thus it is recommended to
    analyze the impact of forwarding an OAM packet for all OAM functions
    prior to enabling this behavior.  The configurable parameter MUST be
    disabled by default.

    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.

This seems to me a VERY clear description of when the bit is to be set, 
and what handling is required when packets with this bit are received at 
an NSH support entity.

If you consider this wording unclear, please propose specific text to 
improve it.

Yours,
Joel

On 7/1/17 5:02 PM, Greg Mirsky wrote:
> Hi Joel,
> by all means, I'm not asking to hold NSH document until SFC OAM 
> solutions progress. But NSH refers to OAM packet and, in my view, it is 
> too ambiguous term. Please consider, OAM packet may be:
> 
>   * control message of active SFC OAM protocol carried as payload;
>   * control message of active SFC OAM protocol carried as metadata;
>   * control information and/or measurement results of hybrid SFC OAM
> On Sat, Jul 1, 2017 at 1:21 PM, Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     More importantly, we have been careful that the NSH document does
>     not normatively depend upon the OAM specification.  This was
>     discussed with the working group several times, and the OAM wording
>     in -13 is the result of that discussion.
>     </chair hat on>
>     <chair hat off>
>     document until we have agreement on all of the complex OAM issues
>     (such as in-situ, etc.)  I observe a steady rate of new OAM
>     proposals, with new behaviors.  That seems to indicate that such
>     ahold-up would be almost indefinite.
>     </chair hat off>
> 
>     Yours,
>     Joel M. Halpern
> 
>         you'd expect that I'll look into OAM bit and wording on OAM
>         packet first. And so I had. I'm concerned that NSH refers to
>         expired and, frankly, stalled document that had not been
>         discussed for too long. I believe the NSH document should have
>         or refer to clear definition of SFC OAM packet before it defines
>         interpretation of O-bit flag. draft-farrel-sfc-convent correctly
>         points that in current form O-bit indicates presence of OAM
>         information which can be either as metadata or as payload. I
>         believe that we must have more clear and deterministic
>         definition of OAM packet as current, in my opinion, may cause
>         problems for HW-based SFC OAM support.
> 
>         Regards,
>         Greg
> 
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
> 
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/sfc>
> 
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 1 Jul 2017 17:26:58 -0400

Joel,

I would like to suggest changing:

to:

O bit: Setting this bit indicates the presence of Operations,
Administration, and
   Maintenance (OAM) information.  The actual OAM information format and
processing
   is outside the scope of this specification (see  [oam-frame]).

The reason for this change is that we don’t yet know if the format of OAM
information, and whether it will be in metadata, packet contents, or
both. Thus, we don’t yet even know if there will be “OAM packets” per se,
as data packets could possibly also carry OAM information in the metadata.

If this change is acceptable, then the following two paragraphs should also
be amended to:

   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 packets with the
O bit
   set unmodified to the next element in the chain.  Forwarding
   packets with the O bit set unmodified by SFC elements that do not
support SFC OAM
   procedures may be acceptable for a subset of OAM functions, but can
   result in unexpected outcomes for others, thus it is recommended to
   analyze the impact of forwarding a packet with the O bit set for all OAM
functions
   prior to enabling this behavior.  The configurable parameter MUST be
   disabled by default.

   The O bit MUST be set for packets containing OAM information and MUST
NOT be set for
   packets without OAM information.  The O bit MUST NOT be modified along
the SFP.

Finally, I’ve seen both “O bit” and O-bit” used in the document. The
document should choose one.

Thanks,
Andy

On Sat, Jul 1, 2017 at 5:11 PM, Joel M. Halpern <[email-masked]> wrote:

> and what handling is required when packets with this bit are received at an
> NSH support entity.
>

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 1 Jul 2017 14:35:09 -0700

Dear All,
I agree and support changes suggested by Andrew.

Regards,
Greg

On Sat, Jul 1, 2017 at 2:26 PM, Andrew G. Malis <[email-masked]> wrote:

> If this change is acceptable, then the following two paragraphs should
> also be amended to:
>
>    analyze the impact of forwarding a packet with the O bit set for all
> OAM functions
>>> solutions progress. But NSH refers to OAM packet and, in my view, it is too
>>> ambiguous term. Please consider, OAM packet may be:
>>>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 4 Jul 2017 00:34:22 +0000

Hi, Greg, WG,

The OAM specific processing should not be included in the NSH base document. The O-bit text was discussed in the WG and contains enough information for an NSH spec to know what to do.

Please see inline.

> On Jul 1, 2017, at 3:39 PM, Greg Mirsky <[email-masked]> wrote:
> 
> Hi Joel, Adrian, et. al,
> you'd expect that I'll look into OAM bit and wording on OAM packet first. And so I had. I'm concerned that NSH refers to expired and, frankly, stalled document

The document you refer to has been refreshed.  https://tools.ietf.org/html/draft-ietf-sfc-oam-framework-02 

This is not a refresh simply increasing version number and reposting, but rather it incorporates several updates.
https://tools.ietf.org/rfcdiff?url2=draft-ietf-sfc-oam-framework-02.txt

I would encourage the WG to comment on it.

> that had not been discussed for too long. I believe the NSH document should have or refer to clear definition of SFC OAM packet before it defines interpretation of O-bit flag. draft-farrel-sfc-convent correctly points that in current form O-bit indicates presence of OAM information which can be either as metadata or as payload.

This is not strictly correct. Only for the case of a NULL packet.

> I believe that we must have more clear and deterministic definition of OAM packet as current, in my opinion, may cause problems for HW-based SFC OAM support.
> 

Do you have specific concerns with forwarding implementations? The current nsh-base does not define OAM procedures yet it is deterministic as to what to do with O=1.

Thanks,

— Carlos.

> Regards,
> Greg
> 
> On Thu, Jun 29, 2017 at 4:22 PM, Joel Halpern Direct <[email-masked]> wrote:
> If we already had it out, we would have already asked for the WG to take a last look.
> 
> Yours,
> Joel
> 
> 
> is the -12 the latest published version of the NSH draft? As I see, it is missing TTL and all related changes:
> 

—
Carlos Pignataro, [email-masked]

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 4 Jul 2017 00:37:41 +0000

Hi Andy,

I believe that s/packet/information/ can actually cause more confusion that bring clarity.

O=0 means that the payload is a user packet. O=1 means the payload is an OAM packet.

However, this is independent of the Metadata, since some Metadata can be OAM-ish (as a timestamp). And this is also independent of a NULL payload as in Adrian’s draft.

A user packet with OAM-ish metadata will have O=0.

The text can always be polished more — I am not sure if we might be in diminishing return territory.

(I would not oppose a clarification that speaks to the metadata independence of O for user packets, although maybe that does belong in other documents)

Thanks!

Carlos.

On Jul 1, 2017, at 5:26 PM, Andrew G. Malis <[email-masked]<mailto:[email-masked]>> wrote:

Joel,

to:

O bit: Setting this bit indicates the presence of Operations, Administration, and
   Maintenance (OAM) information.  The actual OAM information format and processing
   is outside the scope of this specification (see  [oam-frame]).

The reason for this change is that we don’t yet know if the format of OAM information, and whether it will be in metadata, packet contents, or both. Thus, we don’t yet even know if there will be “OAM packets” per se, as data packets could possibly also carry OAM information in the metadata.

If this change is acceptable, then the following two paragraphs should also be amended to:

   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 packets with the O bit
   set unmodified to the next element in the chain.  Forwarding
   packets with the O bit set unmodified by SFC elements that do not support SFC OAM
   procedures may be acceptable for a subset of OAM functions, but can
   result in unexpected outcomes for others, thus it is recommended to
   analyze the impact of forwarding a packet with the O bit set for all OAM functions
   prior to enabling this behavior.  The configurable parameter MUST be
   disabled by default.

   The O bit MUST be set for packets containing OAM information and MUST NOT be set for
   packets without OAM information.  The O bit MUST NOT be modified along the SFP.

Finally, I’ve seen both “O bit” and O-bit” used in the document. The document should choose one.

Thanks,
Andy

On Sat, Jul 1, 2017 at 5:11 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:
The definition of the O bit in the document is:

This seems to me a VERY clear description of when the bit is to be set, and what handling is required when packets with this bit are received at an NSH support entity.

If you consider this wording unclear, please propose specific text to improve it.

Yours,
Joel

On 7/1/17 5:02 PM, Greg Mirsky wrote:
Hi Joel,
by all means, I'm not asking to hold NSH document until SFC OAM solutions progress. But NSH refers to OAM packet and, in my view, it is too ambiguous term. Please consider, OAM packet may be:

If work on OAM framework is progressing, perhaps all the OAM related discussion as well as allocation of the O-bit itself can be moved there.

As co-author of several SFC OAM drafts I'd note that none of them has dependency on where OAM information must be placed, metadata or payload. But clear and unambiguous definitionsof OAM packet and interpretation of O-bit are very much needed and will help to progress SFC OAM solutions.

Regards,
Greg

On Sat, Jul 1, 2017 at 1:21 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    <chair hat on>

    Yours,
    Joel M. Halpern

        Hi Joel, Adrian, et. al,

        Regards,
        Greg

        On Thu, Jun 29, 2017 at 4:22 PM, Joel Halpern Direct
        <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
        <mailto:[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:

             The -13 will be out in a few days with all the changes.
             That is what we will ask the WG to review.
             If we already had it out, we would have already asked for
        the WG to
             take a last look.

             Yours,
             Joel

                 Hi Joel,
                 is the -12 the latest published version of the NSH
        draft? As I
                 see, it is missing TTL and all related changes:

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

_______________________________________________
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

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

---

From: <[email-masked]>
Date: Tue, 4 Jul 2017 05:32:59 +0000

Hi Andy, all,

I agree with Carlos.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Carlos Pignataro (cpignata)
Envoyé : mardi 4 juillet 2017 02:38
À : Andrew G. Malis
Cc : Greg Mirsky; Joel M. Halpern; [email-masked]
Objet : Re: [sfc] Status of draft-ietf-sfc-nsh [Was: Meeting at IETF 99 in Prague]

Hi Andy,

Thanks!

Carlos.

Joel,

to:

Thanks,
Andy

Yours,
Joel

Regards,
Greg

    <chair hat on>

    Yours,
    Joel M. Halpern

        Hi Joel, Adrian, et. al,

        Regards,
        Greg

             Yours,
             Joel

                 Hi Joel,

—

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 3 Jul 2017 22:41:23 -0700

Hi Carlos,
you have valid interpretation of the text in its current version. And I
think that if it was in the document as you have presented (or very close
to it), it would address my concern, as you've provided clear and
unambiguous definition of what considered as OAM packet in SFC - packet
that carries OAM information as payload that immediately follows the NSH.

Regards,
Greg

On Mon, Jul 3, 2017 at 5:37 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> However, this is independent of the Metadata, since some Metadata can be
> OAM-ish (as a timestamp). And this is also independent of a NULL payload as
> in Adrian’s draft.
>
> (I would not oppose a clarification that speaks to the metadata
> independence of O for user packets, although maybe that does belong in
> other documents)
>
> Thanks!
>
> Carlos.
>
> On Jul 1, 2017, at 5:26 PM, Andrew G. Malis <[email-masked]> wrote:
>
> Joel,
>
> *“Sometimes I use big words that I do not fully understand, to make myself
> sound more photosynthesis."*
>
>

---

From: James N Guichard <[email-masked]>
Date: Wed, 5 Jul 2017 15:45:03 +0000

Hi Greg/Carlos,

It is difficult to tell from this thread whether a textual change is being proposed or if the current text is sufficient; please can you clarify for the WG and if a textual change is being proposed please clearly state what this is so that the WG can evaluate and we can move forward.

Many thanks!

Jim

From: sfc [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Tuesday, July 04, 2017 1:41 AM
To: Carlos Pignataro (cpignata) <[email-masked]>
Cc: Joel M. Halpern <[email-masked]>; Andrew G. Malis <[email-masked]>; [email-masked]
Subject: Re: [sfc] Status of draft-ietf-sfc-nsh [Was: Meeting at IETF 99 in Prague]

Hi Carlos,
you have valid interpretation of the text in its current version. And I think that if it was in the document as you have presented (or very close to it), it would address my concern, as you've provided clear and unambiguous definition of what considered as OAM packet in SFC - packet that carries OAM information as payload that immediately follows the NSH.

Regards,
Greg

On Mon, Jul 3, 2017 at 5:37 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andy,

Thanks!

Carlos.

Joel,

to:

Thanks,
Andy

Yours,
Joel

Regards,
Greg

    <chair hat on>

    Yours,
    Joel M. Halpern

        Hi Joel, Adrian, et. al,

        Regards,
        Greg

             Yours,
             Joel

                 Hi Joel,

—

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 6 Jul 2017 19:07:16 -0700

Hi Jim,
I can give my interpretation of what Carlos had proposed and how his
clarification may be reflected in the document:
OLD:

NEW:

   O bit: Setting this bit indicates an Operations, Administration, and
   Maintenance (OAM) packet.  SFC OAM packet is the packet that has
OAM payload immediately following NSH.  In all other cases, i.e. when
the payload is not OAM, the O-bit MUST be reset. The actual packet
format and processing of SFC OAM messages are outside the scope of
this specification (see [oam-frame]).

Regards,

Greg

On Wed, Jul 5, 2017 at 8:45 AM, James N Guichard <
[email-masked]> wrote:

> Hi Greg/Carlos,
>
>
>
> It is difficult to tell from this thread whether a textual change is being
> proposed or if the current text is sufficient; please can you clarify for
> the WG and if a textual change is being proposed please clearly state what
> this is so that the WG can evaluate and we can move forward.
>
>
>
> Many thanks!
>
>
>
> Jim
>
>
>
> *From:* sfc [mailto:[email-masked]] *On Behalf Of *Greg Mirsky
> *Sent:* Tuesday, July 04, 2017 1:41 AM
> *To:* Carlos Pignataro (cpignata) <[email-masked]>
> *Cc:* Joel M. Halpern <[email-masked]>; Andrew G. Malis <
> [email-masked]>; [email-masked]
> *Subject:* Re: [sfc] Status of draft-ietf-sfc-nsh [Was: Meeting at IETF
> 99 in Prague]
>
>
>
> Hi Carlos,
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 7 Jul 2017 03:14:13 +0000

Thanks Greg and Jim. I would like to close on this item.

For clarity, what you (Greg) are proposing is the addition of the following text:

“SFC OAM packet is the packet that has OAM payload immediately following NSH.  In all other cases, i.e. when the payload is not OAM, the O-bit MUST be reset.”

And while at first glance it sounds like a potentially useful or at least non-harmful addition, very similar text already exists one paragraph below:

“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.”

I prefer to specify as little as possible of OAM here, since we are already pointing to a spec that would detail this processing. Things like “immediately following” can be specified in the OAM document. As it is now, what O means is clear and aligns with what I wrote below.

Additionally, I’d much rather not change the text that was worked through iterations and consensus. However, I suggest we can move up that sentence one paragraph up to improve the flow and make it explicitly clear:

    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]).

+   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.
+

-   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.
-

Thoughts on this proposal? It seems to achieve the right balance of not over specify but bring clarity.

Thanks,

— Carlos.

On Jul 6, 2017, at 10:07 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jim,
I can give my interpretation of what Carlos had proposed and how his clarification may be reflected in the document:
OLD:

NEW:

   O bit: Setting this bit indicates an Operations, Administration, and
   Maintenance (OAM) packet.  SFC OAM packet is the packet that has OAM payload immediately following NSH.  In all other cases, i.e. when the payload is not OAM, the O-bit MUST be reset. The actual packet format and processing of SFC OAM messages are outside the scope of this specification (see [oam-frame]).

Regards,

Greg

On Wed, Jul 5, 2017 at 8:45 AM, James N Guichard <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg/Carlos,

Many thanks!

Jim

From: sfc [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Greg Mirsky
Sent: Tuesday, July 04, 2017 1:41 AM
To: Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>>
Cc: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; Andrew G. Malis <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Status of draft-ietf-sfc-nsh [Was: Meeting at IETF 99 in Prague]

Hi Carlos,

Regards,
Greg

Thanks!

Carlos.

Joel,

to:

Thanks,
Andy

Yours,
Joel

Regards,
Greg

    <chair hat on>

    Yours,
    Joel M. Halpern

        Hi Joel, Adrian, et. al,

        Regards,
        Greg

             Yours,
             Joel

                 Hi Joel,

—

—

---

From: Dave Dolson <[email-masked]>
Date: Fri, 7 Jul 2017 03:20:06 +0000

Practically, "The O-bit MUST be zero." Until OAM for NSH is defined.
Isn't that where we are at?

David Dolson
Sandvine
From: Carlos Pignataro (cpignata)
Sent: Thursday, July 6, 2017 11:14 PM
To: Greg Mirsky
Cc: Joel M. Halpern; Andrew G. Malis; [email-masked]; James N Guichard
Subject: Re: [sfc] Status of draft-ietf-sfc-nsh [Was: Meeting at IETF 99 in Prague]

Thanks,

— Carlos.

Hi Jim,

NEW:

Regards,

Greg

Many thanks!

Jim

Hi Carlos,

Regards,
Greg

Thanks!

Carlos.

Joel,

to:

Thanks,
Andy

Yours,
Joel

Regards,
Greg

    <chair hat on>

    Yours,
    Joel M. Halpern

        Hi Joel, Adrian, et. al,

        Regards,
        Greg

             Yours,
             Joel

                 Hi Joel,

—

—

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 7 Jul 2017 03:24:23 +0000

Correct practically — zero for user packets.

And I believe that’s what this says (using more words):

Thanks,

— Carlos.

On Jul 6, 2017, at 11:20 PM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:

David Dolson
Sandvine
From: Carlos Pignataro (cpignata)
Sent: Thursday, July 6, 2017 11:14 PM
To: Greg Mirsky
Cc: Joel M. Halpern; Andrew G. Malis; [email-masked]<mailto:[email-masked]>; James N Guichard
Subject: Re: [sfc] Status of draft-ietf-sfc-nsh [Was: Meeting at IETF 99 in Prague]

Thanks,

— Carlos.

Hi Jim,

NEW:

Regards,

Greg

Many thanks!

Jim

Hi Carlos,

Regards,
Greg

Thanks!

Carlos.

Joel,

to:

Thanks,
Andy

Yours,
Joel

Regards,
Greg

    <chair hat on>

    Yours,
    Joel M. Halpern

        Hi Joel, Adrian, et. al,

        Regards,
        Greg

             Yours,
             Joel

                 Hi Joel,

—

—

—

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 6 Jul 2017 23:48:53 -0400

The current text says rather more than just "the O bit must be zero". 
It prescribes what behavior should be implemented in NSH devices for 
processing packets where the O bit is set.  Which we were specifically 
asked to provide.

Speaking personally, I prefer that the OAM text in the NSH document not 
specify where the OAM information is carried.  While some folks have 
assumptions about where the information will reside, we have not agreed 
on that.

Yours,
Joel

On 7/6/17 11:24 PM, Carlos Pignataro (cpignata) wrote:
>> *From: *Carlos Pignataro (cpignata)
>> *Sent: *Thursday, July 6, 2017 11:14 PM
>> *To: *Greg Mirsky
>> *Cc: *Joel M. Halpern; Andrew G. Malis; [email-masked] 
>> <mailto:[email-masked]>; James N Guichard
>> *Subject: *Re: [sfc] Status of draft-ietf-sfc-nsh [Was: Meeting at 
>> IETF 99 in Prague]
>>
>>
>> “SFC OAM packet is the packet that has OAM payload immediately 
>> following NSH.  In all other cases, i.e. when the payload is not OAM, 
>> the O-bit MUST be reset.”
>>
>> And while at first glance it sounds like a potentially useful or at 
>> least non-harmful addition, very similar text already exists one 
>> paragraph below:
>>
>> “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.”
>>
>> I prefer to specify as little as possible of OAM here, since we are 
>> already pointing to a spec that would detail this processing. Things 
>> like “immediately following” can be specified in the OAM document. As 
>> it is now, what O means is clear and aligns with what I wrote below.
>>
>> Additionally, I’d much rather not change the text that was worked 
>> through iterations and consensus. However, I suggest we can move up 
>> that sentence one paragraph up to improve the flow and make it 
>> explicitly clear:
>>
>>
>>> Maintenance (OAM) packet. SFC OAM packet is the packet that has OAM 
>>> payload immediately following NSH. In all other cases, i.e. when the 
>>> payload is not OAM, the O-bit MUST be reset. The actual packet format 
>>> and processing of SFC OAM messages are outside the scope of this 
>>> specification (see [oam-frame]).
>>> Regards,
>>> Greg
>>>
>>> On Wed, Jul 5, 2017 at 8:45 AM, James N Guichard 
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>     Hi Greg/Carlos,____
>>>
>>>     __ __
>>>
>>>     It is difficult to tell from this thread whether a textual change
>>>     is being proposed or if the current text is sufficient; please
>>>     can you clarify for the WG and if a textual change is being
>>>     proposed please clearly state what this is so that the WG can
>>>     evaluate and we can move forward.____
>>>
>>>     __ __
>>>
>>>     Many thanks!____
>>>
>>>     __ __
>>>
>>>     Jim____
>>>
>>>     __ __
>>>
>>>     *From:*sfc [mailto:[email-masked]
>>>     <mailto:[email-masked]>] *On Behalf Of *Greg Mirsky
>>>     *To:* Carlos Pignataro (cpignata) <[email-masked]
>>>     <mailto:[email-masked]>>
>>>     *Cc:* Joel M. Halpern <[email-masked]
>>>     <mailto:[email-masked]>>; Andrew G. Malis <[email-masked]
>>>     <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>>>     *Subject:* Re: [sfc] Status of draft-ietf-sfc-nsh [Was: Meeting
>>>     at IETF 99 in Prague]____
>>>
>>>     __ __
>>>
>>>     Hi Carlos,____
>>>
>>>     you have valid interpretation of the text in its current version.
>>>     And I think that if it was in the document as you have presented
>>>     (or very close to it), it would address my concern, as you've
>>>     provided clear and unambiguous definition of what considered as
>>>     OAM packet in SFC - packet that carries OAM information as
>>>     payload that immediately follows the NSH.____
>>>
>>>     __ __
>>>
>>>     Regards,____
>>>
>>>     Greg____
>>>
>>>     __ __
>>>
>>>     On Mon, Jul 3, 2017 at 5:37 PM, Carlos Pignataro (cpignata)
>>>     <[email-masked] <mailto:[email-masked]>> wrote:____
>>>
>>>         Hi Andy, ____
>>>
>>>         __ __
>>>
>>>         I believe that s/packet/information/ can actually cause more
>>>         confusion that bring clarity.____
>>>
>>>         __ __
>>>
>>>         O=0 means that the payload is a user packet. O=1 means the
>>>         payload is an OAM packet. ____
>>>
>>>         __ __
>>>
>>>         However, this is independent of the Metadata, since some
>>>         Metadata can be OAM-ish (as a timestamp). And this is also
>>>         independent of a NULL payload as in Adrian’s draft.____
>>>
>>>         __ __
>>>
>>>         A user packet with OAM-ish metadata will have O=0.____
>>>
>>>         __ __
>>>
>>>         The text can always be polished more — I am not sure if we
>>>         might be in diminishing return territory.____
>>>
>>>         __ __
>>>
>>>         (I would not oppose a clarification that speaks to the
>>>         metadata independence of O for user packets, although maybe
>>>         that does belong in other documents)____
>>>
>>>         __ __
>>>
>>>         Thanks!____
>>>
>>>         __ __
>>>
>>>         Carlos.____
>>>
>>>         __ __
>>>
>>>             On Jul 1, 2017, at 5:26 PM, Andrew G. Malis
>>>             <[email-masked] <mailto:[email-masked]>> wrote:____
>>>
>>>             __ __
>>>
>>>             Joel, ____
>>>
>>>             __ __
>>>
>>>             I would like to suggest changing:____
>>>
>>>             __ __
>>>
>>>                [oam-frame]).____
>>>             __ __
>>>             to:____
>>>             __ __
>>>                Maintenance (OAM) information.  The actual OAM
>>>             information format and processing____
>>>
>>>                is outside the scope of this specification (see 
>>>             [oam-frame]).____
>>>
>>>             __ __
>>>
>>>             __ __
>>>
>>>             The reason for this change is that we don’t yet know if
>>>             the format of OAM information, and whether it will be in
>>>             metadata, packet contents, or both. Thus, we don’t yet
>>>             even know if there will be “OAM packets” per se, as data
>>>             packets could possibly also carry OAM information in the
>>>             metadata.____
>>>
>>>             __ __
>>>
>>>             If this change is acceptable, then the following two
>>>             paragraphs should also be amended to:____
>>>
>>>             __ __
>>>
>>>                a configurable parameter to enable forwarding received
>>>             packets with the O bit____
>>>
>>>                packets without OAM information.  The O bit MUST NOT
>>>             be modified along the SFP.____
>>>
>>>             __ __
>>>
>>>             __ __
>>>
>>>             Finally, I’ve seen both “O bit” and O-bit” used in the
>>>             document. The document should choose one.____
>>>
>>>             __ __
>>>
>>>             Thanks,____
>>>
>>>             Andy____
>>>
>>>             __ __
>>>
>>>             __ __
>>>
>>>             On Sat, Jul 1, 2017 at 5:11 PM, Joel M. Halpern
>>>             <[email-masked] <mailto:[email-masked]>> wrote:____
>>>
>>>                 This seems to me a VERY clear description of when the
>>>                 bit is to be set, and what handling is required when
>>>                 packets with this bit are received at an NSH support
>>>                 entity.
>>>
>>>                 On 7/1/17 5:02 PM, Greg Mirsky wrote:____
>>>
>>>                     Hi Joel,
>>>                     by all means, I'm not asking to hold NSH document
>>>                     until SFC OAM solutions progress. But NSH refers
>>>                     to OAM packet and, in my view, it is too
>>>                     If work on OAM framework is progressing, perhaps
>>>                     all the OAM related discussion as well as
>>>                     allocation of the O-bit itself can be moved there.
>>>
>>>                     As co-author of several SFC OAM drafts I'd note
>>>                     that none of them has dependency on where OAM
>>>                     information must be placed, metadata or payload.
>>>                     But clear and unambiguous definitionsof OAM
>>>                     packet and interpretation of O-bit are very much
>>>                     needed and will help to progress SFC OAM solutions.
>>>
>>>                     Regards,
>>>                     Greg____
>>>
>>>                     On Sat, Jul 1, 2017 at 1:21 PM, Joel M. Halpern
>>>                     <[email-masked] <mailto:[email-masked]>
>>>                     <mailto:[email-masked]
>>>                     <mailto:[email-masked]>>> wrote:
>>>
>>>                     <mailto:[email-masked]>>____
>>>
>>>                     <mailto:[email-masked]>
>>>                     <mailto:[email-masked]>>>> wrote:
>>>
>>>                     <mailto:[email-masked] <mailto:[email-masked]>>
>>>                     <https://www.ietf.org/mailman/listinfo/sfc
>>>                     <https://www.ietf.org/mailman/listinfo/sfc>>
>>>
>>>                     ____
>>>
>>>
>>>                 <https://www.ietf.org/mailman/listinfo/sfc>____
>>>
>>>             __ __
>>>
>>>             <https://www.ietf.org/mailman/listinfo/sfc>____
>>>
>>>         __ __
>>>
>>>         —____
>>>
>>>         Carlos Pignataro, [email-masked] <mailto:[email-masked]>
>>>
>>>         /“Sometimes I use big words that I do not fully understand,
>>>         to make myself sound more photosynthesis."/____
>>>
>>>         __ __
>>>
>>>     __ __
>>>
>>>
>>
>> —
>> Carlos Pignataro, [email-masked] <mailto:[email-masked]>
>>
>> /“Sometimes I use big words that I do not fully understand, to make 
>> myself sound more photosynthesis."/
>>
> 
> —
> Carlos Pignataro, [email-masked] <mailto:[email-masked]>
> 
> /“Sometimes I use big words that I do not fully understand, to make 
> myself sound more photosynthesis."/
>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 6 Jul 2017 20:53:07 -0700

Hi Carlos,
thank you for clarification. Andy and I had pointed that the NSH document
doesn't provide definition of OAM packet and thus use of O-bit is unclear.
In your earlier mail you've mentioned that SFC OAM packet is the packet
with OAM payload (that could be control message or measurement results). If
you believe that the current wording on O-bit should not be changed to
provide the definition of SFC OAM packet, then I support adoption of the
text proposed by Andy Malis.

Regards,
Greg

On Thu, Jul 6, 2017 at 8:24 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> On Jul 6, 2017, at 11:20 PM, Dave Dolson <[email-masked]> wrote:
>
> *Cc: *Joel M. Halpern; Andrew G. Malis; [email-masked]; James N Guichard
> *Subject: *Re: [sfc] Status of draft-ietf-sfc-nsh [Was: Meeting at IETF
> 99 in Prague]
>
> “SFC OAM packet is the packet that has OAM payload immediately following
> NSH.  In all other cases, i.e. when the payload is not OAM, the O-bit MUST
> be reset.”
>
> And while at first glance it sounds like a potentially useful or at least
> non-harmful addition, very similar text already exists one paragraph below:
>
> already pointing to a spec that would detail this processing. Things like
> “immediately following” can be specified in the OAM document. As it is now,
> what O means is clear and aligns with what I wrote below.
>
> Additionally, I’d much rather not change the text that was worked through
> iterations and consensus. However, I suggest we can move up that sentence
> one paragraph up to improve the flow and make it explicitly clear:
>
>
> On Jul 6, 2017, at 10:07 PM, Greg Mirsky <[email-masked]> wrote:
>
> Hi Jim,
>> It is difficult to tell from this thread whether a textual change is
>> being proposed or if the current text is sufficient; please can you clarify
>> for the WG and if a textual change is being proposed please clearly state
>> what this is so that the WG can evaluate and we can move forward.
>>
>>
>>
>> Many thanks!
>>
>>
>>
>> Jim
>>
>>
>>
>> *“Sometimes I use big words that I do not fully understand, to make
>> myself sound more photosynthesis."*
>>
>>
>>
>>
>>
>
>
> —

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 6 Jul 2017 20:59:10 -0700

Hi Joel,
considering that we have active and hybrid OAM mechanisms under discussion,
the clear definition of what SFC OAM packet must be, in my view, in the NSH
document. I, for one, will support the definition of SFC OAM packet as
active OAM packet that is specifically generated for OAM purpose and whose
scope is limited by the SFC domain.

Regards,
Greg

On Thu, Jul 6, 2017 at 8:48 PM, Joel M. Halpern <[email-masked]> wrote:

> The current text says rather more than just "the O bit must be zero". It
> prescribes what behavior should be implemented in NSH devices for
> assumptions about where the information will reside, we have not agreed on
> that.
>
> Yours,
> Joel
>
>> On Jul 6, 2017, at 11:20 PM, Dave Dolson <[email-masked] <mailto:
>>> [email-masked]>> wrote:
>>>
>>> *Cc: *Joel M. Halpern; Andrew G. Malis; [email-masked] <mailto:
>>> [email-masked]>; James N Guichard
>>> least non-harmful addition, very similar text already exists one paragraph
>>> below:
>>>
>>> “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.”
>>>
>>> through iterations and consensus. However, I suggest we can move up that
>>> sentence one paragraph up to improve the flow and make it explicitly clear:
>>>
>>>
>>> On Jul 6, 2017, at 10:07 PM, Greg Mirsky <[email-masked] <mailto:
>>>> [email-masked]>> wrote:
>>>>
>>>> Hi Jim,
>>>> Maintenance (OAM) packet. The actual packet format and processing of SFC
>>>> OAM messages is outside the scope of this specification (see [oam-frame]).
>>>> NEW:
>>>> Maintenance (OAM) packet. SFC OAM packet is the packet that has OAM payload
>>>> immediately following NSH. In all other cases, i.e. when the payload is not
>>>> OAM, the O-bit MUST be reset. The actual packet format and processing of
>>>> SFC OAM messages are outside the scope of this specification (see
>>>> [oam-frame]).
>>>> Regards,
>>>> Greg
>>>>
>>>> [email-masked] <mailto:[email-masked]>>
>>>> wrote:
>>>>
>>>>     Hi Greg/Carlos,____
>>>>
>>>>     __ __
>>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 7 Jul 2017 00:05:15 -0400

<all of the below without WG chair hat>
I would have to see specific text.  I am personally not happy with the 
wording you suggested recently that an OAM packet is one where the OAM 
payload follows the NSH header.

The point of the bit is that it tells the NSH processing entity that it 
is required to do extra work.  The point of the bit is NOT to tell it 
what extra work is required, or where to look for extra information. 
And by keeping that separation, we get significant flexibility in how we 
address various cases.  And we can evaluate the behaviors we want for 
the different situations, and set the bit appropriately for our desired 
behavior.

Yours,
Joel

On 7/6/17 11:59 PM, Greg Mirsky wrote:
> Hi Joel,
> considering that we have active and hybrid OAM mechanisms under 
> discussion, the clear definition of what SFC OAM packet must be, in my 
> view, in the NSH document. I, for one, will support the definition of 
> SFC OAM packet as active OAM packet that is specifically generated for 
> OAM purpose and whose scope is limited by the SFC domain.
> 
> Regards,
> Greg
> 
> On Thu, Jul 6, 2017 at 8:48 PM, Joel M. Halpern <[email-masked] 
>     The current text says rather more than just "the O bit must be
>     zero". It prescribes what behavior should be implemented in NSH
>     devices for processing packets where the O bit is set.  Which we
>     were specifically asked to provide.
> 
>     Speaking personally, I prefer that the OAM text in the NSH document
>     not specify where the OAM information is carried.  While some folks
>     have assumptions about where the information will reside, we have
>     not agreed on that.
> 
>     Yours,
>     Joel
> 
>             On Jul 6, 2017, at 11:20 PM, Dave Dolson
>             <[email-masked] <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>>
>             wrote:
> 
>             <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>; James N Guichard
>             *Subject: *Re: [sfc] Status of draft-ietf-sfc-nsh [Was:
>             Meeting at IETF 99 in Prague]
> 
> 
> 
>             “SFC OAM packet is the packet that has OAM payload
>             immediately following NSH.  In all other cases, i.e. when
>             the payload is not OAM, the O-bit MUST be reset.”
> 
>             And while at first glance it sounds like a potentially
>             useful or at least non-harmful addition, very similar text
>             already exists one paragraph below:
> 
>             “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.”
> 
>             I prefer to specify as little as possible of OAM here, since
>             we are already pointing to a spec that would detail this
>             processing. Things like “immediately following” can be
>             specified in the OAM document. As it is now, what O means is
>             clear and aligns with what I wrote below.
> 
>             Additionally, I’d much rather not change the text that was
>             worked through iterations and consensus. However, I suggest
>             we can move up that sentence one paragraph up to improve the
>             flow and make it explicitly clear:
> 
> 
>             SFC OAM
>             Thoughts on this proposal? It seems to achieve the right
>             balance of not over specify but bring clarity.
> 
>             Thanks,
> 
>             — Carlos.
> 
> 
>                 On Jul 6, 2017, at 10:07 PM, Greg Mirsky
>                 <[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked]
>                 <mailto:[email-masked]>>> wrote:
> 
>                 Hi Jim,
>                 I can give my interpretation of what Carlos had proposed
>                 and how his clarification may be reflected in the document:
>                 OLD:
>                 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 [oam-frame]).
>                 NEW:
>                 O bit: Setting this bit indicates an Operations,
>                 Administration, and Maintenance (OAM) packet. SFC OAM
>                 packet is the packet that has OAM payload immediately
>                 following NSH. In all other cases, i.e. when the payload
>                 is not OAM, the O-bit MUST be reset. The actual packet
>                 format and processing of SFC OAM messages are outside
>                 the scope of this specification (see [oam-frame]).
>                 Regards,
>                 Greg
> 
>                 <[email-masked]
>                 <mailto:[email-masked]>
>                 <mailto:[email-masked]
>                 <mailto:[email-masked]>>> wrote:
> 
>                      Hi Greg/Carlos,____
> 
>                      __ __
> 
>                 <mailto:[email-masked]>
>                      <mailto:[email-masked]
>                 <mailto:[email-masked]>>] *On Behalf Of *Greg Mirsky
>                      *To:* Carlos Pignataro (cpignata)
>                 <[email-masked] <mailto:[email-masked]>
>                      <mailto:[email-masked]
>                 <mailto:[email-masked]>>>
>                 <mailto:[email-masked]>
>                 <mailto:[email-masked]>>>; Andrew G. Malis
>                 <[email-masked] <mailto:[email-masked]>
>                      <mailto:[email-masked]
>                 <mailto:[email-masked]>>>; [email-masked]
>                 <mailto:[email-masked]> <mailto:[email-masked]
>                 <mailto:[email-masked]>>
>                      <[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>>
>                 wrote:____
> 
>                          Hi Andy, ____
> 
>                          __ __
> 
>                              <[email-masked]
>                 <mailto:[email-masked]> <mailto:[email-masked]
>                 <mailto:[email-masked]>>> wrote:____
> 
>                              __ __
> 
>                              Joel, ____
> 
>                              __ __
> 
>                              O bit: Setting this bit indicates an
>                 Operations,
>                              Administration, and
>                                 Maintenance (OAM) packet.  The actual
>                 packet format
>                              and processing of
>                              O bit: Setting this bit indicates the
>                 presence of
>                              Operations, Administration, and
>                                 is outside the scope of this
>                 specification (see             [oam-frame]).____
> 
>                              __ __
> 
>                              __ __
> 
>                                 SF/SFF/SFC Proxy/Classifer
>                 implementations that do not
>                              support SFC
>                                 OAM procedures SHOULD discard packets
>                 with O bit set,
>                              but MAY support
>                                 packets with the O bit set unmodified by
>                 SFC elements
>                              that do not support SFC OAM
>                                 procedures may be acceptable for a
>                 subset of OAM
>                              functions, but can
>                                 result in unexpected outcomes for
>                 others, thus it is
>                              recommended to
>                                 analyze the impact of forwarding a
>                 packet with the O
>                              bit set for all OAM functions
>                                 prior to enabling this behavior.  The
>                 configurable
>                              parameter MUST be
>                                 disabled by default.
> 
>                                 The O bit MUST be set for packets
>                 containing OAM
>                              information and MUST NOT be set for
>                              <[email-masked]
>                 <mailto:[email-masked]> <mailto:[email-masked]
>                 <mailto:[email-masked]>>> wrote:____
> 
> 
>                                  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
>                                     [oam-frame]).
> 
>                                     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.  Forwarding OAM
>                                     packets unmodified by SFC elements
>                 that do not
>                                  support SFC OAM
>                                     procedures may be acceptable for a
>                 subset of OAM
>                                  functions, but can
>                                     result in unexpected outcomes for
>                 others, thus it
>                                  is recommended to
>                                     analyze the impact of forwarding an
>                 OAM packet for
>                                  all OAM functions
>                                     prior to enabling this behavior. 
>                 The configurable
>                                  parameter MUST be
>                                     disabled by default.
> 
>                                     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.
> 
>                                  If you consider this wording unclear,
>                 please propose
>                                  specific text to improve it.
> 
>                                  Yours,
>                                  Joel
> 
>                                        * control message of active SFC
>                 OAM protocol
>                                      carried as payload;
>                                        * control message of active SFC
>                 OAM protocol
>                                      carried as metadata;
>                                        * control information and/or
>                 measurement
>                                      results of hybrid SFC OAM
>                                      <[email-masked]
>                 <mailto:[email-masked]> <mailto:[email-masked]
>                 <mailto:[email-masked]>>
>                 <mailto:[email-masked]>
> 
>                 <mailto:[email-masked]>>>> wrote:
> 
>                                          Greg, the editors are working
>                 on the revision
>                                      of the OAM Framework
>                                          document.
> 
>                                          <chair hat on>
>                                          More importantly, we have been
>                 careful that
>                                      the NSH document does
>                                          discussed with the working
>                 group several
>                                      times, and the OAM wording
>                                          Are you really asking that we
>                 hold up RFC
>                                      publication of the NSH
>                                          document until we have
>                 agreement on all of
>                                      the complex OAM issues
>                                          (such as in-situ, etc.)  I
>                 observe a steady
>                                      rate of new OAM
>                                          proposals, with new behaviors. 
>                 That seems to
>                                      indicate that such
>                                          ahold-up would be almost
>                 indefinite.
>                                          </chair hat off>
> 
>                                          Yours,
>                                          Joel M. Halpern
> 
>                                              you'd expect that I'll look
>                 into OAM bit
>                                      and wording on OAM
>                                              packet first. And so I had.
>                 I'm concerned
>                                      that NSH refers to
>                                              expired and, frankly,
>                 stalled document
>                                      that had not been
>                                              discussed for too long. I
>                 believe the NSH
>                                      document should have
>                                              or refer to clear
>                 definition of SFC OAM
>                                      packet before it defines
>                                              points that in current form
>                 O-bit
>                                      indicates presence of OAM
>                                              information which can be
>                 either as
>                                      metadata or as payload. I
>                                              believe that we must have
>                 more clear and
>                                      deterministic
>                                              definition of OAM packet as
>                 current, in
>                                      my opinion, may cause
>                                              On Thu, Jun 29, 2017 at
>                 4:22 PM, Joel
>                                      Halpern Direct
>                 <mailto:[email-masked]>>
>                 <mailto:[email-masked]>>>____
> 
>                                             
>                 <mailto:[email-masked]>>
>                                             
>                 <mailto:[email-masked]>>>>> wrote:
> 
>                                                   The -13 will be out in
>                 a few days
>                                      with all the changes.
>                                                   That is what we will
>                 ask the WG to
>                                      review.
>                                                   If we already had it
>                 out, we would
>                                      have already asked for
>                                              the WG to
>                                                   take a last look.
> 
>                                                   Yours,
>                                                   Joel
> 
> 
>                                                   On 6/29/17 7:21 PM,
>                 Greg Mirsky wrote:
> 
>                                                       Hi Joel,
>                                                       is the -12 the
>                 latest published
>                                      version of the NSH
>                                              draft? As I
>                                                       see, it is missing
>                 TTL and all
>                                      related changes:
> 
> 
> 
> 
>                                                               
>                 [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>                 <mailto:[email-masked]>>
>                                      <mailto:[email-masked]
>                 <mailto:[email-masked]> <mailto:[email-masked]
>                 <mailto:[email-masked]>>>
>                 <https://www.ietf.org/mailman/listinfo/sfc>>>
> 
>                                      ____
> 
> 
>                                 
>                 [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>                 <mailto:[email-masked]>>
>                 <https://www.ietf.org/mailman/listinfo/sfc>>____
> 
>                              __ __
> 
>                 [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>                 <mailto:[email-masked]>>
>                 <https://www.ietf.org/mailman/listinfo/sfc>>____
> 
>                          __ __
> 
>                          —____
> 
>                 <mailto:[email-masked]> <mailto:[email-masked]
>                 <mailto:[email-masked]>>
> 
>             <mailto:[email-masked] <mailto:[email-masked]>>
> 
>             to make myself sound more photosynthesis."/
> 
> 
>         —
>         <mailto:[email-masked] <mailto:[email-masked]>>
> 
>         /“Sometimes I use big words that I do not fully understand, to
>         make myself sound more photosynthesis."/
> 
> 
> 
>

---

From: Dave Dolson <[email-masked]>
Date: Fri, 7 Jul 2017 14:14:07 +0000

Earlier I suggested that if OAM=0, it is guaranteed that any SFC forwarding agent needs only consider the SPI and SI.

In other words, O is the slow-path bit, if you think of ASICs and handling exceptional cases in software.

David Dolson
Sandvine
  Original Message
From: Joel M. Halpern
Sent: Friday, July 7, 2017 12:05 AM
To: Greg Mirsky
Cc: Carlos Pignataro (cpignata); Andrew G. Malis; [email-masked]; Dave Dolson; James N Guichard
Subject: Re: [sfc] Status of draft-ietf-sfc-nsh [Was: Meeting at IETF 99 in Prague]

Yours,
Joel

On 7/6/17 11:59 PM, Greg Mirsky wrote:
>                 forwarding received

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 7 Jul 2017 14:15:32 +0000

Hi, Greg,

I feel I’ve been on this marry-go-round before… twice already at least.

You say:

I had pointed that

Yes, you had. But repetition of the same point ad-nauseaum when the WG agreed on an approach is distracting and unhelpful.

the NSH document doesn't provide definition of OAM packet

By design choice. The NSH document clearly says that “ The actual packet format and processing of SFC OAM messages is outside the scope of this specification”.

and thus use of O-bit is unclear.

As far as the NSH specification is concerned, this is not the case.

The use of the O-bit for NSH is clear, well-defined, and deterministic for NSH: O set means OAM packet, SHOULD be discarded, further definitions in a separate place not on the -base NSH. The WG discussions took the text to a place in which there is already a lot of details on what to do at the NSH layer, without concerning itself with the OAM format and specific functions. That’s the path of maximum efficiency for the document.

In regards to the changes proposed by Andy, when I diff the text it seems that the change limits itself to substituting OAM packet with OAM information. To me, personally, that makes the definition more fuzzy and unsharpened.

Andy, have I misinterpreted? I did not see a response from you later on the thread.

Please do not lose sight of the WG goal and the collective high-order bit.

Thanks!

— Carlos.

On Jul 6, 2017, at 11:53 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,
thank you for clarification. Andy and I had pointed that the NSH document doesn't provide definition of OAM packet and thus use of O-bit is unclear. In your earlier mail you've mentioned that SFC OAM packet is the packet with OAM payload (that could be control message or measurement results). If you believe that the current wording on O-bit should not be changed to provide the definition of SFC OAM packet, then I support adoption of the text proposed by Andy Malis.

Regards,
Greg

On Thu, Jul 6, 2017 at 8:24 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Correct practically — zero for user packets.

Thanks,

— Carlos.

David Dolson
Sandvine

Thanks,

— Carlos.

Hi Jim,

NEW:

Regards,

Greg

Many thanks!

Jim

Hi Carlos,

Regards,
Greg

Thanks!

Carlos.

Joel,

to:

Thanks,
Andy

Yours,
Joel

Regards,
Greg

    <chair hat on>

    Yours,
    Joel M. Halpern

        Hi Joel, Adrian, et. al,

        Regards,
        Greg

             Yours,
             Joel

                 Hi Joel,

—

—

—

—

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 7 Jul 2017 14:22:49 +0000

I agree with this point, as it does not lock NSH and gives future proof and flexibility for OAM.

Greg, you added:

I, for one, will support the definition of SFC OAM packet as active OAM packet that is specifically generated for OAM purpose and whose scope is limited by the SFC domain.

I think that’s a great discussion and initial comment for the OAM document. Not for NSH.

Thanks,

— Carlos.

On Jul 7, 2017, at 12:05 AM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:

<all of the below without WG chair hat>
I would have to see specific text.  I am personally not happy with the wording you suggested recently that an OAM packet is one where the OAM payload follows the NSH header.

The point of the bit is that it tells the NSH processing entity that it is required to do extra work.  The point of the bit is NOT to tell it what extra work is required, or where to look for extra information. And by keeping that separation, we get significant flexibility in how we address various cases.  And we can evaluate the behaviors we want for the different situations, and set the bit appropriately for our desired behavior.

Yours,
Joel

On 7/6/17 11:59 PM, Greg Mirsky wrote:
Hi Joel,
considering that we have active and hybrid OAM mechanisms under discussion, the clear definition of what SFC OAM packet must be, in my view, in the NSH document. I, for one, will support the definition of SFC OAM packet as active OAM packet that is specifically generated for OAM purpose and whose scope is limited by the SFC domain.
Regards,
Greg
On Thu, Jul 6, 2017 at 8:48 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:
   The current text says rather more than just "the O bit must be
   zero". It prescribes what behavior should be implemented in NSH
   devices for processing packets where the O bit is set.  Which we
   were specifically asked to provide.
   Speaking personally, I prefer that the OAM text in the NSH document
   not specify where the OAM information is carried.  While some folks
   have assumptions about where the information will reside, we have
   not agreed on that.
   Yours,
   Joel
   On 7/6/17 11:24 PM, Carlos Pignataro (cpignata) wrote:
       Correct practically — zero for user packets.
       And I believe that’s what this says (using more words):
             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]).
             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,
       — Carlos.
           On Jul 6, 2017, at 11:20 PM, Dave Dolson
           <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
           <mailto:[email-masked] <mailto:[email-masked]>>>
           wrote:
           Practically, "The O-bit MUST be zero." Until OAM for NSH is
           defined.
           Isn't that where we are at?
           David Dolson
           Sandvine
           *From: *Carlos Pignataro (cpignata)
           *Sent: *Thursday, July 6, 2017 11:14 PM
           *To: *Greg Mirsky
           *Cc: *Joel M. Halpern; Andrew G. Malis; [email-masked]<mailto:[email-masked]>
           <mailto:[email-masked]> <mailto:[email-masked]
           <mailto:[email-masked]>>; James N Guichard
           *Subject: *Re: [sfc] Status of draft-ietf-sfc-nsh [Was:
           Meeting at IETF 99 in Prague]
           Thanks Greg and Jim. I would like to close on this item.
           For clarity, what you (Greg) are proposing is the addition
           of the following text:
           “SFC OAM packet is the packet that has OAM payload
           immediately following NSH.  In all other cases, i.e. when
           the payload is not OAM, the O-bit MUST be reset.”
           And while at first glance it sounds like a potentially
           useful or at least non-harmful addition, very similar text
           already exists one paragraph below:
           “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.”
           I prefer to specify as little as possible of OAM here, since
           we are already pointing to a spec that would detail this
           processing. Things like “immediately following” can be
           specified in the OAM document. As it is now, what O means is
           clear and aligns with what I wrote below.
           Additionally, I’d much rather not change the text that was
           worked through iterations and consensus. However, I suggest
           we can move up that sentence one paragraph up to improve the
           flow and make it explicitly clear:
                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]).
           +   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.
           +
                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.             Forwarding OAM
                packets unmodified by SFC elements that do not support
           SFC OAM
                procedures may be acceptable for a subset of OAM
           functions, but can
                result in unexpected outcomes for others, thus it is
           recommended to
                analyze the impact of forwarding an OAM packet for all
           OAM functions
                prior to enabling this behavior.  The configurable
           parameter MUST be
                disabled by default.
           -   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.
           -
           Thoughts on this proposal? It seems to achieve the right
           balance of not over specify but bring clarity.
           Thanks,
           — Carlos.
               On Jul 6, 2017, at 10:07 PM, Greg Mirsky
               <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
               <mailto:[email-masked]
               <mailto:[email-masked]>>> wrote:
               Hi Jim,
               I can give my interpretation of what Carlos had proposed
               and how his clarification may be reflected in the document:
               OLD:
               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 [oam-frame]).
               NEW:
               O bit: Setting this bit indicates an Operations,
               Administration, and Maintenance (OAM) packet. SFC OAM
               packet is the packet that has OAM payload immediately
               following NSH. In all other cases, i.e. when the payload
               is not OAM, the O-bit MUST be reset. The actual packet
               format and processing of SFC OAM messages are outside
               the scope of this specification (see [oam-frame]).
               Regards,
               Greg
               On Wed, Jul 5, 2017 at 8:45 AM, James N Guichard
               <[email-masked]<mailto:[email-masked]>
               <mailto:[email-masked]>
               <mailto:[email-masked]
               <mailto:[email-masked]>>> wrote:
                    Hi Greg/Carlos,____
                    __ __
                    It is difficult to tell from this thread whether a
               textual change
                    is being proposed or if the current text is
               sufficient; please
                    can you clarify for the WG and if a textual change
               is being
                    proposed please clearly state what this is so that
               the WG can
                    evaluate and we can move forward.____
                    __ __
                    Many thanks!____
                    __ __
                    Jim____
                    __ __
                    *From:*sfc [mailto:[email-masked]
               <mailto:[email-masked]>
                    <mailto:[email-masked]
               <mailto:[email-masked]>>] *On Behalf Of *Greg Mirsky
                    *Sent:* Tuesday, July 04, 2017 1:41 AM
                    *To:* Carlos Pignataro (cpignata)
               <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
                    <mailto:[email-masked]
               <mailto:[email-masked]>>>
                    *Cc:* Joel M. Halpern <[email-masked]<mailto:[email-masked]>
               <mailto:[email-masked]>
                    <mailto:[email-masked]
               <mailto:[email-masked]>>>; Andrew G. Malis
               <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
                    <mailto:[email-masked]
               <mailto:[email-masked]>>>; [email-masked]<mailto:[email-masked]>
               <mailto:[email-masked]> <mailto:[email-masked]
               <mailto:[email-masked]>>
                    *Subject:* Re: [sfc] Status of draft-ietf-sfc-nsh
               [Was: Meeting
                    at IETF 99 in Prague]____
                    __ __
                    Hi Carlos,____
                    you have valid interpretation of the text in its
               current version.
                    And I think that if it was in the document as you
               have presented
                    (or very close to it), it would address my concern,
               as you've
                    provided clear and unambiguous definition of what
               considered as
                    OAM packet in SFC - packet that carries OAM
               information as
                    payload that immediately follows the NSH.____
                    __ __
                    Regards,____
                    Greg____
                    __ __
                    On Mon, Jul 3, 2017 at 5:37 PM, Carlos Pignataro
               (cpignata)
                    <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
               <mailto:[email-masked] <mailto:[email-masked]>>>
               wrote:____
                        Hi Andy, ____
                        __ __
                        I believe that s/packet/information/ can
               actually cause more
                        confusion that bring clarity.____
                        __ __
                        O=0 means that the payload is a user packet.
               O=1 means the
                        payload is an OAM packet. ____
                        __ __
                        However, this is independent of the Metadata,
               since some
                        Metadata can be OAM-ish (as a timestamp). And
               this is also
                        independent of a NULL payload as in Adrian’s
               draft.____
                        __ __
                        A user packet with OAM-ish metadata will have
               O=0.____
                        __ __
                        The text can always be polished more — I am not
               sure if we
                        might be in diminishing return territory.____
                        __ __
                        (I would not oppose a clarification that speaks
               to the
                        metadata independence of O for user packets,
               although maybe
                        that does belong in other documents)____
                        __ __
                        Thanks!____
                        __ __
                        Carlos.____
                        __ __
                            On Jul 1, 2017, at 5:26 PM, Andrew G. Malis
                            <[email-masked]<mailto:[email-masked]>
               <mailto:[email-masked]> <mailto:[email-masked]
               <mailto:[email-masked]>>> wrote:____
                            __ __
                            Joel, ____
                            __ __
                            I would like to suggest changing:____
                            __ __
                            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
                               [oam-frame]).____
                            __ __
                            to:____
                            __ __
                            O bit: Setting this bit indicates the
               presence of
                            Operations, Administration, and
                               Maintenance (OAM) information.  The
               actual OAM
                            information format and processing____
                               is outside the scope of this
               specification (see             [oam-frame]).____
                            __ __
                            __ __
                            The reason for this change is that we don’t
               yet know if
                            the format of OAM information, and whether
               it will be in
                            metadata, packet contents, or both. Thus,
               we don’t yet
                            even know if there will be “OAM packets”
               per se, as data
                            packets could possibly also carry OAM
               information in the
                            metadata.____
                            __ __
                            If this change is acceptable, then the
               following two
                            paragraphs should also be amended to:____
                            __ __
                               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
                            packets with the O bit____
                               set unmodified to the next element in
               the chain.             Forwarding
                               packets with the O bit set unmodified by
               SFC elements
                            that do not support SFC OAM
                               procedures may be acceptable for a
               subset of OAM
                            functions, but can
                               result in unexpected outcomes for
               others, thus it is
                            recommended to
                               analyze the impact of forwarding a
               packet with the O
                            bit set for all OAM functions
                               prior to enabling this behavior.  The
               configurable
                            parameter MUST be
                               disabled by default.
                               The O bit MUST be set for packets
               containing OAM
                            information and MUST NOT be set for
                               packets without OAM information.  The O
               bit MUST NOT
                            be modified along the SFP.____
                            __ __
                            __ __
                            Finally, I’ve seen both “O bit” and O-bit”
               used in the
                            document. The document should choose one.____
                            __ __
                            Thanks,____
                            Andy____
                            __ __
                            __ __
                            On Sat, Jul 1, 2017 at 5:11 PM, Joel M. Halpern
                            <[email-masked]<mailto:[email-masked]>
               <mailto:[email-masked]> <mailto:[email-masked]
               <mailto:[email-masked]>>> wrote:____
                                The definition of the O bit in the
               document is:
                                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
                                   [oam-frame]).
                                   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.  Forwarding OAM
                                   packets unmodified by SFC elements
               that do not
                                support SFC OAM
                                   procedures may be acceptable for a
               subset of OAM
                                functions, but can
                                   result in unexpected outcomes for
               others, thus it
                                is recommended to
                                   analyze the impact of forwarding an
               OAM packet for
                                all OAM functions
                                   prior to enabling this behavior.                 The configurable
                                parameter MUST be
                                   disabled by default.
                                   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.
                                This seems to me a VERY clear
               description of when the
                                bit is to be set, and what handling is
               required when
                                packets with this bit are received at
               an NSH support
                                entity.
                                If you consider this wording unclear,
               please propose
                                specific text to improve it.
                                Yours,
                                Joel
                                On 7/1/17 5:02 PM, Greg Mirsky wrote:____
                                    Hi Joel,
                                    by all means, I'm not asking to
               hold NSH document
                                    until SFC OAM solutions progress.
               But NSH refers
                                    to OAM packet and, in my view, it
               is too
                                    ambiguous term. Please consider,
               OAM packet may be:
                                      * control message of active SFC
               OAM protocol
                                    carried as payload;
                                      * control message of active SFC
               OAM protocol
                                    carried as metadata;
                                      * control information and/or
               measurement
                                    results of hybrid SFC OAM
                                        protocol carried as metadata
                                    If work on OAM framework is
               progressing, perhaps
                                    all the OAM related discussion as
               well as
                                    allocation of the O-bit itself can
               be moved there.
                                    As co-author of several SFC OAM
               drafts I'd note
                                    that none of them has dependency on
               where OAM
                                    information must be placed,
               metadata or payload.
                                    But clear and unambiguous
               definitionsof OAM
                                    packet and interpretation of O-bit
               are very much
                                    needed and will help to progress
               SFC OAM solutions.
                                    Regards,
                                    Greg____
                                    On Sat, Jul 1, 2017 at 1:21 PM,
               Joel M. Halpern
                                    <[email-masked]<mailto:[email-masked]>
               <mailto:[email-masked]> <mailto:[email-masked]
               <mailto:[email-masked]>>
                                    <mailto:[email-masked]
               <mailto:[email-masked]>
                                    <mailto:[email-masked]
               <mailto:[email-masked]>>>> wrote:
                                        Greg, the editors are working
               on the revision
                                    of the OAM Framework
                                        document.
                                        <chair hat on>
                                        More importantly, we have been
               careful that
                                    the NSH document does
                                        not normatively depend upon the OAM
                                    specification.  This was
                                        discussed with the working
               group several
                                    times, and the OAM wording
                                        in -13 is the result of that
               discussion.
                                        </chair hat on>
                                        <chair hat off>
                                        Are you really asking that we
               hold up RFC
                                    publication of the NSH
                                        document until we have
               agreement on all of
                                    the complex OAM issues
                                        (such as in-situ, etc.)  I
               observe a steady
                                    rate of new OAM
                                        proposals, with new behaviors.                 That seems to
                                    indicate that such
                                        ahold-up would be almost
               indefinite.
                                        </chair hat off>
                                        Yours,
                                        Joel M. Halpern
                                        On 7/1/17 3:39 PM, Greg Mirsky
               wrote:
                                            Hi Joel, Adrian, et. al,
                                            you'd expect that I'll look
               into OAM bit
                                    and wording on OAM
                                            packet first. And so I had.
               I'm concerned
                                    that NSH refers to
                                            expired and, frankly,
               stalled document
                                    that had not been
                                            discussed for too long. I
               believe the NSH
                                    document should have
                                            or refer to clear
               definition of SFC OAM
                                    packet before it defines
                                            interpretation of O-bit flag.
                                    draft-farrel-sfc-convent correctly
                                            points that in current form
               O-bit
                                    indicates presence of OAM
                                            information which can be
               either as
                                    metadata or as payload. I
                                            believe that we must have
               more clear and
                                    deterministic
                                            definition of OAM packet as
               current, in
                                    my opinion, may cause
                                            problems for HW-based SFC
               OAM support.
                                            Regards,
                                            Greg
                                            On Thu, Jun 29, 2017 at
               4:22 PM, Joel
                                    Halpern Direct
                                            <[email-masked]<mailto:[email-masked]>
               <mailto:[email-masked]>
                                    <mailto:[email-masked]
               <mailto:[email-masked]>>
                                    <mailto:[email-masked]
               <mailto:[email-masked]>
                                    <mailto:[email-masked]
               <mailto:[email-masked]>>>____
                                                           <mailto:[email-masked]
               <mailto:[email-masked]>
                                    <mailto:[email-masked]
               <mailto:[email-masked]>>
                                                           <mailto:[email-masked]
               <mailto:[email-masked]>
                                    <mailto:[email-masked]
               <mailto:[email-masked]>>>>> wrote:
                                                 The -13 will be out in
               a few days
                                    with all the changes.
                                                 That is what we will
               ask the WG to
                                    review.
                                                 If we already had it
               out, we would
                                    have already asked for
                                            the WG to
                                                 take a last look.
                                                 Yours,
                                                 Joel
                                                 On 6/29/17 7:21 PM,
               Greg Mirsky wrote:
                                                     Hi Joel,
                                                     is the -12 the
               latest published
                                    version of the NSH
                                            draft? As I
                                                     see, it is missing
               TTL and all
                                    related changes:
                                                                               _______________________________________________
                                            sfc mailing list
               [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]
               <mailto:[email-masked]>>
                                    <mailto:[email-masked]
               <mailto:[email-masked]> <mailto:[email-masked]
               <mailto:[email-masked]>>>
               https://www.ietf.org/mailman/listinfo/sfc
               <https://www.ietf.org/mailman/listinfo/sfc>
                                                   <https://www.ietf.org/mailman/listinfo/sfc
               <https://www.ietf.org/mailman/listinfo/sfc>>
                                                                               <https://www.ietf.org/mailman/listinfo/sfc
               <https://www.ietf.org/mailman/listinfo/sfc>
                                                   <https://www.ietf.org/mailman/listinfo/sfc
               <https://www.ietf.org/mailman/listinfo/sfc>>>
                                    ____
                                               _______________________________________________
                                sfc mailing list
               [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]
               <mailto:[email-masked]>>
               https://www.ietf.org/mailman/listinfo/sfc
               <https://www.ietf.org/mailman/listinfo/sfc>
                                               <https://www.ietf.org/mailman/listinfo/sfc
               <https://www.ietf.org/mailman/listinfo/sfc>>____
                            __ __
                            _______________________________________________
                            sfc mailing list
               [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]
               <mailto:[email-masked]>>
               https://www.ietf.org/mailman/listinfo/sfc
               <https://www.ietf.org/mailman/listinfo/sfc>
                            <https://www.ietf.org/mailman/listinfo/sfc
               <https://www.ietf.org/mailman/listinfo/sfc>>____
                        __ __
                        —____
                        Carlos Pignataro, [email-masked]<mailto:[email-masked]>
               <mailto:[email-masked]> <mailto:[email-masked]
               <mailto:[email-masked]>>
                        /“Sometimes I use big words that I do not fully
               understand,
                        to make myself sound more photosynthesis."/____
                        __ __
                    __ __
           —
           Carlos Pignataro, [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
           <mailto:[email-masked] <mailto:[email-masked]>>
           /“Sometimes I use big words that I do not fully understand,
           to make myself sound more photosynthesis."/
       —
       Carlos Pignataro, [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
       <mailto:[email-masked] <mailto:[email-masked]>>
       /“Sometimes I use big words that I do not fully understand, to
       make myself sound more photosynthesis."/
_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

—

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 7 Jul 2017 14:31:01 +0000

Hi, Dave,

On Jul 7, 2017, at 10:14 AM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:

If O=0, all the text from draft-ietf-sfc-nsh applies.

I think this is too implementation of a consideration for the spec. I do not think a definition at this level is about processing paths and exception paths. OAM might not be an exceptional case and some OAMs can be/are ASIC processed.

This is why my belief is that for the base NSH document, we should strongly avoid the temptation (that I also have) to go into OAM details (format, processing, etc).

Thanks,

Carlos.

David Dolson
Sandvine
 Original Message
From: Joel M. Halpern
Sent: Friday, July 7, 2017 12:05 AM
To: Greg Mirsky
Cc: Carlos Pignataro (cpignata); Andrew G. Malis; [email-masked]<mailto:[email-masked]>; Dave Dolson; James N Guichard
Subject: Re: [sfc] Status of draft-ietf-sfc-nsh [Was: Meeting at IETF 99 in Prague]

Yours,
Joel

Regards,
Greg

On Thu, Jul 6, 2017 at 8:48 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>> wrote:

   Yours,
   Joel

       Thanks,

       — Carlos.

           David Dolson
           Sandvine

                packets unmodified to the next element in the chain.
           Forwarding OAM

           Thanks,

           — Carlos.

               Hi Jim,

                    Hi Greg/Carlos,____

                    __ __

                    __ __

                    Many thanks!____

                    __ __

                    Jim____

                    __ __

                    __ __

                    Hi Carlos,____

                    __ __

                    Regards,____

                    Greg____

                    __ __

                        Hi Andy, ____

                        __ __

                        __ __

                        __ __

                        __ __

                        __ __

                        __ __

                        __ __

                        Thanks!____

                        __ __

                        Carlos.____

                        __ __

                            __ __

                            Joel, ____

                            __ __

                            __ __

                            __ __

                            to:____

                            __ __

                            __ __

                            __ __

                            __ __

                            __ __

                            __ __

                            __ __

                            __ __

                            Thanks,____

                            Andy____

                            __ __

                            __ __

                                Yours,
                                Joel

                                    Hi Joel,

                                    Regards,
                                    Greg____

                                        <chair hat on>

                                        Yours,
                                        Joel M. Halpern

                                            Hi Joel, Adrian, et. al,

                                            Regards,
                                            Greg

                                            On Thu, Jun 29, 2017 at
               4:22 PM, Joel
                                    Halpern Direct

                                                 The -13 will be out in
               a few days
                                    with all the changes.
                                                 That is what we will
               ask the WG to
                                    review.
                                                 If we already had it
               out, we would
                                    have already asked for
                                            the WG to
                                                 take a last look.

                                                 Yours,
                                                 Joel

                                                 On 6/29/17 7:21 PM,
               Greg Mirsky wrote:

                                                     Hi Joel,
                                                     is the -12 the
               latest published
                                    version of the NSH
                                            draft? As I
                                                     see, it is missing
               TTL and all
                                    related changes:

                                    ____

                            __ __

                        __ __

                        —____

                        __ __

                    __ __

           —

       —

—

---

From: Dave Dolson <[email-masked]>
Date: Fri, 7 Jul 2017 14:51:35 +0000

My point is we can at least clearly define the requirements of a compliant implementation when O=0.
And if we don't define what to do when O=1, we must preclude it from being used. A later document will define that, thereby updating the current document.

At this time O really is a reserved bit, or at best Experimental for OAM.

David Dolson
Sandvine
From: Carlos Pignataro (cpignata)
Sent: Friday, July 7, 2017 10:31 AM
To: Dave Dolson
Cc: Joel M. Halpern; Greg Mirsky; Andrew G. Malis; James N Guichard; [email-masked]
Subject: Re: [sfc] Status of draft-ietf-sfc-nsh [Was: Meeting at IETF 99 in Prague]

Hi, Dave,

Thanks,

Carlos.

David Dolson
Sandvine
 Original Message
From: Joel M. Halpern

Yours,
Joel

Regards,
Greg

   Yours,
   Joel

       Thanks,

       — Carlos.

           David Dolson
           Sandvine

           Thanks,

           — Carlos.

               Hi Jim,

                    Hi Greg/Carlos,____

                    __ __

                    __ __

                    Many thanks!____

                    __ __

                    Jim____

                    __ __

                    __ __

                    Hi Carlos,____

                    __ __

                    Regards,____

                    Greg____

                    __ __

                        Hi Andy, ____

                        __ __

                        __ __

                        __ __

                        __ __

                        __ __

                        __ __

                        __ __

                        Thanks!____

                        __ __

                        Carlos.____

                        __ __

                            __ __

                            Joel, ____

                            __ __

                            __ __

                            __ __

                            to:____

                            __ __

                            __ __

                            __ __

                            __ __

                            __ __

                            __ __

                            __ __

                            __ __

                            Thanks,____

                            Andy____

                            __ __

                            __ __

                                Yours,
                                Joel

                                    Hi Joel,

                                    Regards,
                                    Greg____

                                        <chair hat on>

                                        Yours,
                                        Joel M. Halpern

                                            Hi Joel, Adrian, et. al,

                                            Regards,
                                            Greg

                                            On Thu, Jun 29, 2017 at
               4:22 PM, Joel
                                    Halpern Direct

                                                 The -13 will be out in
               a few days
                                    with all the changes.
                                                 That is what we will
               ask the WG to
                                    review.
                                                 If we already had it
               out, we would
                                    have already asked for
                                            the WG to
                                                 take a last look.

                                                 Yours,
                                                 Joel

                                                 On 6/29/17 7:21 PM,
               Greg Mirsky wrote:

                                                     Hi Joel,
                                                     is the -12 the
               latest published
                                    version of the NSH
                                            draft? As I
                                                     see, it is missing
               TTL and all
                                    related changes:

                                    ____

                            __ __

                        __ __

                        —____

                        __ __

                    __ __

           —

       —

—

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 7 Jul 2017 15:04:11 +0000

Hi, Dave,

On Jul 7, 2017, at 10:51 AM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:

CMP: Agreed with your point, I believe this is exactly what the current text achieves.

Thanks,

— Carlos.

David Dolson
Sandvine
From: Carlos Pignataro (cpignata)
Sent: Friday, July 7, 2017 10:31 AM
To: Dave Dolson
Cc: Joel M. Halpern; Greg Mirsky; Andrew G. Malis; James N Guichard; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Status of draft-ietf-sfc-nsh [Was: Meeting at IETF 99 in Prague]

Hi, Dave,

Thanks,

Carlos.

David Dolson
Sandvine
 Original Message
From: Joel M. Halpern

Yours,
Joel

Regards,
Greg

   Yours,
   Joel

       Thanks,

       — Carlos.

           David Dolson
           Sandvine

           Thanks,

           — Carlos.

               Hi Jim,

                    Hi Greg/Carlos,____

                    __ __

                    __ __

                    Many thanks!____

                    __ __

                    Jim____

                    __ __

                    __ __

                    Hi Carlos,____

                    __ __

                    Regards,____

                    Greg____

                    __ __

                        Hi Andy, ____

                        __ __

                        __ __

                        __ __

                        __ __

                        __ __

                        __ __

                        __ __

                        Thanks!____

                        __ __

                        Carlos.____

                        __ __

                            __ __

                            Joel, ____

                            __ __

                            __ __

                            __ __

                            to:____

                            __ __

                            __ __

                            __ __

                            __ __

                            __ __

                            __ __

                            __ __

                            __ __

                            Thanks,____

                            Andy____

                            __ __

                            __ __

                                Yours,
                                Joel

                                    Hi Joel,

                                    Regards,
                                    Greg____

                                        <chair hat on>

                                        Yours,
                                        Joel M. Halpern

                                            Hi Joel, Adrian, et. al,

                                            Regards,
                                            Greg

                                            On Thu, Jun 29, 2017 at
               4:22 PM, Joel
                                    Halpern Direct

                                                 The -13 will be out in
               a few days
                                    with all the changes.
                                                 That is what we will
               ask the WG to
                                    review.
                                                 If we already had it
               out, we would
                                    have already asked for
                                            the WG to
                                                 take a last look.

                                                 Yours,
                                                 Joel

                                                 On 6/29/17 7:21 PM,
               Greg Mirsky wrote:

                                                     Hi Joel,
                                                     is the -12 the
               latest published
                                    version of the NSH
                                            draft? As I
                                                     see, it is missing
               TTL and all
                                    related changes:

                                    ____

                            __ __

                        __ __

                        —____

                        __ __

                    __ __

           —

       —

—

—

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 7 Jul 2017 17:28:42 -0400

Joel et al,

The point of the bit is that it tells the NSH processing entity that it is
> required to do extra work.  The point of the bit is NOT to tell it what
> extra work is required, or where to look for extra information. And by
> keeping that separation, we get significant flexibility in how we address
> various cases.  And we can evaluate the behaviors we want for the different
> situations, and set the bit appropriately for our desired behavior.
>
>>
>> This was exactly the point of my proposed text change, to reflect that we
don’t yet know where OAM information will occur. However, after catching up
on the discussion, my reaction is perhaps we can simply state that the
definition of an “OAM packet” is a packet with the O bit set, and leave it
at that.

Also, because the details of the forwarding and processing of OAM packets
is outside the scope of this document, so should be the details of any
optional parameters that modify that processing.

So I now propose replacing the existing three OAM paragraphs with:

   O bit: Setting this bit indicates an Operations, Administration, and
   Maintenance (OAM) packet.  The actual format and processing of
   SFC OAM packets is outside the scope of this specification (see
   [oam-frame <https://tools.ietf.org/html/draft-ietf-sfc-nsh-13#ref-oam-frame>]).
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.

FInally, I want to reiterate that we need to decide bewteen “O bit” and
“O-bit”. I don’t care which, but we should be consistent. I’m happy to
leave that decision to the editors.

Also, sorry for the delayed response, but I’ve been mostly offline for the
last few days.

Cheers,
Andy

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 7 Jul 2017 21:36:40 +0000

Thanks Andy for the follow-up!

I do not oppose this proposal. I think it is useful and simplifies the overall definition of the OAM bit. It might be useful to include “unless otherwise specified, implementations SHOULD discard packets with the O bit set.” (as this was important to the WG during earlier discussions)

And yes, I suggest using “O bit” instead of “O-bit”. I will make this change for now.

Thanks!

Carlos.

On Jul 7, 2017, at 5:28 PM, Andrew G. Malis <[email-masked]<mailto:[email-masked]>> wrote:

Joel et al,

This was exactly the point of my proposed text change, to reflect that we don’t yet know where OAM information will occur. However, after catching up on the discussion, my reaction is perhaps we can simply state that the definition of an “OAM packet” is a packet with the O bit set, and leave it at that.

Also, because the details of the forwarding and processing of OAM packets is outside the scope of this document, so should be the details of any optional parameters that modify that processing.

   O bit: Setting this bit indicates an Operations, Administration, and
   Maintenance (OAM) packet.  The actual format and processing of
   SFC OAM packets is outside the scope of this specification (see
   [oam-frame<https://tools.ietf.org/html/draft-ietf-sfc-nsh-13#ref-oam-frame>]). The O bit MUST be set for OAM packets and MUST NOT be

FInally, I want to reiterate that we need to decide bewteen “O bit” and “O-bit”. I don’t care which, but we should be consistent. I’m happy to leave that decision to the editors.

Also, sorry for the delayed response, but I’ve been mostly offline for the last few days.

Cheers,
Andy

—

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 7 Jul 2017 17:50:46 -0400

Carlos,

I would support that revision, and perhaps even make it stronger, into a
MUST. But I could live with SHOULD.

Cheers,
Andy

On Fri, Jul 7, 2017 at 5:36 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> I do not oppose this proposal. I think it is useful and simplifies the
> overall definition of the OAM bit. It might be useful to include “unless
> otherwise specified, implementations SHOULD discard packets with the O bit
> set.” (as this was important to the WG during earlier discussions)
>
> On Jul 7, 2017, at 5:28 PM, Andrew G. Malis <[email-masked]> wrote:
>
> Joel et al,
>
>>> This was exactly the point of my proposed text change, to reflect that
> we don’t yet know where OAM information will occur. However, after catching
> up on the discussion, my reaction is perhaps we can simply state that the
>    [oam-frame <https://tools.ietf.org/html/draft-ietf-sfc-nsh-13#ref-oam-frame>]). The O bit MUST be set for OAM packets and MUST NOT be
>

---

From: <[email-masked]>
Date: Mon, 10 Jul 2017 07:58:19 +0000

Hi Andy, all,

The reason we had « SHOULD » is because we allow for a configurable parameter.

From that standpoint, I do personally prefer this change that takes into account your comment:

OLD:

   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
   [oam-frame<https://tools.ietf.org/html/draft-ietf-sfc-nsh-13#ref-oam-frame>]).

NEW:

   O bit: Setting this bit indicates an Operations, Administration, and
   Maintenance (OAM) packet.  The actual format and processing of
   SFC OAM packets is outside the scope of this specification (see
   [oam-frame<https://tools.ietf.org/html/draft-ietf-sfc-nsh-13#ref-oam-frame>]).

   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.

   SF/SFF/SFC Proxy/Classifier implementations that do not support SFC

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Andrew G. Malis
Envoyé : vendredi 7 juillet 2017 23:51
À : Carlos Pignataro (cpignata)
Cc : Greg Mirsky; Joel M. Halpern; James N Guichard; Dave Dolson; [email-masked]
Objet : Re: [sfc] Status of draft-ietf-sfc-nsh [Was: Meeting at IETF 99 in Prague]

Carlos,

I would support that revision, and perhaps even make it stronger, into a MUST. But I could live with SHOULD.

Cheers,
Andy

On Fri, Jul 7, 2017 at 5:36 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Andy for the follow-up!

Thanks!

Carlos.

Joel et al,

Cheers,
Andy

—

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 10 Jul 2017 07:43:12 -0400

Med,

The first two paragraphs look great, thanks.

The third paragraph is inconsistent (this goes back to the original text as
well). It starts out with:

   OAM procedures SHOULD discard packets with O bit set,

but then later says:

   Forwarding OAM

The inconsistency is that forwarding OAM packets without supporting OAM
procedures is clearly not recommended without analysis of the impact.
However, since discarding is only a SHOULD for an implementation, not a
MUST, the operator may not have a choice in the matter, since the vendor
may not have implemented discarding at all.

Thus, discarding should be a MUST in the absence of setting the
configurable parameter. The configurable parameter would then allow the
operator to modify the discarding behavior if they wish, following their
analysis.

Cheers,
Andy

On Mon, Jul 10, 2017 at 3:58 AM, <[email-masked]> wrote:

>    [oam-frame
> <https://tools.ietf.org/html/draft-ietf-sfc-nsh-13#ref-oam-frame>]).
>
>
>
>    [oam-frame
> <https://tools.ietf.org/html/draft-ietf-sfc-nsh-13#ref-oam-frame>]).
>
>
>
> *De :* sfc [mailto:[email-masked]] *De la part de* Andrew G. Malis
> *Envoyé :* vendredi 7 juillet 2017 23:51
> *À :* Carlos Pignataro (cpignata)
> *Cc :* Greg Mirsky; Joel M. Halpern; James N Guichard; Dave Dolson;
> [email-masked]
> *Objet :* Re: [sfc] Status of draft-ietf-sfc-nsh [Was: Meeting at IETF 99
> in Prague]
>
>
>
> Carlos,
>
>
>

---

From: <[email-masked]>
Date: Mon, 10 Jul 2017 12:08:03 +0000

Andy,

Please see inline.

Cheers,
Med

De : Andrew G. Malis [mailto:[email-masked]]
Envoyé : lundi 10 juillet 2017 13:43
À : BOUCADAIR Mohamed IMT/OLN
Cc : Carlos Pignataro (cpignata); Greg Mirsky; Joel M. Halpern; James N Guichard; Dave Dolson; [email-masked]
Objet : Re: [sfc] Status of draft-ietf-sfc-nsh [Was: Meeting at IETF 99 in Prague]

Med,

The third paragraph is inconsistent (this goes back to the original text as well).

It starts out with:

   Forwarding OAM

The inconsistency is that forwarding OAM packets without supporting OAM procedures is clearly not recommended without analysis of the impact.
[Med] The rationale was to disable forwarding such packets by default…but if under some deployments and after local assessment, that default behavior can be changed. We included in that text sufficient warrants.

However, since discarding is only a SHOULD for an implementation, not a MUST, the operator may not have a choice in the matter, since the vendor may not have implemented discarding at all.
[Med] We used to have this wording in an earlier version of the NSH specification (-10) :

   SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC
   OAM procedures, SHALL discard packets with O-bit set.

We agreed to change SHALL to SHOULD as per this discussion: https://www.ietf.org/mail-archive/web/sfc/current/msg05624.html. I don’t think we need to (re)play that discussion.

Thus, discarding should be a MUST in the absence of setting the configurable parameter. The configurable parameter would then allow the operator to modify the discarding behavior if they wish, following their analysis.
[Med] I hear you. This was my opinion too, but I changed my opinion on this based on the comment from Adrian.

Cheers,
Andy

On Mon, Jul 10, 2017 at 3:58 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andy, all,

OLD:

NEW:

Cheers,
Med

De : sfc [mailto:[email-masked]<mailto:[email-masked]>] De la part de Andrew G. Malis
Envoyé : vendredi 7 juillet 2017 23:51
À : Carlos Pignataro (cpignata)
Cc : Greg Mirsky; Joel M. Halpern; James N Guichard; Dave Dolson; [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] Status of draft-ietf-sfc-nsh [Was: Meeting at IETF 99 in Prague]

Carlos,

Cheers,
Andy

Thanks!

Carlos.

Joel et al,

Cheers,
Andy

—

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 10 Jul 2017 08:58:05 -0400

Med,

Sigh, I see Adrian’s point as well. Thanks for reminding me of his email.
:-)

So I’m OK with your revision.

Cheers,
Andy

On Mon, Jul 10, 2017 at 8:08 AM, <[email-masked]> wrote:

> Andy,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Andrew G. Malis [mailto:[email-masked]]
> *Envoyé :* lundi 10 juillet 2017 13:43
> *À :* BOUCADAIR Mohamed IMT/OLN
> *Cc :* Carlos Pignataro (cpignata); Greg Mirsky; Joel M. Halpern; James N
> Guichard; Dave Dolson; [email-masked]
> [Med] The rationale was to disable forwarding such packets by default…but
> if under some deployments and after local assessment, that default behavior
> can be changed. We included in that text sufficient warrants.
>
>
>
> We agreed to change SHALL to SHOULD as per this discussion:
> https://www.ietf.org/mail-archive/web/sfc/current/msg05624.html. I don’t
> think we need to (re)play that discussion.
>
>
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 10 Jul 2017 15:34:39 +0000

This is also acceptable to me, and I believe closes the loop on the OAM text. I will add however one additional clarification, add “for example” qualifying [oam-frame].

Consequently, the current version looks like this — please comment on the list if there’s any heartburn with it:

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

Also,

Joel, as Shepherd, the current idnits only marks this:

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  ** Downref: Normative reference to an Informational RFC: RFC 7665

Thanks!

Carlos.

On Jul 10, 2017, at 8:58 AM, Andrew G. Malis <[email-masked]<mailto:[email-masked]>> wrote:

Med,

Sigh, I see Adrian’s point as well. Thanks for reminding me of his email. :-)

Cheers,
Andy

On Mon, Jul 10, 2017 at 8:08 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Andy,

Please see inline.

Cheers,
Med

De : Andrew G. Malis [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : lundi 10 juillet 2017 13:43
À : BOUCADAIR Mohamed IMT/OLN
Cc : Carlos Pignataro (cpignata); Greg Mirsky; Joel M. Halpern; James N Guichard; Dave Dolson; [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] Status of draft-ietf-sfc-nsh [Was: Meeting at IETF 99 in Prague]

Med,

It starts out with:

   Forwarding OAM

Cheers,
Andy

OLD:

NEW:

Cheers,
Med

Carlos,

Cheers,
Andy

Thanks!

Carlos.

Joel et al,

Cheers,
Andy

—

—