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

[Greg Mirsky <[e-mail]>]

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) <
[e-mail]> 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 <[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.
>
>
> 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.
>
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.

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

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

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

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

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

>
>
>>
>> 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.
>
>
> CMP2: Whether you remove it from your draft, it is still another SFC
> Active OAM Protocol.
>
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: 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.
>
GIM3>> I'll repeat my question here. Would an ICMP packet always have the O
bit set in its NSH?

>
> 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 <[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*
>>>
>>>
>>>
>> <Diff_ draft-ietf-sfc-multi-layer-oam-17.txt -
> draft-ietf-sfc-multi-layer-oam-18.txt.html>
>
>
>