Subject: [sfc] Progression of OAM work in the SFC WG

From: James Guichard <[email-masked]>
Date: Wed, 2 Feb 2022 18:36:26 +0000

Hi WG:

Having reviewed all of the OAM related documents in our WG, the chairs would like to provide a few comments to hopefully generate discussion and forward progress of this work:

1) The chairs have reviewed the O bit definition in RFC 8300.  That definition is at best open to interpretation and therefore incomplete.  For example, the clear intention is only to mark packets which are intended for SFC OAM at the SFC service layer.  But that is not what the current text says.  There is also, unfortunately, ambiguity as to what constitutes an OAM packet.  So it is reasonable for documents to update 8300 to clarify the exact applicability and action for the O-bit.

2) However, related to point 1), we can't have multiple documents updating the definition differently.  As such, the authors of the SFC iOAM draft and the SFC multi-layer-oam draft need to come together and figure out what the clarification is for the definition of that bit. We do not believe as chairs that either of these documents can move forward from the WG until such clarity has been reached.

3) Related to the SFC iOAM, we need a clear definition of iOAM.  There seem to be differences between the definitions in published RFCs, the usage (which is not a definition) in the SFC draft, and the various ippm drafts.  Any such definition will need to be vetted with the ippm working group.

Again, it would be good if members of the working group beyond the two author teams spoke up about their readings of the documents, and their understandings of what we need.

Yours,
Jim and Joel

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 2 Feb 2022 14:42:18 -0800

Thank you, Jim and Joel, for guiding the SFC OAM work and pointing out the
issue that must be addressed.

I've reviewed our SFC OAM documents and draft-ietf-sfc-nsh-tlv. As I
understand these documents, the Active SFC OAM and IOAM are identified by
the respective values for the NSH Next Protocol field (to be assigned by
IANA). At the same time, so far no OAM-specific meta data TLV has been
defined. Thus, it appears that one way forward could be to not involve the
O bit in the active SFC OAM or IOAM altogether. In other words, to
deprecate the NSH O bit.

I greatly appreciate your comments on the proposal to deprecate the NSH O
bit.

Regards,
Greg

On Wed, Feb 2, 2022 at 10:36 AM James Guichard <
[email-masked]> wrote:

> Hi WG:
>
>
>
> Having reviewed all of the OAM related documents in our WG, the chairs
> would like to provide a few comments to hopefully generate discussion and
> forward progress of this work:
>
>
>
> 1) The chairs have reviewed the O bit definition in RFC 8300.  That
> definition is at best open to interpretation and therefore incomplete.  For
> example, the clear intention is only to mark packets which are intended for
> SFC OAM at the SFC service layer.  But that is not what the current text
> says.  There is also, unfortunately, ambiguity as to what constitutes an
> OAM packet.  So it is reasonable for documents to update 8300 to clarify
> the exact applicability and action for the O-bit.
>
>
>
> 2) However, related to point 1), we can't have multiple documents updating
> the definition differently.  As such, the authors of the SFC iOAM draft and
> the SFC multi-layer-oam draft need to come together and figure out what the
> clarification is for the definition of that bit. We do not believe as
> chairs that either of these documents can move forward from the WG until
> such clarity has been reached.
>
>
>
> 3) Related to the SFC iOAM, we need a clear definition of iOAM.  There
> seem to be differences between the definitions in published RFCs, the usage
> (which is not a definition) in the SFC draft, and the various ippm drafts.
> Any such definition will need to be vetted with the ippm working group.
>
>
>
> Again, it would be good if members of the working group beyond the two
> author teams spoke up about their readings of the documents, and their
> understandings of what we need.
>
>
>
> Yours,
>
> Jim and Joel
>
>
>
>
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 13 Feb 2022 02:52:22 -0500

Hi Jim, Joel & SFC WG,

I agree that the RFC 8300 definition of O bit is incomplete and not clear
as to its intended use.

That is a problem that I agree needs to be rectified.

I understand that we need to get this resolved before we can progress
Multilayer SFC OAM draft-ietf-sfc-multi-layer-oam-18 and SFC IOAM.

I agree that what makes sense to me as a path forward is to deprecate the O
bit and not use in SFC Multilayer OAM and SFC IOAM, as both SFC Multilayer OAM
and SFC IOAM are identified by the respective values for the NSH Next
Protocol field (to be assigned by IANA), as well as so far no OAM-specific
meta data TLV has been yet defined.

So we have I believe solid solution and path forward and I support
deprecating the O bit.

Kind Regards

Gyan

On Wed, Feb 2, 2022 at 5:42 PM Greg Mirsky <[email-masked]> wrote:

>> 2) However, related to point 1), we can't have multiple documents
>> updating the definition differently.  As such, the authors of the SFC iOAM
>> draft and the SFC multi-layer-oam draft need to come together and figure
>> out what the clarification is for the definition of that bit. We do not
>> believe as chairs that either of these documents can move forward from the
>> WG until such clarity has been reached.
>>
>>
>>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 13 Feb 2022 09:55:53 -0500

There is an implication of deprecating the O-bit that I would like to 
hear from more WG participants about.

As far as I can tell, if we deprecate the O-bit and rely on the next 
protocol field, we are saying that in practice (not by rule) NSH 
metadata can not be used for OAM.  That's fine with me as long as we 
agree on that.

Yours,
Joel

On 2/13/2022 2:52 AM, Gyan Mishra wrote:
> 
> Hi Jim, Joel & SFC WG,
> 
> I agree that the RFC 8300 definition of O bit is incomplete and not 
> clear as to its intended use.
> 
> I agree that what makes sense to me as a path forward is to deprecate 
> the O bit and not use in SFC Multilayer OAM and SFC IOAM, as both SFC 
> Multilayer OAM and SFC IOAM are identified by the respective values for 
> the NSH Next Protocol field (to be assigned by IANA), as well as so far 
> no OAM-specific meta data TLV has been yet defined.
> 
> On Wed, Feb 2, 2022 at 5:42 PM Greg Mirsky <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Thank you, Jim and Joel, for guiding the SFC OAM work and pointing
>     out the issue that must be addressed.
> 
>     understand these documents, the Active SFC OAM and IOAM are
>     identified by the respective values for the NSH Next Protocol field
>     (to be assigned by IANA). At the same time, so far no OAM-specific
>     meta data TLV has been defined. Thus, it appears that one way
>     forward could be to not involve the O bit in the active SFC OAM or
>     IOAM altogether. In other words, to deprecate the NSH O bit.
> 
>     I greatly appreciate your comments on the proposal to deprecate the
>     NSH O bit.
> 
>     Regards,
>     Greg
> 
>     On Wed, Feb 2, 2022 at 10:36 AM James Guichard
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Hi WG:____
> 
>         __ __
> 
>         Having reviewed all of the OAM related documents in our WG, the
>         chairs would like to provide a few comments to hopefully
>         generate discussion and forward progress of this work:____
> 
>         __ __
> 
>         1) The chairs have reviewed the O bit definition in RFC 8300. 
>         That definition is at best open to interpretation and therefore
>         incomplete.  For example, the clear intention is only to mark
>         packets which are intended for SFC OAM at the SFC service
>         layer.  But that is not what the current text says.  There is
>         also, unfortunately, ambiguity as to what constitutes an OAM
>         packet.  So it is reasonable for documents to update 8300 to
>         clarify the exact applicability and action for the O-bit.____
> 
>         __ __
> 
>         2) However, related to point 1), we can't have multiple
>         documents updating the definition differently.  As such, the
>         authors of the SFC iOAM draft and the SFC multi-layer-oam draft
>         need to come together and figure out what the clarification is
>         for the definition of that bit. We do not believe as chairs that
>         either of these documents can move forward from the WG until
>         such clarity has been reached. ____
> 
>         __ __
> 
>         3) Related to the SFC iOAM, we need a clear definition of iOAM. 
>         There seem to be differences between the definitions in
>         published RFCs, the usage (which is not a definition) in the SFC
>         draft, and the various ippm drafts.  Any such definition will
>         need to be vetted with the ippm working group.____
> 
>         __ __
> 
>         Again, it would be good if members of the working group beyond
>         the two author teams spoke up about their readings of the
>         documents, and their understandings of what we need.____
> 
>         __ __
> 
>         Yours,____
> 
>         Jim and Joel____
> 
>         __ __
> 
>         __ __
> 
>         __ __
> 
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/sfc>
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/sfc>
> 
> -- 
> 
> /Network Solutions A//rchitect /
> 
> /Email [email-masked] <mailto:[email-masked]>//
> /
> 
> /M 301 502-1347
> 
> /
> 
>

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 13 Feb 2022 09:04:00 -0800

