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

[Greg Mirsky <[e-mail]>]

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) <
[e-mail]> 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 <[e-mail]> 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) <
> [e-mail]> 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=[e-mail]> 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=[e-mail]>
>>
>> *Sent:* Tuesday, 23 November 2021 15:44
>> *To:* Frank Brockners (fbrockne) <[e-mail]>
>> *Cc:* Greg Mirsky <[e-mail]>; Gyan Mishra <
>> [e-mail]>; James N Guichard <[e-mail]
>> >; [e-mail]; Joel Halpern Direct <[e-mail]>
>> *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=[e-mail]>のメール:
>>
>> Hi Greg,
>>
>> Thanks for the quick reply. Please see inline.
>>
>> *From:* Greg Mirsky <[e-mail]>
>> *Sent:* Monday, 22 November 2021 23:16
>> *To:* Frank Brockners (fbrockne) <[e-mail]>
>> *Cc:* Carlos Pignataro (cpignata) <cpignata=[e-mail]>;
>> Gyan Mishra <[e-mail]>; James N Guichard <
>> [e-mail]>; [e-mail]; Joel Halpern Direct <
>> [e-mail]>
>> *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) <
>> [e-mail]> 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 <[e-mail]> *On Behalf Of *Carlos Pignataro
>> (cpignata)
>> *Sent:* Monday, 22 November 2021 00:52
>> *To:* Gyan Mishra <[e-mail]>
>> *Cc:* James N Guichard <[e-mail]>; Greg Mirsky <
>> [e-mail]>; [e-mail]; Joel Halpern Direct <
>> [e-mail]>
>> *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 <[e-mail]>のメール:
>>
>> Hi Carlos
>>
>> Many Thanks for your feedback
>>
>> Responses in-line
>>
>> On Fri, Nov 19, 2021 at 11:39 PM Carlos Pignataro (cpignata) <
>> [e-mail]> 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 <[e-mail]>のメール:
>>
>>
>>
>> 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=
>> [e-mail]> 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 <[e-mail]>のメール:
>>
>> 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) <
>> [e-mail]> 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 <[e-mail]>のメール:
>>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sfc
>>
>>
>> _______________________________________________
>> sfc mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sfc
>>
>> --
>> <image001.jpg> <http://www.verizon.com/>
>> *Gyan Mishra*
>> *Network Solutions Architect *
>> *Email [e-mail] <[e-mail]>*
>>
>> *M 301 502-1347*
>>
>>
>>
>>
>> --
>> <image001.jpg> <http://www.verizon.com/>
>> *Gyan Mishra*
>> *Network Solutions Architect *
>> *Email [e-mail] <[e-mail]>*
>>
>> *M 301 502-1347*
>>
>>
>>
>