Subject: Re: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam

From: Greg Mirsky <[email-masked]>
Date: Wed, 15 Dec 2021 17:00:55 -0800

Dear Carlos,
please find my notes below in-line under the GIM2>> tag. Attached is the
diff highlighting two editorial changes.

Regards,
Greg

On Fri, Nov 26, 2021 at 8:18 PM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Dear Greg,
>
> I disagree. My perspective is that they go from not helpful to plain
> harmful.
>
> Let’s look at those three aspects one-by-one (changing the bulleted list
> into a numbered list for ease of tracking):
>
>    1. This is no different than RFC 8300. The O bit specifies the packet
>    being OAM,
>
> GIM2>> I don't know of a definition of an "OAM packet". Even more, RFC
8300 does not refer to any such definition, nor does it provide it.
draft-ietf-sfc-multi-layer-oam clarifies the use of O bit for the active
SFC NSH OAM.

>
>    1. the Next Protocol specifies the type of packet which can be “Active
>    SFC OAM”
>       - Stating however that the identification is based on a combination
>       of fields is incorrect.
>    2. This is not a generic behavior that needs specifying or updating.
>    It is part of the specific NSH Next Protocol value behavior for the NSH
>    Next Protocol being defined as “Active SFC OAM”.
>    3. This is incorrect and a serious over-reach. Specifically:
>       - If the O bit is set and the Next protocol is not “Active SFC
>       OAM”, the definition is much beyond the scope of this document — since this
>       document specifies behaviors for one specific SFC OAM protocol which is
>       “One Active SFC OAM” (name to be narrowscoped as per other pending thread)
>
> GIM2>> I don't see why you re-name the Active SFC OAM protocol into "One
Active SFC OAM". That is not what is in the draft. Are you preparing
another draft that you believe will update draft-ietf-sfc-multi-layer-oam
by introducing an additional active SFC OAM protocol?

>
>    - If the O bit is set and the Next protocol is not “Active SFC OAM”,
>       and this document somehow concludes that the OAM is in the Context Header,
>       then it is:
>          - Breaking other OAM protocols including other Active SFC OAM
>          protocols encapsulated in IPv4, in IPv6, SFC Trace. It is valid to have
>          O=1, NSH NP as IPv4, and an OAM packet encapsulated.
>
> GIM2>> Protocols that use IP/UDP encapsulation are not active SFM OAM
protocols even though they might be used as such. I expect that if the
payload of NSH is an ICMPv6 echo request, the O bit will be cleared and the
Next Protocol set to IPv6 value.

>
>    - Breaking the use of context headers, since they need context that
>          ought to equally apply to OAMs and to data packets, as for example a Flow
>          Label, a Forwarding context, etc. Re-writing Context Headers breaks that.
>
> GIM2>> draft-ietf-sfc-multi-layer-oam does not include any processing that
requires re-writing an NSH Context Header.

>
>
>
> I’d encourage the WG, shepherd, and WG Chairs to more closely inspect and
> review this document, specifically whether is defining one SFC Active OAM
> protocol, or breaking functionality while redefining base RFC 8300 behavior.
>
>
>
> Although these were brought up before, highlighting a couple of comments:
>
>
> 1.  Introduction
>    Also, this document updates Section 2.2 of [RFC8300] in part of the
>    definition of O bit in the NSH.
>
> CMP: I do not see the need to redefine the O bit in the NSH.
>
>
> 4.  Active OAM Identification in the NSH
>    The O bit in the NSH is defined in [RFC8300] as follows:
>       O bit: Setting this bit indicates an OAM packet.
>    This document updates that definition as follows:
>       O bit: Setting this bit indicates an OAM command and/or data in
>       the NSH Context Header or packet payload.
>
> CMP: There is, as shown above, no need for this.
>
GIM2>> As a result of RFC 8300 not providing a reference or definition of
an "OAM packet", this draft addresses that for the case of Active SFC OAM.

>
>    *  O bit set and the "Next Protocol" value does not match the value
>       Active SFC OAM (TBA1), defined in Section 9.1:
>          - An SFC NSH Context Header(s) contain an OAM processing
>          instructions or data.
>
> CMP: As shown above, this 1. breaks functionality (e.g., Flow Label in
> context) and 2. has absolutely *no* need to be included in this specific
> OAM protocol document.
>
GIM2>> If there's no NSH Context Header with OAM processing instruction or
data, then the O bit will not be set. If one or more NSH Context Header
includes OAM processing instructions or data, then, I assume, the O bit
will be set. draft-ietf-sfc-multi-layer-oam does not change that. (I much
appreciate Frank's comments and the discussion that helped clarify that
scenario.)

>
>
> 5.  Active SFC OAM Header
>
>    This document defines Active OAM Header
>    (Figure 2) to demultiplex active OAM protocols on an SFC.
>
> CMP: The identification of OAM protocols is already solved directly in RFC
> 8300 by using the NSH Next Protocol.
> CMP: This meta-header is redundant at best.
>
>       Msg Type - six bits long field identifies OAM protocol, e.g., Echo
>       Request/Reply or Bidirectional Forwarding Detection.
>
> CMP: First, why would BFD be carried as “One SFC Active OAM protocol” ->
> G-ACh-like meta-header with BFD Msg Type?
>
GIM2>> draft-ietf-sfc-multi-layer-oam does not define how BFD to be carried
in NSH environment. Will remove the reference to BFD in the next update.

> CMP: Second, I believe this also explains that what this document is
> defining is the “Echo Request/Reply” Active OAM Protocol.
>
> CMP: Since the name of the active OAM protocol defined in this document is
> "Echo Request/Reply”, could I please request to:
> CMP: 1. Provide a more specific name (since Echo Request/Reply can easily
> be confused with using ICMP)
>
GIM2>> Throughout the document, "Echo Request/Reply" and "SFC Echo
Request/Reply" are used interchangeably. Will add an explicit note to that
in the Terminology section.

> CMP: 2. Rename the title of this document to clearly define its scope for
> one specific SFC Active OAM protocol, by name, and not all Active OAM
> Protocols?
>
GIM2>> The document provides the framework for Active SFC OAM and defines
SFC Echo Request/Reply protocol. I will gladly update the title of the
document, the WG decides that is necessary.