Hi Joel,
I agree that, as we find SFC NSH now, no OAM metadata has been defined. It
appears to me that deprecating the O bit does not affect any of the already
defined mechanisms in the SFC NSH. I think that if a new, for example, MD
Type = 2 TLV that is used for any OAM functionality to be proposed in the
future, deprecated the O bit would not prevent using such NSH TLV.
What do you think?

Regards,
Greg

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 13 Feb 2022 12:32:06 -0500

Hi Joel

I am in agreement as well with what you have stated that once the O bit is
deprecated that NSH metadata cannot be used for OAM and that we would have
to now from that point forward rely on the next protocol field as we will
be doing for SFC Multilayer and SFC IOAM drafts as well as will have
backwards compatible with any already existing defined mechanisms in SFC
NSH.

I don’t see any issues or impact with moving forward.

Kind Regards

Gyan

*Gyan Mishra*

*M 301 502-1347*

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 14 Feb 2022 04:06:42 +0000

Replying to this specific email in the thread, only because it is the latest one at this point in time, but bundling comments from various places on the thread. Please find some follow-up comments and questions marked “CMP”, indicating the “From”, and organized chronologically:

James N Guichard <[email-masked]<mailto:[email-masked]>>:

CMP: It is unclear to me what exact issues the chairs are calling out. There are two issues mentioned:
CMP: 1. "But that is not what the current text says.” —> what does the text say precisely?  Can you point to the specific RFC 8300 text that is believed to be incomplete, and a detailed use case that showcases the potential issue? An extrapolated counter-example just to make a point: the text does not  say what days of the week OAM packets can be marked, yet there’s an expectation that they will work Mondays and Saturdays all the same — even holidays.
CMP: 2. What specifically is the ambiguity with what an OAM packet is? Please grep the RFC series for “oam packet”, it is not a new term.
CMP: Net-net, O-bit=1, OAM packet.

CMP: If there is still believed to be an ambiguity or a clear opportunity for improving the definition, I agree with consolidating that update. I had suggested before that if such new text or real clarification is agreed, a separate document that only makes that O-bit clarification is the most clear and clean way to go. That doc should be a one-pager or less. I’d be happy to contribute to that minimal doc, if it is shown to be needed.

CMP: For completeness also, the "SFC multi-layer-oam” document has many outstanding issues besides the O-bit.

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

I've reviewed our SFC OAM documents and draft-ietf-sfc-nsh-tlv. As I understand these documents, the Active SFC OAM and IOAM are identified by the respective values for the NSH Next Protocol field (to be assigned by IANA).

CMP: There is a major issue with the sentence above. Active SFC OAM (as a category), as per RFC 8300, needs to be identified by setting the O-bit. No way around that based on RFC 8300. However, the text "the Active SFC OAM” creates confusion since it refer to a specific OAM protocol which has the same name as a the category as well. That name collision is quite unfortunate in my opinion.

At the same time, so far no OAM-specific meta data TLV has been defined. Thus, it appears that one way forward could be to not involve the O bit in the active SFC OAM or IOAM altogether. In other words, to deprecate the NSH O bit.

CMP: RFC 8924 already includes ICMP and BFD as example SFC Action OAM protocols. Those can be encapsulated in IP, in which the Next-Protocol indicates IP — and (as per RFC 8300) the O-bit is set to indicate an OAM packet.
CMP: The proposal of deprecating the O-bit breaks those SFC OAM protocols already included in an RFC.
CMP: That proposal of deprecating the O-bit also breaks Section 4.1 of IOAM.
CMP: This expired I-D yet implemented in open source uses the O-bit: https://www.ietf.org/archive/id/draft-penno-sfc-trace-03.txt

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

I agree that what makes sense to me as a path forward is to deprecate the O bit and not use in SFC Multilayer OAM and SFC IOAM, as both SFC Multilayer OAM and SFC IOAM are identified by the respective values for the NSH Next Protocol field (to be assigned by IANA), as well as so far no OAM-specific meta data TLV has been yet defined.

CMP: What is the “SFC Multilayer OAM”?
CMP: The O-bit (reading RFC 8300) does not indicate if there is OAM Metadata. It indicates an OAM packet.

"Joel M. Halpern" <[email-masked]<mailto:[email-masked]>>

As far as I can tell, if we deprecate the O-bit and rely on the next protocol field, we are saying that in practice (not by rule) NSH metadata can not be used for OAM.  That's fine with me as long as we agree on that.

CMP: I do not fully follow this. Can you explain the relationship of the O-bit with Metadata?
CMP: Here’s an example: RFC 8924 shows ICMP as Active OAM. The SFC next protocol is IP, the IP next protocol is ICMP, the O-bit needs to be set.

CMP: Consider the following document, independent submission and in the RFC Publication queue already:
CMP: https://datatracker.ietf.org/doc/draft-mymb-sfc-nsh-allocation-timestamp/
CMP: Is a Timestamp in Metadata an OAM element?

CMP: Consider this proposal https://datatracker.ietf.org/doc/draft-mirsky-sfc-pmamm/
CMP: Where the base header borrows a bit for an OAM function.

CMP: Neither of those have any impact on the O-bit.

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

I agree that, as we find SFC NSH now, no OAM metadata has been defined. It appears to me that deprecating the O bit does not affect any of the already defined mechanisms in the SFC NSH.

CMP: It actually does, see my example above.

I think that if a new, for example, MD Type = 2 TLV that is used for any OAM functionality to be proposed in the future, deprecated the O bit would not prevent using such NSH TLV.

CMP: I agree with this — because there is no correlation between MD Type field and O-bit as defined.

Best,

Carlos.

2/13/22 午後12:32、Gyan Mishra <[email-masked]<mailto:[email-masked]>>のメール:

Hi Joel

I am in agreement as well with what you have stated that once the O bit is deprecated that NSH metadata cannot be used for OAM and that we would have to now from that point forward rely on the next protocol field as we will be doing for SFC Multilayer and SFC IOAM drafts as well as will have backwards compatible with any already existing defined mechanisms in SFC NSH.

Kind Regards

Gyan

On Sun, Feb 13, 2022 at 12:04 PM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Joel,
I agree that, as we find SFC NSH now, no OAM metadata has been defined. It appears to me that deprecating the O bit does not affect any of the already defined mechanisms in the SFC NSH. I think that if a new, for example, MD Type = 2 TLV that is used for any OAM functionality to be proposed in the future, deprecated the O bit would not prevent using such NSH TLV.
What do you think?

Regards,
Greg

On Sun, Feb 13, 2022 at 6:55 AM Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:
There is an implication of deprecating the O-bit that I would like to
hear from more WG participants about.

Yours,
Joel

