Subject: [sfc] Fwd: New Version Notification for draft-ietf-sfc-multi-layer-oam-03.txt

From: Greg Mirsky <[email-masked]>
Date: Wed, 8 May 2019 22:31:01 -0700

Dear All,
the update to the draft addresses the comment received from Joel at the
meeting in Prague:
- Joel: if we get an echo request we can't parse, how do we know that it is
an echo request, and do we have the information to return it to the correct
source?
- Greg: we will clarify this in the draft. It has to practical so the
sender can understand the situation. We introduced two classes of TLVs:
mandatory and optional. Will add clearer text.

A new TLV, Errored TLVs, introduced to be optionally used to pass in an
echo reply mandatory TLVs that were not understood because either the
implementation on the receiver does not support them or couldn't parse them
correctly.

Also, please review the update to the interpretation of O-bit and the value
of the Next Protocol field to address Adrian's comments at the meeting in
Bangkok:
The rules of
   interpreting the values of O bit and the Next Protocol field are as
   follows:

   o  O bit set, and the Next Protocol value is not one of identifying
      active or hybrid OAM protocol (per [RFC7799] definitions), e.g.,
      defined in this specification Active SFC OAM - a Fixed-Length
      Context Header or Variable-Length Context Header(s) contain OAM
      command or data.  and the type of payload determined by the Next
      Protocol field;

   o  O bit set, and the Next Protocol value is one of identifying
      active or hybrid OAM protocol - the payload that immediately
      follows SFC NSH contains OAM command or data;

   o  O bit is clear - no OAM in a Fixed-Length Context Header or
      Variable-Length Context Header(s) and the payload determined by
      the value of the Next Protocol field;

   o  O bit is clear and the Next Protocol value is one of identifying
      active or hybrid OAM protocol MUST be identified and reported as
      the erroneous combination.  An implementation MAY have control to
      enable processing of the OAM payload.

   From the above-listed rules follows the recommendation to avoid
   combination of OAM in a Fixed-Length Context Header or Variable-
   Length Context Header(s) and in the payload immediately following the
   SFC NSH because there is no unambiguous way to identify such
   combination using the O bit and the Next Protocol field.

Regards,
Greg

---------- Forwarded message ---------
From: <[email-masked]>
Date: Wed, May 8, 2019 at 10:21 PM
Subject: New Version Notification for draft-ietf-sfc-multi-layer-oam-03.txt
To: <[email-masked]>, Gregory Mirsky <[email-masked]>, Bhumip
Khasnabish <[email-masked]>, Wei Meng <[email-masked]>, Cui(Linda)
Wang <[email-masked]>

A new version of I-D, draft-ietf-sfc-multi-layer-oam-03.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:           draft-ietf-sfc-multi-layer-oam
Revision:       03
Title:          Active OAM for Service Function Chains in Networks
Document date:  2019-05-08
Group:          sfc
Pages:          18
URL:
https://www.ietf.org/internet-drafts/draft-ietf-sfc-multi-layer-oam-03.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-sfc-multi-layer-oam/
Htmlized:
https://tools.ietf.org/html/draft-ietf-sfc-multi-layer-oam-03
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-sfc-multi-layer-oam
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-multi-layer-oam-03

Abstract:
   A set of requirements for active Operation, Administration and
   Maintenance (OAM) of Service Function Chains (SFCs) in networks is
   presented.  Based on these requirements an encapsulation of active
   OAM message in SFC and a mechanism to detect and localize defects
   described.  Also, this document updates RFC 8300 in the definition of
   O (OAM) bit in the Network Service Header (NSH) and defines how the
   active OAM message identified in SFC NSH.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 11 May 2019 02:53:30 +0000

Hi, Greg, SFC,

In order to understand the positioning of draft-ietf-sfc-multi-layer-oam, please find 3 high-level yet very important questions and associated comments for consideration.

To avoid potential misinterpretation and to be explicit on this note's intention: this email does not imply interest in this draft, does not mean support, I have not read the document fully.

But a quick note for completeness:

1. “Implementation Status” Section.

The authors seem to selectively respond to comments.

I asked for an “Implementation Status” Section [RFC7942] at least two or three times:
* March 29, 2018, on draft-wang-sfc-multi-layer-oam https://mailarchive.ietf.org/arch/msg/nvo3/eNRV-7GLWO_lLeeXwI97HhTrtBo
* October 27, 2018, on adoption https://mailarchive.ietf.org/arch/msg/sfc/wuK4MiyeOMNbXrRIYjiW7zCtZ70

