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

[Greg Mirsky <[e-mail]>]

Hi Frank,
thank you for your suggestions to improve the proposed text. I'll work with
the text and return with the updated version. I thought about the IOAM
layering case. Wouldn't for SFC NSH it be just an IPv6 payload? As
you've mentioned, an IPv6 packet that has the IOAM Header and data-fields
would not be processed by an SFF or SF. Thus, from SFC NSH, it should not
be identified as an OAM packet and the O-bit must be clear. What do you
think?

Regards,
Greg

On Tue, Nov 23, 2021 at 6:33 AM Frank Brockners (fbrockne) <
[e-mail]> wrote:

> 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
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
>
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
>
>
>