On 2/13/2022 2:52 AM, Gyan Mishra wrote:
> On Wed, Feb 2, 2022 at 5:42 PM Greg Mirsky <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>         Hi WG:____
>
>         __ __
>
>         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> /Email [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>//
> /
>
> /M 301 502-1347
>
> /
>
>
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra
Network Solutions Architect
Email [email-masked]<mailto:[email-masked]>
M 301 502-1347

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 14 Feb 2022 07:05:32 -0500

Thank you for taking the time to provide a careful reply.

It appears, from your description of ICMP packets that your 
understanding of 8300 is that in SFC an external ICMP packet will get 
the O bit set in the NSH header.  Presumably, base on this, the SFF or 
SF are supposed to look through and notice this content?   (Otherwise, 
why set the bit?)  This seems an undesirable and expensive implications 
which other readers have not drawn from the RFC 8300 text.  (It also 
requires the encapsulating node to do extra checking to discover this case.)

Am I reading your expectation correctly?

Yours,
Joel

On 2/13/2022 11:06 PM, Carlos Pignataro (cpignata) wrote:
> Replying to this specific email in the thread, only because it is the 
> latest one at this point in time, but bundling comments from various 
> places on the thread. Please find some follow-up comments and questions 
> marked “CMP”, indicating the “From”, and organized chronologically:
> 
> *James N Guichard <[email-masked] 
> <mailto:[email-masked]>>:*
> 
>> definition is at best open to interpretation and therefore 
>> incomplete.  For example, the clear intention is only to mark packets 
>> which are intended for SFC OAM at the SFC service layer.  But that is 
>> not what the current text says.  There is also, unfortunately, 
>> ambiguity as to what constitutes an OAM packet.  So it is reasonable 
>> for documents to update 8300 to clarify the exact applicability and 
>> action for the O-bit.
> 
> CMP: 1. "But that is not what the current text says.” —> what does the 
> text say precisely?  Can you point to the specific RFC 8300 text that is 
> believed to be incomplete, and a detailed use case that showcases the 
> potential issue? An extrapolated counter-example just to make a point: 
> the text does not  say what days of the week OAM packets can be marked, 
> yet there’s an expectation that they will work Mondays and Saturdays all 
> the same — even holidays.
> CMP: 2. What specifically is the ambiguity with what an OAM packet is? 
> Please grep the RFC series for “oam packet”, it is not a new term.
>> updating the definition differently.  As such, the authors of the SFC 
>> iOAM draft and the SFC multi-layer-oam draft need to come together and 
>> figure out what the clarification is for the definition of that bit. 
>> We do not believe as chairs that either of these documents can move 
>> forward from the WG until such clarity has been reached.
> 
> CMP: If there is still believed to be an ambiguity or a clear 
> opportunity for improving the definition, I agree with consolidating 
> that update. I had suggested before that if such new text or real 
> clarification is agreed, a separate document that only makes that O-bit 
> clarification is the most clear and clean way to go. That doc should be 
> a one-pager or less. I’d be happy to contribute to that minimal doc, if 
> it is shown to be needed.
> 
> *Greg Mirsky <[email-masked] <mailto:[email-masked]>>*
> 
>> understand these documents, the Active SFC OAM and IOAM are identified 
>> by the respective values for the NSH Next Protocol field (to be 
>> assigned by IANA). 
> 
> CMP: There is a major issue with the sentence above. Active SFC OAM (as 
> a category), as per RFC 8300, needs to be identified by setting the 
> O-bit. No way around that based on RFC 8300. However, the text "the 
> Active SFC OAM” creates confusion since it refer to a specific OAM 
> protocol which has the same name as a the category as well. That name 
> collision is quite unfortunate in my opinion.
> 
>> At the same time, so far no OAM-specific meta data TLV has been 
>> defined. Thus, it appears that one way forward could be to not involve 
>> the O bit in the active SFC OAM or IOAM altogether. In other words, to 
>> deprecate the NSH O bit.
> 
> CMP: RFC 8924 already includes ICMP and BFD as example SFC Action OAM 
> protocols. Those can be encapsulated in IP, in which the Next-Protocol 
> indicates IP — and (as per RFC 8300) the O-bit is set to indicate an OAM 
> packet.
> CMP: This expired I-D yet implemented in open source uses the O-bit: 
> https://www.ietf.org/archive/id/draft-penno-sfc-trace-03.txt 
> <https://www.ietf.org/archive/id/draft-penno-sfc-trace-03.txt>
> 
> 
> *Gyan Mishra <[email-masked] <mailto:[email-masked]>>*
> 
>> Multilayer OAM and SFC IOAM are identified by the respective values 
>> for the NSH Next Protocol field (to be assigned by IANA), as well as 
>> so far no OAM-specific meta data TLV has been yet defined.
> 
> *"Joel M. Halpern" <[email-masked] <mailto:[email-masked]>>*
> 
> CMP: Here’s an example: RFC 8924 shows ICMP as Active OAM. The SFC next 
> protocol is IP, the IP next protocol is ICMP, the O-bit needs to be set.
> 
> CMP: 
> https://datatracker.ietf.org/doc/draft-mymb-sfc-nsh-allocation-timestamp/ <https://datatracker.ietf.org/doc/draft-mymb-sfc-nsh-allocation-timestamp/>
> CMP: Consider this proposal 
> https://datatracker.ietf.org/doc/draft-mirsky-sfc-pmamm/ 
> <https://datatracker.ietf.org/doc/draft-mirsky-sfc-pmamm/>
> *Greg Mirsky <[email-masked] <mailto:[email-masked]>>*
> 
>> I agree that, as we find SFC NSH now, no OAM metadata has been 
>> defined. It appears to me that deprecating the O bit does not affect 
>> any of the already defined mechanisms in the SFC NSH.
> 
>> I think that if a new, for example, MD Type = 2 TLV that is used for 
>> any OAM functionality to be proposed in the future, deprecated the O 
>> bit would not prevent using such NSH TLV.
> 
>> I am in agreement as well with what you have stated that once the O 
>> bit is deprecated that NSH metadata cannot be used for OAM and that we 
>> would have to now from that point forward rely on the next protocol 
>> field as we will be doing for SFC Multilayer and SFC IOAM drafts as 
>> well as will have backwards compatible with any already existing 
>> defined mechanisms in SFC NSH.
>>
>>     I agree that, as we find SFC NSH now, no OAM metadata has been
>>     defined. It appears to me that deprecating the O bit does not
>>     affect any of the already defined mechanisms in the SFC NSH. I
>>     think that if a new, for example, MD Type = 2 TLV that is used for
>>     any OAM functionality to be proposed in the future, deprecated the
>>     O bit would not prevent using such NSH TLV.
>>     What do you think?
>>
>>     Regards,
>>     Greg
>>
>>     On Sun, Feb 13, 2022 at 6:55 AM Joel M. Halpern
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         > On Wed, Feb 2, 2022 at 5:42 PM Greg Mirsky
>>         <[email-masked] <mailto:[email-masked]>
>>         <mailto:[email-masked]>
>>         >     <mailto:[email-masked]
>>         <mailto:[email-masked]>>> wrote:
>>         >
>>         >         Hi WG:____
>>         >
>>         >         __ __
>>         >
>>         > [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>>
>>         >
>>         > [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>>
>>         >
>>         > --
>>         >
>>         > <http://www.verizon.com/ <http://www.verizon.com/>>
>>         >
>>         > *Gyan Mishra*
>>         >
>>         > /Email [email-masked]
>>         <mailto:[email-masked]>
>>         <mailto:[email-masked]
>>         <mailto:[email-masked]>>//
>>         > /
>>         >
>>         > /M 301 502-1347
>>         >
>>         > /
>>         >
>>         >
>>
>> -- 
>>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 14 Feb 2022 13:02:09 +0000

Joel,

Happy to.

No, that is not what I meant. I am not sure where (or why) you added the word “external”, but that was key to showing a disconnect (I might not have been clear and/or you might not have read correctly).

Let me try different way:

There is an I-D now, sfc-multi-layer-oam, that sends “SFC Active OAM" packets with a new SFC next protocol for a newly created protocol. In this case, the SFC next protocol is not expected to be used in user packets, at least for now (or people have not thought about that in hierarchical cases)

Imagine now that BFD or ICMP want to be used as an SFC Active OAM protocols, instead of the sfc-multi-layer-oam one. Those can be encapsulated in IP (even with a 127/8 destination). Using the O-bit set and SFC NP as IP is the RFC 8300 expected way. (I imagine creating a new SFC next protocol for “BFD-in-IP-used-in-SFC” so as to avoid an SFC NP expected on external packets would be an approach if there was no O-bit defined)

Best,

Carlos.

2/14/22 午前7:05、Joel M. Halpern <[email-masked]<mailto:[email-masked]>>のメール:

It appears, from your description of ICMP packets that your understanding of 8300 is that in SFC an external ICMP packet will get the O bit set in the NSH header.  Presumably, base on this, the SFF or SF are supposed to look through and notice this content?   (Otherwise, why set the bit?)  This seems an undesirable and expensive implications which other readers have not drawn from the RFC 8300 text.  (It also requires the encapsulating node to do extra checking to discover this case.)

Yours,
Joel

On 2/13/2022 11:06 PM, Carlos Pignataro (cpignata) wrote:
Replying to this specific email in the thread, only because it is the latest one at this point in time, but bundling comments from various places on the thread. Please find some follow-up comments and questions marked “CMP”, indicating the “From”, and organized chronologically:
*James N Guichard <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>:*
1) The chairs have reviewed the O bit definition in RFC 8300.  That definition is at best open to interpretation and therefore incomplete.  For example, the clear intention is only to mark packets which are intended for SFC OAM at the SFC service layer.  But that is not what the current text says.  There is also, unfortunately, ambiguity as to what constitutes an OAM packet.  So it is reasonable for documents to update 8300 to clarify the exact applicability and action for the O-bit.
CMP: It is unclear to me what exact issues the chairs are calling out. There are two issues mentioned:
CMP: 1. "But that is not what the current text says.” —> what does the text say precisely?  Can you point to the specific RFC 8300 text that is believed to be incomplete, and a detailed use case that showcases the potential issue? An extrapolated counter-example just to make a point: the text does not  say what days of the week OAM packets can be marked, yet there’s an expectation that they will work Mondays and Saturdays all the same — even holidays.
CMP: 2. What specifically is the ambiguity with what an OAM packet is? Please grep the RFC series for “oam packet”, it is not a new term.
CMP: Net-net, O-bit=1, OAM packet.
2) However, related to point 1), we can't have multiple documents updating the definition differently.  As such, the authors of the SFC iOAM draft and the SFC multi-layer-oam draft need to come together and figure out what the clarification is for the definition of that bit. We do not believe as chairs that either of these documents can move forward from the WG until such clarity has been reached.
CMP: If there is still believed to be an ambiguity or a clear opportunity for improving the definition, I agree with consolidating that update. I had suggested before that if such new text or real clarification is agreed, a separate document that only makes that O-bit clarification is the most clear and clean way to go. That doc should be a one-pager or less. I’d be happy to contribute to that minimal doc, if it is shown to be needed.
CMP: For completeness also, the "SFC multi-layer-oam” document has many outstanding issues besides the O-bit.
*Greg Mirsky <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>*
I've reviewed our SFC OAM documents and draft-ietf-sfc-nsh-tlv. As I understand these documents, the Active SFC OAM and IOAM are identified by the respective values for the NSH Next Protocol field (to be assigned by IANA).
CMP: There is a major issue with the sentence above. Active SFC OAM (as a category), as per RFC 8300, needs to be identified by setting the O-bit. No way around that based on RFC 8300. However, the text "the Active SFC OAM” creates confusion since it refer to a specific OAM protocol which has the same name as a the category as well. That name collision is quite unfortunate in my opinion.
At the same time, so far no OAM-specific meta data TLV has been defined. Thus, it appears that one way forward could be to not involve the O bit in the active SFC OAM or IOAM altogether. In other words, to deprecate the NSH O bit.
CMP: RFC 8924 already includes ICMP and BFD as example SFC Action OAM protocols. Those can be encapsulated in IP, in which the Next-Protocol indicates IP — and (as per RFC 8300) the O-bit is set to indicate an OAM packet.
CMP: The proposal of deprecating the O-bit breaks those SFC OAM protocols already included in an RFC.
CMP: That proposal of deprecating the O-bit also breaks Section 4.1 of IOAM.
CMP: This expired I-D yet implemented in open source uses the O-bit: https://www.ietf.org/archive/id/draft-penno-sfc-trace-03.txt <https://www.ietf.org/archive/id/draft-penno-sfc-trace-03.txt>
*Gyan Mishra <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>*
I agree that what makes sense to me as a path forward is to deprecate the O bit and not use in SFC Multilayer OAM and SFC IOAM, as both SFC Multilayer OAM and SFC IOAM are identified by the respective values for the NSH Next Protocol field (to be assigned by IANA), as well as so far no OAM-specific meta data TLV has been yet defined.
CMP: What is the “SFC Multilayer OAM”?
CMP: The O-bit (reading RFC 8300) does not indicate if there is OAM Metadata. It indicates an OAM packet.
*"Joel M. Halpern" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>*
As far as I can tell, if we deprecate the O-bit and rely on the next protocol field, we are saying that in practice (not by rule) NSH metadata can not be used for OAM.  That's fine with me as long as we agree on that.
CMP: I do not fully follow this. Can you explain the relationship of the O-bit with Metadata?
CMP: Here’s an example: RFC 8924 shows ICMP as Active OAM. The SFC next protocol is IP, the IP next protocol is ICMP, the O-bit needs to be set.
CMP: Consider the following document, independent submission and in the RFC Publication queue already:
CMP: https://datatracker.ietf.org/doc/draft-mymb-sfc-nsh-allocation-timestamp/ <https://datatracker.ietf.org/doc/draft-mymb-sfc-nsh-allocation-timestamp/>
CMP: Is a Timestamp in Metadata an OAM element?
CMP: Consider this proposal https://datatracker.ietf.org/doc/draft-mirsky-sfc-pmamm/ <https://datatracker.ietf.org/doc/draft-mirsky-sfc-pmamm/>
CMP: Where the base header borrows a bit for an OAM function.
CMP: Neither of those have any impact on the O-bit.
*Greg Mirsky <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>*
I agree that, as we find SFC NSH now, no OAM metadata has been defined. It appears to me that deprecating the O bit does not affect any of the already defined mechanisms in the SFC NSH.
CMP: It actually does, see my example above.
I think that if a new, for example, MD Type = 2 TLV that is used for any OAM functionality to be proposed in the future, deprecated the O bit would not prevent using such NSH TLV.
CMP: I agree with this — because there is no correlation between MD Type field and O-bit as defined.
Best,
Carlos.
2/13/22 午後12:32、Gyan Mishra <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>のメール:

Hi Joel

Kind Regards

Gyan

On Sun, Feb 13, 2022 at 12:04 PM Greg Mirsky <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:

   Hi Joel,

   Regards,
   Greg

   On Sun, Feb 13, 2022 at 6:55 AM Joel M. Halpern
   <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:

       There is an implication of deprecating the O-bit that I would
       like to
       hear from more WG participants about.

       As far as I can tell, if we deprecate the O-bit and rely on
       the next
       protocol field, we are saying that in practice (not by rule) NSH
       metadata can not be used for OAM.  That's fine with me as long
       as we
       agree on that.

       Yours,
       Joel

       > On Wed, Feb 2, 2022 at 5:42 PM Greg Mirsky
       <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
       <mailto:[email-masked]>>> wrote:
       > [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]>>
       > /Email [email-masked]<mailto:[email-masked]>

--

*Gyan Mishra*
/Network Solutions A//rchitect /
/Email [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>//
/
/M 301 502-1347

/

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 14 Feb 2022 09:10:05 -0500

Hmm.  let me paraphrase to make sure I understood, and assuming I did, 
clarify my confusion.

You seem to be saying that a way to do SFP OAM is to use something 
carried in IP carried in an NSH, with the O bit set.

If I am reading this correctly, this means that you expect an SFF seeing 
a packet with the O bit is supposed to examine not only the carried 
protocol (indicated by the next protocol field in the NSH) but to 
examine the various fields of that protocol to decide if the inned 
content is OAM the SFF is supposed to pay attention to.

That does not match my understanding of expected behavior.  Particularly 
since that carried IP packet is likely not addressed to the SFF, and 
also will not be having its TTL or other fields checked.

Again, it would be good to hear from other WG participants as to whether 
they understand expect behavior of an SFF to include this (based on 8300).

Yours,
Joel

On 2/14/2022 8:02 AM, Carlos Pignataro (cpignata) wrote:
> Joel,
> 
> Happy to.
> 
> No, that is not what I meant. I am not sure where (or why) you added the 
> word “external”, but that was key to showing a disconnect (I might not 
> have been clear and/or you might not have read correctly).
> 
> There is an I-D now, sfc-multi-layer-oam, that sends “SFC Active OAM" 
> packets with a new SFC next protocol for a newly created protocol. In 
> this case, the SFC next protocol is not expected to be used in user 
> packets, at least for now (or people have not thought about that 
> in hierarchical cases)
> 
> Imagine now that BFD or ICMP want to be used as an SFC Active OAM 
> protocols, instead of the sfc-multi-layer-oam one. Those can be 
> encapsulated in IP (even with a 127/8 destination). Using the O-bit set 
> and SFC NP as IP is the RFC 8300 expected way. (I imagine creating a new 
> SFC next protocol for “BFD-in-IP-used-in-SFC” so as to avoid an SFC NP 
> expected on external packets would be an approach if there was no O-bit 
> defined)
> 
> Best,
> 
> Carlos.
> 
>> why set the bit?)  This seems an undesirable and expensive 
>> implications which other readers have not drawn from the RFC 8300 
>> text.  (It also requires the encapsulating node to do extra checking 
>> to discover this case.)
>>
>>> places on the thread. Please find some follow-up comments and 
>>> questions marked “CMP”, indicating the “From”, and organized 
>>> chronologically:
>>> <mailto:[email-masked]>>>:*
>>>> packets which are intended for SFC OAM at the SFC service layer.  
>>>> But that is not what the current text says.  There is also, 
>>>> unfortunately, ambiguity as to what constitutes an OAM packet.  So 
>>>> it is reasonable for documents to update 8300 to clarify the exact 
>>>> applicability and action for the O-bit.
>>> CMP: 1. "But that is not what the current text says.” —> what does 
>>> the text say precisely?  Can you point to the specific RFC 8300 text 
>>> that is believed to be incomplete, and a detailed use case that 
>>> showcases the potential issue? An extrapolated counter-example just 
>>> to make a point: the text does not  say what days of the week OAM 
>>> packets can be marked, yet there’s an expectation that they will work 
>>> Mondays and Saturdays all the same — even holidays.
>>> CMP: 2. What specifically is the ambiguity with what an OAM packet 
>>> is? Please grep the RFC series for “oam packet”, it is not a new term.
>>>> updating the definition differently.  As such, the authors of the 
>>>> SFC iOAM draft and the SFC multi-layer-oam draft need to come 
>>>> together and figure out what the clarification is for the definition 
>>>> of that bit. We do not believe as chairs that either of these 
>>>> documents can move forward from the WG until such clarity has been 
>>>> reached.
>>> clarification is agreed, a separate document that only makes that 
>>> O-bit clarification is the most clear and clean way to go. That doc 
>>> should be a one-pager or less. I’d be happy to contribute to that 
>>> minimal doc, if it is shown to be needed.
>>> CMP: For completeness also, the "SFC multi-layer-oam” document has 
>>> many outstanding issues besides the O-bit.
>>> *Greg Mirsky <[email-masked] <mailto:[email-masked]> 
>>> <mailto:[email-masked] <mailto:[email-masked]>>>*
>>>> (to be assigned by IANA).
>>> CMP: There is a major issue with the sentence above. Active SFC OAM 
>>> (as a category), as per RFC 8300, needs to be identified by setting 
>>> the O-bit. No way around that based on RFC 8300. However, the text 
>>> "the Active SFC OAM” creates confusion since it refer to a specific 
>>> OAM protocol which has the same name as a the category as well. That 
>>> name collision is quite unfortunate in my opinion.
>>>> defined. Thus, it appears that one way forward could be to not 
>>>> involve the O bit in the active SFC OAM or IOAM altogether. In other 
>>>> words, to deprecate the NSH O bit.
>>> protocols. Those can be encapsulated in IP, in which the 
>>> Next-Protocol indicates IP — and (as per RFC 8300) the O-bit is set 
>>> to indicate an OAM packet.
>>> <https://www.ietf.org/archive/id/draft-penno-sfc-trace-03.txt 
>>> <https://www.ietf.org/archive/id/draft-penno-sfc-trace-03.txt>>
>>> *Gyan Mishra <[email-masked] <mailto:[email-masked]> 
>>> <mailto:[email-masked] <mailto:[email-masked]>>>*
>>>> I agree that what makes sense to me as a path forward is to 
>>>> deprecate the O bit and not use in SFC Multilayer OAM and SFC IOAM, 
>>>> as both SFC Multilayer OAM and SFC IOAM are identified by the 
>>>> respective values for the NSH Next Protocol field (to be assigned by 
>>>> IANA), as well as so far no OAM-specific meta data TLV has been yet 
>>>> defined.
>>> *"Joel M. Halpern" <[email-masked] <mailto:[email-masked]> 
>>> <mailto:[email-masked] <mailto:[email-masked]>>>*
>>> CMP: Here’s an example: RFC 8924 shows ICMP as Active OAM. The SFC 
>>> next protocol is IP, the IP next protocol is ICMP, the O-bit needs to 
>>> be set.
>>> https://datatracker.ietf.org/doc/draft-mymb-sfc-nsh-allocation-timestamp/ 
>>> <https://datatracker.ietf.org/doc/draft-mymb-sfc-nsh-allocation-timestamp/> 
>>> <https://datatracker.ietf.org/doc/draft-mymb-sfc-nsh-allocation-timestamp/ 
>>> <https://datatracker.ietf.org/doc/draft-mymb-sfc-nsh-allocation-timestamp/>>
>>> <https://datatracker.ietf.org/doc/draft-mirsky-sfc-pmamm/ 
>>> <https://datatracker.ietf.org/doc/draft-mirsky-sfc-pmamm/>>
>>> *Greg Mirsky <[email-masked] <mailto:[email-masked]> 
>>> <mailto:[email-masked] <mailto:[email-masked]>>>*
>>>> 2/13/22 午後12:32、Gyan Mishra <[email-masked] 
>>>> <mailto:[email-masked]> <mailto:[email-masked] 
>>>> <mailto:[email-masked]>>>のメール:
>>>>
>>>> Hi Joel
>>>>
>>>> bit is deprecated that NSH metadata cannot be used for OAM and that 
>>>> we would have to now from that point forward rely on the next 
>>>> protocol field as we will be doing for SFC Multilayer and SFC IOAM 
>>>> drafts as well as will have backwards compatible with any already 
>>>> existing defined mechanisms in SFC NSH.
>>>>
>>>> On Sun, Feb 13, 2022 at 12:04 PM Greg Mirsky <[email-masked] 
>>>> <mailto:[email-masked]> <mailto:[email-masked] 
>>>> <mailto:[email-masked]>>> wrote:
>>>>
>>>>    Hi Joel,
>>>>    <[email-masked] <mailto:[email-masked]> 
>>>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>>
>>>>        >
>>>>        > Hi Jim, Joel & SFC WG,
>>>>        >
>>>>        > I agree that the RFC 8300 definition of O bit is incomplete
>>>>        and not
>>>>        > clear as to its intended use.
>>>>        >
>>>>        > That is a problem that I agree needs to be rectified.
>>>>        >
>>>>        > I understand that we need to get this resolved before we can
>>>>        progress
>>>>        > Multilayer SFC OAM draft-ietf-sfc-multi-layer-oam-18 and SFC
>>>>        IOAM.
>>>>        >
>>>>        > I agree that what makes sense to me as a path forward is to
>>>>        deprecate
>>>>        > the O bit and not use in SFC Multilayer OAM and SFC IOAM, as
>>>>        both SFC
>>>>        > Multilayer OAM and SFC IOAM are identified by the respective
>>>>        values for
>>>>        > the NSH Next Protocol field (to be assigned by IANA), as
>>>>        well as so far
>>>>        > no OAM-specific meta data TLV has been yet defined.
>>>>        >
>>>>        > So we have I believe solid solution and path forward and I
>>>>        support
>>>>        > deprecating the O bit.
>>>>        >
>>>>        > Kind Regards
>>>>        >
>>>>        > Gyan
>>>>        >
>>>>        > On Wed, Feb 2, 2022 at 5:42 PM Greg Mirsky
>>>> <mailto:[email-masked] <mailto:[email-masked]>>
>>>>        > <mailto:[email-masked] <mailto:[email-masked]>
>>>>        <mailto:[email-masked] 
>>>> <mailto:[email-masked]>>>> wrote:
>>>>        >
>>>>        >     Thank you, Jim and Joel, for guiding the SFC OAM work
>>>>        and pointing
>>>>        >     out the issue that must be addressed.
>>>>        >
>>>>        >     I've reviewed our SFC OAM documents and
>>>>        draft-ietf-sfc-nsh-tlv. As I
>>>>        >     understand these documents, the Active SFC OAM and IOAM are
>>>>        >     identified by the respective values for the NSH Next
>>>>        Protocol field
>>>>        >     (to be assigned by IANA). At the same time, so far no
>>>>        OAM-specific
>>>>        >     meta data TLV has been defined. Thus, it appears that
>>>>        one way
>>>>        >     forward could be to not involve the O bit in the active
>>>>        SFC OAM or
>>>>        >     IOAM altogether. In other words, to deprecate the NSH O 
>>>> bit.
>>>>        >
>>>>        >     I greatly appreciate your comments on the proposal to
>>>>        deprecate the
>>>>        >     NSH O bit.
>>>>        >
>>>>        >     Regards,
>>>>        >     Greg
>>>>        >
>>>>        >     On Wed, Feb 2, 2022 at 10:36 AM James Guichard
>>>>        >     <[email-masked] 
>>>> <mailto:[email-masked]>>
>>>>        >     <mailto:[email-masked] 
>>>> <mailto:[email-masked]>>>> wrote:
>>>>        >
>>>>        >         Hi WG:____
>>>>        >
>>>>        >         __ __
>>>>        >
>>>>        >         Having reviewed all of the OAM related documents in
>>>>        our WG, the
>>>>        >         chairs would like to provide a few comments to 
>>>> hopefully
>>>>        >         generate discussion and forward progress of this
>>>>        work:____
>>>>        >
>>>>        >         __ __
>>>>        >
>>>>        >         1) The chairs have reviewed the O bit definition in
>>>>        RFC 8300.
>>>>        >         That definition is at best open to interpretation
>>>>        and therefore
>>>>        >         incomplete.  For example, the clear intention is
>>>>        only to mark
>>>>        >         packets which are intended for SFC OAM at the SFC
>>>>        service
>>>>        >         layer.  But that is not what the current text says. 
>>>>         There is
>>>>        >         also, unfortunately, ambiguity as to what
>>>>        constitutes an OAM
>>>>        >         packet.  So it is reasonable for documents to update
>>>>        8300 to
>>>>        >         clarify the exact applicability and action for the
>>>>        O-bit.____
>>>>        >
>>>>        >         __ __
>>>>        >
>>>>        >         2) However, related to point 1), we can't have multiple
>>>>        >         documents updating the definition differently.  As
>>>>        such, the
>>>>        >         authors of the SFC iOAM draft and the SFC
>>>>        multi-layer-oam draft
>>>>        >         need to come together and figure out what the
>>>>        clarification is
>>>>        >         for the definition of that bit. We do not believe as
>>>>        chairs that
>>>>        >         either of these documents can move forward from the
>>>>        WG until
>>>>        >         such clarity has been reached. ____
>>>>        >
>>>>        >         __ __
>>>>        >
>>>>        >         3) Related to the SFC iOAM, we need a clear
>>>>        definition of iOAM.
>>>>        >         There seem to be differences between the definitions in
>>>>        >         published RFCs, the usage (which is not a
>>>>        definition) in the SFC
>>>>        >         draft, and the various ippm drafts.  Any such
>>>>        definition will
>>>>        >         need to be vetted with the ippm working group.____
>>>>        >
>>>>        >         __ __
>>>>        >
>>>>        >         Again, it would be good if members of the working
>>>>        group beyond
>>>>        >         the two author teams spoke up about their readings
>>>>        of the
>>>>        >         documents, and their understandings of what we 
>>>> need.____
>>>>        >
>>>>        >         __ __
>>>>        >
>>>>        >         Yours,____
>>>>        >
>>>>        >         Jim and Joel____
>>>>        >
>>>>        >         __ __
>>>>        >
>>>>        >         __ __
>>>>        >
>>>>        >         __ __
>>>>        >
>>>>        >         _______________________________________________
>>>>        >         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]>>>
>>>>        > 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] <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>>>
>>>>        >
>>>>        > --
>>>>        >
>>>>        > <http://www.verizon.com/ <http://www.verizon.com/> 
>>>> <http://www.verizon.com/ <http://www.verizon.com/>>>
>>>>        >
>>>>        > *Gyan Mishra*
>>>>        >
>>>>        > /Network Solutions A//rchitect /
>>>>        >
>>>>        > /Email [email-masked] 
>>>> <mailto:[email-masked]>>
>>>> <mailto:[email-masked]>>>//
>>>>        > /
>>>>        >
>>>>        > /M 301 502-1347
>>>>        >
>>>>        > /
>>>>        >
>>>>        >
>>>>
>>>> -- 
>>>>
>>>> /Email [email-masked] <mailto:[email-masked]> 
>>>> <mailto:[email-masked] <mailto:[email-masked]>>//
>>>> /
>>>> /M 301 502-1347
>>>>
>>>> /
>>>>