Instead, this drafts seems to be inventing a full blown protocol without implementation practice.

SFC Chairs, could we please follow-up on repeated comments made on the list and track a disposition? These are over a year old, and part of an adoption call.

Request: Can we please add an “Implementation Status” section?

2. New protocol invention outside of / rogue to an SFC OAM Framework.

draft-ietf-sfc-multi-layer-oam does not reference any other SFC I-Ds. It does not build upon existing work in progress, and instead invents a new protocol with RFC8300 as the only Normative reference from SFC.

The draft-ietf-sfc-oam-framework at https://tools.ietf.org/html/draft-ietf-sfc-oam-framework-06 takes a holistic approach of including an analysis (selecting only some section titles):
4.  SFC OAM Functions . . . . . . . . . . . . . . . . . . . . . .   8
5.  Gap Analysis  . . . . . . . . . . . . . . . . . . . . . . . .  11
5.1.  Existing OAM Functions  . . . . . . . . . . . . . . . . .  11
5.2.  Missing OAM Functions . . . . . . . . . . . . . . . . . .  12
6.4.  OAM Toolset applicability . . . . . . . . . . . . . . . .  13
       6.4.1.  ICMP Applicability  . . . . . . . . . . . . . . . . .  13

This analysis ought to guide protocol definition.

Question: Can this draft consider existing protocols and gap performed before re-inventing? Specifically Normatively cite the SFC OAM Framework and see where reuse is best?

3. Existing implementation of OAM functions.

Hows does this draft work with existing OAM functions with existing implementation, such as https://tools.ietf.org/html/draft-penno-sfc-trace-03 ? The fact that the draft is expired does not mean the implementation is uncoded.

Many thanks,

— Carlos Pignataro

On May 9, 2019, at 1:31 AM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Dear All,
the update to the draft addresses the comment received from Joel at the meeting in Prague:
- Joel: if we get an echo request we can't parse, how do we know that it is an echo request, and do we have the information to return it to the correct source?
- Greg: we will clarify this in the draft. It has to practical so the sender can understand the situation.. We introduced two classes of TLVs: mandatory and optional. Will add clearer text.

A new TLV, Errored TLVs, introduced to be optionally used to pass in an echo reply mandatory TLVs that were not understood because either the implementation on the receiver does not support them or couldn't parse them correctly.

Also, please review the update to the interpretation of O-bit and the value of the Next Protocol field to address Adrian's comments at the meeting in Bangkok:
The rules of
   interpreting the values of O bit and the Next Protocol field are as
   follows:

Regards,
Greg

---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Wed, May 8, 2019 at 10:21 PM
Subject: New Version Notification for draft-ietf-sfc-multi-layer-oam-03.txt
To: <[email-masked]<mailto:[email-masked]>>, Gregory Mirsky <[email-masked]<mailto:[email-masked]>>, Bhumip Khasnabish <[email-masked]<mailto:[email-masked]>>, Wei Meng <[email-masked]<mailto:meng.wei2@zte..com.cn>>, Cui(Linda) Wang <[email-masked]<mailto:[email-masked]>>

Name:           draft-ietf-sfc-multi-layer-oam
Revision:       03
Title:          Active OAM for Service Function Chains in Networks
Document date:  2019-05-08
Group:          sfc
Pages:          18
URL:            https://www.ietf.org/internet-drafts/draft-ietf-sfc-multi-layer-oam-03.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-sfc-multi-layer-oam/
Htmlized:       https://tools.ietf.org/html/draft-ietf-sfc-multi-layer-oam-03
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-sfc-multi-layer-oam
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-multi-layer-oam-03

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.

The IETF Secretariat

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

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 10 May 2019 20:14:25 -0700

Hi Carlos,
I'm sure you've read the section "Implementation Status" in RFC 7942 that
opens with the following sentence:
   Each Internet-Draft may contain a section entitled "Implementation
Status".
Thus I'm puzzled why are you demanding that this optional section be added
to the draft now? Yes, the work on the implementation is ongoing and when
there will be updates, we'll certainly share them with the WG.

Regards,
Greg

