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

[Greg Mirsky <[e-mail]>]

Hi Frank,
thank you for your comments and suggestions on the updated text. Below is
the its new version:
The rules for
   interpreting the values of the O bit and the "Next Protocol" field
   are as follows:

   *  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 command or data.

         - The "Next Protocol" field determines the type of the 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 an SFC NSH Context Header(s).

         - The payload determined by the "Next Protocol" field MUST be
         present.

   *  O bit is clear, and the "Next Protocol" field is set to Active SFC
      OAM (TBA1):

         - Erroneous combination.  An implementation MUST report it.
         The notification mechanism is outside the scope of this
         specification.  The packet SHOULD be dropped.  An
         implementation MAY have control to enable processing of the OAM
         payload.

I also have a question. You've noted:

The O-bit would only be set if the traffic is active OAM traffic.

Then, as I understand it, O-bit would not indicate the content of SFC NSH
Context Headers. Right? If we, the SFC WG, agree with this definition of
the O-bit, then we can use it to replace the proposed in the draft:
 OLD TEXT:
      O bit: Setting this bit indicates an OAM command and/or data in
      the NSH Context Header or packet payload.
NEW TEXT:
      O bit: Setting this bit indicates an active OAM in the NSH packet
payload.

What are your thoughts?

Regards,
Greg

On Tue, Nov 23, 2021 at 1:00 PM Frank Brockners (fbrockne) <
[e-mail]> wrote:

> Hi Greg,
>
>
>
> Please see inline.
>
>
>
> *From:* Greg Mirsky <[e-mail]>
> *Sent:* Tuesday, 23 November 2021 18:30
> *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 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?
>
>
>
> …FB: Yes – an IPv6 packet with IOAM in an extension header would be just a
> “regular” packet for NSH – and the O-bit would be clear.
> And for the case, where IOAM would be encapsulated with NSH (as a next
> header), the O-bit would also be clear if regular user traffic is carried.
> The O-bit would only be set if the traffic is active OAM traffic.
>
>
>
> Cheers, Frank
>
>
>
> 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*
>
>
>
>
>
>