---

From: James Guichard <[email-masked]>
Date: Mon, 14 Feb 2022 14:28:07 +0000

Hi Carlos,

Some responses in-line …

From: sfc <[email-masked]> On Behalf Of Carlos Pignataro (cpignata)
Sent: Sunday, February 13, 2022 11:07 PM
To: Gyan Mishra <[email-masked]>
Cc: Greg Mirsky <[email-masked]>; [email-masked]
Subject: Re: [sfc] Progression of OAM work in the SFC WG

CMP: It is unclear to me what exact issues the chairs are calling out. There are two issues mentioned:
CMP: 1. "But that is not what the current text says.” -> what does the text say precisely?  Can you point to the specific RFC 8300 text that is believed to be incomplete, and a detailed use case that showcases the potential issue? An extrapolated counter-example just to make a point: the text does not  say what days of the week OAM packets can be marked, yet there’s an expectation that they will work Mondays and Saturdays all the same - even holidays.

Jim> Currently RFC8300 says “The O bit MUST be set for OAM packets and MUST NOT be set for non-OAM packets”. The first issue is does this mean the O bit should be set for ALL OAM packets regardless of whether they belong to the NSH service plane? Or should it only be set for SFC OAM packets? And what exactly is an SFC OAM packet as the earlier reference to RFC6291 is just a generate set of guidelines for the use of the term OAM. The second issue is that if that O bit is set then Greg’s document is in conflict with IOAM as both use the next protocol field and even if the O bit is set it is meaningless as the protocol action is based solely on the setting of the next protocol field. So in this case can their solutions simply ignore what RFC 8300 says e.g. MUST set the O bit? Or if they set the O bit to be conformant to what RFC 8300 says then do we need clearer rules stating what to do if the next protocol field is NOT an OAM next protocol such as the context headers should then be examined?