On Fri, May 10, 2019 at 7:53 PM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Hi, Greg, SFC,
>
> In order to understand the positioning of draft-ietf-sfc-multi-layer-oam,
> please find 3 high-level yet very important questions and associated
> comments for consideration.
>
> To avoid potential misinterpretation and to be explicit on this note's
> intention: this email does not imply interest in this draft, does not mean
> support, I have not read the document fully.
>
> * March 29, 2018, on draft-wang-sfc-multi-layer-oam
> https://mailarchive.ietf.org/arch/msg/nvo3/eNRV-7GLWO_lLeeXwI97HhTrtBo
> * October 27, 2018, on adoption
> https://mailarchive.ietf.org/arch/msg/sfc/wuK4MiyeOMNbXrRIYjiW7zCtZ70
>
> SFC Chairs, could we please follow-up on repeated comments made on the
> list and track a disposition? These are over a year old, and part of an
> adoption call.
>
> draft-ietf-sfc-multi-layer-oam does not reference any other SFC I-Ds. It
> does not build upon existing work in progress, and instead invents a new
> protocol with RFC8300 as the only Normative reference from SFC.
>
> The draft-ietf-sfc-oam-framework at
> https://tools.ietf.org/html/draft-ietf-sfc-oam-framework-06 takes a
> holistic approach of including an analysis (selecting only some section
> titles):
> Question: Can this draft consider existing protocols and gap performed
> before re-inventing? Specifically Normatively cite the SFC OAM Framework
> and see where reuse is best?
>
>
> Hows does this draft work with existing OAM functions with existing
> implementation, such as
> https://tools.ietf.org/html/draft-penno-sfc-trace-03 ? The fact that the
> draft is expired does not mean the implementation is uncoded.
>
>
> Many thanks,
>
> — Carlos Pignataro
>
> On May 9, 2019, at 1:31 AM, Greg Mirsky <[email-masked]> wrote:
>
> Dear All,
> - Joel: if we get an echo request we can't parse, how do we know that it
> is an echo request, and do we have the information to return it to the
> correct source?
> sender can understand the situation.. We introduced two classes of TLVs:
> Also, please review the update to the interpretation of O-bit and the
> value of the Next Protocol field to address Adrian's comments at the
> meeting in Bangkok:
> The rules of
> Khasnabish <[email-masked]>, Wei Meng <[email-masked]
> <meng.wei2@zte..com.cn>>, Cui(Linda) Wang <[email-masked]>
>
>
>
> [email-masked]

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 11 May 2019 03:34:45 +0000

Dear SFC Chairs,

I believe Greg’s response is mis-representing my position, and mis-quoting what I wrote, as follows:

Greg wrote:
Thus I'm puzzled why are you demanding that this optional section be added to the draft now?

1. I am not demanding. Instead I wrote:
Request: Can we please add an “Implementation Status” section?

Greg wrote:
Thus I'm puzzled why are you demanding that this optional section be added to the draft now?

However, I suggested this over a year ago, and then 6 months ago, as per the list posting included below. Not “now”.
* March 29, 2018, on draft-wang-sfc-multi-layer-oam https://mailarchive.ietf.org/arch/msg/nvo3/eNRV-7GLWO_lLeeXwI97HhTrtBo
* October 27, 2018, on adoption https://mailarchive.ietf.org/arch/msg/sfc/wuK4MiyeOMNbXrRIYjiW7zCtZ70

My main request is that on-list comments and suggestions are responded to and discussed on technical merits. The previous two/three times, my comment was ignored and not responded to.

I also do not understand why questions are selectively ignored. I asked three questions on this email, but received a response to only one.

Dear Greg,

Sorry to have puzzled you. That was not the intention. The intention was to engage in a technical discussion about an Internet Best Current Practice.

Apologies if I sounded (or was) repetitive, just seeking an answer.

I understand the “Implementation Status” section is optional, but since Internet documents are (among other things) for interoperability, I kindly request you consider adding that optional section. Besides the one-liner you quoted, RFC 7942 goes into great lengths at explaining the importance of doing so.

You also mention:
Yes, the work on the implementation is ongoing

Does this mean “the implementation” as in only one?

Best,

— Carlos Pignataro

On May 10, 2019, at 11:14 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,
I'm sure you've read the section "Implementation Status" in RFC 7942 that opens with the following sentence:
   Each Internet-Draft may contain a section entitled "Implementation Status".
Thus I'm puzzled why are you demanding that this optional section be added to the draft now? Yes, the work on the implementation is ongoing and when there will be updates, we'll certainly share them with the WG.

Regards,
Greg

On Fri, May 10, 2019 at 7:53 PM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Greg, SFC,