>
>
> Best,
>
> Carlos.
>
> On Nov 26, 2021, at 10:30 PM, Greg Mirsky <[email-masked]> wrote:
>
> Dear Carlos,
> I believe that the proposed new text clarifies several aspects of O bit:
>
>    - active SFC NSH OAM packet is identified by the combination of O bit
>    set and the value of the NSH' Next Protocol field is Active SFC OAM;
>    - the combination of O bit clear and the Next Protocol set to the
>    Active SFC OAM value - erroneous and must be reported;
>    - O bit set and the Next Protocol is not Active SFC OAM - Context
>    Header(s) include OAM processing instructions or data.
>
> Would you agree that these are helpful clarifications?
>
> Regards,
> Greg
>
> On Fri, Nov 26, 2021 at 7:10 PM Carlos Pignataro (cpignata) <
> [email-masked]> wrote:
>
>> Thank you Frank and Greg — what is the actual behavioral change in the
>> proposed redefinition of the O-bit from the processing and rules defined in
>> RFC8300?
>>
>> Thanks,
>>
>> Carlos.
>>
>> On Nov 26, 2021, at 4:09 PM, Frank Brockners (fbrockne) <
>> fbrockne=[email-masked]> wrote:
>>
>> Hi Carlos,
>>
>> Personally I don’t see a strong need to evolve the definition of the
>> O-bit – but if the working group decides to do so, IMHO it would be good to
>> ensure that the O-bit indeed signals the fact that active OAM information
>> related to NSH is carried.
>>
>> Cheers, Frank
>>
>> *From:* Carlos Pignataro (cpignata) <cpignata=[email-masked]>
>>
>> *Sent:* Tuesday, 23 November 2021 15:44
>> *To:* Frank Brockners (fbrockne) <[email-masked]>
>> *Cc:* Greg Mirsky <[email-masked]>; Gyan Mishra <
>> [email-masked]>; James N Guichard <[email-masked]
>> >; [email-masked]; Joel Halpern Direct <[email-masked]>
>> *Subject:* Re: [sfc] Regarding last call for
>> draft-ietf-sfc-multi-layer-oam
>>
>> Frank, Greg,
>>
>> Do you see a reason to redefine the O-bit?
>>
>> Thanks,
>>
>> Carlos.
>>
>>
>> 11/23/21 午前9:33、Frank Brockners (fbrockne) <
>> fbrockne=[email-masked]>のメール:
>>
>> Hi Greg,
>>
>> Thanks for the quick reply. Please see inline.
>>
>> *From:* Greg Mirsky <[email-masked]>
>> *Sent:* Monday, 22 November 2021 23:16
>> *To:* Frank Brockners (fbrockne) <[email-masked]>
>> *Cc:* Carlos Pignataro (cpignata) <cpignata=[email-masked]>;
>> Gyan Mishra <[email-masked]>; James N Guichard <
>> [email-masked]>; [email-masked]; Joel Halpern Direct <
>> [email-masked]>
>> *Subject:* Re: [sfc] Regarding last call for
>> draft-ietf-sfc-multi-layer-oam
>>
>> Hi Frank,
>> thank you for your comment describing an interesting IOAM use case in SFC
>> NSH. I've thought about this case and I have several questions. I greatly
>> appreciate your help clarifying them to me:
>>
>>    - Is it envisioned that the IOAM can be part of NSH payload but not
>>    to immediately follow the SFC NSH? Perhaps such a case can be referred to
>>    as "IOAM inside NSH payload" to differentiate from "IOAM on top of NSH
>>    payload"? For example, assuming that the client payload is IPv6, then NSH
>>    is followed by an IPv6 packet, which, in turn, is followed by IOAM.
>>    - If IOAM inside NSH payload is a viable use case, which SFC element
>>    is the intended addressee - SFF or SF/SF Proxy? If it is the former, what
>>    are the requirements for an SFF to handle this scenario? If it is the
>>    latter, what happens with the client packet if an SF/SF Proxy does  not
>>    support IOAM in NSH but only NSH per RFC 8300?
>>
>> …FB: The scenario that you outline, i.e. NSH over “IPv6 with IOAM
>> encapsulation”, sounds valid to me; and it could even be that NSH would
>> also leverage IOAM, in which case, it would become a case of “IOAM
>> Layering” as described in
>> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-deployment-00#section-7.2.
>> As outlined in the draft-ietf-ippm-ioam-deployment, IOAM-Data-Fields are
>> specific to the layer (and the associated protocol) that they’re
>> encapsulated into. As such, in the case of NSH over “IPv6 with IOAM
>> encapsulation” it would be the IPv6 forwarder that would handle the IOAM
>> processing. SFF/SF would be orthogonal/ships-in-the night.
>> I've looked through draft-ietf-sfc-ioam-nsh but I couldn't find answers
>> to these questions (I admit, I could have missed it).
>> Also, I think that your suggestion to avoid any reference to a hybrid OAM
>> protocol concentrating on the active OAM identification in the update to
>> O-bit definition is logical and reasonable. Below, please find the proposed
>> update:
>> OLD TEXT:
>>    *  O bit set and the "Next Protocol" value does not match one of
>>       identifying active or hybrid OAM protocols (per classification
>>       defined in [RFC7799]), e.g., defined in Section 9.1 Active SFC OAM
>>       (TBA1).
>>
>>          - a Fixed-Length Context Header or Variable-Length Context
>>          Header(s) contain an OAM command or data.
>>
>>          - the "Next Protocol" field determines the type of payload.
>>
>>    *  O bit set and the "Next Protocol" value matches one of identifying
>>       active or hybrid OAM protocols:
>>
>>          - the payload that immediately follows the NSH MUST contain an
>>          OAM command or data.
>>
>>    *  O bit is clear:
>>
>>          - no OAM in a Fixed-Length Context Header or Variable-Length
>>          Context Header(s).
>>
>>          - the payload determined by the "Next Protocol" field MUST be
>>          present.
>>
>>    *  O bit is clear, and the "Next Protocol" field identifies active or
>>       hybrid OAM protocol MUST be identified and reported as an
>>       erroneous combination.  An implementation MAY have control to
>>       enable processing of the OAM payload.
>>
>> NEW TEXT:
>>
>> …FB: The new text looks better. Couple of additional thoughts inline
>> below.
>>
>>    *  O bit set and the "Next Protocol" value does not match defined in
>>       Section 9.1 Active SFC OAM (TBA1).
>>
>> …FB: The above sentence doesn’t sound complete. Likely you wanted to say
>> something like “O bit set and the "Next Protocol" value does not match any
>> of the SFC Next Protocol values define defined in Section 9.1 Active SFC
>> OAM (TBA1).”
>>
>>
>>          - a Fixed-Length Context Header or Variable-Length Context
>>          Header(s) contain an OAM command or data.
>>
>> …FB: Given that it applies to both, fixed and variable – how about
>> simplifying to “Context-header(s) that contain active OAM commands and/or
>> data.”
>>
>>          - the "Next Protocol" field determines the type of payload.
>>
>>    *  O bit set and the "Next Protocol" value matches Active SFC OAM
>>       (TBA1) value:
>>
>>          - the payload that immediately follows the NSH MUST be the
>>          Active OAM Header (Section 5).
>>
>>    *  O bit is clear:
>>
>>          - no OAM in a Fixed-Length Context Header or Variable-Length
>>          Context Header(s).
>> …FB: Similar to the note above, “No Context-header(s) that contain active
>> OAM commands and/or data.” might be simpler
>>
>>          - the payload determined by the "Next Protocol" field MUST be
>>          present.
>>
>> …FB: Isn’t this obvious? The reader might wonder why this is even stated.
>> IMHO we could safely remove this bullet.
>>
>>    *  O bit is clear, and the "Next Protocol" field is set to Active SFC
>>       OAM (TBA1) MUST be identified and reported as an erroneous
>>       combination.  An implementation MAY have control to enable
>>       processing of the OAM payload.
>>
>> …FB: Just cosmetic, but it would be good to stay with the pattern of
>> “condition: action” of this paragraph, e.g.
>>
>> * O but is clear and the "Next Protocol" field is set to Active SFC
>>       OAM (TBA1):
>>
>>    - Erroneous combination. The combination MUST be identified and
>> reported.
>>
>>
>> In addition, what would be good,  is to expand a bit on how that
>> reporting is supposed to happen – as well as what is supposed to happen
>> with the packet that contains the erroneous combination. Is it going to be
>> forwarded or dropped? Is the node detecting the error supposed to remove
>> the active IOAM header, etc., …?
>>
>> Thanks again, Frank
>>
>>
>> I hope that the proposed update addresses your concern.
>>
>> Regards,
>> Greg
>>
>> On Mon, Nov 22, 2021 at 11:56 AM Frank Brockners (fbrockne) <
>> [email-masked]> wrote:
>>
>>
>> Just saw this thread – and the section on the O-bit in section 4 caught
>> might attention.
>>
>>
>>    *  O bit is clear, and the "Next Protocol" field identifies active or
>>
>>       hybrid OAM protocol MUST be identified and reported as an
>>
>>       erroneous combination.  An implementation MAY have control to
>>
>>       enable processing of the OAM payload.
>> Per what is mentioned below, the statement contradicts the principles of
>> IOAM operation. A packet with O-bit cleared can very well have a hybrid OAM
>> protocol in the next protocol field. IOAM is classified as a “Hybrid Type
>> I” protocol per RFC 7799.
>> A key objective of IOAM is to trace packets through the network as if
>> they weren’t observed, i.e., the packet forwarding operation of a packet
>> with IOAM is expected to be that of a plain packet, i.e., a packet without
>> IOAM. Consequently, draft-ietf-sfc-ioam-nsh states clearly that the O-bit
>> isn’t changed when IOAM is added to an NSH-tagged packet:
>> https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2
>>
>> I’d strongly suggest to re-word section 4 to either avoid the reference
>> to “hybrid IOAM” entirely, or to explicitly list which hybrid OAM
>> approaches the section applies to – and that way ensure, that IOAM is not
>> affected. An even simpler approach would be – as discussed below – so
>> simply avoid the redefinition of the O-Bit.
>>
>>
>> Thanks, Frank
>>
>>
>> *From:* sfc <[email-masked]> *On Behalf Of *Carlos Pignataro
>> (cpignata)
>> *Sent:* Monday, 22 November 2021 00:52
>> *To:* Gyan Mishra <[email-masked]>
>> *Cc:* James N Guichard <[email-masked]>; Greg Mirsky <
>> [email-masked]>; [email-masked]; Joel Halpern Direct <
>> [email-masked]>
>> *Subject:* Re: [sfc] Regarding last call for
>> draft-ietf-sfc-multi-layer-oam
>>
>> Hi, Gyan,
>>
>> Thank you for your response!
>>
>> On #1, I recall LIME (I co-chaired), but there’s no “LIME” reference
>> in draft-ietf-sfc-multi-layer-oam, not I see the relationship. The draft
>> you quote on
>> https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02 seems
>> to have expired many years ago.
>>
>> Further, Greg Mirsky wrote that it was for “Historical” reasons. Which
>> one is it?
>>
>> On #2, thanks for suggesting that section to be added. I agree.
>>
>> On #3, thanks for the description of the various sections
>> of draft-ietf-sfc-multi-layer-oam.
>>
>> For the record I still do not see how foundational changes like the O-bit
>> redefinition are needed.
>> While you write that "trace an SFP” is a new functionality, there’s open
>> source running code I-D documented tools which do that.
>>
>> Best,
>>
>> Carlos.
>>
>>
>>
>>
>> 11/20/21 午前10:36、Gyan Mishra <[email-masked]>のメール:
>>
>> Hi Carlos
>>
>> Many Thanks for your feedback
>>
>> Responses in-line
>>
>> On Fri, Nov 19, 2021 at 11:39 PM Carlos Pignataro (cpignata) <
>> [email-masked]> wrote:
>>
>> Dear Gyan,
>>
>> I hope all is well!
>>
>> Could I please ask three short clarifying questions, follow-ons on your
>> statement below?
>>
>> 1. When you write "*with an Active Multi layer OAM model*”, can you
>> please explain what exactly is “Multi layer” about this “OAM model”, and
>> why is important? You highlight it in your top-post but I cannot find that
>> text in the draft.
>>
>> When I asked your co-author Greg Mirsky, he said:
>>
>> Additionally, I wonder: Why the file name “sfc-multi-layer-oam”?
>>
>> GIM>> It is historical.
>>
>> OAM has historic connotations but for good technical reasons as called
>> multi layer as it provides a different job of managing different layers of
>> the network thus the nomenclature “multi layer”
>>
>>
>> We can add some verbiage to the draft as we have the draft and file name
>> with “multi layer” in the name.
>>
>> LIME is a concluded WG on OAM that has discuss the OAM management of the
>> various layers of the network.
>>
>> https://datatracker.ietf.org/wg/lime/about/
>>
>> OPSWG has this draft which hones in on the multi layer OAM aspects of PM
>> and Fault management of SFC.
>> https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02
>>
>> This draft talks about a transport independent OAM where OAM mechanisms
>> are data plane transport dependent thus the concept of multi layer OAM
>> requirements of multiple discrete layers of OAM to map to each layer of the
>> network.  This document also talks about E2E OAM inter layer OAM
>> considerations in SFC as the fault may occur with the service functions at
>> different OSI layers being chained and different  network layers.
>>
>>
>>
>>
>> 2. When you write "*fills a crucial gap for operators*”, are you aware
>> of interoperable implementations (which I expect is what operators need for
>> it to be useful in an actual deployment)? Perhaps an RFC 7942
>> "Implementation Status” section could be added?
>>
>>
>> Gyan> I am not aware of any implementations however Ican review with the
>> authors on adding the section.  Thank you
>>
>>
>>
>> 3. When you write “*for new OAM functionality*”, could you please
>> clearly describe or explicitly enumerate the specific *new* functionality
>> you refer to, on top of what existing OAMs provide, and how you find that
>> crucial, specifically?
>>
>>
>> Troubleshooting SFC is a complex tax for operators and having additional
>> OAM capabilities that can provide value to operators in E2E SFC
>> troubleshooting is a major gain for operators.
>>
>> RFC 8924 defines the base specification for SFC OAM, requirements
>> analysis and generically existing OAM mechanisms used at various layers
>>  and how they can apply to SFC defined in section 7.
>>
>> This draft provides a comprehensive SFC OAM solution and takes the base
>> SFC OAM RFC 8924 and existing network layer mechanisms and applies them to
>> SFC OAM localized SFC fault isolation with a  new Active OAM header,
>> Authenticated Echo Request/Reply message and Source TLV.
>>
>> The new functionality in this draft is defining a new procedure  for
>> Active OAM message on RSP in NSH updating NSH RFC 8300 definition of the O
>> bit which indicates an OAM command and/or data in NSH header or packet
>> payload discussed in section 4.
>>
>> Section 5  talks about the issue related to additional IP/UDP headers in
>> an IPv6 network adds noticeable overhead and this draft defines a new
>> active OAM header to demultiplex Active OAM protocols on an SFC.
>>
>> Section 6 defines a new Active OAM based Authenticated  Echo
>> Request/Reply message for SFC that addresses additional requirements, fate
>> sharing, monitoring of continuity between SFPs, RDI by ingress to egress,
>> connectivity verification, fault localization and tracing to discover RSP
>> and finally on-demand FM with response back to initiator.
>>
>> This draft also provides OAM integrity check with authentication of
>> request/reply message in conjunction with use of source TLV to prevent DDOS
>> attack vector with SFC OAM.
>>
>> The critical new functionality provided for operators with Active OAM is
>> the honed in focus on troubleshooting continuity of an SFP, trace an SFP ,
>> consistency verification of SFP and fault isolation and localizing of a
>> failure within an SFP as well as valuable SFF record TLV, SFF information
>> TLV/Sub-TLV  for multiple SFs as hops of SFP or multiple SFs for load
>> balancing using SFP consistency verification procedures.
>>
>> Many Thanks!!
>>
>> Gyan
>>
>>
>>
>> Many thanks in advance, I am just trying to understand.
>>
>> Best,
>>
>> Carlos.
>>
>>
>>
>> 11/19/21 午後11:02、Gyan Mishra <[email-masked]>のメール:
>>
>>
>>
>> Dear Chairs & All
>>
>> As co-author I support publication of this draft.
>>
>> This specification fills a crucial gap for operators for
>> new OAM functionality, with an Active Multi layer OAM model, by defining
>> extensibility with Active OAM messages, in NSH,  to troubleshoot faults in
>> the data plane SFC forwarding plane, SFP E2E path in the service plane
>> framework.
>>
>> Kind Regards
>>
>> Gyan
>> Verizon
>>
>> On Fri, Nov 19, 2021 at 8:33 PM Carlos Pignataro (cpignata) <cpignata=
>> [email-masked]> wrote:
>>
>> Dear Greg,
>>
>> Thank you for replying to my email. Please find a couple follow-ups
>> inline, as I invite other WG interested parties to the discussion.
>>
>>
>>
>> 11/19/21 午後7:11、Greg Mirsky <[email-masked]>のメール:
>>
>> Dear Carlos,
>> thank you for your thorough review and detailed comments. Please find
>> responses in-lined below under the GIM>> tag.
>>
>> Regards,
>> Greg (on behalf of the authors)
>>
>> On Sat, Nov 13, 2021 at 11:50 PM Carlos Pignataro (cpignata) <
>> [email-masked]> wrote:
>>
>> Hello, WG,
>>
>> In reviewing draft-ietf-sfc-multi-layer-oam-16, I find that the issues
>> listed below are such that I cannot support publication.
>>
>> Observing what appears to be a single non-author response to the original
>> WGLC email, and one more after this extension, I also perceive the energy
>> level to work on this to be low.
>>
>> Please find some review comments and observations, I hope these are
>> useful:
>>
>>
>>
>>                 Active OAM for Service Function Chaining
>>
>>                    draft-ietf-sfc-multi-layer-oam-16
>>
>>
>>
>> Abstract
>>
>>
>>
>>    A set of requirements for active Operation, Administration, and
>>
>>    Maintenance (OAM) of Service Function Chains (SFCs) in a network is
>>
>>    presented in this document.  Based on these requirements, an
>>
>>    encapsulation of active OAM messages in SFC and a mechanism to detect
>>
>>    and localize defects are described.
>>
>>
>> First, a generic comment on the whole document: Even though the WG
>> produces an SFC OAM framework in rfc8924, I cannot find exactly how
>> draft-ietf-sfc-multi-layer-oam follows or maps to such framework.
>>
>>    - rfc8924 lists requirements in S4, but this document mentions them
>>    in passing. Instead, as per the Abstract above, this document creates new
>>    requirements and based on them creates a new OAM protocol.
>>
>> GIM>> We've followed the requirements listed in RFC 8924 and used them
>> when designing SFC Echo Request/Reply. SFC Echo Request/Reply addresses the
>> essential requirements in Section 4 of RFC 8924.
>>
>>
>> CMP: That’s an issue, those are not requirements for a new protocol.
>> Neither for a single protocol to perform all functions.
>>
>> CMP: Specifically, RFC 8924 says:
>>
>>
>> CMP:   “7.  Candidate SFC OAM Tools”
>> CMP: Why were candidates descarted? When it is shown how they can address
>> some of the functions.
>>
>>
>>
>>
>>
>>    - rfc8924 lists candidate SFC OAM tools, but this document does not
>>    consider them. Or compare requirements to options. Perhaps I could be
>>    pointed to the discussion on the list?
>>
>> GIM>> RFC 8924 already provides the analysis and pointed out gaps in
>> listed protocols. RFC 8924 has concluded that none of the available tools
>> complies with the requirements.
>>
>>
>> CMP: I do not see that conclusion in RFC 8924, perhaps you can quote /
>> copy/paste the relevant text. The specific text that includes a conclusion.
>> And specific text that says that none of the tools comply with the
>> requirements.
>>
>> CMP: In any case, there is also no implication that creating a new
>> protocol for all requirements and ignoring the analysis of existing
>> protocols that can be used or extended is in the best interest of SFC’s OAM.
>>
>> CMP: Additionally, I did not see the discussion on the list of this
>> comparison (since it does not exist in the draft).
>>
>>
>>
>>
>> Additionally, I wonder: Why the file name “sfc-multi-layer-oam”?
>>
>> GIM>> It is historical.
>>
>>
>>
>>
>>    Active OAM tools,
>>
>>    conformant to the requirements listed in Section 3, improve, for
>>
>>    example, troubleshooting efficiency and defect localization in SFP
>>
>>    because they specifically address the architectural principles of
>>
>>    NSH.  For that purpose, SFC Echo Request and Echo Reply are specified
>>
>>    in Section 6.
>>
>>
>> I do not fully follow these cause-consequence pair of sentences. They
>> seem to be foundational to the rational of the document, is this why a new
>> OAM protocol is used?
>>
>> GIM>> Indeed. Based on the analysis in RFC 8924, we've learned that none
>> of the available OAM tools can address the requirements for active SFP OAM.
>> The SFC Echo Request/Reply is specifically designed to address these
>> requirements.
>>
>>
>> CMP: This is a very useful response. As I responded above, there’s no
>> implication that if no existing tools address all requirements, the path is
>> to create a brand new one ignoring the existing ones.
>>
>>
>>
>>
>> Specifically, I feel this document over-reaches in that it presumes that
>> the only “Active OAM” protocol for NSH SFCs is this new protocol, whereas
>> some of the existing protocols listed in rfc8924 are also “Active OAM”.
>>
>> GIM>> I think that the document is positioned not as a general active OAM
>> protocol but as one of the active SFC NSH OAM protocols.
>>
>>
>>
>>    This mechanism enables on-demand Continuity Check,
>>
>>    Connectivity Verification, among other operations over SFC in
>>
>>    networks, addresses functionalities discussed in Sections 4.1, 4.2,
>>
>>    and 4.3 of [RFC8924].
>>
>>
>> This could be well the case — however many others (including existing)
>> mechanisms also enable in these broad terms all the
>> connectivity+continuity+trace functions.
>>
>> GIM>> We are not questioning that there are other solutions. But these
>> mechanisms are not supported by specifications that ensure independent
>> interoperable implementations.
>>
>>
>> CMP: Can you please point to independent interoperable implementations
>> of draft-ietf-sfc-multi-layer-oam?
>>
>> CMP: Part of my point is that any partial solution can be extended
>> interoperably.
>>
>>
>>
>> At the same time, this mechanisms is very complex.
>> I would like to see a study of comparative benefits of this added
>> complexity vis-a-vis existing approaches that can be extended.
>>
>> GIM>> In the face of absence of sufficient and up to date documentation
>> describing proprietary solutions, I don't see that any comparison can be
>> comprehensive.
>>
>>
>> CMP: I am not sure if you are answering a different question, but there’s
>> no reference to any proprietary solutions.
>>
>> CMP: ICMP, BFD, iOAM, SFC-Tracceroute, all documented in I-Ds and with
>> open source implementations.
>>
>>
>>
>>
>>
>>
>>    The ingress may be
>>
>>    capable of recovering from the failure, e.g., using redundant SFC
>>
>>    elements.  Thus, it is beneficial for the egress to signal the new
>>
>>    defect state to the ingress, which in this example is the Classifier.
>>
>>    Hence the following requirement:
>>
>>
>>
>>       REQ#3: SFC OAM MUST support Remote Defect Indication notification
>>
>>       by the egress to the ingress.
>>
>>
>> I see a gap between “it is beneficial” and “MUST”. What is "Remote Defect
>> Indication” in the context of SFC OAM since it is not in the OAM framework?
>> Is this "Remote Defect Indication” the only way to achieve the rerouting or
>> redundancy triggering?
>>
>> GIM>> That is one of possible solutions. Other mechanisms may conform to
>> the requirement using different approach.
>>
>>
>>
>>
>> 4.  Active OAM Identification in the NSH
>>
>>
>>
>>    The O bit in the NSH is defined in [RFC8300] as follows:
>>
>>
>>
>>       O bit: Setting this bit indicates an OAM packet.
>>
>>
>>
>>    This document updates that definition as follows:
>>
>>
>>
>>       O bit: Setting this bit indicates an OAM command and/or data in
>>
>>       the NSH Context Header or packet payload.
>>
>>
>>
>>    Active SFC OAM is defined as a combination of OAM commands and/or
>>
>>    data included in a message that immediately follows the NSH.  To
>>
>>    identify the active OAM message, the "Next Protocol" field MUST be
>>
>>    set to Active SFC OAM (TBA1) (Section 9.1).
>>
>>
>> This is an example of over-reach. A “Next Protocol” pointing to IPv4, in
>> turn pointing to ICMP, in turn pointing to Echo is already one example of
>> “Active SFC OAM”. I wonder if this new protocol might be best served by
>> choosing a name that is not so generic? It could be called “One of many
>> active SFC OAM protocols” :-)
>>
>> GIM>> Will clarify that throughout the document "active OAM" and "active
>> SFC OAM" refers to specially constructed packets that immediately follow
>> the SFC Active OAM Header (Figure 2).
>>
>>
>> CMP: The “SFC Active OAM Header” is therefore not part of the “active SFC
>> OAM” packet?
>>
>>
>>
>>
>> Otherwise, the “MUST” in the last sentence seems to not follow.
>>
>>
>>    The rules for
>>
>>    interpreting the values of the O bit and the "Next Protocol" field
>>
>>    are as follows:
>>
>>
>> I am extremely concerned about this attempted re-definition (of the O-bit
>> and Protocol fields). On several fronts as explained below. During RFC8300
>> the WG evaluated these and provided a solution already.
>>
>>
>>    *  O bit set and the "Next Protocol" value does not match one of
>>
>>       identifying active or hybrid OAM protocols (per classification
>>
>>       defined in [RFC7799]), e.g., defined in Section 9.1 Active SFC OAM
>>
>>       (TBA1).
>>
>> This potentially breaks the concept of nodes not understanding OAM (i.e,.
>> Partial deployment of a new protocol)
>>
>> GIM>> Can you clarify what do you mean by "nodes not understanding OAM"?
>> Partial deployment is, in my opinion, an operational issue. An operator
>> plans deployments of new releases according to new features and their
>> intended use.
>>
>>
>> CMP: Apologies, I meant not s/understanding/parsing/.
>>
>> CMP: I agree it is an operational issue — an issue of operations. Like
>> the “O” in “OAM”. Should Operational Considerations be included as well?
>>
>>
>>
>>
>>
>>          - a Fixed-Length Context Header or Variable-Length Context
>>
>>          Header(s) contain an OAM command or data.
>>
>>
>>
>>          - the "Next Protocol" field determines the type of payload.
>>
>> The semantic of Context Headers is outside this definition. For example
>> the types in MD Type 2 define the variable headers.
>>
>> This potentially breaks also OAM, since things like ECMP can be encoded
>> in context headers that the OAM needs. (e.g., "Flow ID”
>> from draft-ietf-sfc-nsh-tlv).
>>
>> GIM>> As I understand it, MD Type 2 Flow ID TLV is recommended to
>> identify a flow in SFC NSH. The document makes the use of this method.
>>
>>
>> CMP: How?
>>
>>
>>
>>
>> Further, is this describing a Hybrid OAM use?
>>
>> GIM>> No, the document does not describe the use of hybrid OAM (per RFC
>> 7799).
>>
>>
>>
>>    *  O bit set and the "Next Protocol" value matches one of identifying
>>
>>       active or hybrid OAM protocols:
>>
>>
>>
>>          - the payload that immediately follows the NSH MUST contain an
>>
>>          OAM command or data.
>>
>> This is also unclear — what is an OAM command or data? If the O-bit is
>> set, it is an OAM packet.
>>
>> GIM>> What is an OAM packet? Is an SFC NSH packet with IOAM an OAM packet
>> or not? If an SFC NSH packet is part of flow under the Alternate Marking,
>> is it an OAM packet because the Alternate Marking method is an example of
>> the hybrid OAM?
>>
>>
>> CMP: This reads like not answering by asking questions.
>>
>> CMP: A user packet with marking, implicitly or explicitly, is not an OAM
>> packet.
>>
>>
>>
>>
>>
>>    *  O bit is clear:
>>
>>
>>
>>          - no OAM in a Fixed-Length Context Header or Variable-Length
>>
>>          Context Header(s).
>>
>>
>>
>>          - the payload determined by the "Next Protocol" field MUST be
>>
>>          present.
>>
>> It is unclear the rational for this.
>>
>> GIM>> Can you please clarify your interpretation, so we can look for ways
>> to improve the text?
>>
>>
>> CMP: Same as above. It is unclear why these rules. It is not a matter of
>> interpretation.
>>
>>
>>
>>
>>
>>    *  O bit is clear, and the "Next Protocol" field identifies active or
>>
>>       hybrid OAM protocol MUST be identified and reported as an
>>
>>       erroneous combination.  An implementation MAY have control to
>>
>>       enable processing of the OAM payload.
>>
>> This seems to break the existing usage in draft-ietf-sfc-ioam-nsh.
>> Section 4.2 of draft-ietf-sfc-ioam-nsh says clearly:
>>
>> GIM>> I don't see any problem. In fact, both definitions are in sync.
>> According to draft-ietf-sfc-ioam-nsh if the Next Protocol field identifies
>> a use data payload, e.g., IPv6, then O bit MUST NOT be set. If the Next
>> Protocol is set to IOAM, then the O-bit MUST be set.
>>
>>
>> CMP: Sorry, but you do not seem to be actually reading
>> draft-ietf-sfc-ioam-nsh. Please refer to:
>>
>> CMP:
>> https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2
>>
>> CMP: 4.2.  IOAM and the use of the NSH O-bit
>>    [RFC8300] defines an "O bit" for OAM packets.  Per [RFC8300] the O
>>    bit must be set for OAM packets and must not be set for non-OAM
>>    packets.  Packets with IOAM data included MUST follow this
>>    definition, i.e. the O bit MUST NOT be set for regular customer
>>    traffic which also carries IOAM data and the O bit MUST be set for
>>    OAM packets which carry only IOAM data without any regular data
>>    payload.
>>
>> CMP: Please note the “MUST NOT” in the paragraph immediately above.
>>
>>
>>
>> We agree in how O-bit works in presence of IOAM that accompanies user
>> data and without it.
>>
>>
>> CMP: I do not see that agreement.
>>
>>
>>
>>
>>
>> 4.2.  IOAM and the use of the NSH O-bit
>>
>>
>>
>>    [RFC8300] defines an "O bit" for OAM packets.  Per [RFC8300] the O
>>
>>    bit must be set for OAM packets and must not be set for non-OAM
>>
>>    packets.  Packets with IOAM data included MUST follow this
>>
>>    definition, i.e. the O bit MUST NOT be set for regular customer
>>
>>    traffic which also carries IOAM data and the O bit MUST be set for
>>
>>    OAM packets which carry only IOAM data without any regular data
>>
>>    payload.
>>
>>
>>
>>
>> 5.  Active SFC OAM Header
>>
>>
>>
>>    As demonstrated in Section 4 [RFC8924] and Section 3 of this
>>
>>    document, SFC OAM is required to perform multiple tasks.  Several
>>
>>    active OAM protocols could be used to address all the requirements.
>>
>>    When IP/UDP encapsulation of an SFC OAM control message is used,
>>
>>    protocols can be demultiplexed using the destination UDP port number.
>>
>>    But extra IP/UDP headers, especially in an IPv6 network, add
>>
>>    noticeable overhead.  This document defines Active OAM Header
>>
>>    (Figure 2) to demultiplex active OAM protocols on an SFC.
>>
>>
>> Does this paragraph imply that the main reason for this protocol is this
>> perceived overhead? If so, experience seems to show that in practice
>> IP-encaped OAM works fine (as e.g., for LSP Ping).
>>
>> GIM>> Isn't IP/UDP encapsulation, and IPv6 in particular, is a larger
>> overhead?
>>
>>
>> CMP: I am sorry Greg to call this out, but you are choosing again to not
>> answer the question and instead ask another one.
>>
>> CMP: I am happy to answer: it is larger. It also does not matter. And
>> further it is proven to work in LSP Ping.
>>
>> CMP: My question again: is the whole purpose of this new protocol to be
>> overhead efficient? I am sure there are ways of encasulating that are more
>> overhead-efficient than draft-ietf-sfc-multi-layer-oam.
>>
>>
>>
>>
>> Alternatively, “Next Protocols” could be defined for “raw” existing
>> protocols.
>>
>>
>>       Msg Type - six bits long field identifies OAM protocol, e.g., Echo
>>
>>       Request/Reply or Bidirectional Forwarding Detection.
>>
>>
>> Why does BFD get encapsulated in this new protocol, as opposed to using a
>> “Next Protocol” for it? That looks like unnecessary overhead and
>> indirection.
>>
>> GIM>> Are you proposing assigning different Next Protocol values for
>> every possible active OAM protocol?
>>
>>
>> CMP: I am not proposing anything. I am simply asking a question.
>>
>>
>>
>>
>>
>>       Flags - eight bits long field carries bit flags that define
>>
>>       optional capability and thus processing of the SFC active OAM
>>
>>       control packet, e.g., optional timestamping.
>>
>> Does this timestamp conflict with context header timestamps?
>> E.g., rfc8592 or draft-mymb-sfc-nsh-allocation-timestamp.
>>
>> GIM>> What do you see as a potential conflict?
>>
>>
>> CMP: Two timestamps in different parts of a packet.
>>
>>
>>
>>
>>
>> 6.  Echo Request/Echo Reply for SFC
>>
>>
>>
>>    Echo Request/Reply is a well-known active OAM mechanism extensively
>>
>>    used to verify a path's continuity, detect inconsistencies between a
>>
>>    state in control and the data planes, and localize defects in the
>>
>>    data plane.  ICMP ([RFC0792] for IPv4 and [RFC4443] for IPv6
>>
>>    networks, respectively) and [RFC8029] are examples of broadly used
>>
>>    active OAM protocols based on the Echo Request/Reply principle.  The
>>
>>    SFC Echo Request/Reply defined in this document addresses several
>>
>>    requirements listed in Section 3.  Specifically, it can be used to
>>
>>    check the continuity of an SFP, trace an SFP, or localize the failure
>>
>>    within an SFP.  The SFC Echo Request/Reply control message format is
>>
>>    presented in Figure 3.
>>
>>
>> This seems to be an important paragraph — would be useful to also
>> understand how other existing and broadly used protocols cannot fulfill
>> requirements.
>>
>> GIM>> RFC 8924 already provided a comprehensive analysis and concluded
>> that none of the available tools can fully conform to the requirements
>> listed in Section 4.
>>
>>
>> CMP: As per above, I do not see that conclusion.
>>
>> CMP: And frankly even if that was the case, there’s no implication that
>> using the existing pieces is not sufficient, or that it is not easier to
>> extend the candidate protocols.
>>
>>
>>
>>
>>
>>       Length - two-octet-long field equal to the Value field's length in
>>
>>       octets.
>>
>>
>> There are several nested lengths defined in this document — would be
>> useful to analyze that they do not result in issues such as piggybacking
>> unaccounted data.
>>
>> GIM>> Do you see any scenario when that might be the case?
>>
>>
>>
>> 6.3.1.  Source TLV
>>
>>
>>
>>    Responder to the SFC Echo Request encapsulates the SFC Echo Reply
>>
>>    message in IP/UDP packet if the Reply mode is "Reply via an IPv4/IPv6
>>
>>    UDP Packet".  Because the NSH does not identify the ingress node that
>>
>>    generated the Echo Request, the source ID MUST be included in the
>>
>>    message and used as the IP destination address and destination UDP
>>
>>    port number of the SFC Echo Reply.  The sender of the SFC Echo
>>
>>    Request MUST include an SFC Source TLV (Figure 5).
>>
>>
>> This seems to negate the benefit of less overhead, if the IP/UDP fields
>> are embedded as OAM TLVs.
>>
>> GIM>> Only the Source ID is required, not the whole set of IP and UDP
>> headers.
>>
>>
>> This also seems to be a bit of an invitation for an attack.
>>
>>
>>
>> 6.4.1.  Errored TLVs TLV
>>
>>
>> I wonder at this point if it is easier to use LSP Ping directly instead
>> of re-define it.
>>
>> GIM>> If someone wants to explore that option, of course.
>>
>>
>>
>> 6.5.1.  SFC Reply Path TLV
>>
>> …
>>
>>    *  Service Index: the value for the Service Index field in the NSH of
>>
>>       the SFC Echo Reply message.
>>
>> How is the service index in a reply constructed?
>>
>> GIM>> It is provided by the sender of the SFC Echo Request.
>>
>>
>> CMP: Does this mean it skips hops? Apologies I do not understand.
>>
>>
>>
>>
>>
>>
>> 6.5.3.  SFC Echo Reply Reception
>>
>>
>>
>>    An SFF SHOULD NOT accept SFC Echo Reply unless the received message
>>
>>    passes the following checks:
>>
>>
>>
>>    *  the received SFC Echo Reply is well-formed;
>>
>>
>>
>>    *  it has an outstanding SFC Echo Request sent from the UDP port that
>>
>>       matches destination UDP port number of the received packet;
>>
>>
>> Is the demultiplexing based on UDP, OAM handle, or combination?
>>
>> GIM>> The values of the Sender's Handle and  Sequence Number fields can
>> be used.
>>
>>
>> CMP: I understand several values can be used.
>> CMP: Which one is actually used?
>> CMP: If the Handles and sequences match but not the port?
>>
>>
>>
>>
>>
>> 6.6.  Verification of the SFP Consistency
>>
>>    *  Collect information of the traversed by the CVReq packet SFs and
>>
>>       send it to the ingress SFF as CVRep packet over IP network;
>>
>>
>> What if NSH is not over IP?
>>
>> GIM>> Then the operator will specify another method using the Reply mode.
>>
>>
>> CMP: Sorry that does not answer my question. The text in question is not
>> contextual to a specified reply mode.
>>
>>
>>
>>
>>
>>    SF Type: Two octets long field.  It is defined in [RFC9015] and
>>
>>    indicates the type of SF, e.g., Firewall, Deep Packet Inspection, WAN
>>
>>    optimization controller, etc.
>>
>>
>> Is RFC 9015 a hard dependency to implement this OAM?
>>
>> GIM>> RFC 9015 established the IANA registry of SF Type and any new SF
>> types must be registered.
>>
>>
>>
>>    IANA is requested to assign a new type from the SFC Active OAM
>>
>>    Message Type sub-registry as follows:
>>
>>
>>
>>           +=======+=============================+===============+
>>
>>           | Value |         Description         | Reference     |
>>
>>           +=======+=============================+===============+
>>
>>           | TBA2  | SFC Echo Request/Echo Reply | This document |
>>
>>           +-------+-----------------------------+---------------+
>>
>>
>> Is there a single value for both Request and Reply?
>>
>> GIM>> Yes, it is a single value. Echo Request and Echo Reply are
>> identified in the Message Type field (Figure 3).
>>
>>
>> CMP: Is this document defining a full 64k space for a single value? If so
>> it appears to be wasteful.
>>
>>
>>
>>
>>
>> 9.2.1.  Version in the Active SFC OAM Header
>>
>> 9.3.1.  SFC Echo Request/Reply Version
>>
>>
>> There seems to be a version for the OAM and a version for the msg type.
>> Is this correct? Are they hierarchical versions? Or independent?
>> This seems to overly complicate parsing and compliance.
>>
>> GIM>> All versions are independent.
>>
>>
>> CMP: This seems like an operational unnecessary complexity, in keeping a
>> matrix of supported combination of versions. If there was an Operational
>> Considerations section, this should be included.
>>
>>
>>
>>
>>
>> 9.3.3.  SFC Echo Request/Echo Reply Message Types
>>
>> Does this mean that there’s a protocol number for “Active OAM” with a
>> protocol number for “Request/Reply” with a protocol number for either
>> request or reply?
>>
>> GIM>> These are not all protocol numbers. Only the Active OAM is a new
>> protocol number. Others are message types.
>>
>>
>> CMP: Apologies I was not clear.
>> CMP: The “SFC Active OAM” is actually a "SFC Next Protocol”.
>> CMP: My intention of using “protocol number” is in a generic way. To get
>> to some OAM function, a node needs to recursively parse 3 TLVs. Correct?
>> This seems overly complex.
>>
>>
>>
>>
>>
>>    Values defined for the Return Codes sub-registry are listed in
>>
>>    Table 14.
>>
>>
>> Various values in this table are not defined in the document. The
>> procedures seem lacking.
>>
>> GIM>> Other specifications may define additional code points in the
>> registry.
>>
>>
>> CMP: Thank you. The procedures still seem lacking.
>>
>> CMP: Best,
>>
>> CMP: — Carlos.
>>
>>
>>
>>
>>
>> 9.7.  SF Identifier Types
>>
>> This document seems to be creating a space for identifying SFs — which I
>> thought was mostly outside the scope of OAM to test SFs.
>>
>> GIM>> The registry is of SF Identifiers, not of SF Types (that already
>> exists). Hope that clarifies the issue.
>>
>>
>> Does this further imply that there’s a new requirement to have unique
>> identifiers within the domain for all SFs?
>>
>> I hope these comments and review questions and concerns are useful for
>> the WG discussion and consideration.
>>
>> Thanks,
>>
>> Carlos.
>>
>>
>>
>>
>> Nov 1, 2021 2:50 PM、Joel Halpern Direct <[email-masked]>のメール:
>>
>> I have received a polite request with explanation for delay asking for
>> more time to read and review the subject document.  Given the state of the
>> working group, i want to encourage any and all review.  So I am extending
>> the last call by two additional weeks.
>>
>> Please read and review the document.
>> Also, if you are willing to serve as shepherd for this, please let the
>> chairs know.  (Don't worry if you have not shepherded a document before.
>> The chairs are more than happy to help you with the process.)
>>
>> Thank you,
>> Joel
>>
>> _______________________________________________
>> sfc mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sfc
>>
>>
>> _______________________________________________
>> sfc mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sfc
>>
>> --
>>  <http://www.verizon.com/>
>> *Gyan Mishra*
>> *Network Solutions Architect *
>> *Email [email-masked] <[email-masked]>*
>>
>> *M 301 502-1347*
>>
>>
>>
>>
>> --
>>  <http://www.verizon.com/>
>> *Gyan Mishra*
>> *Network Solutions Architect *
>> *Email [email-masked] <[email-masked]>*
>>
>> *M 301 502-1347*
>>
>>
>>
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 18 Dec 2021 22:41:50 +0000

Dear Greg,

Thank you for the reply — please find inline my follow-ups (to the comments you responded to, even though there’s a few you missed or otherwise skipped)

As dialogue in this thread seem to be getting intertwined and hard to follow, with several weeks between responses, I will let the chairs (I believe there’s no shepherd assigned) track the issues and review comments (not sure if there’s an issue tracker) and take it from here.

Happy Holidays!

12/15/21 午後8:00、Greg Mirsky <[email-masked]<mailto:[email-masked]>>のメール:

Dear Carlos,
please find my notes below in-line under the GIM2>> tag. Attached is the diff highlighting two editorial changes.

Regards,
Greg

On Fri, Nov 26, 2021 at 8:18 PM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Dear Greg,

I disagree. My perspective is that they go from not helpful to plain harmful.

Let’s look at those three aspects one-by-one (changing the bulleted list into a numbered list for ease of tracking):

  1.  This is no different than RFC 8300. The O bit specifies the packet being OAM,

GIM2>> I don't know of a definition of an "OAM packet". Even more, RFC 8300 does not refer to any such definition, nor does it provide it.  draft-ietf-sfc-multi-layer-oam clarifies the use of O bit for the active SFC NSH OAM.

CMP2: I am not sure of the implication of you not knowing that definition, nor do I see this response moving alignment forward.

CMP2: From RFC8300:
CMP2:       The O bit MUST be set for OAM packets and MUST NOT be set for
CMP2:       non-OAM packets.  The O bit MUST NOT be modified along the SFP.

CMP2: And RFC8924 includes “OAM packet” 30 times.

  1.  the Next Protocol specifies the type of packet which can be “Active SFC OAM”
     *   Stating however that the identification is based on a combination of fields is incorrect.
  2.  This is not a generic behavior that needs specifying or updating. It is part of the specific NSH Next Protocol value behavior for the NSH Next Protocol being defined as “Active SFC OAM”.
  3.  This is incorrect and a serious over-reach. Specifically:
     *   If the O bit is set and the Next protocol is not “Active SFC OAM”, the definition is much beyond the scope of this document — since this document specifies behaviors for one specific SFC OAM protocol which is “One Active SFC OAM” (name to be narrowscoped as per other pending thread)

GIM2>> I don't see why you re-name the Active SFC OAM protocol into "One Active SFC OAM". That is not what is in the draft. Are you preparing another draft that you believe will update draft-ietf-sfc-multi-layer-oam by introducing an additional active SFC OAM protocol?

CMP2: My point is that draft-ietf-sfc-multi-layer-oam is not the only Active SFC OAM protocol.
CMP2: RFC8924 includes ICMP, which by simply setting O=1 and NP as IP can be used.

     *   If the O bit is set and the Next protocol is not “Active SFC OAM”, and this document somehow concludes that the OAM is in the Context Header, then it is:
        *   Breaking other OAM protocols including other Active SFC OAM protocols encapsulated in IPv4, in IPv6, SFC Trace. It is valid to have O=1, NSH NP as IPv4, and an OAM packet encapsulated.