Jim> ambiguity is whether it is only SFC OAM packets that are being discussed or ALL OAM packets nothing that some might be at the service layer and some might not.

Jim

CMP: RFC 8924 already includes ICMP and BFD as example SFC Action OAM protocols. Those can be encapsulated in IP, in which the Next-Protocol indicates IP - and (as per RFC 8300) the O-bit is set to indicate an OAM packet.
CMP: The proposal of deprecating the O-bit breaks those SFC OAM protocols already included in an RFC.
CMP: That proposal of deprecating the O-bit also breaks Section 4.1 of IOAM.
CMP: This expired I-D yet implemented in open source uses the O-bit: https://www.ietf.org/archive/id/draft-penno-sfc-trace-03.txt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-penno-sfc-trace-03.txt&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C9db2ab0a9382461397f908d9ef6f7ff5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637804084481196264%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=z%2BkFgDqH24pyY47wH0JOJgeo2maLlCgfFSp3MZ5KzZc%3D&reserved=0>

CMP: Consider the following document, independent submission and in the RFC Publication queue already:
CMP: https://datatracker.ietf.org/doc/draft-mymb-sfc-nsh-allocation-timestamp/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mymb-sfc-nsh-allocation-timestamp%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C9db2ab0a9382461397f908d9ef6f7ff5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637804084481196264%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=B0%2FQPQTbQruTKzqXfin6ZfEYyauA2KZhq0m8YKSLtLE%3D&reserved=0>
CMP: Is a Timestamp in Metadata an OAM element?

CMP: Consider this proposal https://datatracker.ietf.org/doc/draft-mirsky-sfc-pmamm/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mirsky-sfc-pmamm%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C9db2ab0a9382461397f908d9ef6f7ff5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637804084481196264%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JiikGgXG35%2FW518disuIxAvaWa5FuqvkKcG%2Fayg6R48%3D&reserved=0>
CMP: Where the base header borrows a bit for an OAM function.

CMP: I agree with this - because there is no correlation between MD Type field and O-bit as defined.

Best,

Carlos.

Hi Joel

Kind Regards

Gyan

Regards,
Greg

Yours,
Joel