Many thanks,

— Carlos Pignataro

Dear All,

Regards,
Greg

---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Wed, May 8, 2019 at 10:21 PM
Subject: New Version Notification for draft-ietf-sfc-multi-layer-oam-03.txt
To: <[email-masked]<mailto:[email-masked]>>, Gregory Mirsky <[email-masked]<mailto:[email-masked]>>, Bhumip Khasnabish <[email-masked]<mailto:[email-masked]>>, Wei Meng <[email-masked]<mailto:meng.wei2@zte..com.cn>>, Cui(Linda) Wang <[email-masked]<mailto:[email-masked]>>

Abstract:

The IETF Secretariat

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 10 May 2019 23:48:14 -0400

Not comment on your other questions, and hoping that Greg will engage 
you in discussion on them, I want to comment on the "implementation 
section" comment.

There are two aspects to this question.
The first aspect is that you have (and the WG as a whole can) ask "are 
there implementations?"  I think we all expect authors to answer that 
question when asked.  The answer will likely end up in the shepherd 
writeup for the information of the IESG.

Separately, given that it appears that there is not an available 
implementation at this time, it is not the normal practice to expect 
that an implementation section be put in a draft highlighting that gap. 
That is not the expected practice as I understand it for the IETF as a 
whole, nor is it a practice that the SFC working group has adopted. 
There is a large difference between making sure that the group is aware 
of the status and explicitly stating the gap in the I-D.

It is certainly worth while to note, as you do, that there are 
implementations of some of the other OAM proposals.  I believe (although 
I do not have the evidence to hand) that those implementations have 
proven useful in practice, which is important information for the WG. 
If you have more details on that, I think taht would be good information 
(I am not asking for an OAM implementations I-D.  Just some email comments.)

Yours,
Joel

On 5/10/19 11:34 PM, Carlos Pignataro (cpignata) wrote:
> However, I suggested this over a year ago, and then 6 months ago, as per 
> the list posting included below. Not “now”.
>>
> My main request is that on-list comments and suggestions are responded 
> to and discussed on technical merits. The previous two/three times, my 
> comment was ignored and not responded to.
> 
> I also do not understand why questions are selectively ignored. I asked 
> three questions on this email, but received a response to only one.
> 
> 
> Dear Greg,
> 
> Sorry to have puzzled you. That was not the intention. The intention was 
> to engage in a technical discussion about an Internet Best Current Practice.
> 
> I understand the “Implementation Status” section is optional, but since 
> Internet documents are (among other things) for interoperability, I 
> kindly request you consider adding that optional section. Besides the 
> one-liner you quoted, RFC 7942 goes into great lengths at explaining the 
> importance of doing so.
> 
> You also mention:
>> Thus I'm puzzled why are you demanding that this optional section be 
>> added to the draft now? Yes, the work on the implementation is ongoing 
>> and when there will be updates, we'll certainly share them with the WG.
>>
>> Regards,
>> Greg
>>
>> On Fri, May 10, 2019 at 7:53 PM Carlos Pignataro (cpignata) 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     Hi, Greg, SFC,
>>
>>     In order to understand the positioning of
>>     draft-ietf-sfc-multi-layer-oam, please find 3 high-level yet very
>>     important questions and associated comments for consideration.
>>
>>     To avoid potential misinterpretation and to be explicit on this
>>     note's intention: this email does not imply interest in this
>>     draft, does not mean support, I have not read the document fully.
>>
>>     SFC Chairs, could we please follow-up on repeated comments made on
>>     the list and track a disposition? These are over a year old, and
>>     part of an adoption call.
>>
>>     draft-ietf-sfc-multi-layer-oam does not reference any other SFC
>>     I-Ds. It does not build upon existing work in progress, and
>>     instead invents a new protocol with RFC8300 as the only Normative
>>     reference from SFC.
>>
>>     https://tools.ietf.org/html/draft-ietf-sfc-oam-framework-06 takes
>>     a holistic approach of including an analysis (selecting only some
>>     section titles):
>>     Question: Can this draft consider existing protocols and gap
>>     performed before re-inventing? Specifically Normatively cite the
>>     SFC OAM Framework and see where reuse is best?
>>
>>
>>     Hows does this draft work with existing OAM functions with
>>     existing implementation, such as
>>     https://tools.ietf.org/html/draft-penno-sfc-trace-03 ? The fact
>>     that the draft is expired does not mean the implementation is uncoded.
>>
>>
>>     Many thanks,
>>
>>     — Carlos Pignataro
>>
>>>     - Joel: if we get an echo request we can't parse, how do we know
>>>     that it is an echo request, and do we have the information to
>>>     return it to the correct source?
>>>     - Greg: we will clarify this in the draft. It has to practical so
>>>     the sender can understand the situation.. We introduced two
>>>     classes of TLVs: mandatory and optional. Will add clearer text.
>>>
>>>     A new TLV, Errored TLVs, introduced to be optionally used to pass
>>>     in an echo reply mandatory TLVs that were not understood because
>>>     either the implementation on the receiver does not support them
>>>     or couldn't parse them correctly.
>>>
>>>     Also, please review the update to the interpretation of O-bit and
>>>     the value of the Next Protocol field to address Adrian's comments
>>>     at the meeting in Bangkok:
>>>     The rules of
>>>     From: <[email-masked] <mailto:[email-masked]>>
>>>     To: <[email-masked] <mailto:[email-masked]>>, Gregory
>>>     Mirsky <[email-masked] <mailto:[email-masked]>>,
>>>     Bhumip Khasnabish <[email-masked] <mailto:[email-masked]>>,
>>>     Wei Meng <[email-masked] <mailto:meng.wei2@zte..com.cn>>,
>>>     Cui(Linda) Wang <[email-masked]
>>>     <mailto:[email-masked]>>
>>>
>>>
>>>
>>>     until the htmlized version and diff are available at
>>>     tools.ietf.org <http://tools.ietf.org/>.
>>>
>>>     The IETF Secretariat
>>>
>>>     [email-masked] <mailto:[email-masked]>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 11 May 2019 03:58:18 +0000