GIM2>> Protocols that use IP/UDP encapsulation are not active SFM OAM protocols even though they might be used as such. I expect that if the payload of NSH is an ICMPv6 echo request, the O bit will be cleared and the Next Protocol set to IPv6 value.

CMP2: The first sentence is interesting:
CMP2: 1. please point to a reference that explains that using a specific encapsulation prevents specific functionality.
CMP2: 2. What is a protocol used as active OAM but not being active OAM?
CMP2: Regarding the second sentence, thanks for sharing what you expect — however that is different than what specs write :-) Why would encapsulation dictate the value of the O bit? Take for example BFD encapsulated in IP…

        *   Breaking the use of context headers, since they need context that ought to equally apply to OAMs and to data packets, as for example a Flow Label, a Forwarding context, etc. Re-writing Context Headers breaks that.

GIM2>> draft-ietf-sfc-multi-layer-oam does not include any processing that requires re-writing an NSH Context Header.

CMP2: Your document says the following:
CMP2:          - An SFC NSH Context Header(s) contain an OAM processing
CMP2:          instructions or data.
CMP2: which prevents using context header for spec’ed context header uses.

I’d encourage the WG, shepherd, and WG Chairs to more closely inspect and review this document, specifically whether is defining one SFC Active OAM protocol, or breaking functionality while redefining base RFC 8300 behavior.

1.  Introduction

CMP: There is, as shown above, no need for this.
GIM2>> As a result of RFC 8300 not providing a reference or definition of an "OAM packet", this draft addresses that for the case of Active SFC OAM.

CMP2: Thank you for explaining the rational for the O-bit text in your document.
CMP2: Please search for “OAM packet” in existing RFCs going back to at least 15 years ago.
CMP2: draft-ietf-sfc-multi-layer-oam does not provide the definition (not needed frankly) of what you say needs defining.

CMP: As shown above, this 1. breaks functionality (e.g., Flow Label in context) and 2. has absolutely *no* need to be included in this specific OAM protocol document.
GIM2>> If there's no NSH Context Header with OAM processing instruction or data, then the O bit will not be set. If one or more NSH Context Header includes OAM processing instructions or data, then, I assume, the O bit will be set. draft-ietf-sfc-multi-layer-oam does not change that. (I much appreciate Frank's comments and the discussion that helped clarify that scenario.)

CMP2: Can you please share a reference to OAM in NSH context headers?

5.  Active SFC OAM Header

CMP: The identification of OAM protocols is already solved directly in RFC 8300 by using the NSH Next Protocol.
CMP: This meta-header is redundant at best.

CMP: First, why would BFD be carried as “One SFC Active OAM protocol” -> G-ACh-like meta-header with BFD Msg Type?
GIM2>> draft-ietf-sfc-multi-layer-oam does not define how BFD to be carried in NSH environment. Will remove the reference to BFD in the next update.

CMP2: Whether you remove it from your draft, it is still another SFC Active OAM Protocol.

CMP: Second, I believe this also explains that what this document is defining is the “Echo Request/Reply” Active OAM Protocol.

CMP: Since the name of the active OAM protocol defined in this document is "Echo Request/Reply”, could I please request to:
CMP: 1. Provide a more specific name (since Echo Request/Reply can easily be confused with using ICMP)
GIM2>> Throughout the document, "Echo Request/Reply" and "SFC Echo Request/Reply" are used interchangeably. Will add an explicit note to that in the Terminology section.

CMP2: Whether there’s a global replace, ICMP can still be another SFC Active OAM Protocol.

CMP: 2. Rename the title of this document to clearly define its scope for one specific SFC Active OAM protocol, by name, and not all Active OAM Protocols?
GIM2>> The document provides the framework for Active SFC OAM and defines SFC Echo Request/Reply protocol. I will gladly update the title of the document, the WG decides that is necessary.

CMP2: What you write immediately above does not match the Abstract of draft-ietf-sfc-multi-layer-oam.
CMP2: And again, the only time the word “Framework appears in this draft is as part of the Citation for RFC8924! :-)
CMP2: No other framework needed.
CMP2: The Abstract says “requirements”, "an encapsulation”, "a mechanism to detect and localize defects”… you say now a “framework” and “a protocol”.

Best,

Carlos.

Best,

Carlos.

On Nov 26, 2021, at 10:30 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Dear Carlos,

  *   active SFC NSH OAM packet is identified by the combination of O bit set and the value of the NSH' Next Protocol field is Active SFC OAM;
  *   the combination of O bit clear and the Next Protocol set to the Active SFC OAM value - erroneous and must be reported;
  *   O bit set and the Next Protocol is not Active SFC OAM - Context Header(s) include OAM processing instructions or data.

Regards,
Greg

On Fri, Nov 26, 2021 at 7:10 PM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Thank you Frank and Greg — what is the actual behavioral change in the proposed redefinition of the O-bit from the processing and rules defined in RFC8300?

Thanks,

Carlos.

On Nov 26, 2021, at 4:09 PM, Frank Brockners (fbrockne) <fbrockne=[email-masked]<mailto:fbrockne=[email-masked]>> wrote:

Hi Carlos,

Personally I don’t see a strong need to evolve the definition of the O-bit – but if the working group decides to do so, IMHO it would be good to ensure that the O-bit indeed signals the fact that active OAM information related to NSH is carried.

Cheers, Frank

From: Carlos Pignataro (cpignata) <cpignata=[email-masked]<mailto:cpignata=[email-masked]>>
Sent: Tuesday, 23 November 2021 15:44
To: Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>>
Cc: Greg Mirsky <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>; James N Guichard <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Joel Halpern Direct <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam

Frank, Greg,

Thanks,

Carlos.

11/23/21 午前9:33、Frank Brockners (fbrockne) <fbrockne=[email-masked]<mailto:fbrockne=[email-masked]>>のメール:

Hi Greg,

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: Monday, 22 November 2021 23:16
To: Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>>
Cc: Carlos Pignataro (cpignata) <cpignata=[email-masked]<mailto:cpignata=[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>; James N Guichard <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Joel Halpern Direct <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam

Hi Frank,
thank you for your comment describing an interesting IOAM use case in SFC NSH. I've thought about this case and I have several questions. I greatly appreciate your help clarifying them to me:

  *   Is it envisioned that the IOAM can be part of NSH payload but not to immediately follow the SFC NSH? Perhaps such a case can be referred to as "IOAM inside NSH payload" to differentiate from "IOAM on top of NSH payload"? For example, assuming that the client payload is IPv6, then NSH is followed by an IPv6 packet, which, in turn, is followed by IOAM.
  *   If IOAM inside NSH payload is a viable use case, which SFC element is the intended addressee - SFF or SF/SF Proxy? If it is the former, what are the requirements for an SFF to handle this scenario? If it is the latter, what happens with the client packet if an SF/SF Proxy does  not support IOAM in NSH but only NSH per RFC 8300?

…FB: The scenario that you outline, i.e. NSH over “IPv6 with IOAM encapsulation”, sounds valid to me; and it could even be that NSH would also leverage IOAM, in which case, it would become a case of “IOAM Layering” as described in https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-deployment-00#section-7.2. As outlined in the draft-ietf-ippm-ioam-deployment, IOAM-Data-Fields are specific to the layer (and the associated protocol) that they’re encapsulated into. As such, in the case of NSH over “IPv6 with IOAM encapsulation” it would be the IPv6 forwarder that would handle the IOAM processing. SFF/SF would be orthogonal/ships-in-the night.
I've looked through draft-ietf-sfc-ioam-nsh but I couldn't find answers to these questions (I admit, I could have missed it).
Also, I think that your suggestion to avoid any reference to a hybrid OAM protocol concentrating on the active OAM identification in the update to O-bit definition is logical and reasonable. Below, please find the proposed update:
OLD TEXT:
   *  O bit set and the "Next Protocol" value does not match one of
      identifying active or hybrid OAM protocols (per classification
      defined in [RFC7799]), e.g., defined in Section 9.1 Active SFC OAM
      (TBA1).

   *  O bit is clear:

NEW TEXT:

…FB: The new text looks better. Couple of additional thoughts inline below.

…FB: The above sentence doesn’t sound complete. Likely you wanted to say something like “O bit set and the "Next Protocol" value does not match any of the SFC Next Protocol values define defined in Section 9.1 Active SFC OAM (TBA1).”

…FB: Given that it applies to both, fixed and variable – how about simplifying to “Context-header(s) that contain active OAM commands and/or data.”

   *  O bit is clear:

         - no OAM in a Fixed-Length Context Header or Variable-Length
         Context Header(s).
…FB: Similar to the note above, “No Context-header(s) that contain active OAM commands and/or data.” might be simpler

…FB: Isn’t this obvious? The reader might wonder why this is even stated. IMHO we could safely remove this bullet.

…FB: Just cosmetic, but it would be good to stay with the pattern of “condition: action” of this paragraph, e.g.

   - Erroneous combination. The combination MUST be identified and reported.

In addition, what would be good,  is to expand a bit on how that reporting is supposed to happen – as well as what is supposed to happen with the packet that contains the erroneous combination. Is it going to be forwarded or dropped? Is the node detecting the error supposed to remove the active IOAM header, etc., …?

Thanks again, Frank

Regards,
Greg

On Mon, Nov 22, 2021 at 11:56 AM Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>> wrote:

Just saw this thread – and the section on the O-bit in section 4 caught might attention.

   *  O bit is clear, and the "Next Protocol" field identifies active or
      hybrid OAM protocol MUST be identified and reported as an
      erroneous combination.  An implementation MAY have control to
      enable processing of the OAM payload.
Per what is mentioned below, the statement contradicts the principles of IOAM operation. A packet with O-bit cleared can very well have a hybrid OAM protocol in the next protocol field. IOAM is classified as a “Hybrid Type I” protocol per RFC 7799.
A key objective of IOAM is to trace packets through the network as if they weren’t observed, i.e., the packet forwarding operation of a packet with IOAM is expected to be that of a plain packet, i.e., a packet without IOAM. Consequently, draft-ietf-sfc-ioam-nsh states clearly that the O-bit isn’t changed when IOAM is added to an NSH-tagged packet: https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2

I’d strongly suggest to re-word section 4 to either avoid the reference to “hybrid IOAM” entirely, or to explicitly list which hybrid OAM approaches the section applies to – and that way ensure, that IOAM is not affected. An even simpler approach would be – as discussed below – so simply avoid the redefinition of the O-Bit.

Thanks, Frank

From: sfc <[email-masked]<mailto:[email-masked]>> On Behalf Of Carlos Pignataro (cpignata)
Sent: Monday, 22 November 2021 00:52
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Cc: James N Guichard <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Joel Halpern Direct <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam

Hi, Gyan,

On #1, I recall LIME (I co-chaired), but there’s no “LIME” reference in draft-ietf-sfc-multi-layer-oam, not I see the relationship. The draft you quote on https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02 seems to have expired many years ago.

Further, Greg Mirsky wrote that it was for “Historical” reasons. Which one is it?

On #3, thanks for the description of the various sections of draft-ietf-sfc-multi-layer-oam.

For the record I still do not see how foundational changes like the O-bit redefinition are needed.
While you write that "trace an SFP” is a new functionality, there’s open source running code I-D documented tools which do that.

Best,

Carlos.

11/20/21 午前10:36、Gyan Mishra <[email-masked]<mailto:[email-masked]>>のメール:

Hi Carlos

Responses in-line

On Fri, Nov 19, 2021 at 11:39 PM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Dear Gyan,

I hope all is well!

Could I please ask three short clarifying questions, follow-ons on your statement below?

1. When you write "with an Active Multi layer OAM model”, can you please explain what exactly is “Multi layer” about this “OAM model”, and why is important? You highlight it in your top-post but I cannot find that text in the draft.

When I asked your co-author Greg Mirsky, he said:
Additionally, I wonder: Why the file name “sfc-multi-layer-oam”?
GIM>> It is historical.
OAM has historic connotations but for good technical reasons as called multi layer as it provides a different job of managing different layers of the network thus the nomenclature “multi layer”

We can add some verbiage to the draft as we have the draft and file name with “multi layer” in the name.

LIME is a concluded WG on OAM that has discuss the OAM management of the various layers of the network.

OPSWG has this draft which hones in on the multi layer OAM aspects of PM and Fault management of SFC.
https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02

This draft talks about a transport independent OAM where OAM mechanisms are data plane transport dependent thus the concept of multi layer OAM requirements of multiple discrete layers of OAM to map to each layer of the network.  This document also talks about E2E OAM inter layer OAM considerations in SFC as the fault may occur with the service functions at different OSI layers being chained and different  network layers.

2. When you write "fills a crucial gap for operators”, are you aware of interoperable implementations (which I expect is what operators need for it to be useful in an actual deployment)? Perhaps an RFC 7942 "Implementation Status” section could be added?

Gyan> I am not aware of any implementations however Ican review with the authors on adding the section.  Thank you

3. When you write “for new OAM functionality”, could you please clearly describe or explicitly enumerate the specific *new* functionality you refer to, on top of what existing OAMs provide, and how you find that crucial, specifically?

Troubleshooting SFC is a complex tax for operators and having additional OAM capabilities that can provide value to operators in E2E SFC troubleshooting is a major gain for operators.

RFC 8924 defines the base specification for SFC OAM, requirements analysis and generically existing OAM mechanisms used at various layers  and how they can apply to SFC defined in section 7.

This draft provides a comprehensive SFC OAM solution and takes the base SFC OAM RFC 8924 and existing network layer mechanisms and applies them to SFC OAM localized SFC fault isolation with a  new Active OAM header, Authenticated Echo Request/Reply message and Source TLV.

The new functionality in this draft is defining a new procedure  for Active OAM message on RSP in NSH updating NSH RFC 8300 definition of the O bit which indicates an OAM command and/or data in NSH header or packet payload discussed in section 4.

Section 5  talks about the issue related to additional IP/UDP headers in an IPv6 network adds noticeable overhead and this draft defines a new active OAM header to demultiplex Active OAM protocols on an SFC.

Section 6 defines a new Active OAM based Authenticated  Echo Request/Reply message for SFC that addresses additional requirements, fate sharing, monitoring of continuity between SFPs, RDI by ingress to egress, connectivity verification, fault localization and tracing to discover RSP and finally on-demand FM with response back to initiator.

This draft also provides OAM integrity check with authentication of request/reply message in conjunction with use of source TLV to prevent DDOS attack vector with SFC OAM.

The critical new functionality provided for operators with Active OAM is the honed in focus on troubleshooting continuity of an SFP, trace an SFP , consistency verification of SFP and fault isolation and localizing of a failure within an SFP as well as valuable SFF record TLV, SFF information TLV/Sub-TLV  for multiple SFs as hops of SFP or multiple SFs for load balancing using SFP consistency verification procedures.

Many Thanks!!

Gyan

Best,

Carlos.

11/19/21 午後11:02、Gyan Mishra <[email-masked]<mailto:[email-masked]>>のメール:

Dear Chairs & All

This specification fills a crucial gap for operators for new OAM functionality, with an Active Multi layer OAM model, by defining extensibility with Active OAM messages, in NSH,  to troubleshoot faults in the data plane SFC forwarding plane, SFP E2E path in the service plane framework.

Kind Regards

Gyan
Verizon

On Fri, Nov 19, 2021 at 8:33 PM Carlos Pignataro (cpignata) <cpignata=[email-masked]<mailto:[email-masked]>> wrote:
Dear Greg,

Thank you for replying to my email. Please find a couple follow-ups inline, as I invite other WG interested parties to the discussion.

11/19/21 午後7:11、Greg Mirsky <[email-masked]<mailto:[email-masked]>>のメール:

Dear Carlos,
thank you for your thorough review and detailed comments. Please find responses in-lined below under the GIM>> tag.

Regards,

On Sat, Nov 13, 2021 at 11:50 PM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Hello, WG,

In reviewing draft-ietf-sfc-multi-layer-oam-16, I find that the issues listed below are such that I cannot support publication.

Observing what appears to be a single non-author response to the original WGLC email, and one more after this extension, I also perceive the energy level to work on this to be low.

Please find some review comments and observations, I hope these are useful:

Abstract

First, a generic comment on the whole document: Even though the WG produces an SFC OAM framework in rfc8924, I cannot find exactly how draft-ietf-sfc-multi-layer-oam follows or maps to such framework.

  *   rfc8924 lists requirements in S4, but this document mentions them in passing. Instead, as per the Abstract above, this document creates new requirements and based on them creates a new OAM protocol.

GIM>> We've followed the requirements listed in RFC 8924 and used them when designing SFC Echo Request/Reply. SFC Echo Request/Reply addresses the essential requirements in Section 4 of RFC 8924.

CMP: That’s an issue, those are not requirements for a new protocol. Neither for a single protocol to perform all functions.

CMP:   “7.  Candidate SFC OAM Tools”
CMP: Why were candidates descarted? When it is shown how they can address some of the functions.

  *   rfc8924 lists candidate SFC OAM tools, but this document does not consider them. Or compare requirements to options. Perhaps I could be pointed to the discussion on the list?

GIM>> RFC 8924 already provides the analysis and pointed out gaps in listed protocols. RFC 8924 has concluded that none of the available tools complies with the requirements.

CMP: I do not see that conclusion in RFC 8924, perhaps you can quote / copy/paste the relevant text. The specific text that includes a conclusion. And specific text that says that none of the tools comply with the requirements.

CMP: In any case, there is also no implication that creating a new protocol for all requirements and ignoring the analysis of existing protocols that can be used or extended is in the best interest of SFC’s OAM.

CMP: Additionally, I did not see the discussion on the list of this comparison (since it does not exist in the draft).

   Active OAM tools,

   in Section 6.

I do not fully follow these cause-consequence pair of sentences. They seem to be foundational to the rational of the document, is this why a new OAM protocol is used?
GIM>> Indeed. Based on the analysis in RFC 8924, we've learned that none of the available OAM tools can address the requirements for active SFP OAM. The SFC Echo Request/Reply is specifically designed to address these requirements.

CMP: This is a very useful response. As I responded above, there’s no implication that if no existing tools address all requirements, the path is to create a brand new one ignoring the existing ones.

Specifically, I feel this document over-reaches in that it presumes that the only “Active OAM” protocol for NSH SFCs is this new protocol, whereas some of the existing protocols listed in rfc8924 are also “Active OAM”.
GIM>> I think that the document is positioned not as a general active OAM protocol but as one of the active SFC NSH OAM protocols.

   and 4.3 of [RFC8924].

This could be well the case — however many others (including existing) mechanisms also enable in these broad terms all the connectivity+continuity+trace functions.
GIM>> We are not questioning that there are other solutions. But these mechanisms are not supported by specifications that ensure independent interoperable implementations.

CMP: Can you please point to independent interoperable implementations of draft-ietf-sfc-multi-layer-oam?

CMP: Part of my point is that any partial solution can be extended interoperably.

At the same time, this mechanisms is very complex.
I would like to see a study of comparative benefits of this added complexity vis-a-vis existing approaches that can be extended.
GIM>> In the face of absence of sufficient and up to date documentation describing proprietary solutions, I don't see that any comparison can be comprehensive.

CMP: I am not sure if you are answering a different question, but there’s no reference to any proprietary solutions.

CMP: ICMP, BFD, iOAM, SFC-Tracceroute, all documented in I-Ds and with open source implementations.

   The ingress may be

I see a gap between “it is beneficial” and “MUST”. What is "Remote Defect Indication” in the context of SFC OAM since it is not in the OAM framework? Is this "Remote Defect Indication” the only way to achieve the rerouting or redundancy triggering?
GIM>> That is one of possible solutions. Other mechanisms may conform to the requirement using different approach.

This is an example of over-reach. A “Next Protocol” pointing to IPv4, in turn pointing to ICMP, in turn pointing to Echo is already one example of “Active SFC OAM”. I wonder if this new protocol might be best served by choosing a name that is not so generic? It could be called “One of many active SFC OAM protocols” :-)
GIM>> Will clarify that throughout the document "active OAM" and "active SFC OAM" refers to specially constructed packets that immediately follow the SFC Active OAM Header (Figure 2).

CMP: The “SFC Active OAM Header” is therefore not part of the “active SFC OAM” packet?

   The rules for

   are as follows:

I am extremely concerned about this attempted re-definition (of the O-bit and Protocol fields). On several fronts as explained below. During RFC8300 the WG evaluated these and provided a solution already.

      (TBA1).

This potentially breaks the concept of nodes not understanding OAM (i.e,. Partial deployment of a new protocol)
GIM>> Can you clarify what do you mean by "nodes not understanding OAM"? Partial deployment is, in my opinion, an operational issue. An operator plans deployments of new releases according to new features and their intended use.

CMP: I agree it is an operational issue — an issue of operations. Like the “O” in “OAM”. Should Operational Considerations be included as well?

The semantic of Context Headers is outside this definition. For example the types in MD Type 2 define the variable headers.