On 2/13/2022 2:52 AM, Gyan Mishra wrote:
>         https://www.ietf.org/mailman/listinfo/sfc<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsfc&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C9db2ab0a9382461397f908d9ef6f7ff5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637804084481196264%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=R120rPMaYbbRLOv5jGA%2BiAJotLq4BO8fahg3452n2PU%3D&reserved=0>
>         <https://www.ietf.org/mailman/listinfo/sfc<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsfc&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C9db2ab0a9382461397f908d9ef6f7ff5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637804084481352514%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FkotEwodgOcwwpPgrNIIyZ%2BY5tC3bIiegKAjzvo%2BpKI%3D&reserved=0>>
>
>     https://www.ietf.org/mailman/listinfo/sfc<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsfc&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C9db2ab0a9382461397f908d9ef6f7ff5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637804084481352514%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FkotEwodgOcwwpPgrNIIyZ%2BY5tC3bIiegKAjzvo%2BpKI%3D&reserved=0>
>     <https://www.ietf.org/mailman/listinfo/sfc<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsfc&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C9db2ab0a9382461397f908d9ef6f7ff5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637804084481352514%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FkotEwodgOcwwpPgrNIIyZ%2BY5tC3bIiegKAjzvo%2BpKI%3D&reserved=0>>
>
> --
>
> <http://www.verizon.com/<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C9db2ab0a9382461397f908d9ef6f7ff5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637804084481352514%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ONjfg3GZJ5atr1x8BR792XzO%2F9pozjN2GGJBA%2F5jK8w%3D&reserved=0>>
>
> *Gyan Mishra*
>
--
[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C9db2ab0a9382461397f908d9ef6f7ff5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637804084481352514%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ONjfg3GZJ5atr1x8BR792XzO%2F9pozjN2GGJBA%2F5jK8w%3D&reserved=0>
Gyan Mishra
Network Solutions Architect
Email [email-masked]<mailto:[email-masked]>
M 301 502-1347

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 14 Feb 2022 15:06:06 +0000

Thanks — I’d expect SFC OAM layer packets only, and would also expect a model that works equally with multilayer-oam approaches or with existing OAMs.

Thanks!

Carlos.

2/14/22 午前9:28、James Guichard <[email-masked]<mailto:[email-masked]>>のメール:

Hi Carlos,

Some responses in-line …

From: sfc <[email-masked]<mailto:[email-masked]>> On Behalf Of Carlos Pignataro (cpignata)
Sent: Sunday, February 13, 2022 11:07 PM
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Cc: Greg Mirsky <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Progression of OAM work in the SFC WG

Jim

Best,

Carlos.

Hi Joel

Kind Regards

Gyan

Regards,
Greg

Yours,
Joel

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 14 Feb 2022 10:08:54 -0800

Dear Carlos,
top-posting your questions addressed to my proposal to deprecate the O-bit.
Please find my answers and notes in-lined under the GIM>> tag below.
CMP: RFC 8924 already includes ICMP and BFD as example SFC Action OAM
protocols. Those can be encapsulated in IP, in which the Next-Protocol
indicates IP — and (as per RFC 8300) the O-bit is set to indicate an OAM
packet.
GIM>> I cannot find in RFC 8924 the explanation of the encapsulation of the
BFD Control message. Should we assume that IPv4/IPv6 is assumed? If that is
the case, which IP address is to be used as the destination IP address? And
one more, What special processing is ensured by setting the O bit?
CMP: The proposal of deprecating the O-bit breaks those SFC OAM protocols
already included in an RFC.
GIM>> Could you please clarify in which part the removal of the O bit
breaks, for example, ICMP or BFD?
CMP: That proposal of deprecating the O-bit also breaks Section 4.1 of IOAM.
GIM>> Could you please clarify to which IOAM document you are referring?
CMP: This expired I-D yet implemented in open source uses the O-bit:
https://www.ietf.org/archive/id/draft-penno-sfc-trace-03.txt
GIM>> I recall that the WG discussed and agreed to significantly modify the
NSH format. That possibly had affected some existing implementations.

Regards,
Greg

On Sun, Feb 13, 2022 at 8:06 PM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> latest one at this point in time, but bundling comments from various places
> on the thread. Please find some follow-up comments and questions marked
> “CMP”, indicating the “From”, and organized chronologically:
>
> <[email-masked]>>:*
>
> potential issue? An extrapolated counter-example just to make a point: the
> text does not  say what days of the week OAM packets can be marked, yet
> there’s an expectation that they will work Mondays and Saturdays all the
> same — even holidays.
> CMP: If there is still believed to be an ambiguity or a clear opportunity
> for improving the definition, I agree with consolidating that update. I had
> suggested before that if such new text or real clarification is agreed, a
> separate document that only makes that O-bit clarification is the most
> clear and clean way to go. That doc should be a one-pager or less. I’d be
> happy to contribute to that minimal doc, if it is shown to be needed.
>
> *Greg Mirsky <[email-masked] <[email-masked]>>*
>
> IANA).
> CMP: There is a major issue with the sentence above. Active SFC OAM (as a
> category), as per RFC 8300, needs to be identified by setting the O-bit. No
> way around that based on RFC 8300. However, the text "the Active SFC OAM”
> creates confusion since it refer to a specific OAM protocol which has the
> same name as a the category as well. That name collision is quite
> unfortunate in my opinion.
>
> At the same time, so far no OAM-specific meta data TLV has been defined.
> Thus, it appears that one way forward could be to not involve the O bit in
> the active SFC OAM or IOAM altogether. In other words, to deprecate the NSH
> O bit.
>
>
> *Gyan Mishra <[email-masked] <[email-masked]>>*
>
> I agree that what makes sense to me as a path forward is to deprecate the
> O bit and not use in SFC Multilayer OAM and SFC IOAM, as both SFC
> Multilayer OAM and SFC IOAM are identified by the respective values for the
> NSH Next Protocol field (to be assigned by IANA), as well as so far no
> OAM-specific meta data TLV has been yet defined.
>
>
> *"Joel M. Halpern" <[email-masked] <[email-masked]>>*
>
> protocol field, we are saying that in practice (not by rule) NSH metadata
> can not be used for OAM.  That's fine with me as long as we agree on that.
>
>
> *Greg Mirsky <[email-masked] <[email-masked]>>*
>
> defined mechanisms in the SFC NSH.
>
>
> I think that if a new, for example, MD Type = 2 TLV that is used for any
> OAM functionality to be proposed in the future, deprecated the O bit
> would not prevent using such NSH TLV.
>
>
> 2/13/22 午後12:32、Gyan Mishra <[email-masked]>のメール:
>
> Hi Joel
>
>> I agree that, as we find SFC NSH now, no OAM metadata has been defined.
>> It appears to me that deprecating the O bit does not affect any of
>> the already defined mechanisms in the SFC NSH. I think that if a new, for
>> example, MD Type = 2 TLV that is used for any OAM functionality to be
>> proposed in the future, deprecated the O bit would not prevent using such
>> NSH TLV.
>> What do you think?
>>
>> Regards,
>> Greg
>>
>>> for
> *M 301 502-1347 *

---

From: <[email-masked]>
Date: Wed, 16 Feb 2022 09:58:08 +0000

Hi Jim, all,

We had many discussions in the past about the O-bit (including a proposal to tag the flag as reserved and define it when needed [1], deprecate the O-bit [2]) before finally agreeing on the text we have in 8300.

I don’t think we have new arguments to deprecate the O-bit. However, a clarification of intended meaning of “OAM packet” is worth to have. I’m happy to work with other volunteers on a short document that fixes that.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/sfc/f4RbYlUKKHm53U1eaCvjhMypLc0/
[2] https://mailarchive.ietf.org/arch/msg/sfc/lyTfojhc7iispryG4bX66B7Fci4/

De : sfc <[email-masked]> De la part de James Guichard
Envoyé : lundi 14 février 2022 15:28
À : Carlos Pignataro (cpignata) <cpignata=[email-masked]>; Gyan Mishra <[email-masked]>
Cc : Greg Mirsky <[email-masked]>; [email-masked]
Objet : Re: [sfc] Progression of OAM work in the SFC WG

Hi Carlos,

Some responses in-line …

Jim

Best,

Carlos.

Hi Joel

Kind Regards

Gyan

Regards,
Greg

Yours,
Joel

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: James Guichard <[email-masked]>
Date: Wed, 16 Feb 2022 13:08:02 +0000

Hi Carlos,

Thank you for the clarification. Your response highlights quite nicely the issues that the chairs are trying to bring to the WGs attention - maybe responses to the following questions will help settle this:

  1.  Should the O-bit be set ONLY for OAM packets that are specific to the SFC service layer?
  2.  Should the O-bit be set in the cases where a solution uses the next protocol field in the NSH header? In this case what is the purpose of the O-bit given that the next protocol field already indicates the expected behavior?
  3.  If the O-bit is set is it the expected behavior to find relevant SFC service layer OAM information in the context headers?

Thanks!

Jim

From: Carlos Pignataro (cpignata) <[email-masked]>
Sent: Monday, February 14, 2022 10:06 AM
To: James Guichard <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Greg Mirsky <[email-masked]>; [email-masked]
Subject: Re: [sfc] Progression of OAM work in the SFC WG

Thanks - I’d expect SFC OAM layer packets only, and would also expect a model that works equally with multilayer-oam approaches or with existing OAMs.

Thanks!

Carlos.

Hi Carlos,

Some responses in-line …

Jim

CMP: RFC 8924 already includes ICMP and BFD as example SFC Action OAM protocols. Those can be encapsulated in IP, in which the Next-Protocol indicates IP - and (as per RFC 8300) the O-bit is set to indicate an OAM packet.
CMP: The proposal of deprecating the O-bit breaks those SFC OAM protocols already included in an RFC.
CMP: That proposal of deprecating the O-bit also breaks Section 4.1 of IOAM.
CMP: This expired I-D yet implemented in open source uses the O-bit: https://www.ietf.org/archive/id/draft-penno-sfc-trace-03.txt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-penno-sfc-trace-03.txt&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C004888763ed04b7826e408d9efcb8a5f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637804479774063548%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yVs%2FSvVIIXSMUjItso3gY6JmUgrFbv7hyJYTKKIKvBw%3D&reserved=0>

CMP: Consider the following document, independent submission and in the RFC Publication queue already:
CMP: https://datatracker.ietf.org/doc/draft-mymb-sfc-nsh-allocation-timestamp/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mymb-sfc-nsh-allocation-timestamp%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C004888763ed04b7826e408d9efcb8a5f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637804479774063548%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8HhoPP9NKc269OlDOYhCn8ZSaV2QBy0qYVAebOS3XiU%3D&reserved=0>
CMP: Is a Timestamp in Metadata an OAM element?