Joel,

In regards to the “Implementation Status” section, I am absolutely OK if the authors intentionally and deliberately choose not to include it and explain the rationale when asked, and clearly OK if there are no implementations.

My concern here is that neither of those two have been answered by an author yet. (1. Are there implementations? 2. What are the reason, many valid, for which an implementation section would not be added to this document) Instead they have been silently dropped twice, once during adoption call.

If you look at the other two questions I posted originally, they speak to a larger concern, which includes:
Q2 - many of these problems are solved with existing protocols, hence refer to the gap analysis in the ohm-framework, which is not even referenced.
Q3 - there are other coded solutions which are being ignored (e.g., trace route)

Best,

— Carlos Pignataro

On May 10, 2019, at 11:48 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:

Not comment on your other questions, and hoping that Greg will engage you in discussion on them, I want to comment on the "implementation section" comment.

There are two aspects to this question.
The first aspect is that you have (and the WG as a whole can) ask "are there implementations?"  I think we all expect authors to answer that question when asked.  The answer will likely end up in the shepherd writeup for the information of the IESG.

Separately, given that it appears that there is not an available implementation at this time, it is not the normal practice to expect that an implementation section be put in a draft highlighting that gap. That is not the expected practice as I understand it for the IETF as a whole, nor is it a practice that the SFC working group has adopted. There is a large difference between making sure that the group is aware of the status and explicitly stating the gap in the I-D.

It is certainly worth while to note, as you do, that there are implementations of some of the other OAM proposals.  I believe (although I do not have the evidence to hand) that those implementations have proven useful in practice, which is important information for the WG. If you have more details on that, I think taht would be good information (I am not asking for an OAM implementations I-D.  Just some email comments.)

Yours,
Joel

Greg wrote:

On May 10, 2019, at 11:14 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:

Hi Carlos,

Regards,
Greg