This potentially breaks also OAM, since things like ECMP can be encoded in context headers that the OAM needs. (e.g., "Flow ID” from draft-ietf-sfc-nsh-tlv).
GIM>> As I understand it, MD Type 2 Flow ID TLV is recommended to identify a flow in SFC NSH. The document makes the use of this method.

CMP: How?

Further, is this describing a Hybrid OAM use?
GIM>> No, the document does not describe the use of hybrid OAM (per RFC 7799).

         OAM command or data.

This is also unclear — what is an OAM command or data? If the O-bit is set, it is an OAM packet.
GIM>> What is an OAM packet? Is an SFC NSH packet with IOAM an OAM packet or not? If an SFC NSH packet is part of flow under the Alternate Marking, is it an OAM packet because the Alternate Marking method is an example of the hybrid OAM?

CMP: A user packet with marking, implicitly or explicitly, is not an OAM packet.

   *  O bit is clear:

         Context Header(s).

         present.

It is unclear the rational for this.
GIM>> Can you please clarify your interpretation, so we can look for ways to improve the text?

CMP: Same as above. It is unclear why these rules. It is not a matter of interpretation.

This seems to break the existing usage in draft-ietf-sfc-ioam-nsh. Section 4.2 of draft-ietf-sfc-ioam-nsh says clearly:
GIM>> I don't see any problem. In fact, both definitions are in sync. According to draft-ietf-sfc-ioam-nsh if the Next Protocol field identifies a use data payload, e.g., IPv6, then O bit MUST NOT be set. If the Next Protocol is set to IOAM, then the O-bit MUST be set.

CMP: Sorry, but you do not seem to be actually reading draft-ietf-sfc-ioam-nsh. Please refer to:

CMP: https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2

We agree in how O-bit works in presence of IOAM that accompanies user data and without it.

   payload.

5.  Active SFC OAM Header

Does this paragraph imply that the main reason for this protocol is this perceived overhead? If so, experience seems to show that in practice IP-encaped OAM works fine (as e.g., for LSP Ping).
GIM>> Isn't IP/UDP encapsulation, and IPv6 in particular, is a larger overhead?

CMP: I am sorry Greg to call this out, but you are choosing again to not answer the question and instead ask another one.

CMP: I am happy to answer: it is larger. It also does not matter. And further it is proven to work in LSP Ping.

CMP: My question again: is the whole purpose of this new protocol to be overhead efficient? I am sure there are ways of encasulating that are more overhead-efficient than draft-ietf-sfc-multi-layer-oam.

Alternatively, “Next Protocols” could be defined for “raw” existing protocols.

Why does BFD get encapsulated in this new protocol, as opposed to using a “Next Protocol” for it? That looks like unnecessary overhead and indirection.
GIM>> Are you proposing assigning different Next Protocol values for every possible active OAM protocol?

Does this timestamp conflict with context header timestamps? E.g., rfc8592 or draft-mymb-sfc-nsh-allocation-timestamp.
GIM>> What do you see as a potential conflict?

   presented in Figure 3.

This seems to be an important paragraph — would be useful to also understand how other existing and broadly used protocols cannot fulfill requirements.
GIM>> RFC 8924 already provided a comprehensive analysis and concluded that none of the available tools can fully conform to the requirements listed in Section 4.

CMP: And frankly even if that was the case, there’s no implication that using the existing pieces is not sufficient, or that it is not easier to extend the candidate protocols.

      octets.

There are several nested lengths defined in this document — would be useful to analyze that they do not result in issues such as piggybacking unaccounted data.
GIM>> Do you see any scenario when that might be the case?

6.3.1.  Source TLV

This seems to negate the benefit of less overhead, if the IP/UDP fields are embedded as OAM TLVs.
GIM>> Only the Source ID is required, not the whole set of IP and UDP headers.

6.4.1.  Errored TLVs TLV

I wonder at this point if it is easier to use LSP Ping directly instead of re-define it.
GIM>> If someone wants to explore that option, of course.

…

Is the demultiplexing based on UDP, OAM handle, or combination?
GIM>> The values of the Sender's Handle and  Sequence Number fields can be used.

CMP: Sorry that does not answer my question. The text in question is not contextual to a specified reply mode.

Is RFC 9015 a hard dependency to implement this OAM?
GIM>> RFC 9015 established the IANA registry of SF Type and any new SF types must be registered.

Is there a single value for both Request and Reply?
GIM>> Yes, it is a single value. Echo Request and Echo Reply are identified in the Message Type field (Figure 3).

CMP: Is this document defining a full 64k space for a single value? If so it appears to be wasteful.

There seems to be a version for the OAM and a version for the msg type. Is this correct? Are they hierarchical versions? Or independent?
This seems to overly complicate parsing and compliance.
GIM>> All versions are independent.

CMP: This seems like an operational unnecessary complexity, in keeping a matrix of supported combination of versions. If there was an Operational Considerations section, this should be included.

Does this mean that there’s a protocol number for “Active OAM” with a protocol number for “Request/Reply” with a protocol number for either request or reply?
GIM>> These are not all protocol numbers. Only the Active OAM is a new protocol number. Others are message types.

CMP: Apologies I was not clear.
CMP: The “SFC Active OAM” is actually a "SFC Next Protocol”.
CMP: My intention of using “protocol number” is in a generic way. To get to some OAM function, a node needs to recursively parse 3 TLVs. Correct? This seems overly complex.

   Table 14.

Various values in this table are not defined in the document. The procedures seem lacking.
GIM>> Other specifications may define additional code points in the registry.

CMP: Best,

CMP: — Carlos.

9.7.  SF Identifier Types

This document seems to be creating a space for identifying SFs — which I thought was mostly outside the scope of OAM to test SFs.
GIM>> The registry is of SF Identifiers, not of SF Types (that already exists). Hope that clarifies the issue.

Does this further imply that there’s a new requirement to have unique identifiers within the domain for all SFs?

I hope these comments and review questions and concerns are useful for the WG discussion and consideration.

Thanks,

Carlos.

Nov 1, 2021 2:50 PM、Joel Halpern Direct <[email-masked]<mailto:[email-masked]>>のメール:

I have received a polite request with explanation for delay asking for more time to read and review the subject document.  Given the state of the working group, i want to encourage any and all review.  So I am extending the last call by two additional weeks.

Please read and review the document.
Also, if you are willing to serve as shepherd for this, please let the chairs know.  (Don't worry if you have not shepherded a document before.  The chairs are more than happy to help you with the process.)

Thank you,
Joel

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

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc
--
<http://www.verizon.com/>
Gyan Mishra
Network Solutions Architect
Email [email-masked]<mailto:[email-masked]>
M 301 502-1347

--
<http://www.verizon.com/>
Gyan Mishra
Network Solutions Architect
Email [email-masked]<mailto:[email-masked]>
M 301 502-1347

<Diff_ draft-ietf-sfc-multi-layer-oam-17.txt - draft-ietf-sfc-multi-layer-oam-18.txt.html>

---

From: Joel Halpern Direct <[email-masked]>
Date: Sat, 18 Dec 2021 19:48:53 -0500

Just commenting on one aspect of your note.  I think the definition of 
the SFC NSH header O bit is unclear.  It never occurred to me that one 
would expect an SFC classifier to not that an inncoming packet was 
carrying ICMP, look at the ICMP type, decide it was an OAM packet, and 
set the O bit in the SFC NSH header.  No, nothing in the OAM framework 
prohibits that.  But nothing leads one to expect it either.

Thus, I think it is helpful to clarify the meaning of the O-bit. 
Personally, I rather like saying that the NSH O bit is to indicate the 
presence of OAM for SFFs.  But my personal view is largely irrelevant.

It would be good to hear from others in the working group.

Yours,
Joel

On 12/18/2021 5:41 PM, Carlos Pignataro (cpignata) wrote:
> Dear Greg,
> 
> Thank you for the reply — please find inline my follow-ups (to the 
> comments you responded to, even though there’s a few you missed or 
> otherwise skipped)
> 
> As dialogue in this thread seem to be getting intertwined and hard to 
> follow, with several weeks between responses, I will let the chairs (I 
> believe there’s no shepherd assigned) track the issues and review 
> comments (not sure if there’s an issue tracker)and take it from here.
> 
> Happy Holidays!
> 
>> please find my notes below in-line under the GIM2>> tag. Attached is 
>> the diff highlighting two editorial changes.
>>
>> Regards,
>> Greg
>>
>> On Fri, Nov 26, 2021 at 8:18 PM Carlos Pignataro (cpignata) 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     Dear Greg,
>>
>>     Let’s look at those three aspects one-by-one (changing the
>>     bulleted list into a numbered list for ease of tracking):
>>
>> draft-ietf-sfc-multi-layer-oam clarifies the use of O bit for the 
>> active SFC NSH OAM.
> 
> CMP2: I am not sure of the implication of you not knowing that 
> definition, nor do I see this response moving alignment forward.
> 
> CMP2:From RFC8300:
>>      2. This is not a generic behavior that needs specifying or
>>         updating. It is part of the specific NSH Next Protocol value
>>         behavior for the NSH Next Protocol being defined as “Active
>>         SFC OAM”.
>>           * If the O bit is set and the Next protocol is not “Active
>>             SFC OAM”, the definition is much beyond the scope of this
>>             document — since this document specifies behaviors for one
>>             specific SFC OAM protocol which is “One Active SFC OAM”
>>             (name to be narrowscoped as per other pending thread)
>>
>> GIM2>> I don't see why you re-name the Active SFC OAM protocol into 
>> "One Active SFC OAM". That is not what is in the draft. Are you 
>> preparing another draft that you believe will update 
>> draft-ietf-sfc-multi-layer-oam by introducing an additional active SFC 
>> OAM protocol?
> 
>>           * If the O bit is set and the Next protocol is not “Active
>>             SFC OAM”, and this document somehow concludes that the OAM
>>             is in the Context Header, then it is:
>>               o Breaking other OAM protocols including other Active
>>                 SFC OAM protocols encapsulated in IPv4, in IPv6, SFC
>>                 Trace. It is valid to have O=1, NSH NP as IPv4, and an
>>                 OAM packet encapsulated. 
>>
>> payload of NSH is an ICMPv6 echo request, the O bit will be cleared 
>> and the Next Protocol set to IPv6 value.
> 
> CMP2: 1. please point to a reference that explains that using a specific 
> encapsulation prevents specific functionality.
> CMP2: Regarding the second sentence, thanks for sharing what you expect 
> — however that is different than what specs write :-) Why would 
> encapsulation dictate the value of the O bit? Take for example BFD 
> encapsulated in IP…
> 
>>               o Breaking the use of context headers, since they need
>>                 context that ought to equally apply to OAMs and to
>>                 data packets, as for example a Flow Label, a
>>                 Forwarding context, etc. Re-writing Context Headers
>>                 breaks that.
>>
>> GIM2>> draft-ietf-sfc-multi-layer-oam does not include any processing 
>> that requires re-writing an NSH Context Header.
> 
>>     I’d encourage the WG, shepherd, and WG Chairs to more closely
>>     inspect and review this document, specifically whether is defining
>>     one SFC Active OAM protocol, or breaking functionality while
>>     redefining base RFC 8300 behavior.
>>
>>
>>
>> GIM2>> As a result of RFC 8300 not providing a reference or definition 
>> of an "OAM packet", this draft addresses that for the case of Active 
>> SFC OAM.
> 
> CMP2: draft-ietf-sfc-multi-layer-oam does not provide the definition 
> (not needed frankly) of what you say needs defining.
> 
>>
>>     CMP: As shown above, this 1. breaks functionality (e.g., Flow
>>     Label in context) and 2. has absolutely *no* need to be included
>>     in this specific OAM protocol document.
>>
>> GIM2>> If there's no NSH Context Header with OAM processing 
>> instruction or data, then the O bit will not be set. If one or more 
>> NSH Context Header includes OAM processing instructions or data, then, 
>> I assume, the O bit will be set. draft-ietf-sfc-multi-layer-oam does 
>> not change that. (I much appreciate Frank's comments and the 
>> discussion that helped clarify that scenario.)
> 
>>     CMP: The identification of OAM protocols is already solved
>>     directly in RFC 8300 by using the NSH Next Protocol.
>>     CMP: First, why would BFD be carried as “One SFC Active OAM
>>     protocol” -> G-ACh-like meta-header with BFD Msg Type?
>>
>> GIM2>> draft-ietf-sfc-multi-layer-oam does not define how BFD to be 
>> carried in NSH environment. Will remove the reference to BFD in the 
>> next update.
> 
>>     CMP: Second, I believe this also explains that what this document
>>     is defining is the “Echo Request/Reply” Active OAM Protocol.
>>
>>     CMP: Since the name of the active OAM protocol defined in this
>>     document is "Echo Request/Reply”, could I please request to:
>> Request/Reply" are used interchangeably. Will add an explicit note to 
>> that in the Terminology section.
> 
>>     CMP: 2. Rename the title of this document to clearly define its
>>     scope for one specific SFC Active OAM protocol, by name, and not
>>     all Active OAM Protocols?
>>
>> GIM2>> The document provides the framework for Active SFC OAM and 
>> defines SFC Echo Request/Reply protocol. I will gladly update the 
>> title of the document, the WG decides that is necessary.
> 
> CMP2: And again, the only time the word “Framework appears in this draft 
> is as part of the Citation for RFC8924! :-)
> CMP2: The Abstract says “requirements”, "an encapsulation”, "a mechanism 
> to detect and localize defects”… you say now a “framework” and “a protocol”.
> 
> Best,
> 
> Carlos.
> 
>>
>>
>>     Best,
>>
>>     Carlos.
>>
>>>       * active SFC NSH OAM packet is identified by the combination of
>>>         O bit set and the value of the NSH' Next Protocol field is
>>>         Active SFC OAM;
>>>       * the combination of O bit clear and the Next Protocol set to
>>>         the Active SFC OAM value - erroneous and must be reported;
>>>       * O bit set and the Next Protocol is not Active SFC OAM -
>>>         Context Header(s) include OAM processing instructions or data.
>>>
>>>     On Fri, Nov 26, 2021 at 7:10 PM Carlos Pignataro (cpignata)
>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>         Thank you Frank and Greg — what is the actual behavioral
>>>         change in the proposed redefinition of the O-bit from the
>>>         processing and rules defined in RFC8300?
>>>
>>>         Thanks,
>>>
>>>         Carlos.
>>>
>>>>         On Nov 26, 2021, at 4:09 PM, Frank Brockners (fbrockne)
>>>>         <fbrockne=[email-masked]
>>>>         <mailto:fbrockne=[email-masked]>> wrote:
>>>>
>>>>         Hi Carlos,____
>>>>         __ __
>>>>         Personally I don’t see a strong need to evolve the
>>>>         definition of the O-bit – but if the working group decides
>>>>         to do so, IMHO it would be good to ensure that the O-bit
>>>>         indeed signals the fact that active OAM information related
>>>>         to NSH is carried.____
>>>>         __ __
>>>>         Cheers, Frank____
>>>>         __ __
>>>>         *From:*Carlos Pignataro (cpignata)
>>>>         <cpignata=[email-masked]
>>>>         <mailto:cpignata=[email-masked]>>
>>>>         *Sent:*Tuesday, 23 November 2021 15:44
>>>>         *To:*Frank Brockners (fbrockne) <[email-masked]
>>>>         <mailto:[email-masked]>>
>>>>         *Cc:*Greg Mirsky <[email-masked]
>>>>         <mailto:[email-masked]>>; Gyan Mishra
>>>>         <[email-masked] <mailto:[email-masked]>>;
>>>>         James N Guichard <[email-masked]
>>>>         <mailto:[email-masked]>>;[email-masked]
>>>>         <mailto:[email-masked]>; Joel Halpern Direct
>>>>         <[email-masked] <mailto:[email-masked]>>
>>>>         *Subject:*Re: [sfc] Regarding last call for
>>>>         draft-ietf-sfc-multi-layer-oam____
>>>>         __ __
>>>>         Frank, Greg,____
>>>>         __ __
>>>>         Do you see a reason to redefine the O-bit?____
>>>>         __ __
>>>>         Thanks,____
>>>>         __ __
>>>>         Carlos.____
>>>>
>>>>
>>>>         ____
>>>>
>>>>             11/23/21午前9:33、Frank Brockners (fbrockne)
>>>>             <fbrockne=[email-masked]
>>>>             <mailto:fbrockne=[email-masked]>>のメール:____
>>>>             __ __
>>>>             Hi Greg,____
>>>>             ____
>>>>             Thanks for the quick reply. Please see inline.____
>>>>             ____
>>>>             *From:*Greg Mirsky <[email-masked]
>>>>             <mailto:[email-masked]>>
>>>>             *Sent:*Monday, 22 November 2021 23:16
>>>>             *To:*Frank Brockners (fbrockne) <[email-masked]
>>>>             <mailto:[email-masked]>>
>>>>             *Cc:*Carlos Pignataro (cpignata)
>>>>             <cpignata=[email-masked]
>>>>             <mailto:cpignata=[email-masked]>>; Gyan
>>>>             Mishra <[email-masked]
>>>>             <mailto:[email-masked]>>; James N Guichard
>>>>             <[email-masked]
>>>>             <mailto:[email-masked]>>;[email-masked]
>>>>             <mailto:[email-masked]>; Joel Halpern Direct
>>>>             <[email-masked]
>>>>             <mailto:[email-masked]>>
>>>>             *Subject:*Re: [sfc] Regarding last call for
>>>>             draft-ietf-sfc-multi-layer-oam____
>>>>             ____
>>>>             Hi Frank,____
>>>>             thank you for your comment describing an interesting
>>>>             IOAM use case in SFC NSH. I've thought about this case
>>>>             and I have several questions. I greatly appreciate your
>>>>             help clarifying them to me:____
>>>>
>>>>               * Is it envisioned that the IOAM can be part of NSH
>>>>                 payload but not to immediately follow the SFC NSH?
>>>>                 Perhaps such a case can be referred to as "IOAM
>>>>                 inside NSH payload" to differentiate from "IOAM on
>>>>                 top of NSH payload"? For example, assuming that the
>>>>                 client payload is IPv6, then NSH is followed by an
>>>>                 IPv6 packet, which, in turn, is followed by IOAM. ____
>>>>               * If IOAM inside NSH payload is a viable use case,
>>>>                 which SFC element is the intended addressee - SFF or
>>>>                 SF/SF Proxy? If it is the former, what are the
>>>>                 requirements for an SFF to handle this scenario? If
>>>>                 it is the latter, what happens with the client
>>>>                 packet if an SF/SF Proxy does  not support IOAM in
>>>>                 NSH but only NSH per RFC 8300?____
>>>>
>>>>             …FB: The scenario that you outline, i.e. NSH over “IPv6
>>>>             with IOAM encapsulation”, sounds valid to me; and it
>>>>             could even be that NSH would also leverage IOAM, in
>>>>             which case, it would become a case of “IOAM Layering” as
>>>>             described
>>>>             inhttps://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-deployment-00#section-7.2
>>>>             <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-deployment-00#section-7.2>.
>>>>             As outlined in the draft-ietf-ippm-ioam-deployment,
>>>>             IOAM-Data-Fields are specific to the layer (and the
>>>>             associated protocol) that they’re encapsulated into. As
>>>>             such, in the case of NSH over “IPv6 with IOAM
>>>>             encapsulation” it would be the IPv6 forwarder that would
>>>>             handle the IOAM processing. SFF/SF would be
>>>>             orthogonal/ships-in-the night.____
>>>>             I've looked through draft-ietf-sfc-ioam-nsh but I
>>>>             couldn't find answers to these questions (I admit, I
>>>>             could have missed it).____
>>>>             Also, I think that your suggestion to avoid any
>>>>             reference to a hybrid OAM protocol concentrating on the
>>>>             active OAM identification in the update to O-bit
>>>>             definition is logical and reasonable. Below, please find
>>>>             the proposed update:____
>>>>             OLD TEXT:____
>>>>                *  O bit set and the "Next Protocol" value does not
>>>>             match one of____
>>>>                   identifying active or hybrid OAM protocols (per
>>>>             classification____
>>>>                   defined in [RFC7799]), e.g., defined in Section
>>>>             9.1 Active SFC OAM____
>>>>                   (TBA1).____
>>>>             ____
>>>>                      - a Fixed-Length Context Header or
>>>>             Variable-Length Context____
>>>>                      Header(s) contain an OAM command or data.____
>>>>             ____
>>>>                      - the "Next Protocol" field determines the type
>>>>             of payload.____
>>>>             ____
>>>>                *  O bit set and the "Next Protocol" value matches
>>>>             one of identifying____
>>>>                   active or hybrid OAM protocols:____
>>>>             ____
>>>>                      - the payload that immediately follows the NSH
>>>>             MUST contain an____
>>>>                      OAM command or data.____
>>>>             ____
>>>>                *  O bit is clear:____
>>>>             ____
>>>>                      - no OAM in a Fixed-Length Context Header or
>>>>             Variable-Length____
>>>>                      Context Header(s).____
>>>>             ____
>>>>                      - the payload determined by the "Next Protocol"
>>>>             field MUST be____
>>>>                      present.____
>>>>             ____
>>>>                *  O bit is clear, and the "Next Protocol" field
>>>>             identifies active or____
>>>>                   hybrid OAM protocol MUST be identified and
>>>>             reported as an____
>>>>                   erroneous combination.  An implementation MAY have
>>>>             control to____
>>>>                   enable processing of the OAM payload.____
>>>>             ____
>>>>             NEW TEXT:____
>>>>             ____
>>>>             …FB: The new text looks better. Couple of additional
>>>>             thoughts inline below.____
>>>>             ____
>>>>                *  O bit set and the "Next Protocol" value does not
>>>>             match defined in____
>>>>                   Section 9.1 Active SFC OAM (TBA1).____
>>>>             ____
>>>>             …FB: The above sentence doesn’t sound complete. Likely
>>>>             you wanted to say something like “O bit set and the
>>>>             "Next Protocol" value does not matchany of the SFC Next
>>>>             Protocol values definedefined in Section 9.1 Active SFC
>>>>             OAM (TBA1).”____
>>>>             ____
>>>>             ____
>>>>                      - a Fixed-Length Context Header or
>>>>             Variable-Length Context____
>>>>                      Header(s) contain an OAM command or data.____
>>>>             ____
>>>>             …FB: Given that it applies to both, fixed and variable –
>>>>             how about simplifying to “Context-header(s) that contain
>>>>             active OAM commands and/or data.”____
>>>>             ____
>>>>                      - the "Next Protocol" field determines the type
>>>>             of payload.____
>>>>             ____
>>>>                *  O bit set and the "Next Protocol" value matches
>>>>             Active SFC OAM____
>>>>                   (TBA1) value:____
>>>>             ____
>>>>                      - the payload that immediately follows the NSH
>>>>             MUST be the____
>>>>                      Active OAM Header (Section 5).____
>>>>             ____
>>>>                *  O bit is clear:____
>>>>             ____
>>>>                      - no OAM in a Fixed-Length Context Header or
>>>>             Variable-Length____
>>>>                      Context Header(s).____
>>>>             …FB: Similar to the note above, “No Context-header(s)
>>>>             that contain active OAM commands and/or data.” might be
>>>>             simpler____
>>>>             ____
>>>>                      - the payload determined by the "Next Protocol"
>>>>             field MUST be____
>>>>                      present.____
>>>>             ____
>>>>             …FB: Isn’t this obvious? The reader might wonder why
>>>>             this is even stated. IMHO we could safely remove this
>>>>             bullet.____
>>>>             ____
>>>>                *  O bit is clear, and the "Next Protocol" field is
>>>>             set to Active SFC____
>>>>                   OAM (TBA1) MUST be identified and reported as an
>>>>             erroneous____
>>>>                   combination.  An implementation MAY have control
>>>>             to enable____
>>>>                   processing of the OAM payload.____
>>>>             ____
>>>>             …FB: Just cosmetic, but it would be good to stay with
>>>>             the pattern of “condition: action” of this paragraph,
>>>>             e.g.____
>>>>             ____
>>>>             * O but is clear andthe "Next Protocol" field is set to
>>>>             Active SFC____
>>>>                   OAM (TBA1):____
>>>>             ____
>>>>             ____
>>>>             In addition, what would be good,  is to expand a bit on
>>>>             how that reporting is supposed to happen – as well as
>>>>             what is supposed to happen with the packet that contains
>>>>             the erroneous combination. Is it going to be forwarded
>>>>             or dropped? Is the node detecting the error supposed to
>>>>             remove the active IOAM header, etc., …?____
>>>>             ____
>>>>             Thanks again, Frank____
>>>>             ____
>>>>             ____
>>>>             I hope that the proposed update addresses your concern.____
>>>>             ____
>>>>             Regards,____
>>>>             Greg____
>>>>             ____
>>>>             On Mon, Nov 22, 2021 at 11:56 AM Frank Brockners
>>>>             (fbrockne) <[email-masked]
>>>>             <mailto:[email-masked]>> wrote:____
>>>>
>>>>                 ____
>>>>                 Just saw this thread – and the section on the O-bit
>>>>                 in section 4 caught might attention.____
>>>>                 ____
>>>>
>>>>                    *  O bit is clear, and the "Next Protocol" field
>>>>                 identifies active or____
>>>>
>>>>                       hybrid OAM protocol MUST be identified and
>>>>                 reported as an____
>>>>
>>>>                       erroneous combination.  An implementation MAY
>>>>                 have control to____
>>>>
>>>>                       enable processing of the OAM payload.____
>>>>
>>>>                 Per what is mentioned below, the statement
>>>>                 contradicts the principles of IOAM operation. A
>>>>                 packet with O-bit cleared can very well have a
>>>>                 hybrid OAM protocol in the next protocol field. IOAM
>>>>                 is classified as a “Hybrid Type I” protocol per RFC
>>>>                 7799.
>>>>                 A key objective of IOAM is to trace packets through
>>>>                 the network as if they weren’t observed, i.e., the
>>>>                 packet forwarding operation of a packet with IOAM is
>>>>                 expected to be that of a plain packet, i.e., a
>>>>                 packet without IOAM. Consequently,
>>>>                 draft-ietf-sfc-ioam-nsh states clearly that the
>>>>                 O-bit isn’t changed when IOAM is added to an
>>>>                 NSH-tagged
>>>>                 packet:https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2
>>>>                 <https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2>____
>>>>                 ____
>>>>                 I’d strongly suggest to re-word section 4 to either
>>>>                 avoid the reference to “hybrid IOAM” entirely, or to
>>>>                 explicitly list which hybrid OAM approaches the
>>>>                 section applies to – and that way ensure, that IOAM
>>>>                 is not affected. An even simpler approach would be –
>>>>                 as discussed below – so simply avoid the
>>>>                 redefinition of the O-Bit.____
>>>>                 ____
>>>>
>>>>                 Thanks, Frank____
>>>>
>>>>                 ____
>>>>                 ____
>>>>                 *From:*sfc <[email-masked]
>>>>                 <mailto:[email-masked]>>*On Behalf Of*Carlos
>>>>                 Pignataro (cpignata)
>>>>                 *Sent:*Monday, 22 November 2021 00:52
>>>>                 *To:*Gyan Mishra <[email-masked]
>>>>                 <mailto:[email-masked]>>
>>>>                 *Cc:*James N Guichard
>>>>                 <[email-masked]
>>>>                 <mailto:[email-masked]>>; Greg
>>>>                 Mirsky <[email-masked]
>>>>                 <mailto:[email-masked]>>;[email-masked]
>>>>                 <mailto:[email-masked]>; Joel Halpern Direct
>>>>                 <[email-masked]
>>>>                 <mailto:[email-masked]>>
>>>>                 *Subject:*Re: [sfc] Regarding last call for
>>>>                 draft-ietf-sfc-multi-layer-oam____
>>>>                 ____
>>>>                 Hi, Gyan,____
>>>>                 ____
>>>>                 Thank you for your response!____
>>>>                 ____
>>>>                 On #1, I recall LIME (I co-chaired), but there’s no
>>>>                 “LIME” reference in draft-ietf-sfc-multi-layer-oam,
>>>>                 not I see the relationship. The draft you quote on
>>>>                 <https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02> seems
>>>>                 to have expired many years ago. ____
>>>>                 ____
>>>>                 Further, Greg Mirsky wrote that it was for
>>>>                 “Historical” reasons. Which one is it?____
>>>>                 ____
>>>>                 On #2, thanks for suggesting that section to be
>>>>                 added. I agree.____
>>>>                 ____
>>>>                 On #3, thanks for the description of the various
>>>>                 sections of draft-ietf-sfc-multi-layer-oam.____
>>>>                 ____
>>>>                 For the record I still do not see how foundational
>>>>                 changes like the O-bit redefinition are needed.____
>>>>                 While you write that "trace an SFP” is a new
>>>>                 functionality, there’s open source running code I-D
>>>>                 documented tools which do that.____
>>>>                 ____
>>>>                 Best,____
>>>>                 ____
>>>>                 Carlos.____
>>>>                 ____
>>>>
>>>>                 ____
>>>>
>>>>                     11/20/21午前10:36、Gyan Mishra
>>>>                     <[email-masked]
>>>>                     <mailto:[email-masked]>>のメール:____
>>>>                     ____
>>>>                     Hi Carlos____
>>>>                     ____
>>>>                     Many Thanks for your feedback____
>>>>                     ____
>>>>                     Responses in-line____
>>>>                     ____
>>>>                     On Fri, Nov 19, 2021 at 11:39 PM Carlos
>>>>                     Pignataro (cpignata) <[email-masked]
>>>>                     <mailto:[email-masked]>> wrote:____
>>>>
>>>>                         Dear Gyan,____
>>>>                         ____
>>>>                         I hope all is well!____
>>>>                         ____
>>>>                         Could I please ask three short clarifying
>>>>                         questions, follow-ons on your statement
>>>>                         below?____
>>>>                         ____
>>>>                         1. When you write "/with an
>>>>                         Active Multi layer OAM model/”, can you
>>>>                         please explain what exactly is “Multi layer”
>>>>                         about this “OAM model”, and why is
>>>>                         important? You highlight it in your top-post
>>>>                         but I cannot find that text in the draft.____
>>>>                         ____
>>>>                         When I asked your co-author Greg Mirsky, he
>>>>                         said:____
>>>>
>>>>                                 Additionally, I wonder: Why the file
>>>>                                 name “sfc-multi-layer-oam”?____
>>>>
>>>>                             GIM>> It is historical. ____
>>>>
>>>>                         OAM has historic connotations but for good
>>>>                         technical reasons as called multi layer as
>>>>                         it provides a different job of managing
>>>>                         different layers of the network thus the
>>>>                         nomenclature “multi layer”____
>>>>
>>>>                     ____
>>>>                     We can add some verbiage to the draft as we have
>>>>                     the draft and file name with “multi layer” in
>>>>                     the name.____
>>>>                     ____
>>>>                     LIME is a concluded WG on OAM that has discuss
>>>>                     the OAM management of the various layers of the
>>>>                     network.____
>>>>                     ____
>>>>                     <https://datatracker.ietf.org/wg/lime/about/>____
>>>>                     ____
>>>>                     OPSWG has this draft which hones in on the multi
>>>>                     layer OAM aspects of PM and Fault management of
>>>>                     SFC. ____
>>>>                     <https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02>____
>>>>                     ____
>>>>                     This draft talks about a transport independent
>>>>                     OAM where OAM mechanisms are data plane
>>>>                     transport dependent thus the concept of multi
>>>>                     layer OAM requirements of multiple discrete
>>>>                     layers of OAM to map to each layer of the
>>>>                     network. This document also talks about E2E OAM
>>>>                     inter layer OAM considerations in SFC as the
>>>>                     fault may occur with the service functions at
>>>>                     different OSI layers being chained and different
>>>>                      network layers.____
>>>>                     ____
>>>>                     ____
>>>>
>>>>                         ____
>>>>                         2. When you write "/fills a crucial gap for
>>>>                         operators/”, are you aware of interoperable
>>>>                         implementations (which I expect is what
>>>>                         operators need for it to be useful in an
>>>>                         actual deployment)? Perhaps an RFC 7942
>>>>                         "Implementation Status” section could be
>>>>                         added?____
>>>>
>>>>                     ____
>>>>                     Gyan> I am not aware of any implementations
>>>>                     however Ican review with the authors on adding
>>>>                     the section.  Thank you____
>>>>
>>>>                         ____
>>>>                         ____
>>>>                         3. When you write “/for
>>>>                         new OAM functionality/”, could you please
>>>>                         clearly describe or explicitly enumerate the
>>>>                         specific *new* functionality you refer to,
>>>>                         on top of what existing OAMs provide, and
>>>>                         how you find that crucial, specifically?____
>>>>
>>>>                     ____
>>>>                     Troubleshooting SFC is a complex tax for
>>>>                     operators and having additional OAM capabilities
>>>>                     that can provide value to operators in E2E SFC
>>>>                     troubleshooting is a major gain for operators.____
>>>>                     ____
>>>>                     RFC 8924 defines the base specification for SFC
>>>>                     OAM, requirements analysis and generically
>>>>                     existing OAM mechanisms used at various layers
>>>>                      and how they can apply to SFC defined in
>>>>                     section 7. ____
>>>>                     ____
>>>>                     This draft provides a comprehensive SFC OAM
>>>>                     solution and takes the base SFC OAM RFC 8924 and
>>>>                     existing network layer mechanisms and applies
>>>>                     them to SFC OAM localized SFC fault isolation
>>>>                     with a  new Active OAM header, Authenticated
>>>>                     Echo Request/Reply message and Source TLV. ____
>>>>                     ____
>>>>                     The new functionality in this draft is defining
>>>>                     a new procedure  for Active OAM message on RSP
>>>>                     in NSH updating NSH RFC 8300 definition of the O
>>>>                     bit which indicates an OAM command and/or data
>>>>                     in NSH header or packet payload discussed in
>>>>                     section 4. ____
>>>>                     ____
>>>>                     Section 5  talks about the issue related to
>>>>                     additional IP/UDP headers in an IPv6 network
>>>>                     adds noticeable overhead and this draft defines
>>>>                     a new active OAM header to demultiplex Active
>>>>                     OAM protocols on an SFC.____
>>>>                     ____
>>>>                     Section 6 defines a new Active OAM based
>>>>                     Authenticated  Echo Request/Reply message for
>>>>                     SFC that addresses additional requirements, fate
>>>>                     sharing, monitoring of continuity between SFPs,
>>>>                     RDI by ingress to egress, connectivity
>>>>                     verification, fault localization and tracing to
>>>>                     discover RSP and finally on-demand FM with
>>>>                     response back to initiator. ____
>>>>                     ____
>>>>                     This draft also provides OAM integrity check
>>>>                     with authentication of request/reply message in
>>>>                     conjunction with use of source TLV to prevent
>>>>                     DDOS attack vector with SFC OAM.____
>>>>                     ____
>>>>                     The critical new functionality provided for
>>>>                     operators with Active OAM is the honed in focus
>>>>                     on troubleshooting continuity of an SFP, trace
>>>>                     an SFP , consistency verification of SFP and
>>>>                     fault isolation and localizing of a failure
>>>>                     within an SFP as well as valuable SFF record
>>>>                     TLV, SFF information TLV/Sub-TLV  for multiple
>>>>                     SFs as hops of SFP or multiple SFs for load
>>>>                     balancing using SFP consistency verification
>>>>                     procedures.____
>>>>                     ____
>>>>                     Many Thanks!!____
>>>>                     ____
>>>>                     Gyan____
>>>>
>>>>                         ____
>>>>                         ____
>>>>                         Many thanks in advance, I am just trying to
>>>>                         understand.____
>>>>                         ____
>>>>                         Best,____
>>>>                         ____
>>>>                         Carlos.____
>>>>
>>>>                         ____
>>>>
>>>>                             11/19/21午後11:02、Gyan Mishra
>>>>                             <[email-masked]
>>>>                             <mailto:[email-masked]>>のメール:____
>>>>
>>>>                             ____
>>>>                             ____
>>>>                             Dear Chairs & All ____
>>>>                             ____
>>>>                             As co-author I support publication of
>>>>                             this draft. ____
>>>>                             ____
>>>>                             This specification fills a crucial gap
>>>>                             for operators for new OAM functionality,
>>>>                             with an Active Multi layer OAM model, by
>>>>                             defining extensibility with
>>>>                             Active OAM messages, in NSH,  to
>>>>                             troubleshoot faults in the data
>>>>                             plane SFC forwarding plane, SFP E2E path
>>>>                             in the service plane framework.____
>>>>                             ____
>>>>                             Kind Regards ____
>>>>                             ____
>>>>                             Gyan____
>>>>                             Verizon ____
>>>>                             ____
>>>>                             On Fri, Nov 19, 2021 at 8:33 PM Carlos
>>>>                             Pignataro (cpignata)
>>>>                             <cpignata=[email-masked]
>>>>                             <mailto:[email-masked]>>
>>>>                             wrote:____
>>>>
>>>>                                 Dear Greg,____
>>>>                                 ____
>>>>                                 inline, as I invite other WG
>>>>                                 interested parties to the
>>>>                                 discussion.____
>>>>
>>>>                                 ____
>>>>
>>>>                                     11/19/21午後7:11、Greg Mirsky
>>>>                                     <[email-masked]
>>>>                                     <mailto:[email-masked]>>
>>>>                                     のメール:____
>>>>                                     ____
>>>>                                     Dear Carlos,____
>>>>                                     thank you for your
>>>>                                     thorough review and detailed
>>>>                                     comments. Please find responses
>>>>                                     in-lined below under the GIM>>
>>>>                                     tag.____
>>>>                                     ____
>>>>                                     Regards,____
>>>>                                     Greg (on behalf of the authors)____
>>>>                                     ____
>>>>                                     On Sat, Nov 13, 2021 at 11:50 PM
>>>>                                     Carlos Pignataro (cpignata)
>>>>                                     <[email-masked]
>>>>                                     <mailto:[email-masked]>>
>>>>                                     wrote:____
>>>>
>>>>                                         Hello, WG,____
>>>>                                         ____
>>>>                                         In
>>>>                                         reviewing draft-ietf-sfc-multi-layer-oam-16,
>>>>                                         I find that the issues
>>>>                                         listed below are such that I
>>>>                                         cannot support publication.____
>>>>                                         ____
>>>>                                         Observing what appears to be
>>>>                                         a single non-author response
>>>>                                         to the original WGLC email,
>>>>                                         and one more after this
>>>>                                         extension, I also perceive
>>>>                                         the energy level to work on
>>>>                                         this to be low.____
>>>>                                         ____
>>>>                                         Please find some review
>>>>                                         comments and observations, I
>>>>                                         hope these are useful:____
>>>>                                         ____
>>>>                                         ____
>>>>
>>>>                                                         Active OAM
>>>>                                         for Service Function Chaining____
>>>>
>>>>                                                           
>>>>                                         draft-ietf-sfc-multi-layer-oam-16____
>>>>
>>>>                                         ____
>>>>
>>>>                                         Abstract____
>>>>
>>>>                                         ____
>>>>
>>>>                                            A set of requirements for
>>>>                                         active Operation,
>>>>                                         Administration, and____
>>>>
>>>>                                            Maintenance (OAM) of
>>>>                                         Service Function Chains
>>>>                                         (SFCs) in a network is____
>>>>
>>>>                                            presented in this
>>>>                                         document.  Based on these
>>>>                                         requirements, an____
>>>>
>>>>                                            encapsulation of active
>>>>                                         OAM messages in SFC and a
>>>>                                         mechanism to detect____
>>>>
>>>>                                            and localize defects are
>>>>                                         described.____
>>>>
>>>>                                         ____
>>>>                                         First, a generic comment on
>>>>                                         the whole document: Even
>>>>                                         though the WG produces an
>>>>                                         SFC OAM framework
>>>>                                         in rfc8924, I cannot find
>>>>                                         exactly how
>>>>                                         follows or maps to such
>>>>                                         framework.____
>>>>                                           * rfc8924 lists
>>>>                                             requirements in S4, but
>>>>                                             this document mentions
>>>>                                             them in
>>>>                                             passing. Instead, as per
>>>>                                             the Abstract above, this
>>>>                                             document creates new
>>>>                                             requirements and based
>>>>                                             on them creates a new
>>>>                                             OAM protocol.____
>>>>                                     GIM>> We've followed the
>>>>                                     requirements listed in RFC 8924
>>>>                                     and used them when designing SFC
>>>>                                     Echo Request/Reply. SFC Echo
>>>>                                     Request/Reply addresses the
>>>>                                     essential requirements in
>>>>                                     Section 4 of RFC 8924.____
>>>>
>>>>                                 ____
>>>>                                 Neither for a single protocol to
>>>>                                 perform all functions.____
>>>>                                 ____
>>>>                                 CMP: Specifically, RFC 8924 says:____
>>>>                                 ____
>>>>
>>>>                                 CMP:   “7.  Candidate SFC OAM Tools”____
>>>>
>>>>                                 CMP: Why were candidates descarted?
>>>>                                 When it is shown how they can
>>>>                                 address some of the functions.____
>>>>                                 ____
>>>>
>>>>                                 ____
>>>>
>>>>                                           * rfc8924 lists candidate
>>>>                                             SFC OAM tools, but this
>>>>                                             document does not
>>>>                                             consider them. Or
>>>>                                             compare requirements to
>>>>                                             options. Perhaps I could
>>>>                                             be pointed to the
>>>>                                             discussion on the list?____
>>>>
>>>>                                     GIM>> RFC 8924 already provides
>>>>                                     the analysis and pointed out
>>>>                                     gaps in listed protocols. RFC
>>>>                                     8924 has concluded that none of
>>>>                                     the available tools complies
>>>>                                     with the requirements. ____
>>>>
>>>>                                 ____
>>>>                                 copy/paste the relevant text. The
>>>>                                 specific text that includes a
>>>>                                 conclusion. And specific text that
>>>>                                 says that none of the tools comply
>>>>                                 with the requirements.____
>>>>                                 ____
>>>>                                 protocols that can be used or
>>>>                                 extended is in the best interest of
>>>>                                 SFC’s OAM.____
>>>>                                 ____
>>>>                                 comparison (since it does not exist
>>>>                                 in the draft).____
>>>>
>>>>                                 ____
>>>>
>>>>                                         ____
>>>>                                         Additionally, I wonder: Why
>>>>                                         the file name
>>>>                                         “sfc-multi-layer-oam”?____
>>>>
>>>>                                     GIM>> It is historical. ____
>>>>
>>>>                                         ____
>>>>                                         ____
>>>>
>>>>                                            Active OAM tools,____
>>>>
>>>>                                            conformant to the
>>>>                                         requirements listed in
>>>>                                         Section 3, improve, for____
>>>>
>>>>                                            example, troubleshooting
>>>>                                         efficiency and defect
>>>>                                         localization in SFP____
>>>>
>>>>                                            because they specifically
>>>>                                         address the architectural
>>>>                                         principles of____
>>>>
>>>>                                            NSH.  For that purpose,
>>>>                                         SFC Echo Request and Echo
>>>>                                         Reply are specified____
>>>>
>>>>                                            in Section 6.____
>>>>
>>>>                                         ____
>>>>                                         I do not fully follow these
>>>>                                         cause-consequence pair of
>>>>                                         sentences. They seem to be
>>>>                                         foundational to the rational
>>>>                                         of the document, is this why
>>>>                                         a new OAM protocol is used?____
>>>>
>>>>                                     GIM>> Indeed. Based on the
>>>>                                     analysis in RFC 8924, we've
>>>>                                     learned that none of the
>>>>                                     available OAM tools can address
>>>>                                     the requirements for active SFP
>>>>                                     OAM. The SFC Echo Request/Reply
>>>>                                     is specifically designed to
>>>>                                     address these requirements.____
>>>>
>>>>                                 ____
>>>>                                 implication that if no existing
>>>>                                 tools address all requirements, the
>>>>                                 path is to create a brand new one
>>>>                                 ignoring the existing ones.____
>>>>
>>>>                                 ____
>>>>
>>>>                                         ____
>>>>                                         Specifically, I feel this
>>>>                                         document over-reaches in
>>>>                                         that it presumes that the
>>>>                                         only “Active OAM” protocol
>>>>                                         for NSH SFCs is this new
>>>>                                         protocol, whereas some of
>>>>                                         the existing protocols
>>>>                                         listed in rfc8924 are also
>>>>                                         “Active OAM”.____
>>>>
>>>>                                     GIM>> I think that the document
>>>>                                     is positioned not as a general
>>>>                                     active OAM protocol but as one
>>>>                                     of the active SFC NSH OAM
>>>>                                     protocols.____
>>>>
>>>>                                         ____
>>>>
>>>>                                            This mechanism enables
>>>>                                         on-demand Continuity Check,____
>>>>
>>>>                                            Connectivity
>>>>                                         Verification, among other
>>>>                                         operations over SFC in____
>>>>
>>>>                                            networks, addresses
>>>>                                         functionalities discussed in
>>>>                                         Sections 4.1, 4.2,____
>>>>
>>>>                                            and 4.3 of [RFC8924].____
>>>>
>>>>                                         ____
>>>>                                         This could be well the case
>>>>                                         — however many others
>>>>                                         (including existing)
>>>>                                         connectivity+continuity+trace functions.____
>>>>
>>>>                                     GIM>> We are not questioning
>>>>                                     that there are other solutions.
>>>>                                     But these mechanisms are not
>>>>                                     supported by specifications that
>>>>                                     ensure independent interoperable
>>>>                                     implementations. ____
>>>>
>>>>                                 ____
>>>>                                 CMP: Can you please point to
>>>>                                 independent interoperable
>>>>                                 implementations
>>>>                                 of draft-ietf-sfc-multi-layer-oam?____
>>>>                                 ____
>>>>                                 interoperably.____
>>>>                                 ____
>>>>                                         At the same time, this
>>>>                                         mechanisms is very complex. ____
>>>>                                         I would like to see a study
>>>>                                         of comparative benefits of
>>>>                                         this added complexity
>>>>                                         vis-a-vis existing
>>>>                                         approaches that can be
>>>>                                         extended.____
>>>>
>>>>                                     GIM>> In the face of absence of
>>>>                                     sufficient and up to date
>>>>                                     documentation describing
>>>>                                     proprietary solutions, I don't
>>>>                                     see that any comparison can be
>>>>                                     comprehensive.____
>>>>
>>>>                                 ____
>>>>                                 CMP: I am not sure if you are
>>>>                                 answering a different question, but
>>>>                                 there’s no reference to any
>>>>                                 proprietary solutions.____
>>>>                                 ____
>>>>                                 CMP: ICMP, BFD, iOAM,
>>>>                                 SFC-Tracceroute, all documented in
>>>>                                 I-Ds and with open source
>>>>                                 implementations.____
>>>>
>>>>                                 ____
>>>>
>>>>                                         ____
>>>>                                         ____
>>>>
>>>>                                            The ingress may be____
>>>>
>>>>                                            capable of recovering
>>>>                                         from the failure, e.g.,
>>>>                                         using redundant SFC____
>>>>
>>>>                                            elements.  Thus, it is
>>>>                                         beneficial for the egress to
>>>>                                         signal the new____
>>>>
>>>>                                            defect state to the
>>>>                                         ingress, which in this
>>>>                                         example is the Classifier.____
>>>>
>>>>                                            Hence the following
>>>>                                         requirement:____
>>>>
>>>>                                         ____
>>>>
>>>>                                               REQ#3: SFC OAM MUST
>>>>                                         support Remote Defect
>>>>                                         Indication notification____
>>>>
>>>>                                               by the egress to the
>>>>                                         ingress.____
>>>>
>>>>                                         ____
>>>>                                         I see a gap between “it is
>>>>                                         beneficial” and “MUST”. What
>>>>                                         is "Remote Defect
>>>>                                         Indication” in the context
>>>>                                         of SFC OAM since it is not
>>>>                                         in the OAM framework? Is
>>>>                                         this "Remote Defect
>>>>                                         Indication” the only way to
>>>>                                         achieve the rerouting or
>>>>                                         redundancy triggering?____
>>>>
>>>>                                     GIM>> That is one of possible
>>>>                                     solutions. Other mechanisms may
>>>>                                     conform to the requirement using
>>>>                                     different approach. ____
>>>>
>>>>                                         ____
>>>>                                         ____
>>>>
>>>>                                         4.  Active OAM
>>>>                                         Identification in the NSH____
>>>>
>>>>                                         ____
>>>>
>>>>                                            The O bit in the NSH is
>>>>                                         defined in [RFC8300] as
>>>>                                         follows:____
>>>>
>>>>                                         ____
>>>>
>>>>                                               O bit: Setting this
>>>>                                         bit indicates an OAM packet.____
>>>>
>>>>                                         ____
>>>>
>>>>                                            This document updates
>>>>                                         that definition as follows:____
>>>>
>>>>                                         ____
>>>>
>>>>                                               O bit: Setting this
>>>>                                         bit indicates an OAM command
>>>>                                         and/or data in____
>>>>
>>>>                                               the NSH Context Header
>>>>                                         or packet payload.____
>>>>
>>>>                                         ____
>>>>
>>>>                                            Active SFC OAM is defined
>>>>                                         as a combination of OAM
>>>>                                         commands and/or____
>>>>
>>>>                                            data included in a
>>>>                                         message that immediately
>>>>                                         follows the NSH.  To____
>>>>
>>>>                                            identify the active OAM
>>>>                                         message, the "Next Protocol"
>>>>                                         field MUST be____
>>>>
>>>>                                            set to Active SFC OAM
>>>>                                         (TBA1) (Section 9.1). ____
>>>>
>>>>                                         ____
>>>>                                         This is an example of
>>>>                                         over-reach. A “Next
>>>>                                         Protocol” pointing to IPv4,
>>>>                                         in turn pointing to ICMP, in
>>>>                                         turn pointing to Echo is
>>>>                                         already one example of
>>>>                                         “Active SFC OAM”. I wonder
>>>>                                         if this new protocol might
>>>>                                         be best served by choosing a
>>>>                                         name that is not so generic?
>>>>                                         It could be called “One of
>>>>                                         many active SFC OAM
>>>>                                         protocols” :-) ____
>>>>
>>>>                                     GIM>> Will clarify that
>>>>                                     throughout the document "active
>>>>                                     OAM" and "active SFC OAM" refers
>>>>                                     to specially constructed packets
>>>>                                     that immediately follow the SFC
>>>>                                     Active OAM Header (Figure 2).____
>>>>
>>>>                                 ____
>>>>                                 CMP: The “SFC Active OAM Header” is
>>>>                                 therefore not part of the “active
>>>>                                 SFC OAM” packet?____
>>>>
>>>>                                 ____
>>>>
>>>>                                         ____
>>>>                                         Otherwise, the “MUST” in the
>>>>                                         last sentence seems to not
>>>>                                         follow.____
>>>>                                         ____
>>>>
>>>>                                            The rules for____
>>>>
>>>>                                            interpreting the values
>>>>                                         of the O bit and the "Next
>>>>                                         Protocol" field____
>>>>
>>>>                                            are as follows:____
>>>>
>>>>                                         ____
>>>>                                         I am extremely concerned
>>>>                                         about this attempted
>>>>                                         re-definition (of the O-bit
>>>>                                         and Protocol fields). On
>>>>                                         several fronts as explained
>>>>                                         below. During RFC8300 the WG
>>>>                                         evaluated these and provided
>>>>                                         a solution already.____
>>>>                                         ____
>>>>
>>>>                                            *  O bit set and the
>>>>                                         "Next Protocol" value does
>>>>                                         not match one of____
>>>>
>>>>                                               identifying active or
>>>>                                         hybrid OAM protocols (per
>>>>                                         classification____
>>>>
>>>>                                               defined in [RFC7799]),
>>>>                                         e.g., defined in Section 9.1
>>>>                                         Active SFC OAM____
>>>>
>>>>                                               (TBA1).____
>>>>
>>>>                                         This potentially breaks the
>>>>                                         concept of nodes not
>>>>                                         understanding OAM (i.e,.
>>>>                                         Partial deployment of a new
>>>>                                         protocol)____
>>>>
>>>>                                     GIM>> Can you clarify what do
>>>>                                     you mean by "nodes not
>>>>                                     understanding OAM"? Partial
>>>>                                     deployment is, in my opinion, an
>>>>                                     operational issue. An operator
>>>>                                     plans deployments of new
>>>>                                     releases according to new
>>>>                                     features and their intended use.____
>>>>
>>>>                                 ____
>>>>                                 CMP: Apologies, I meant not
>>>>                                 s/understanding/parsing/.____
>>>>                                 ____
>>>>                                 the “O” in “OAM”. Should Operational
>>>>                                 Considerations be included as well?____
>>>>
>>>>                                 ____
>>>>
>>>>                                         ____
>>>>
>>>>                                                  - a Fixed-Length
>>>>                                         Context Header or
>>>>                                         Variable-Length Context____
>>>>
>>>>                                                  Header(s) contain
>>>>                                         an OAM command or data.____
>>>>
>>>>                                         ____
>>>>
>>>>                                                  - the "Next
>>>>                                         Protocol" field determines
>>>>                                         the type of payload.____
>>>>
>>>>                                         The semantic of Context
>>>>                                         Headers is outside this
>>>>                                         definition. For example the
>>>>                                         types in MD Type 2 define
>>>>                                         the variable headers. ____
>>>>                                         ____
>>>>                                         This potentially breaks also
>>>>                                         OAM, since things like ECMP
>>>>                                         can be encoded in context
>>>>                                         headers that the OAM needs.
>>>>                                         (e.g., "Flow ID”
>>>>                                         from draft-ietf-sfc-nsh-tlv).____
>>>>
>>>>                                     GIM>> As I understand it, MD
>>>>                                     Type 2 Flow ID TLV is
>>>>                                     recommended to identify a flow
>>>>                                     in SFC NSH. The document makes
>>>>                                     the use of this method. ____
>>>>
>>>>                                 ____
>>>>                                 CMP: How?____
>>>>
>>>>                                 ____
>>>>
>>>>                                         ____
>>>>                                         Further, is this describing
>>>>                                         a Hybrid OAM use?____
>>>>
>>>>                                     GIM>> No, the document does not
>>>>                                     describe the use of hybrid OAM
>>>>                                     (per RFC 7799). ____
>>>>
>>>>                                         ____
>>>>
>>>>                                            *  O bit set and the
>>>>                                         "Next Protocol" value
>>>>                                         matches one of identifying____
>>>>
>>>>                                               active or hybrid OAM
>>>>                                         protocols:____
>>>>
>>>>                                         ____
>>>>
>>>>                                                  - the payload that
>>>>                                         immediately follows the NSH
>>>>                                         MUST contain an____
>>>>
>>>>                                                  OAM command or data.____
>>>>
>>>>                                         This is also unclear — what
>>>>                                         is an OAM command or data?
>>>>                                         If the O-bit is set, it is
>>>>                                         an OAM packet.____
>>>>
>>>>                                     GIM>> What is an OAM packet? Is
>>>>                                     an SFC NSH packet with IOAM an
>>>>                                     OAM packet or not? If an SFC NSH
>>>>                                     packet is part of flow under the
>>>>                                     Alternate Marking, is it an OAM
>>>>                                     packet because the Alternate
>>>>                                     Marking method is an example of
>>>>                                     the hybrid OAM? ____
>>>>
>>>>                                 ____
>>>>                                 CMP: This reads like not answering
>>>>                                 by asking questions. ____
>>>>                                 ____
>>>>                                 CMP: A user packet with marking,
>>>>                                 implicitly or explicitly, is not an
>>>>                                 OAM packet.____
>>>>
>>>>                                 ____
>>>>
>>>>                                         ____
>>>>
>>>>                                            *  O bit is clear:____
>>>>
>>>>                                         ____
>>>>
>>>>                                                  - no OAM in a
>>>>                                         Fixed-Length Context Header
>>>>                                         or Variable-Length____
>>>>
>>>>                                                  Context Header(s).____
>>>>
>>>>                                         ____
>>>>
>>>>                                                  - the payload
>>>>                                         determined by the "Next
>>>>                                         Protocol" field MUST be____
>>>>
>>>>                                                  present.____
>>>>
>>>>                                         It is unclear the rational
>>>>                                         for this.____
>>>>
>>>>                                     GIM>> Can you please clarify
>>>>                                     your interpretation, so we can
>>>>                                     look for ways to improve the
>>>>                                     text?____
>>>>
>>>>                                 ____
>>>>                                 CMP: Same as above. It is unclear
>>>>                                 why these rules. It is not a matter
>>>>                                 of interpretation.____
>>>>
>>>>                                 ____
>>>>
>>>>                                         ____
>>>>
>>>>                                            *  O bit is clear, and
>>>>                                         the "Next Protocol" field
>>>>                                         identifies active or____
>>>>
>>>>                                               hybrid OAM protocol
>>>>                                         MUST be identified and
>>>>                                         reported as an____
>>>>
>>>>                                               erroneous
>>>>                                         combination.  An
>>>>                                         implementation MAY have
>>>>                                         control to____
>>>>
>>>>                                               enable processing of
>>>>                                         the OAM payload.____
>>>>
>>>>                                         This seems to break the
>>>>                                         existing usage
>>>>                                         in draft-ietf-sfc-ioam-nsh.
>>>>                                         Section 4.2
>>>>                                         of draft-ietf-sfc-ioam-nsh
>>>>                                         says clearly:____
>>>>
>>>>                                     GIM>> I don't see any problem.
>>>>                                     In fact, both definitions are in
>>>>                                     sync. According to
>>>>                                     draft-ietf-sfc-ioam-nsh if the
>>>>                                     Next Protocol field identifies a
>>>>                                     use data payload, e.g., IPv6,
>>>>                                     then O bit MUST NOT be set. If
>>>>                                     the Next Protocol is set to
>>>>                                     IOAM, then the O-bit MUST be
>>>>                                     set.____
>>>>
>>>>                                 ____
>>>>                                 draft-ietf-sfc-ioam-nsh. Please
>>>>                                 refer to:____
>>>>                                 ____
>>>>                                 CMP:
>>>>                                 <https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2>____
>>>>                                 ____
>>>>                                 CMP: 4.2.  IOAM and the use of the
>>>>                                 NSH O-bit____
>>>>                                    [RFC8300] defines an "O bit" for
>>>>                                 OAM packets.  Per [RFC8300] the O____
>>>>                                    bit must be set for OAM packets
>>>>                                 and must not be set for non-OAM____
>>>>                                    packets.  Packets with IOAM data
>>>>                                 included MUST follow this____
>>>>                                    definition, i.e. the O bit MUST
>>>>                                 NOT be set for regular customer____
>>>>                                    traffic which also carries IOAM
>>>>                                 data and the O bit MUST be set for____
>>>>                                    OAM packets which carry only IOAM
>>>>                                 data without any regular data____
>>>>                                    payload.____
>>>>
>>>>                                 CMP: Please note the “MUST NOT” in
>>>>                                 the paragraph immediately above.____
>>>>
>>>>                                 ____
>>>>
>>>>                                     We agree in how O-bit works in
>>>>                                     presence of IOAM that
>>>>                                     accompanies user data and
>>>>                                     without it.____
>>>>
>>>>                                 ____
>>>>                                 CMP: I do not see that agreement.____
>>>>
>>>>                                 ____
>>>>
>>>>                                         ____
>>>>
>>>>                                         4.2.  IOAM and the use of
>>>>                                         the NSH O-bit____
>>>>
>>>>                                         ____
>>>>
>>>>                                            [RFC8300] defines an "O
>>>>                                         bit" for OAM packets.  Per
>>>>                                         [RFC8300] the O____
>>>>
>>>>                                            bit must be set for OAM
>>>>                                         packets and must not be set
>>>>                                         for non-OAM____
>>>>
>>>>                                            packets.  Packets with
>>>>                                         IOAM data included MUST
>>>>                                         follow this____
>>>>
>>>>                                            definition, i.e. the O
>>>>                                         bit MUST NOT be set for
>>>>                                         regular customer____
>>>>
>>>>                                            traffic which also
>>>>                                         carries IOAM data and the O
>>>>                                         bit MUST be set for____
>>>>
>>>>                                            OAM packets which carry
>>>>                                         only IOAM data without any
>>>>                                         regular data____
>>>>
>>>>                                            payload.____
>>>>
>>>>                                         ____
>>>>                                         ____
>>>>
>>>>                                         5.  Active SFC OAM Header____
>>>>
>>>>                                         ____
>>>>
>>>>                                            As demonstrated in
>>>>                                         Section 4 [RFC8924] and
>>>>                                         Section 3 of this____
>>>>
>>>>                                            document, SFC OAM is
>>>>                                         required to perform multiple
>>>>                                         tasks.  Several____
>>>>
>>>>                                            active OAM protocols
>>>>                                         could be used to address all
>>>>                                         the requirements.____
>>>>
>>>>                                            When IP/UDP encapsulation
>>>>                                         of an SFC OAM control
>>>>                                         message is used,____
>>>>
>>>>                                            protocols can be
>>>>                                         demultiplexed using the
>>>>                                         destination UDP port number.____
>>>>
>>>>                                            But extra IP/UDP headers,
>>>>                                         especially in an IPv6
>>>>                                         network, add____
>>>>
>>>>                                            noticeable overhead. 
>>>>                                         This document defines Active
>>>>                                         OAM Header____
>>>>
>>>>                                            (Figure 2) to demultiplex
>>>>                                         active OAM protocols on an SFC.____
>>>>
>>>>                                         ____
>>>>                                         Does this paragraph imply
>>>>                                         that the main reason for
>>>>                                         this protocol is this
>>>>                                         perceived overhead? If so,
>>>>                                         experience seems to show
>>>>                                         that in practice IP-encaped
>>>>                                         OAM works fine (as e.g., for
>>>>                                         LSP Ping). ____
>>>>
>>>>                                     GIM>> Isn't IP/UDP
>>>>                                     encapsulation, and IPv6 in
>>>>                                     particular, is a larger
>>>>                                     overhead? ____
>>>>
>>>>                                 ____
>>>>                                 CMP: I am sorry Greg to call this
>>>>                                 out, but you are choosing again to
>>>>                                 not answer the question and instead
>>>>                                 ask another one.____
>>>>                                 ____
>>>>                                 further it is proven to work in LSP
>>>>                                 Ping.____
>>>>                                 ____
>>>>                                 overhead efficient? I am sure there
>>>>                                 are ways of encasulating that are
>>>>                                 more overhead-efficient
>>>>                                 than draft-ietf-sfc-multi-layer-oam.____
>>>>
>>>>                                 ____
>>>>
>>>>                                         ____
>>>>                                         Alternatively, “Next
>>>>                                         Protocols” could be defined
>>>>                                         for “raw” existing
>>>>                                         protocols.____
>>>>                                         ____
>>>>
>>>>                                               Msg Type - six bits
>>>>                                         long field identifies OAM
>>>>                                         protocol, e.g., Echo____
>>>>
>>>>                                               Request/Reply or
>>>>                                         Bidirectional Forwarding
>>>>                                         Detection.____
>>>>
>>>>                                         ____
>>>>                                         Why does BFD get
>>>>                                         encapsulated in this new
>>>>                                         protocol, as opposed to
>>>>                                         using a “Next Protocol” for
>>>>                                         it? That looks like
>>>>                                         unnecessary overhead and
>>>>                                         indirection.____
>>>>
>>>>                                     GIM>> Are you proposing
>>>>                                     assigning different Next
>>>>                                     Protocol values for every
>>>>                                     possible active OAM protocol? ____
>>>>
>>>>                                 ____
>>>>                                 CMP: I am not proposing anything. I
>>>>                                 am simply asking a question.____
>>>>
>>>>                                 ____
>>>>
>>>>                                         ____
>>>>
>>>>                                               Flags - eight bits
>>>>                                         long field carries bit flags
>>>>                                         that define____
>>>>
>>>>                                               optional capability
>>>>                                         and thus processing of the
>>>>                                         SFC active OAM____
>>>>
>>>>                                               control packet, e.g.,
>>>>                                         optional timestamping. ____
>>>>
>>>>                                         Does this timestamp conflict
>>>>                                         with context header
>>>>                                         timestamps? E.g., rfc8592
>>>>                                         or draft-mymb-sfc-nsh-allocation-timestamp.____
>>>>
>>>>                                     GIM>> What do you see as a
>>>>                                     potential conflict? ____
>>>>
>>>>                                 ____
>>>>                                 CMP: Two timestamps in different
>>>>                                 parts of a packet.____
>>>>
>>>>                                 ____
>>>>
>>>>                                         ____
>>>>
>>>>                                         6.  Echo Request/Echo Reply
>>>>                                         for SFC____
>>>>
>>>>                                         ____
>>>>
>>>>                                            Echo Request/Reply is a
>>>>                                         well-known active OAM
>>>>                                         mechanism extensively____
>>>>
>>>>                                            used to verify a path's
>>>>                                         continuity, detect
>>>>                                         inconsistencies between a____
>>>>
>>>>                                            state in control and the
>>>>                                         data planes, and localize
>>>>                                         defects in the____
>>>>
>>>>                                            data plane.  ICMP
>>>>                                         ([RFC0792] for IPv4 and
>>>>                                         [RFC4443] for IPv6____
>>>>
>>>>                                            networks, respectively)
>>>>                                         and [RFC8029] are examples
>>>>                                         of broadly used____
>>>>
>>>>                                            active OAM protocols
>>>>                                         based on the Echo
>>>>                                         Request/Reply principle.  The____
>>>>
>>>>                                            SFC Echo Request/Reply
>>>>                                         defined in this document
>>>>                                         addresses several____
>>>>
>>>>                                            requirements listed in
>>>>                                         Section 3.  Specifically, it
>>>>                                         can be used to____
>>>>
>>>>                                            check the continuity of
>>>>                                         an SFP, trace an SFP, or
>>>>                                         localize the failure____
>>>>
>>>>                                            within an SFP.  The SFC
>>>>                                         Echo Request/Reply control
>>>>                                         message format is____
>>>>
>>>>                                            presented in Figure 3.____
>>>>
>>>>                                         ____
>>>>                                         This seems to be an
>>>>                                         important paragraph — would
>>>>                                         be useful to also understand
>>>>                                         how other existing and
>>>>                                         broadly used protocols
>>>>                                         cannot fulfill requirements.____
>>>>
>>>>                                     GIM>> RFC 8924 already provided
>>>>                                     a comprehensive analysis and
>>>>                                     concluded that none of the
>>>>                                     available tools can fully
>>>>                                     conform to the requirements
>>>>                                     listed in Section 4. ____
>>>>
>>>>                                 ____
>>>>                                 CMP: As per above, I do not see that
>>>>                                 conclusion.____
>>>>                                 ____
>>>>                                 CMP: And frankly even if that was
>>>>                                 the case, there’s no implication
>>>>                                 that using the existing pieces is
>>>>                                 not sufficient, or that it is not
>>>>                                 easier to extend the candidate
>>>>                                 protocols.____
>>>>
>>>>                                 ____
>>>>
>>>>                                         ____
>>>>
>>>>                                               Length -
>>>>                                         two-octet-long field equal
>>>>                                         to the Value field's length in____
>>>>
>>>>                                              octets.____
>>>>
>>>>                                         ____
>>>>                                         There are several nested
>>>>                                         lengths defined in this
>>>>                                         document — would be useful
>>>>                                         to analyze that they do not
>>>>                                         result in issues such as
>>>>                                         piggybacking unaccounted
>>>>                                         data.____
>>>>
>>>>                                     GIM>> Do you see any scenario
>>>>                                     when that might be the case? ____
>>>>
>>>>                                         ____
>>>>
>>>>                                         6.3.1.  Source TLV____
>>>>
>>>>                                         ____
>>>>
>>>>                                            Responder to the SFC Echo
>>>>                                         Request encapsulates the SFC
>>>>                                         Echo Reply____
>>>>
>>>>                                            message in IP/UDP packet
>>>>                                         if the Reply mode is "Reply
>>>>                                         via an IPv4/IPv6____
>>>>
>>>>                                            UDP Packet".  Because the
>>>>                                         NSH does not identify the
>>>>                                         ingress node that____
>>>>
>>>>                                            generated the Echo
>>>>                                         Request, the source ID MUST
>>>>                                         be included in the____
>>>>
>>>>                                            message and used as the
>>>>                                         IP destination address and
>>>>                                         destination UDP____
>>>>
>>>>                                            port number of the SFC
>>>>                                         Echo Reply.  The sender of
>>>>                                         the SFC Echo____
>>>>
>>>>                                            Request MUST include an
>>>>                                         SFC Source TLV (Figure 5).____
>>>>
>>>>                                         ____
>>>>                                         This seems to negate the
>>>>                                         benefit of less overhead, if
>>>>                                         the IP/UDP fields are
>>>>                                         embedded as OAM TLVs.____
>>>>
>>>>                                     GIM>> Only the Source ID is
>>>>                                     required, not the whole set of
>>>>                                     IP and UDP headers. ____
>>>>
>>>>                                         ____
>>>>                                         This also seems to be a bit
>>>>                                         of an invitation for an
>>>>                                         attack.____
>>>>                                         ____
>>>>                                         ____
>>>>
>>>>                                         6.4.1.  Errored TLVs TLV____
>>>>
>>>>                                         ____
>>>>                                         I wonder at this point if it
>>>>                                         is easier to use LSP Ping
>>>>                                         directly instead of
>>>>                                         re-define it.____
>>>>
>>>>                                     GIM>> If someone wants to
>>>>                                     explore that option, of course. ____
>>>>
>>>>                                         ____
>>>>
>>>>                                         6.5.1.  SFC Reply Path TLV____
>>>>
>>>>                                         …____
>>>>
>>>>                                            *  Service Index: the
>>>>                                         value for the Service Index
>>>>                                         field in the NSH of____
>>>>
>>>>                                               the SFC Echo Reply
>>>>                                         message.____
>>>>
>>>>                                         How is the service index in
>>>>                                         a reply constructed?____
>>>>
>>>>                                     GIM>> It is provided by the
>>>>                                     sender of the SFC Echo Request. ____
>>>>
>>>>                                 ____
>>>>                                 CMP: Does this mean it skips hops?
>>>>                                 Apologies I do not understand.____
>>>>
>>>>                                 ____
>>>>
>>>>                                         ____
>>>>                                         ____
>>>>
>>>>                                         6.5.3.  SFC Echo Reply
>>>>                                         Reception____
>>>>
>>>>                                         ____
>>>>
>>>>                                            An SFF SHOULD NOT accept
>>>>                                         SFC Echo Reply unless the
>>>>                                         received message____
>>>>
>>>>                                            passes the following checks:____
>>>>
>>>>                                         ____
>>>>
>>>>                                            *  the received SFC Echo
>>>>                                         Reply is well-formed;____
>>>>
>>>>                                         ____
>>>>
>>>>                                            *  it has an outstanding
>>>>                                         SFC Echo Request sent from
>>>>                                         the UDP port that____
>>>>
>>>>                                               matches destination
>>>>                                         UDP port number of the
>>>>                                         received packet;____
>>>>
>>>>                                         ____
>>>>                                         Is the demultiplexing based
>>>>                                         on UDP, OAM handle, or
>>>>                                         combination?____
>>>>
>>>>                                     GIM>> The values of the Sender's
>>>>                                     Handle and  Sequence Number
>>>>                                     fields can be used.____
>>>>
>>>>                                 ____
>>>>                                 CMP: I understand several values can
>>>>                                 be used.____
>>>>                                 CMP: Which one is actually used?____
>>>>                                 CMP: If the Handles and sequences
>>>>                                 match but not the port?____
>>>>
>>>>                                 ____
>>>>
>>>>                                         ____
>>>>
>>>>                                         6.6.  Verification of the
>>>>                                         SFP Consistency____
>>>>
>>>>                                            *  Collect information of
>>>>                                         the traversed by the CVReq
>>>>                                         packet SFs and____
>>>>
>>>>                                               send it to the ingress
>>>>                                         SFF as CVRep packet over IP
>>>>                                         network;____
>>>>
>>>>                                         ____
>>>>                                         What if NSH is not over IP?____
>>>>
>>>>                                     GIM>> Then the operator will
>>>>                                     specify another method using the
>>>>                                     Reply mode. ____
>>>>
>>>>                                 ____
>>>>                                 CMP: Sorry that does not answer my
>>>>                                 question. The text in question is
>>>>                                 not contextual to a specified reply
>>>>                                 mode.____
>>>>
>>>>                                 ____
>>>>
>>>>                                         ____
>>>>
>>>>                                            SF Type: Two octets long
>>>>                                         field.  It is defined in
>>>>                                         [RFC9015] and____
>>>>
>>>>                                            indicates the type of SF,
>>>>                                         e.g., Firewall, Deep Packet
>>>>                                         Inspection, WAN____
>>>>
>>>>                                            optimization controller,
>>>>                                         etc.____
>>>>
>>>>                                         ____
>>>>                                         Is RFC 9015 a hard
>>>>                                         dependency to implement this
>>>>                                         OAM? ____
>>>>
>>>>                                     GIM>> RFC 9015 established the
>>>>                                     IANA registry of SF Type and any
>>>>                                     new SF types must be registered.____
>>>>
>>>>                                         ____
>>>>
>>>>                                            IANA is requested to
>>>>                                         assign a new type from the
>>>>                                         SFC Active OAM____
>>>>
>>>>                                            Message Type sub-registry
>>>>                                         as follows:____
>>>>
>>>>                                         ____
>>>>
>>>>                                                  
>>>>                                         +=======+=============================+===============+____
>>>>
>>>>                                                   | Value |        
>>>>                                         Description         |
>>>>                                         Reference     |____
>>>>
>>>>                                                  
>>>>                                         +=======+=============================+===============+____
>>>>
>>>>                                                   | TBA2  | SFC Echo
>>>>                                         Request/Echo Reply | This
>>>>                                         document |____
>>>>
>>>>                                                  
>>>>                                         +-------+-----------------------------+---------------+____
>>>>
>>>>                                         ____
>>>>                                         Is there a single value for
>>>>                                         both Request and Reply?____
>>>>
>>>>                                     identified in the Message Type
>>>>                                     field (Figure 3). ____
>>>>
>>>>                                 ____
>>>>                                 CMP: Is this document defining a
>>>>                                 full 64k space for a single value?
>>>>                                 If so it appears to be wasteful.____
>>>>
>>>>                                 ____
>>>>
>>>>                                         ____
>>>>
>>>>                                         9.2.1.  Version in the
>>>>                                         Active SFC OAM Header____
>>>>
>>>>                                         9.3.1.  SFC Echo
>>>>                                         Request/Reply Version____
>>>>
>>>>                                         ____
>>>>                                         There seems to be a version
>>>>                                         for the OAM and a version
>>>>                                         for the msg type. Is this
>>>>                                         correct? Are they
>>>>                                         hierarchical versions? Or
>>>>                                         independent? ____
>>>>                                         This seems to overly
>>>>                                         complicate parsing and
>>>>                                         compliance.____
>>>>
>>>>                                     GIM>> All versions are
>>>>                                     independent. ____
>>>>
>>>>                                 ____
>>>>                                 matrix of supported combination of
>>>>                                 versions. If there was an
>>>>                                 Operational Considerations section,
>>>>                                 this should be included.____
>>>>
>>>>                                 ____
>>>>
>>>>                                         ____
>>>>
>>>>                                         9.3.3.  SFC Echo
>>>>                                         Request/Echo Reply Message
>>>>                                         Types____
>>>>
>>>>                                         Does this mean that there’s
>>>>                                         a protocol number for
>>>>                                         “Active OAM” with a protocol
>>>>                                         number for “Request/Reply”
>>>>                                         with a protocol number for
>>>>                                         either request or reply?____
>>>>
>>>>                                     GIM>> These are not all protocol
>>>>                                     numbers. Only the Active OAM is
>>>>                                     a new protocol number. Others
>>>>                                     are message types. ____
>>>>
>>>>                                 ____
>>>>                                 CMP: Apologies I was not clear.____
>>>>                                 CMP: The “SFC Active OAM” is
>>>>                                 actually a "SFC Next Protocol”.____
>>>>                                 to some OAM function, a node needs
>>>>                                 to recursively parse 3 TLVs.
>>>>                                 Correct? This seems overly complex.____
>>>>
>>>>                                 ____
>>>>
>>>>                                         ____
>>>>
>>>>                                            Values defined for the
>>>>                                         Return Codes sub-registry
>>>>                                         are listed in____
>>>>
>>>>                                            Table 14.____
>>>>
>>>>                                         ____
>>>>                                         Various values in this table
>>>>                                         are not defined in the
>>>>                                         document. The procedures
>>>>                                         seem lacking.____
>>>>
>>>>                                     GIM>> Other specifications may
>>>>                                     define additional code points in
>>>>                                     the registry. ____
>>>>
>>>>                                 ____
>>>>                                 CMP: Thank you. The procedures still
>>>>                                 seem lacking.____
>>>>                                 ____
>>>>                                 CMP: Best,____
>>>>                                 ____
>>>>                                 CMP: — Carlos.____
>>>>
>>>>                                 ____
>>>>
>>>>                                         ____
>>>>
>>>>                                         9.7.  SF Identifier Types____
>>>>
>>>>                                         This document seems to be
>>>>                                         creating a space for
>>>>                                         identifying SFs — which I
>>>>                                         thought was mostly outside
>>>>                                         the scope of OAM to test
>>>>                                         SFs. ____
>>>>
>>>>                                     GIM>> The registry is of SF
>>>>                                     Identifiers, not of SF Types
>>>>                                     (that already exists). Hope that
>>>>                                     clarifies the issue. ____
>>>>
>>>>                                         ____
>>>>                                         Does this further imply that
>>>>                                         there’s a new requirement to
>>>>                                         have unique identifiers
>>>>                                         within the domain for all
>>>>                                         SFs?____
>>>>                                         ____
>>>>                                         I hope these comments and
>>>>                                         review questions and
>>>>                                         concerns are useful for the
>>>>                                         WG discussion and
>>>>                                         consideration.____
>>>>                                         ____
>>>>                                         Thanks,____
>>>>                                         ____
>>>>                                         Carlos.____
>>>>                                         ____
>>>>
>>>>                                         ____
>>>>
>>>>                                             Nov 1, 2021 2:50 PM、
>>>>                                             Joel Halpern Direct
>>>>                                             <[email-masked]
>>>>                                             <mailto:[email-masked]>>
>>>>                                             のメール:____
>>>>                                             ____
>>>>                                             I have received a polite
>>>>                                             request with explanation
>>>>                                             for delay asking for
>>>>                                             more time to read and
>>>>                                             review the subject
>>>>                                             document.  Given the
>>>>                                             state of the working
>>>>                                             group, i want to
>>>>                                             encourage any and all
>>>>                                             review.  So I am
>>>>                                             extending the last call
>>>>                                             by two additional weeks.
>>>>
>>>>                                             Please read and review
>>>>                                             the document.
>>>>                                             Also, if you are willing
>>>>                                             to serve as shepherd for
>>>>                                             this, please let the
>>>>                                             chairs know.  (Don't
>>>>                                             worry if you have not
>>>>                                             shepherded a document
>>>>                                             before.  The chairs are
>>>>                                             more than happy to help
>>>>                                             you with the process.)
>>>>
>>>>                                             Thank you,
>>>>                                             Joel
>>>>
>>>>                                             <mailto:[email-masked]>
>>>>                                             <https://www.ietf.org/mailman/listinfo/sfc>____
>>>>
>>>>                                 ____
>>>>                                 [email-masked] <mailto:[email-masked]>
>>>>                                 <https://www.ietf.org/mailman/listinfo/sfc>____
>>>>
>>>>                             --____
>>>>                              <http://www.verizon.com/>____
>>>>                             *Gyan Mishra*____
>>>>                             /Network Solutions Architect /____
>>>>                             /[email-masked]
>>>>                             <mailto:[email-masked]>/____
>>>>
>>>>                             /M 301 502-1347/____
>>>>
>>>>                             ____
>>>>
>>>>                         ____
>>>>
>>>>                     --____
>>>>                      <http://www.verizon.com/>____
>>>>                     *Gyan Mishra*____
>>>>                     /Network Solutions Architect /____
>>>>                     /[email-masked]
>>>>                     <mailto:[email-masked]>/____
>>>>
>>>>                     /M 301 502-1347/
>>>>
>>>
>>
>> <Diff_ draft-ietf-sfc-multi-layer-oam-17.txt - 
>> draft-ietf-sfc-multi-layer-oam-18.txt.html>
>

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 19 Dec 2021 09:53:38 -0800