CMP: Consider this proposal https://datatracker.ietf.org/doc/draft-mirsky-sfc-pmamm/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mirsky-sfc-pmamm%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C004888763ed04b7826e408d9efcb8a5f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637804479774063548%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=CK90uAaVV%2Fg289xwjMfH9MlOuGi69Z03C29Q0QI2eSg%3D&reserved=0>
CMP: Where the base header borrows a bit for an OAM function.

Best,

Carlos.

Hi Joel

Kind Regards

Gyan

Regards,
Greg

Yours,
Joel

On 2/13/2022 2:52 AM, Gyan Mishra wrote:
>         https://www.ietf.org/mailman/listinfo/sfc<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsfc&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C004888763ed04b7826e408d9efcb8a5f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637804479774063548%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=dw9UjjLiSX2Rg2AcLPSEYvpEVabL9dxiFjggbAIUPNQ%3D&reserved=0>
>         <https://www.ietf.org/mailman/listinfo/sfc<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsfc&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C004888763ed04b7826e408d9efcb8a5f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637804479774063548%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=dw9UjjLiSX2Rg2AcLPSEYvpEVabL9dxiFjggbAIUPNQ%3D&reserved=0>>
>
>     https://www.ietf.org/mailman/listinfo/sfc<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsfc&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C004888763ed04b7826e408d9efcb8a5f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637804479774063548%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=dw9UjjLiSX2Rg2AcLPSEYvpEVabL9dxiFjggbAIUPNQ%3D&reserved=0>
>     <https://www.ietf.org/mailman/listinfo/sfc<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsfc&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C004888763ed04b7826e408d9efcb8a5f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637804479774063548%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=dw9UjjLiSX2Rg2AcLPSEYvpEVabL9dxiFjggbAIUPNQ%3D&reserved=0>>
>
> --
>
> <http://www.verizon.com/<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C004888763ed04b7826e408d9efcb8a5f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637804479774063548%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mY2k40DspePY81fLur00ojScqx%2B9PY415au7AOfC2qM%3D&reserved=0>>
>
> *Gyan Mishra*
>
--
[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C004888763ed04b7826e408d9efcb8a5f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637804479774063548%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mY2k40DspePY81fLur00ojScqx%2B9PY415au7AOfC2qM%3D&reserved=0>
Gyan Mishra
Network Solutions Architect
Email [email-masked]<mailto:[email-masked]>
M 301 502-1347

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsfc&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C004888763ed04b7826e408d9efcb8a5f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637804479774063548%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=dw9UjjLiSX2Rg2AcLPSEYvpEVabL9dxiFjggbAIUPNQ%3D&reserved=0>

---

From: <[email-masked]>
Date: Wed, 16 Feb 2022 13:16:01 +0000

Re-,

An approach that would reconciliate all active OAM documents is to clarify “somewhere” that an OAM packet (mentioned in 8300) is "an NSH-encapsulated message that exclusively include an OAM command and/or data in the NSH Context Header(s) or even in the packet payload".

We can further tweak the language.

Cheers,
Med

De : sfc <[email-masked]> De la part de Greg Mirsky
Envoyé : dimanche 13 février 2022 18:04
À : Joel M. Halpern <[email-masked]>
Cc : Gyan Mishra <[email-masked]>; [email-masked]
Objet : Re: [sfc] Progression of OAM work in the SFC WG

Hi Joel,

Regards,
Greg

Yours,
Joel

---

From: James Guichard <[email-masked]>
Date: Wed, 16 Feb 2022 13:29:59 +0000

Dear WG:

I should have clarified in my previous email that RFC 8300 as currently written says that the O-bit MUST be set for OAM packets. This means that for point (2) both IOAM and multilayer-oam MUST have the O-bit set and this causes a conflict between the two as I previously pointed out based upon the current text within the multilayer-oam document, and for point (3) there is nothing in 8300 that suggests that OAM information MUST be in the context headers.

Jim

From: sfc <[email-masked]> On Behalf Of James Guichard
Sent: Wednesday, February 16, 2022 8:08 AM
To: Carlos Pignataro (cpignata) <[email-masked]>
Cc: Greg Mirsky <[email-masked]>; Gyan Mishra <[email-masked]>; [email-masked]
Subject: Re: [sfc] Progression of OAM work in the SFC WG

Hi Carlos,

Thanks!

Jim

From: Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>>
Sent: Monday, February 14, 2022 10:06 AM
To: James Guichard <[email-masked]<mailto:[email-masked]>>
Cc: Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Progression of OAM work in the SFC WG

Thanks!

Carlos.

Hi Carlos,

Some responses in-line …

Jim

CMP: RFC 8924 already includes ICMP and BFD as example SFC Action OAM protocols. Those can be encapsulated in IP, in which the Next-Protocol indicates IP - and (as per RFC 8300) the O-bit is set to indicate an OAM packet.
CMP: The proposal of deprecating the O-bit breaks those SFC OAM protocols already included in an RFC.
CMP: That proposal of deprecating the O-bit also breaks Section 4.1 of IOAM.
CMP: This expired I-D yet implemented in open source uses the O-bit: https://www.ietf.org/archive/id/draft-penno-sfc-trace-03.txt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-penno-sfc-trace-03.txt&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C1995321b7f6a4d824f1208d9f14d6a84%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637806137138429181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=CA1cgENG17xvYgbrCuQWZykPJktgi8EEvcK%2F1coRPhQ%3D&reserved=0>

CMP: Consider the following document, independent submission and in the RFC Publication queue already:
CMP: https://datatracker.ietf.org/doc/draft-mymb-sfc-nsh-allocation-timestamp/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mymb-sfc-nsh-allocation-timestamp%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C1995321b7f6a4d824f1208d9f14d6a84%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637806137138429181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=nlYIyWfygNz6Bap3BubQaK%2BESgPtE%2BlbGm2o4d9kJPs%3D&reserved=0>
CMP: Is a Timestamp in Metadata an OAM element?

CMP: Consider this proposal https://datatracker.ietf.org/doc/draft-mirsky-sfc-pmamm/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mirsky-sfc-pmamm%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C1995321b7f6a4d824f1208d9f14d6a84%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637806137138429181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DNFbn%2BCWinM3s3sijLUZzPBLFlPgWLwyXQKICYWZKTY%3D&reserved=0>
CMP: Where the base header borrows a bit for an OAM function.

Best,

Carlos.

Hi Joel

Kind Regards

Gyan

Regards,
Greg

Yours,
Joel

On 2/13/2022 2:52 AM, Gyan Mishra wrote:
>         https://www.ietf.org/mailman/listinfo/sfc<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsfc&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C1995321b7f6a4d824f1208d9f14d6a84%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637806137138429181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BTmis5ulJftaU645rB8wUdpIIToNhqZNQaPIZ4Fw314%3D&reserved=0>
>         <https://www.ietf.org/mailman/listinfo/sfc<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsfc&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C1995321b7f6a4d824f1208d9f14d6a84%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637806137138429181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BTmis5ulJftaU645rB8wUdpIIToNhqZNQaPIZ4Fw314%3D&reserved=0>>
>
>     https://www.ietf.org/mailman/listinfo/sfc<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsfc&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C1995321b7f6a4d824f1208d9f14d6a84%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637806137138429181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BTmis5ulJftaU645rB8wUdpIIToNhqZNQaPIZ4Fw314%3D&reserved=0>
>     <https://www.ietf.org/mailman/listinfo/sfc<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsfc&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C1995321b7f6a4d824f1208d9f14d6a84%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637806137138429181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BTmis5ulJftaU645rB8wUdpIIToNhqZNQaPIZ4Fw314%3D&reserved=0>>
>
> --
>
> <http://www.verizon.com/<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C1995321b7f6a4d824f1208d9f14d6a84%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637806137138429181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8k5SaeX3JABkvF9gUxeZ26nIvwSOI%2BtWjd5jfP%2F%2FOKQ%3D&reserved=0>>
>
> *Gyan Mishra*
>
--
[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C1995321b7f6a4d824f1208d9f14d6a84%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637806137138429181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8k5SaeX3JABkvF9gUxeZ26nIvwSOI%2BtWjd5jfP%2F%2FOKQ%3D&reserved=0>
Gyan Mishra
Network Solutions Architect
Email [email-masked]<mailto:[email-masked]>
M 301 502-1347

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsfc&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C1995321b7f6a4d824f1208d9f14d6a84%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637806137138429181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BTmis5ulJftaU645rB8wUdpIIToNhqZNQaPIZ4Fw314%3D&reserved=0>