On Fri, May 10, 2019 at 7:53 PM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:

   Hi, Greg, SFC,

   I asked for an “Implementation Status” Section [RFC7942] at least
   two or three times:

   Instead, this drafts seems to be inventing a full blown protocol
   without implementation practice.

          6.4.1.  ICMP Applicability  . . . . . . . . . . . . . . . .
   .  13

   Many thanks,

   — Carlos Pignataro

   On May 9, 2019, at 1:31 AM, Greg Mirsky <[email-masked]<mailto:[email-masked]>
   <mailto:[email-masked]>> wrote:

   Dear All,
   the update to the draft addresses the comment received from Joel
   at the meeting in Prague:
   - Joel: if we get an echo request we can't parse, how do we know
   that it is an echo request, and do we have the information to
   return it to the correct source?
   - Greg: we will clarify this in the draft. It has to practical so
   the sender can understand the situation.. We introduced two
   classes of TLVs: mandatory and optional. Will add clearer text.

   Also, please review the update to the interpretation of O-bit and
   the value of the Next Protocol field to address Adrian's comments
   at the meeting in Bangkok:
   The rules of
      interpreting the values of O bit and the Next Protocol field
   are as
      follows:

      o  O bit set, and the Next Protocol value is not one of
   identifying
         active or hybrid OAM protocol (per [RFC7799] definitions),
   e.g.,
         defined in this specification Active SFC OAM - a Fixed-Length
         Context Header or Variable-Length Context Header(s) contain OAM
         command or data.  and the type of payload determined by the
   Next
         Protocol field;

      o  O bit is clear and the Next Protocol value is one of
   identifying
         active or hybrid OAM protocol MUST be identified and
   reported as
         the erroneous combination.  An implementation MAY have
   control to
         enable processing of the OAM payload.

      Length Context Header(s) and in the payload immediately
   following the

   Regards,
   Greg

   ---------- Forwarded message ---------
   From: <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
   Date: Wed, May 8, 2019 at 10:21 PM
   Subject: New Version Notification for
   draft-ietf-sfc-multi-layer-oam-03.txt
   To: <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>, Gregory
   Mirsky <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>,
   Bhumip Khasnabish <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>,
   Wei Meng <[email-masked]<mailto:[email-masked]> <mailto:meng.wei2@zte..com.cn<http://com.cn/>>>,
   Cui(Linda) Wang <[email-masked]<mailto:[email-masked]>
   <mailto:[email-masked]>>

   Abstract:
      A set of requirements for active Operation, Administration and
      Maintenance (OAM) of Service Function Chains (SFCs) in networks is
      presented.  Based on these requirements an encapsulation of active
      OAM message in SFC and a mechanism to detect and localize defects
      described.  Also, this document updates RFC 8300 in the
   definition of
      O (OAM) bit in the Network Service Header (NSH) and defines
   how the
      active OAM message identified in SFC NSH.

   Please note that it may take a couple of minutes from the time of
   submission
   until the htmlized version and diff are available at
   tools.ietf.org<http://tools.ietf.org/> <http://tools.ietf.org/>.

   The IETF Secretariat

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 11 May 2019 00:25:19 -0400

It has been suggested (with good reason) that my previous response may 
have been unclear.  So, speaking as chair:

1) Carlos did not demand.  He asked.  Even if Greg disagrees with the 
ask, re-casting it as "demand" was inappropriate.

2) Given that Carlos has made these requests before, timely and clear 
responses from Greg are necessary.  To all of the asks.  Greg, you are 
free to disagree.  But you are not free to ignore.

Yours,
Joel

On 5/10/19 11:34 PM, Carlos Pignataro (cpignata) wrote:
>> added to the draft now?
>> added to the draft now?

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 18 May 2019 13:01:07 -0700

Hi Carlos,
please find responses to your questions in-line and tagged GIM>>.

Regards,
Greg

> Request: Can we please add an “Implementation Status” section?
GIM>> As usual, the implementation status will be reflected in the Shepherd
write-up.

> protocol with RFC8300 as the only Normative reference from SFC.
GIM>> Isn't it a contradiction between your statements
"draft-ietf-sfc-multi-layer-oam does not reference any other SFC I-Ds" and
"RFC8300 as the only Normative reference from SFC"?
On the state of the SFC OAM Framework document. I don't recall a discussion
of the draft at any recent SFC WG meeting. Indeed, there were many updates,
plenty of information added that should be reviewed by the WG. At the same
time, contributions to draft-ietf-sfc-multi-layer-oam are always welcome.
Will be glad to discuss them.

> This analysis ought to guide protocol definition.
GIM>> draft-ietf-sfc-oam-framework has not been discussed by the SFC WG
since even though much of material has been added to it.

> and see where reuse is best?
GIM>> SFC OAM Framework has Informational document track and I don't see a
good reason of making it Normative reference for
draft-ietf-sfc-multi-layer-oam.

> draft is expired does not mean the implementation is uncoded.
GIM>> How it can interwork with something that is not fully documented,
which state is unknown, uncertain? The goal of writing, developing
standards is to ensure interoperability among implementations. If someone
is not committed to the development of their solution for the interoperable
multi-vendor environment, then what we can do in such case? You are the
co-author of the draft and I encourage you to re-start the work, bring to
WG for the discussion.