Dear Carlos,
thank you for the continued discussion. Please find my notes in-lined below
and tagged GIM3>>.  I'm looking forward to guidance from the Chairs on how
to proceed further.

Happy Holidays to everyone!

Regards,
Greg

On Sat, Dec 18, 2021 at 2:41 PM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> believe there’s no shepherd assigned) track the issues and review comments (not
> sure if there’s an issue tracker) and take it from here.
>
> Happy Holidays!
>
> 12/15/21 午後8:00、Greg Mirsky <[email-masked]>のメール:
>
> Dear Carlos,
> CMP2: I am not sure of the implication of you not knowing that definition,
> nor do I see this response moving alignment forward.
>
> CMP2: From RFC8300:
GIM3>> I imagine that since a Classifier encapsulates a packet into NSH,
the Classifier also is responsible for properly setting the O bit. To avoid
possible interoperability issues, an implementor must follow clearly
defined rules that govern the handling of the O bit. I assume that part of
such rules is the definition of what is an OAM packet. It seems that
without that interoperation among implementations of SFC elements (e.g.,
Classifier from vendor A and SFFs from vendor B) is not guaranteed.

>>       - Stating however that the identification is based on a
>>       combination of fields is incorrect.
> CMP2: RFC8924 includes ICMP, which by simply setting O=1 and NP as IP can
> be used.\
>
GIM3>> I believe that the document is clear that the described SFC Echo
Request/Reply is not the only Active SFC OAM protocol. I have a question
about your example. If the NSH payload is ICMP, would the O bit be always
set?

> CMP2: 2. What is a protocol used as active OAM but not being active OAM?
GIM3>> According to RFC 7799 "Active Methods generate packet streams.". In
other words, active oam uses specifically constructed packets. If a
protocol doesn't use such packets, then it is not active. RFC 7799 defines
OAM methods that combine passive and active as a hybrid. Hybrid OAM methods
are outside the scope of this document.

> CMP2: Regarding the second sentence, thanks for sharing what you expect —
> however that is different than what specs write :-) Why would encapsulation
> dictate the value of the O bit? Take for example BFD encapsulated in IP…
>
GIM3>> I'll repeat my question from the above. Would any BFD control
message encapsulated in IP/UDP have the O bit set in the NSH?

> CMP2: which prevents using context header for spec’ed context header uses.
GIM3>> Can you please clarify it for me. As I understand RFC 8300, an NSH
may include multiple NSH Context Headers. Is my understanding correct?

> CMP2: draft-ietf-sfc-multi-layer-oam does not provide the definition (not
> needed frankly) of what you say needs defining.
>
GIM3>> I am looking from the point of an implementor that is tasked with
developing the O bit functionality of a Classifier function. I believe that
without a clear definition of what is an OAM packet interoperability among
SFC elements is not guaranteed.

> CMP2: Can you please share a reference to OAM in NSH context headers?
GIM3>> The fact that none has been defined up to now, doesn't mean that
that will never happen. Unless, of course, the WG decides to adopt and
publish a document that explicitly prohibits using the NSH Context Header
for OAM processing instructions and data.

> carried in NSH environment. Will remove the reference to BFD in the next
> update.
>
>
GIM3>> Do you refer to the BFD Control message encapsulated in the SFC
Active OAM header or with, for example, IP/UDP encapsulation under the NSH?

>> CMP: Since the name of the active OAM protocol defined in this document
>> is "Echo Request/Reply”, could I please request to:
GIM3>> I'll repeat my question here. Would an ICMP packet always have the O
bit set in its NSH?

>>> *From:* Carlos Pignataro (cpignata) <cpignata=[email-masked]
>>> >
>>> thank you for your comment describing an interesting IOAM use case in
>>> SFC NSH. I've thought about this case and I have several questions. I
>>> greatly appreciate your help clarifying them to me:
>>>
>>> Also, I think that your suggestion to avoid any reference to a hybrid
>>> OAM protocol concentrating on the active OAM identification in the update
>>> to O-bit definition is logical and reasonable. Below, please find the
>>> proposed update:
>>> OLD TEXT:
>>> of the SFC Next Protocol values define defined in Section 9.1 Active
>>> SFC OAM (TBA1).”
>>>
>>>
>>> …FB: Similar to the note above, “No Context-header(s) that contain
>>> active OAM commands and/or data.” might be simpler
>>>
>>> …FB: Isn’t this obvious? The reader might wonder why this is even
>>> stated. IMHO we could safely remove this bullet.
>>>
>>> Observing what appears to be a single non-author response to the
>>> original WGLC email, and one more after this extension, I also perceive the
>>> energy level to work on this to be low.
>>>
>>> GIM>> I think that the document is positioned not as a general active
>>> OAM protocol but as one of the active SFC NSH OAM protocols.
>>>
>>>
>>>
>>> CMP: I am not sure if you are answering a different question, but
>>> there’s no reference to any proprietary solutions.
>>>
>>> I see a gap between “it is beneficial” and “MUST”. What is "Remote
>>> Defect Indication” in the context of SFC OAM since it is not in the OAM
>>> framework? Is this "Remote Defect Indication” the only way to achieve the
>>> rerouting or redundancy triggering?
>>>
>>> I am extremely concerned about this attempted re-definition (of the
>>> O-bit and Protocol fields). On several fronts as explained below. During
>>> RFC8300 the WG evaluated these and provided a solution already.
>>>
>>>
>>> This potentially breaks the concept of nodes not understanding OAM
>>> (i.e,. Partial deployment of a new protocol)
>>>
>>> GIM>> What is an OAM packet? Is an SFC NSH packet with IOAM an OAM
>>> packet or not? If an SFC NSH packet is part of flow under the Alternate
>>> Marking, is it an OAM packet because the Alternate Marking method is an
>>> example of the hybrid OAM?
>>>
>>>
>>> Why does BFD get encapsulated in this new protocol, as opposed to using
>>> a “Next Protocol” for it? That looks like unnecessary overhead and
>>> indirection.
>>>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 20 Dec 2021 15:15:59 -0800

Dear Carlos,
thank you for your clarifications. Please find my answers and notes
in-lined below under the GIM3>> tag.
Attached, please find the updated working version of the draft that now
includes the Operational Considerations section and the diff.

Happy Holidays to All!

Regards,
Greg

On Wed, Nov 24, 2021 at 8:08 AM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Dear Greg,
>
> Please see inline.
>
> Best,
>
> Carlos.
>
> On Nov 24, 2021, at 10:44 AM, Greg Mirsky <[email-masked]> wrote:
>
> Dear Carlos,
> please find more responses in-line below under the GIM2>> tag.
>
> Regards,
> Greg
>
> On Fri, Nov 19, 2021 at 5:33 PM Carlos Pignataro (cpignata) <
> GIM2>> I don't think that the proposed mechanism discards or negates any
> of the tools listed in RFC 8924. SFC NSH Echo Request/Reply is targeted to
> specifically SFC NSH operational needs is not to replace but to complement
> other OAM tools. The choice of which tool from the SFC OAM toolbox to use
> is, as always, with vendors and operators.
>
>
> CMP2: Sorry if I was not clear, let me ask differently. Where is the
> documented tradeoff and decision for creating a new protocol versus
> extending existing ones which partially address requirements? Indeed, I
> agree operators and vendors have a choice, my question is in regards to the
> WG decision to build new vs. extend.
>
GIM3>> Thank you for clarifying your question. As I understand it, it is
not directed to the authors of the draft but to the WG Chairs.

> GIM3>> I should have been more precise. The conclusion drawn in RFC 8924
is that none of the available tools complies with *all* the requirements,
i.e., each of the available OAM mechanisms has some functional gaps.

> GIM3>> It was the decision of the authors to address all the requirements
in a new protocol. The authors worked on the base mechanism and its
extensions addressing comments and suggestions from the WG.

> GIM3>> I assume that there's no discussion only because no one proposed an
alternative solution. A comparison, as I imagine, can be done when there is
more than one proposal.

>
> CMP2: You seem to have missed these 3 comments. Could you please address?
>
>
>>
> GIM2>> I believe that the WG has demonstrated its support for the proposed
> solution.
>
>
> CMP2: I thought statements like these are within the scope of a WG chair.
>
GIM3>> I apologize to the WG Chairs if I overstepped. I'd point that I
wrote, "I believe" not to sound like a statement. Please correct me if I am
wrong.

> CMP2: From a technical perspective, it is a useful engineering piece of
> data to understand why a new protocol.
>
GIM3>> The proposed solution is the result of discussions among the authors
and our work addressing suggestions and comments from the WG.

>
> Anyone can propose an alternative technical solution in the
> traditional IETF form.
>
>>
>>
> GIM2>> I was told of interest in developing implementations based on the
> mechanism defined. Certain hesitation to be an early adopter is
> understandable to me.
>
>
> CMP2: Shall I understand this as you cannot point to any implementation?
>
GIM3>> At this time I'm not in the position to discuss the state of the
implementations. I'm aware of plans to implement the proposed mechanism.

> GIM2>> Looking at this list, the SFC NSH Echo Request/Reply mechanism is
> not an alternative to BFD or IOAM.
>
>
>
> CMP2: ICMP?
>
GIM3>> As concluded in RFC 8924, ICMP has some gaps towards the
requirements for SFC OAM. Also, the individual draft SFC-Traceroute has
expired 6 years ago.

> GIM2>> SFC Active OAM Header is a part of an active SFC NSH OAM packet.
>
>
> CMP2: In that case, shall I understand that the “SFC Active OAM Header”
> cannot be part of other OAM packet. In that case I am very confused as I
> read:
> CMP2: "      Msg Type - six bits long field identifies OAM protocol, e.g.,
> Echo"
> CMP2: "      Request/Reply or Bidirectional Forwarding Detection."
> CMP2: Why would BFD be carried in the middle of SFC Active OAM? Why not
> use the NSH Next Protocol as intended?
>
GIM3>> This document does not discuss the use of BFD in the SFC NSH
environment. The reference to BFD is now removed in the working version of
the draft.

> GIM2>> I think that it is helpful to provide some operational suggestions
> in the Operational Considerations section. Will work with co-authors.
>
>>
>>
> GIM2>> In Section 6.5.4 of the draft:
>     Suppose a specialized information element (e.g., IPv6 Flow Label
>    [RFC6437] or Flow ID [I-D.ietf-sfc-nsh-tlv]) is used for distributing
>    the load across Equal Cost Multi-Path or Link Aggregation Group
>    paths.  In that case, such an element MAY also be used for the SFC
>    OAM traffic.  Doing so is meant to induce the SFC Echo Request to
>    follow the same RSP as the monitored flow.
>
>
> CMP2: I may have misunderstood — if so apologies in advance — however,
> when I read "a Fixed-Length Context Header or Variable-Length Context
> Header(s) contain an OAM command or data” I thought Context Header (e.g.,
> MD Type 1) was user for OAM, it could not be used for Flow ID as well.
>
GIM3>> I cannot find any WG document on the use of Flow ID in MD Type 1
Context Header. For a Context Header MD Type 2, draft-ietf-sfc-nsh-tlv
states:
   When the base header specifies MD Type = 0x2, zero or more Variable
   Length Context Headers MAY be added, immediately following the
   Service Path Header.

> GIM2>> I am trying to understand the question. RFC 7799, as I understand
> it, defines an active OAM packet as a specifically constructed test packet.
>
>
> CMP2: RFC 7799 does not include the terms “OAM Command” or “OAM Data"
>
>
> GIM2>> Frank has brought very good points and suggested excluding hybrid
> OAM. Now the text is applicable only to active SFC NSH OAM:
>
>
> CMP2: I agree with removing any Hybrid OAM from the “SFC Active OAM”
> document. For sure.
> CMP2: at the same time, what specifically needs to be redefined for the
> O-bit (as opposed to say “use it as intended in 8300”)?
>
GIM3>> I believe that this question has been moved to a separate thread.

>          - An SFC NSH Context Header(s) contain an OAM command or data.
>
>          - The "Next Protocol" field determines the type of the payload.
>
>          - The payload that immediately follows the NSH MUST be the
>          - No OAM in an SFC NSH Context Header(s).
>
>          - The payload determined by the "Next Protocol" field MUST be
>          present.
>
>          - Erroneous combination.  An implementation MUST report it.
>          The notification mechanism is outside the scope of this
>          specification.  The packet SHOULD be dropped.  An
>          implementation MAY have control to enable processing of the OAM
>          payload.
>
>
>>
>>>    *  O bit is clear:
>>>
> GIM2>> We've agreed with Frank to not discuss hybrid SFC NSH OAM in this
> draft.
>
>
> CMP2: Sounds good — why does the O-bit need to be discussed in any case?
>
GIM3>> Following comments and the discussion with Frank, we've updated the
text.

> GIM2>> The purpose of the specification is to address specific SFC NSH OAM
> requirements. The proposed solution is one of possible that can be
> implemented. Encapsulation efficiency is a benefit.
>
>>
>>
> GIM2>> draft-ietf-sfc-multi-layer-oam does not include BFD in SFC NSH in
> its scope.
>
>
> CMP2: The text in the document that I quoted above seems to contradict
> your statement.
>
GIM3>> We've removed the reference to BFD from the document.

> GIM2>> RFC 8592 has been published through the Independent Stream Editor.
> As I understand it, draft-mymb-sfc-nsh-allocation-timestamp is also in the
> ISE track. I'll reach out to the authors
> of draft-mymb-sfc-nsh-allocation-timestamp to see if any considerations
> should be added in their document.
>
>
> CMP2: I would suggest that this document also needs to figure out
> non-clashing proposals.
>
>
>>
> GIM2>> I think that RFC 8924 has firmly established that none of the
> analyzed OAM tools completely addresses all the SFC NSH OAM requirements.
> Can a combination of tools do the job? I don't know. What is easier seems a
> subjective issue.  If anyone has an alternative technical solution, I'll be
> glad to discuss that. Otherwise, it appears as hypothetical.
>
>
> CMP2: I disagree with this approach in principle, as I’d expect the WG to
> compare feasibility and ROI of approaches before embarking in text. Just my
> humble opinion.
>
GIM3>> I hope that we can agree to disagree.

> GIM2>> The sender of the SFC Echo Request includes SFC Reply Path TLV. The
> responder must use the Service Index field in the NSH that encapsulates SFC
> NSH Echo Reply. I hope that clarifies how the Service Index field is used.
>
>
> CMP2: I am sorry, it doesn’t. How does the sender of the request (i.e.,
> based on what criteria) chooses the Service Index field value in the SFC
> Reply Path TLV in the SFC Active OAM packet?
>
GIM3>> It is implemetation-specific.

> GIM2>> I assume you are thinking of IP/UDP encapsulation of SFC NSH. The
> receiver of SFC NSH Echo Reply would not check for port. Or are you
> referring to a different port?
>
>
> CMP2: I am referring to the port that S6.5.3
> of draft-ietf-sfc-multi-layer-oam mentions. "it has an outstanding SFC Echo
> Request sent from the UDP port that matches destination UDP port number of
> the received packet;”
> CMP2: Based on that the question stands.
>
GIM3>> Thank you for the clarification. I agree that is an unnecessary
check and I've removed it from the working version.

> GIM2>> We'll address that in the new Operational Considerations section.
>
>
> CMP2: Look forward to reviewing. The text in Section 6.6 still has issues.
>
GIM3>> The attached copy of the working text includes the new Operational
Considerations section.

> CMP2: You seem to have skipped this comment.
>
GIM3>> The authors think that it is reasonable and allows for future
extensions as well as experimentation.

> GIM2>> Thank you for the suggestion. We'll mention that in the Operational
> Considerations section.
>
>>
>>
> GIM2>> The NSH's Next Protocol field is in the fixed position. Getting to
> SFC NSH active OAM doesn't seem to require parsing TLVs, SFC NSH Context
> Headers can be simply skipped.
>
>
> CMP2: Concern stands. What is the value of this linked protocol
> identification check?
>
GIM3>> SFC Echo Request/Reply maybe not the only protocol using SFC Active
OAM Header.

>
> CMP2: Thanks again, and best,
>
> CMP2: Carlos.
>
>
>>
>>> Nov 1, 2021 2:50 PM、Joel Halpern Direct <[email-masked]
>>> >のメール:
>>>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 21 Dec 2021 01:01:31 +0000

Hi Joel,

Sorry if I was not clear — I did not mean infer from a packet payload the function type. I meant: look at the O-bit. If set, it is OAM. The NP says how that OAM is encapsulated, which can include IP->ICMP.

Based on that, what part of the definition you feel is unclear? 

From RFC 8300:

   O bit:  Setting this bit indicates an OAM packet (see [RFC6291]).
…
      The O bit MUST be set for OAM packets and MUST NOT be set for
      non-OAM packets.  The O bit MUST NOT be modified along the SFP.

This seems to match what I understand is also your preference.

What exactly is needed to be updated on the definition of the O-bit?

Best,

Carlos.

> On Dec 18, 2021, at 7:48 PM, Joel Halpern Direct <[email-masked]> wrote:
> 
> Just commenting on one aspect of your note.  I think the definition of the SFC NSH header O bit is unclear.  It never occurred to me that one would expect an SFC classifier to not that an inncoming packet was carrying ICMP, look at the ICMP type, decide it was an OAM packet, and set the O bit in the SFC NSH header.  No, nothing in the OAM framework prohibits that.  But nothing leads one to expect it either.
> 
> Thus, I think it is helpful to clarify the meaning of the O-bit. Personally, I rather like saying that the NSH O bit is to indicate the presence of OAM for SFFs.  But my personal view is largely irrelevant.
> 
>> As dialogue in this thread seem to be getting intertwined and hard to follow, with several weeks between responses, I will let the chairs (I believe there’s no shepherd assigned) track the issues and review comments (not sure if there’s an issue tracker)and take it from here.
>> Happy Holidays!
>>> 12/15/21 午後8:00、Greg Mirsky <[email-masked] <mailto:[email-masked]>>のメール:
>>> 
>>> Dear Carlos,
>>> On Fri, Nov 26, 2021 at 8:18 PM Carlos Pignataro (cpignata) <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>    Dear Greg,
>>> 
>>>>>                                           noticeable overhead.                                         This document defines Active
>>>>>                                        OAM Header____
>>>>> 
>>>>>                                                  | Value |                                                Description         |

---

From: Joel Halpern Direct <[email-masked]>
Date: Mon, 20 Dec 2021 20:07:43 -0500

from what I read, the example you provided was of an underlying ICMP 
Echo packet.
As I understood your email, you want SFC to mark that as OAM in the NSH 
header.
I would not have expected that behavior from the existing texts.

As such, whichever way we want it to work, we would seem to need to 
clarify our collective expectation.

More generally, I assumed the O bit of the SFC NSH header was concerned 
with OAM related to SFC.  I think, although I could be wrong, that you 
read it more generally.  Again, if different folks read it differently, 
we benefit from clarity.

Yours,
Joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 21 Dec 2021 01:10:55 +0000

For this usage https://datatracker.ietf.org/doc/html/rfc8924#section-7.1, the O-bit should be set. For any “vanilla” ICMP in traffic is not.

On Dec 20, 2021, at 8:07 PM, Joel Halpern Direct <[email-masked]<mailto:[email-masked]>> wrote:

from what I read, the example you provided was of an underlying ICMP Echo packet.
As I understood your email, you want SFC to mark that as OAM in the NSH header.
I would not have expected that behavior from the existing texts.

As such, whichever way we want it to work, we would seem to need to clarify our collective expectation.

More generally, I assumed the O bit of the SFC NSH header was concerned with OAM related to SFC.  I think, although I could be wrong, that you read it more generally.  Again, if different folks read it differently, we benefit from clarity.

Yours,
Joel

On Dec 18, 2021, at 7:48 PM, Joel Halpern Direct <[email-masked]<mailto:[email-masked]>> wrote:

Yours,
Joel

On 12/18/2021 5:41 PM, Carlos Pignataro (cpignata) wrote:
Dear Greg,
Thank you for the reply — please find inline my follow-ups (to the comments you responded to, even though there’s a few you missed or otherwise skipped)
As dialogue in this thread seem to be getting intertwined and hard to follow, with several weeks between responses, I will let the chairs (I believe there’s no shepherd assigned) track the issues and review comments (not sure if there’s an issue tracker)and take it from here.
Happy Holidays!
12/15/21 午後8:00、Greg Mirsky <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>のメール:

Dear Carlos,

Regards,
Greg

On Fri, Nov 26, 2021 at 8:18 PM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:

   Dear Greg,

   I disagree. My perspective is that they go from not helpful to
   plain harmful.

    1. This is no different than RFC 8300. The O bit specifies the
       packet being OAM,

    1. the Next Protocol specifies the type of packet which can be
       “Active SFC OAM”
         * Stating however that the identification is based on a

   Although these were brought up before, highlighting a couple of
   comments:

   1.  Introduction
      Also, this document updates Section 2.2 of [RFC8300] in part of
   the
      definition of O bit in the NSH.

   5.  Active SFC OAM Header

         Msg Type - six bits long field identifies OAM protocol,
   e.g., Echo
         Request/Reply or Bidirectional Forwarding Detection.

   CMP: Since the name of the active OAM protocol defined in this
   document is "Echo Request/Reply”, could I please request to:
   CMP: 1. Provide a more specific name (since Echo Request/Reply can
   easily be confused with using ICMP)

   Best,

   Carlos.

   On Nov 26, 2021, at 10:30 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>
   <mailto:[email-masked]>> wrote:

   Dear Carlos,
   I believe that the proposed new text clarifies several aspects of
   O bit:

   Regards,
   Greg

   On Fri, Nov 26, 2021 at 7:10 PM Carlos Pignataro (cpignata)
   <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:

       Thanks,

       Carlos.

       On Nov 26, 2021, at 4:09 PM, Frank Brockners (fbrockne)
       <fbrockne=[email-masked]<mailto:fbrockne=[email-masked]>
       <mailto:fbrockne=[email-masked]>> wrote:

       Hi Carlos,____
       __ __
       Personally I don’t see a strong need to evolve the
       definition of the O-bit – but if the working group decides
       to do so, IMHO it would be good to ensure that the O-bit
       indeed signals the fact that active OAM information related
       to NSH is carried.____
       __ __
       Cheers, Frank____
       __ __
       *From:*Carlos Pignataro (cpignata)
       <cpignata=[email-masked]<mailto:cpignata=[email-masked]>
       <mailto:cpignata=[email-masked]>>
       *Sent:*Tuesday, 23 November 2021 15:44
       *To:*Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>
       <mailto:[email-masked]>>
       *Cc:*Greg Mirsky <[email-masked]<mailto:[email-masked]>
       <mailto:[email-masked]>>; Gyan Mishra
       <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>;
       James N Guichard <[email-masked]<mailto:[email-masked]>
       <mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]>
       <mailto:[email-masked]>; Joel Halpern Direct
       <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
       *Subject:*Re: [sfc] Regarding last call for
       draft-ietf-sfc-multi-layer-oam____
       __ __
       Frank, Greg,____
       __ __
       Do you see a reason to redefine the O-bit?____
       __ __
       Thanks,____
       __ __
       Carlos.____

       ____

           11/23/21午前9:33、Frank Brockners (fbrockne)
           <fbrockne=[email-masked]<mailto:fbrockne=[email-masked]>
           <mailto:fbrockne=[email-masked]>>のメール:____
           __ __
           Hi Greg,____
           ____
           Thanks for the quick reply. Please see inline.____
           ____
           *From:*Greg Mirsky <[email-masked]<mailto:[email-masked]>
           <mailto:[email-masked]>>
           *Sent:*Monday, 22 November 2021 23:16
           *To:*Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>
           <mailto:[email-masked]>>
           *Cc:*Carlos Pignataro (cpignata)
           <cpignata=[email-masked]<mailto:cpignata=[email-masked]>
           <mailto:cpignata=[email-masked]>>; Gyan
           Mishra <[email-masked]<mailto:[email-masked]>
           <mailto:[email-masked]>>; James N Guichard
           <[email-masked]<mailto:[email-masked]>
           <mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]>
           <mailto:[email-masked]>; Joel Halpern Direct
           <[email-masked]<mailto:[email-masked]>
           <mailto:[email-masked]>>
           *Subject:*Re: [sfc] Regarding last call for
           draft-ietf-sfc-multi-layer-oam____
           ____
           Hi Frank,____
           thank you for your comment describing an interesting
           IOAM use case in SFC NSH. I've thought about this case
           and I have several questions. I greatly appreciate your
           help clarifying them to me:____

              - Erroneous combination. The combination MUST be
           identified and reported.

           ____
           (fbrockne) <[email-masked]<mailto:[email-masked]>

               ____

               Thanks, Frank____

               ____
               ____
               *From:*sfc <[email-masked]<mailto:[email-masked]>
               *To:*Gyan Mishra <[email-masked]<mailto:[email-masked]>
               <[email-masked]<mailto:[email-masked]>
               Mirsky <[email-masked]<mailto:[email-masked]>
               <mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]>
               <[email-masked]<mailto:[email-masked]>

               ____

                   11/20/21午前10:36、Gyan Mishra
                   <[email-masked]<mailto:[email-masked]>
                   <mailto:[email-masked]>>のメール:____
                   ____
                   Hi Carlos____
                   ____
                   Many Thanks for your feedback____
                   ____
                   Responses in-line____
                   ____
                   On Fri, Nov 19, 2021 at 11:39 PM Carlos
                   Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>
                   <mailto:[email-masked]>> wrote:____

                       Dear Gyan,____
                       ____
                       I hope all is well!____
                       ____

                   ____

                       ____

                   ____

                       ____
                       ____
                       3. When you write “/for

                   ____

                       ____
                       ____

                       ____

                           11/19/21午後11:02、Gyan Mishra
                           <[email-masked]<mailto:[email-masked]>
                           <mailto:[email-masked]>>のメール:____

                           ____
                           ____
                           Dear Chairs & All ____
                           ____
                           <cpignata=[email-masked]<mailto:cpignata=[email-masked]>

                               Dear Greg,____
                               ____
                               Thank you for replying to my email.
                               Please find a couple follow-ups
                               inline, as I invite other WG
                               interested parties to the
                               discussion.____

                               ____

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

                                       Hello, WG,____
                                       ____
                                       In

                                                       Active OAM

                                       ____

                                       Abstract____

                                       ____

                                          Maintenance (OAM) of
                                       Service Function Chains

                                          presented in this
                                       document.  Based on these
                                       requirements, an____

                                          encapsulation of active

                                          and localize defects are
                                       described.____

                                       ____

                                         * rfc8924 lists
                                           requirements in S4, but
                                           this document mentions
                                           them in
                                           passing. Instead, as per
                                           the Abstract above, this
                                           document creates new
                                           requirements and based
                                           on them creates a new
                                           OAM protocol.____

                                   GIM>> We've followed the

                               ____
                               CMP: That’s an issue, those are not
                               requirements for a new protocol.
                               Neither for a single protocol to
                               perform all functions.____
                               ____
                               CMP: Specifically, RFC 8924 says:____
                               ____

                               ____

                               ____
                               CMP: I do not see that conclusion in
                               RFC 8924, perhaps you can quote /
                               copy/paste the relevant text. The
                               specific text that includes a
                               conclusion. And specific text that
                               says that none of the tools comply
                               with the requirements.____
                               ____
                               CMP: In any case, there is also no
                               implication that creating a new
                               protocol for all requirements and
                               ignoring the analysis of existing
                               protocols that can be used or
                               extended is in the best interest of
                               SFC’s OAM.____
                               ____
                               CMP: Additionally, I did not see the
                               discussion on the list of this
                               comparison (since it does not exist
                               in the draft).____

                               ____

                                       ____

                                       ____
                                       ____

                                          Active OAM tools,____

                                          conformant to the
                                       requirements listed in

                                          example, troubleshooting
                                       efficiency and defect
                                       localization in SFP____

                                          NSH.  For that purpose,

                                          in Section 6.____

                                       ____

                               ____
                               CMP: This is a very useful response.
                               As I responded above, there’s no
                               implication that if no existing
                               tools address all requirements, the
                               path is to create a brand new one
                               ignoring the existing ones.____

                               ____

                                       ____

                                       ____

                                          This mechanism enables

                                          Connectivity

                                          networks, addresses

                                       ____
                                       This could be well the case
                                       — however many others
                                       (including existing)
                                       mechanisms also enable in
                                       these broad terms all the
                                       connectivity+continuity+trace functions.____

                               ____
                               CMP: Can you please point to
                               independent interoperable
                               implementations
                               of draft-ietf-sfc-multi-layer-oam?____
                               ____
                               CMP: Part of my point is that any
                               partial solution can be extended
                               interoperably.____

                               ____

                                       At the same time, this

                               ____

                               ____

                                       ____
                                       ____

                                          The ingress may be____

                                          capable of recovering
                                       from the failure, e.g.,
                                       using redundant SFC____

                                          elements.  Thus, it is

                                          defect state to the
                                       ingress, which in this

                                          Hence the following
                                       requirement:____

                                       ____

                                             REQ#3: SFC OAM MUST
                                       support Remote Defect

                                             by the egress to the
                                       ingress.____

                                       ____

                                       ____
                                       ____

                                       4.  Active OAM

                                       ____

                                          The O bit in the NSH is
                                       defined in [RFC8300] as
                                       follows:____

                                       ____

                                             O bit: Setting this

                                       ____

                                          This document updates

                                       ____

                                             O bit: Setting this

                                             the NSH Context Header
                                       or packet payload.____

                                       ____

                                          data included in a
                                       message that immediately
                                       follows the NSH.  To____

                                          identify the active OAM

                                          set to Active SFC OAM

                                       ____
                                       This is an example of
                                       over-reach. A “Next

                                   GIM>> Will clarify that

                               ____

                               ____

                                       ____

                                          The rules for____

                                          interpreting the values

                                          are as follows:____

                                       ____
                                       I am extremely concerned
                                       about this attempted

                                          *  O bit set and the

                                             identifying active or

                                             defined in [RFC7799]),

                                             (TBA1).____

                               ____
                               CMP: Apologies, I meant not
                               s/understanding/parsing/.____
                               ____
                               CMP: I agree it is an operational
                               issue — an issue of operations. Like
                               the “O” in “OAM”. Should Operational
                               Considerations be included as well?____

                               ____

                                       ____

                                                - a Fixed-Length
                                       Context Header or

                                                Header(s) contain

                                       ____

                                                - the "Next

                                       The semantic of Context
                                       Headers is outside this

                               ____
                               CMP: How?____

                               ____

                                       ____

                                       ____

                                          *  O bit set and the
                                       "Next Protocol" value

                                             active or hybrid OAM
                                       protocols:____

                                       ____

                                                - the payload that

                                                OAM command or data.____

                               ____

                               ____

                                       ____

                                          *  O bit is clear:____

                                       ____

                                                - no OAM in a

                                                Context Header(s).____

                                       ____

                                                - the payload
                                       determined by the "Next

                                                present.____

                               ____

                               ____

                                       ____

                                          *  O bit is clear, and

                                             hybrid OAM protocol
                                       MUST be identified and
                                       reported as an____

                                             erroneous
                                       combination.  An
                                       implementation MAY have
                                       control to____

                                             enable processing of
                                       the OAM payload.____

                                       This seems to break the
                                       existing usage

                               ____
                               CMP: Sorry, but you do not seem to
                               be actually reading

                               ____

                               ____

                               ____

                                       ____

                                       4.2.  IOAM and the use of
                                       the NSH O-bit____

                                       ____

                                          [RFC8300] defines an "O

                                          bit must be set for OAM

                                          packets.  Packets with
                                       IOAM data included MUST
                                       follow this____

                                          definition, i.e. the O
                                       bit MUST NOT be set for
                                       regular customer____

                                          traffic which also

                                          OAM packets which carry

                                          payload.____

                                       ____
                                       ____

                                       ____

                                          As demonstrated in
                                       Section 4 [RFC8924] and
                                       Section 3 of this____

                                          document, SFC OAM is

                                          active OAM protocols

                                          protocols can be
                                       demultiplexed using the

                                       ____

                                   GIM>> Isn't IP/UDP

                               ____
                               CMP: I am sorry Greg to call this
                               out, but you are choosing again to
                               not answer the question and instead
                               ask another one.____
                               ____
                               CMP: I am happy to answer: it is
                               larger. It also does not matter. And
                               further it is proven to work in LSP
                               Ping.____
                               ____
                               CMP: My question again: is the whole
                               purpose of this new protocol to be
                               overhead efficient? I am sure there
                               are ways of encasulating that are
                               more overhead-efficient
                               than draft-ietf-sfc-multi-layer-oam.____

                               ____

                                       ____
                                       Alternatively, “Next

                                             Msg Type - six bits

                                             Request/Reply or
                                       Bidirectional Forwarding
                                       Detection.____

                                       ____
                                       Why does BFD get
                                       encapsulated in this new
                                       protocol, as opposed to

                                   GIM>> Are you proposing
                                   assigning different Next

                               ____

                               ____

                                       ____

                                             Flags - eight bits

                                             optional capability

                                             control packet, e.g.,

                               ____

                               ____

                                       ____

                                       ____

                                          Echo Request/Reply is a
                                       well-known active OAM

                                          used to verify a path's
                                       continuity, detect

                                          state in control and the

                                          data plane.  ICMP
                                       ([RFC0792] for IPv4 and
                                       [RFC4443] for IPv6____

                                          networks, respectively)

                                          active OAM protocols
                                       based on the Echo

                                          SFC Echo Request/Reply
                                       defined in this document
                                       addresses several____

                                          requirements listed in

                                          check the continuity of
                                       an SFP, trace an SFP, or
                                       localize the failure____

                                          within an SFP.  The SFC

                                       ____
                                       This seems to be an

                               ____

                               ____

                                       ____

                                             Length -

                                            octets.____

                                       ____
                                       There are several nested
                                       lengths defined in this

                                       ____

                                       6.3.1.  Source TLV____

                                       ____

                                          message in IP/UDP packet

                                          UDP Packet".  Because the

                                          generated the Echo

                                          message and used as the

                                          port number of the SFC

                                          Request MUST include an

                                       ____
                                       This seems to negate the

                                       ____

                                       ____

                                       ____

                                       …____

                                          *  Service Index: the

                                             the SFC Echo Reply
                                       message.____

                               ____

                               ____

                                       ____
                                       ____

                                       6.5.3.  SFC Echo Reply
                                       Reception____

                                       ____

                                          An SFF SHOULD NOT accept

                                       ____

                                          *  the received SFC Echo

                                       ____

                                          *  it has an outstanding

                                             matches destination
                                       UDP port number of the
                                       received packet;____

                                       ____

                               ____

                               ____

                                       ____

                                       6.6.  Verification of the
                                       SFP Consistency____

                                          *  Collect information of

                                             send it to the ingress

                                       ____

                               ____

                               ____

                                       ____

                                          SF Type: Two octets long
                                       field.  It is defined in
                                       [RFC9015] and____

                                          optimization controller,
                                       etc.____

                                       ____
                                       Is RFC 9015 a hard

                                       ____

                                          IANA is requested to

                                       ____

                                                 | Value |                                                Description         |
                                       Reference     |____

                                                 | TBA2  | SFC Echo

                                       ____

                                   GIM>> Yes, it is a single value.
                                   Echo Request and Echo Reply are
                                   identified in the Message Type
                                   field (Figure 3). ____

                               ____

                               ____

                                       ____

                                       9.2.1.  Version in the

                                       9.3.1.  SFC Echo

                                       ____

                                   GIM>> All versions are
                                   independent. ____

                               ____
                               CMP: This seems like an operational
                               unnecessary complexity, in keeping a
                               matrix of supported combination of
                               versions. If there was an
                               Operational Considerations section,
                               this should be included.____

                               ____

                                       ____

                                       9.3.3.  SFC Echo

                               ____
                               CMP: Apologies I was not clear.____
                               CMP: The “SFC Active OAM” is
                               actually a "SFC Next Protocol”.____
                               CMP: My intention of using “protocol
                               number” is in a generic way. To get
                               to some OAM function, a node needs
                               to recursively parse 3 TLVs.
                               Correct? This seems overly complex.____

                               ____

                                       ____

                                          Values defined for the

                                          Table 14.____

                                       ____

                               ____

                               ____

                                       ____

                                       ____

                                       ____

                                           Nov 1, 2021 2:50 PM、
                                           Joel Halpern Direct
                                           <[email-masked]<mailto:[email-masked]>
                                           <mailto:[email-masked]>>
                                           のメール:____
                                           ____
                                           I have received a polite
                                           request with explanation
                                           for delay asking for
                                           more time to read and
                                           review the subject
                                           document.  Given the
                                           state of the working
                                           group, i want to
                                           encourage any and all
                                           review.  So I am
                                           extending the last call
                                           by two additional weeks.

                                           Please read and review
                                           the document.
                                           Also, if you are willing
                                           to serve as shepherd for
                                           this, please let the
                                           chairs know.  (Don't
                                           worry if you have not
                                           shepherded a document
                                           before.  The chairs are
                                           more than happy to help
                                           you with the process.)

                                           Thank you,
                                           Joel

                               ____
                               _______________________________________________
                               sfc mailing list
                               [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/>____
                           *Gyan Mishra*____
                           /Network Solutions Architect /____
                           /[email-masked]<mailto:[email-masked]>
                           <mailto:[email-masked]>/____

                           /M 301 502-1347/____

                           ____

                       ____

                   --____
                    <http://www.verizon.com/>____
                   *Gyan Mishra*____
                   /Network Solutions Architect /____
                   /[email-masked]<mailto:[email-masked]>
                   <mailto:[email-masked]>/____

                   /M 301 502-1347/

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 20 Dec 2021 21:59:42 -0500

At this point I would really like to hear from other people in the 
working group.

Is anyone other than the authors, Carlos, adn Frank, paying attention? 
Please?

Thank you,
Joel

On 12/20/2021 8:10 PM, Carlos Pignataro (cpignata) wrote:
> For this usage https://datatracker.ietf.org/doc/html/rfc8924#section-7.1 
> <https://datatracker.ietf.org/doc/html/rfc8924#section-7.1>, the O-bit 
> should be set. For any “vanilla” ICMP in traffic is not.
> 
>> On Dec 20, 2021, at 8:07 PM, Joel Halpern Direct 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> More generally, I assumed the O bit of the SFC NSH header was 
>> concerned with OAM related to SFC.  I think, although I could be 
>> wrong, that you read it more generally.  Again, if different folks 
>> read it differently, we benefit from clarity.
>>
>> Yours,
>> Joel
>>
>>> Sorry if I was not clear — I did not mean infer from a packet payload 
>>> the function type. I meant: look at the O-bit. If set, it is OAM. The 
>>> NP says how that OAM is encapsulated, which can include IP->ICMP.
>>>> On Dec 18, 2021, at 7:48 PM, Joel Halpern Direct 
>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>> Just commenting on one aspect of your note.  I think the definition 
>>>> of the SFC NSH header O bit is unclear.  It never occurred to me 
>>>> that one would expect an SFC classifier to not that an inncoming 
>>>> packet was carrying ICMP, look at the ICMP type, decide it was an 
>>>> OAM packet, and set the O bit in the SFC NSH header.  No, nothing in 
>>>> the OAM framework prohibits that.  But nothing leads one to expect 
>>>> it either.
>>>>
>>>> Personally, I rather like saying that the NSH O bit is to indicate 
>>>> the presence of OAM for SFFs.  But my personal view is largely 
>>>> irrelevant.
>>>>
>>>>> As dialogue in this thread seem to be getting intertwined and hard 
>>>>> to follow, with several weeks between responses, I will let the 
>>>>> chairs (I believe there’s no shepherd assigned) track the issues 
>>>>> and review comments (not sure if there’s an issue tracker)and take 
>>>>> it from here.
>>>>> Happy Holidays!
>>>>>> 12/15/21 午後8:00、Greg Mirsky <[email-masked] 
>>>>>> <mailto:[email-masked]> <mailto:[email-masked] 
>>>>>> <mailto:[email-masked]>>>のメール:
>>>>>>
>>>>>> Dear Carlos,
>>>>>> please find my notes below in-line under the GIM2>> tag. Attached 
>>>>>> is the diff highlighting two editorial changes.
>>>>>>
>>>>>> Regards,
>>>>>> Greg
>>>>>>
>>>>>> <[email-masked] <mailto:[email-masked]> 
>>>>>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>>>>
>>>>>>    Dear Greg,
>>>>>>
>>>>>> GIM2>> I don't know of a definition of an "OAM packet". Even more, 
>>>>>> RFC 8300 does not refer to any such definition, nor does it 
>>>>>> provide it.  draft-ietf-sfc-multi-layer-oam clarifies the use of O 
>>>>>> bit for the active SFC NSH OAM.
>>>>>> GIM2>> I don't see why you re-name the Active SFC OAM protocol 
>>>>>> into "One Active SFC OAM". That is not what is in the draft. Are 
>>>>>> you preparing another draft that you believe will update 
>>>>>> draft-ietf-sfc-multi-layer-oam by introducing an additional active 
>>>>>> SFC OAM protocol?
>>>>>> GIM2>> Protocols that use IP/UDP encapsulation are not active SFM 
>>>>>> OAM protocols even though they might be used as such. I expect 
>>>>>> that if the payload of NSH is an ICMPv6 echo request, the O bit 
>>>>>> will be cleared and the Next Protocol set to IPv6 value.
>>>>> CMP2: 1. please point to a reference that explains that using a 
>>>>> specific encapsulation prevents specific functionality.
>>>>> CMP2: Regarding the second sentence, thanks for sharing what you 
>>>>> expect — however that is different than what specs write :-) Why 
>>>>> would encapsulation dictate the value of the O bit? Take for 
>>>>> example BFD encapsulated in IP…
>>>>>> GIM2>> draft-ietf-sfc-multi-layer-oam does not include any 
>>>>>> processing that requires re-writing an NSH Context Header.
>>>>>> GIM2>> As a result of RFC 8300 not providing a reference or 
>>>>>> definition of an "OAM packet", this draft addresses that for the 
>>>>>> case of Active SFC OAM.
>>>>> CMP2: draft-ietf-sfc-multi-layer-oam does not provide the 
>>>>> definition (not needed frankly) of what you say needs defining.
>>>>>>
>>>>>> instruction or data, then the O bit will not be set. If one or 
>>>>>> more NSH Context Header includes OAM processing instructions or 
>>>>>> data, then, I assume, the O bit will be set. 
>>>>>> draft-ietf-sfc-multi-layer-oam does not change that. (I much 
>>>>>> appreciate Frank's comments and the discussion that helped clarify 
>>>>>> that scenario.)
>>>>>> GIM2>> draft-ietf-sfc-multi-layer-oam does not define how BFD to 
>>>>>> be carried in NSH environment. Will remove the reference to BFD in 
>>>>>> the next update.
>>>>>> Request/Reply" are used interchangeably. Will add an explicit note 
>>>>>> to that in the Terminology section.
>>>>> CMP2: And again, the only time the word “Framework appears in this 
>>>>> draft is as part of the Citation for RFC8924! :-)
>>>>> CMP2: The Abstract says “requirements”, "an encapsulation”, "a 
>>>>> mechanism to detect and localize defects”… you say now a 
>>>>> “framework” and “a protocol”.
>>>>> Best,
>>>>> Carlos.
>>>>>>
>>>>>>
>>>>>>    Best,
>>>>>>
>>>>>>    Carlos.
>>>>>>
>>>>>>>    On Nov 26, 2021, at 10:30 PM, Greg Mirsky 
>>>>>>> <[email-masked] <mailto:[email-masked]>
>>>>>>>    <mailto:[email-masked] <mailto:[email-masked]>>> 
>>>>>>> wrote:
>>>>>>>
>>>>>>>    Dear Carlos,
>>>>>>>    <[email-masked] <mailto:[email-masked]> 
>>>>>>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>>>>>
>>>>>>>> <mailto:fbrockne=[email-masked]>
>>>>>>>>        <mailto:fbrockne=[email-masked] 
>>>>>>>> <mailto:fbrockne=[email-masked]>>> wrote:
>>>>>>>>
>>>>>>>>        Hi Carlos,____
>>>>>>>>        __ __
>>>>>>>> <mailto:cpignata=[email-masked]>
>>>>>>>>        <mailto:cpignata=[email-masked] 
>>>>>>>> <mailto:cpignata=[email-masked]>>>
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>        <mailto:[email-masked] <mailto:[email-masked]>>>
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>        <mailto:[email-masked] 
>>>>>>>> <mailto:[email-masked]>>>; Gyan Mishra
>>>>>>>>        <[email-masked] <mailto:[email-masked]> 
>>>>>>>> <mailto:[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]>>; Joel Halpern 
>>>>>>>> Direct
>>>>>>>> <mailto:[email-masked]> 
>>>>>>>> <mailto:[email-masked] 
>>>>>>>> <mailto:[email-masked]>>>
>>>>>>>> <mailto:fbrockne=[email-masked]>
>>>>>>>>            <mailto:fbrockne=[email-masked] 
>>>>>>>> <mailto:fbrockne=[email-masked]>>>のメール:____
>>>>>>>>            __ __
>>>>>>>>            Hi Greg,____
>>>>>>>>            ____
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>            <mailto:[email-masked] 
>>>>>>>> <mailto:[email-masked]>>>
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>            <mailto:[email-masked] <mailto:[email-masked]>>>
>>>>>>>> <mailto:cpignata=[email-masked]>
>>>>>>>>            <mailto:cpignata=[email-masked] 
>>>>>>>> <mailto:cpignata=[email-masked]>>>; Gyan
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>            <mailto:[email-masked] 
>>>>>>>> <mailto:[email-masked]>>>; James N Guichard
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>            <mailto:[email-masked] 
>>>>>>>> <mailto:[email-masked]>>>;[email-masked] 
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>            <mailto:[email-masked] <mailto:[email-masked]>>; Joel 
>>>>>>>> Halpern Direct
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>            <mailto:[email-masked] 
>>>>>>>> <mailto:[email-masked]>>>
>>>>>>>> <inhttps://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-deployment-00#section-7.2>
>>>>>>>>            <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-deployment-00#section-7.2 
>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-deployment-00#section-7.2>>.
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>            <mailto:[email-masked] 
>>>>>>>> <mailto:[email-masked]>>> wrote:____
>>>>>>>>
>>>>>>>>                ____
>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2>
>>>>>>>>                <https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2 
>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2>>____
>>>>>>>>                ____
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>                <mailto:[email-masked] 
>>>>>>>> <mailto:[email-masked]>>>*On Behalf Of*Carlos
>>>>>>>>                Pignataro (cpignata)
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>                <mailto:[email-masked] 
>>>>>>>> <mailto:[email-masked]>>>
>>>>>>>>                *Cc:*James N Guichard
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>                <mailto:[email-masked] 
>>>>>>>> <mailto:[email-masked]>>>; Greg
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>                <mailto:[email-masked] 
>>>>>>>> <mailto:[email-masked]>>>;[email-masked] <mailto:[email-masked]>
>>>>>>>>                <mailto:[email-masked] <mailto:[email-masked]>>; Joel 
>>>>>>>> Halpern Direct
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>                <mailto:[email-masked] 
>>>>>>>> <mailto:[email-masked]>>>
>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02>
>>>>>>>>                <https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02 
>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02>> 
>>>>>>>> seems
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>                    <mailto:[email-masked] 
>>>>>>>> <mailto:[email-masked]>>>のメール:____
>>>>>>>>                    ____
>>>>>>>>                    Hi Carlos____
>>>>>>>>                    ____
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>                    <mailto:[email-masked] 
>>>>>>>> <mailto:[email-masked]>>> wrote:____
>>>>>>>>
>>>>>>>>                        Dear Gyan,____
>>>>>>>>                        ____
>>>>>>>>                        I hope all is well!____
>>>>>>>>                        ____
>>>>>>>> <https://datatracker.ietf.org/wg/lime/about/>
>>>>>>>>                    <https://datatracker.ietf.org/wg/lime/about/ 
>>>>>>>> <https://datatracker.ietf.org/wg/lime/about/>>____
>>>>>>>>                    ____
>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02>
>>>>>>>>                    <https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02 
>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02>>____
>>>>>>>>                    ____
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>                            <mailto:[email-masked] 
>>>>>>>> <mailto:[email-masked]>>>のメール:____
>>>>>>>>
>>>>>>>>                            ____
>>>>>>>>                            ____
>>>>>>>>                            Dear Chairs & All ____
>>>>>>>>                            ____
>>>>>>>> <mailto:cpignata=[email-masked]>
>>>>>>>>                            <mailto:[email-masked] 
>>>>>>>> <mailto:[email-masked]>>>
>>>>>>>>                            wrote:____
>>>>>>>>
>>>>>>>>                                Dear Greg,____
>>>>>>>>                                ____
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>                                    <mailto:[email-masked] 
>>>>>>>> <mailto:[email-masked]>>>
>>>>>>>>                                    のメール:____
>>>>>>>>                                    ____
>>>>>>>>                                    Dear Carlos,____
>>>>>>>>                                    thank you for your
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>                                    <mailto:[email-masked] 
>>>>>>>> <mailto:[email-masked]>>>
>>>>>>>>                                    wrote:____
>>>>>>>>
>>>>>>>>                                        Hello, WG,____
>>>>>>>>                                        ____
>>>>>>>>                                        In
>>>>>>>>                                        reviewing 
>>>>>>>>                                                 OAM command or 
>>>>>>>>                                                 Context 
>>>>>>>> Header(s).____
>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2>
>>>>>>>>                                <https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2 
>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2>>____
>>>>>>>>                                ____
>>>>>>>>                                        or 
>>>>>>>> draft-mymb-sfc-nsh-allocation-timestamp.____
>>>>>>>>
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>                                            <mailto:[email-masked] 
>>>>>>>> <mailto:[email-masked]>>>
>>>>>>>>                                            のメール:____
>>>>>>>>                                            ____
>>>>>>>>                                            I have received a polite
>>>>>>>>                                            request with explanation
>>>>>>>>                                            for delay asking for
>>>>>>>>                                            more time to read and
>>>>>>>>                                            review the subject
>>>>>>>>                                            document.  Given the
>>>>>>>>                                            state of the working
>>>>>>>>                                            group, i want to
>>>>>>>>                                            encourage any and all
>>>>>>>>                                            review.  So I am
>>>>>>>>                                            extending the last call
>>>>>>>>                                            by two additional weeks.
>>>>>>>>
>>>>>>>>                                            Please read and review
>>>>>>>>                                            the document.
>>>>>>>>                                            Also, if you are willing
>>>>>>>>                                            to serve as shepherd for
>>>>>>>>                                            this, please let the
>>>>>>>>                                            chairs know.  (Don't
>>>>>>>>                                            worry if you have not
>>>>>>>>                                            shepherded a document
>>>>>>>>                                            before.  The chairs are
>>>>>>>>                                            more than happy to help
>>>>>>>>                                            you with the process.)
>>>>>>>>
>>>>>>>>                                            Thank you,
>>>>>>>>                                            Joel
>>>>>>>>
>>>>>>>>                                            <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>>____
>>>>>>>>
>>>>>>>>                                ____
>>>>>>>> [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/>>____
>>>>>>>>                            *Gyan Mishra*____
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>                            <mailto:[email-masked] 
>>>>>>>> <mailto:[email-masked]>>/____
>>>>>>>>
>>>>>>>>                            /M 301 502-1347/____
>>>>>>>>
>>>>>>>>                            ____
>>>>>>>>
>>>>>>>>                        ____
>>>>>>>>
>>>>>>>>                    --____
>>>>>>>>                     <http://www.verizon.com/ 
>>>>>>>> <http://www.verizon.com/>>____
>>>>>>>>                    *Gyan Mishra*____
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>                    <mailto:[email-masked] 
>>>>>>>> <mailto:[email-masked]>>/____
>>>>>>>>
>>>>>>>>                    /M 301 502-1347/
>>>>>>>>
>>>>>>>
>>>>>>