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

["Carlos Pignataro (cpignata)" <[e-mail]>]

Dear Greg,

Please see inline.

Best,

Carlos.

On Nov 24, 2021, at 10:44 AM, Greg Mirsky <[e-mail]<mailto:[e-mail]>> wrote:

Dear Carlos,
please find more responses in-line below under the GIM2>> tag.

Regards,
Greg

On Fri, Nov 19, 2021 at 5:33 PM Carlos Pignataro (cpignata) <[e-mail]<mailto:[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]<mailto:[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]<mailto:[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.
GIM2>> I don't think that the proposed mechanism discards or negates any of the tools listed in RFC 8924. SFC NSH Echo Request/Reply is targeted to specifically SFC NSH operational needs is not to replace but to complement other OAM tools. The choice of which tool from the SFC OAM toolbox to use is, as always, with vendors and operators.

CMP2: Sorry if I was not clear, let me ask differently. Where is the documented tradeoff and decision for creating a new protocol versus extending existing ones which partially address requirements? Indeed, I agree operators and vendors have a choice, my question is in regards to the WG decision to build new vs. extend.




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

CMP2: You seem to have missed these 3 comments. Could you please address?



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.
GIM2>> I believe that the WG has demonstrated its support for the proposed solution.

CMP2: I thought statements like these are within the scope of a WG chair.
CMP2: From a technical perspective, it is a useful engineering piece of data to understand why a new protocol.

Anyone can propose an alternative technical solution in the traditional IETF form.


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?
GIM2>> I was told of interest in developing implementations based on the mechanism defined. Certain hesitation to be an early adopter is understandable to me.

CMP2: Shall I understand this as you cannot point to any implementation?


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.
GIM2>> Looking at this list, the SFC NSH Echo Request/Reply mechanism is not an alternative to BFD or IOAM.


CMP2: ICMP?





   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?
GIM2>> SFC Active OAM Header is a part of an active SFC NSH OAM packet.

CMP2: In that case, shall I understand that the “SFC Active OAM Header” cannot be part of other OAM packet. In that case I am very confused as I read:
CMP2: "      Msg Type - six bits long field identifies OAM protocol, e.g., Echo"
CMP2: "      Request/Reply or Bidirectional Forwarding Detection."
CMP2: Why would BFD be carried in the middle of SFC Active OAM? Why not use the NSH Next Protocol as intended?




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?
GIM2>> I think that it is helpful to provide some operational suggestions in the Operational Considerations section. Will work with co-authors.



         - 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?
GIM2>> In Section 6.5.4 of the draft:
    Suppose a specialized information element (e.g., IPv6 Flow Label
   [RFC6437] or Flow ID [I-D.ietf-sfc-nsh-tlv]) is used for distributing
   the load across Equal Cost Multi-Path or Link Aggregation Group
   paths.  In that case, such an element MAY also be used for the SFC
   OAM traffic.  Doing so is meant to induce the SFC Echo Request to
   follow the same RSP as the monitored flow.


CMP2: I may have misunderstood — if so apologies in advance — however, when I read "a Fixed-Length Context Header or Variable-Length Context Header(s) contain an OAM command or data” I thought Context Header (e.g., MD Type 1) was user for OAM, it could not be used for Flow ID as well.



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.
GIM2>> I am trying to understand the question. RFC 7799, as I understand it, defines an active OAM packet as a specifically constructed test packet.

CMP2: RFC 7799 does not include the terms “OAM Command” or “OAM Data"


CMP: A user packet with marking, implicitly or explicitly, is not an OAM packet.
GIM2>> Frank has brought very good points and suggested excluding hybrid OAM. Now the text is applicable only to active SFC NSH OAM:

CMP2: I agree with removing any Hybrid OAM from the “SFC Active OAM” document. For sure.
CMP2: at the same time, what specifically needs to be redefined for the O-bit (as opposed to say “use it as intended in 8300”)?

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.




   *  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.
GIM2>> We've agreed with Frank to not discuss hybrid SFC NSH OAM in this draft.

CMP2: Sounds good — why does the O-bit need to be discussed in any case?


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.
GIM2>> The purpose of the specification is to address specific SFC NSH OAM requirements. The proposed solution is one of possible that can be implemented. Encapsulation efficiency is a benefit.


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.
GIM2>> draft-ietf-sfc-multi-layer-oam does not include BFD in SFC NSH in its scope.

CMP2: The text in the document that I quoted above seems to contradict your statement.




      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.
GIM2>> RFC 8592 has been published through the Independent Stream Editor. As I understand it, draft-mymb-sfc-nsh-allocation-timestamp is also in the ISE track. I'll reach out to the authors of draft-mymb-sfc-nsh-allocation-timestamp to see if any considerations should be added in their document.

CMP2: I would suggest that this document also needs to figure out non-clashing proposals.




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.
GIM2>> I think that RFC 8924 has firmly established that none of the analyzed OAM tools completely addresses all the SFC NSH OAM requirements. Can a combination of tools do the job? I don't know. What is easier seems a subjective issue.  If anyone has an alternative technical solution, I'll be glad to discuss that. Otherwise, it appears as hypothetical.

CMP2: I disagree with this approach in principle, as I’d expect the WG to compare feasibility and ROI of approaches before embarking in text. Just my humble opinion.




      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.
GIM2>> The sender of the SFC Echo Request includes SFC Reply Path TLV. The responder must use the Service Index field in the NSH that encapsulates SFC NSH Echo Reply. I hope that clarifies how the Service Index field is used.

CMP2: I am sorry, it doesn’t. How does the sender of the request (i.e., based on what criteria) chooses the Service Index field value in the SFC Reply Path TLV in the SFC Active OAM packet?





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?
GIM2>> I assume you are thinking of IP/UDP encapsulation of SFC NSH. The receiver of SFC NSH Echo Reply would not check for port. Or are you referring to a different port?

CMP2: I am referring to the port that S6.5.3 of draft-ietf-sfc-multi-layer-oam mentions. "it has an outstanding SFC Echo Request sent from the UDP port that matches destination UDP port number of the received packet;”
CMP2: Based on that the question stands.






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.
GIM2>> We'll address that in the new Operational Considerations section.

CMP2: Look forward to reviewing. The text in Section 6.6 still has issues.




   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.

CMP2: You seem to have skipped this comment.




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.
GIM2>> Thank you for the suggestion. We'll mention that in the Operational Considerations section.



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.
GIM2>> The NSH's Next Protocol field is in the fixed position. Getting to SFC NSH active OAM doesn't seem to require parsing TLVs, SFC NSH Context Headers can be simply skipped.

CMP2: Concern stands. What is the value of this linked protocol identification check?

CMP2: Thanks again, and best,

CMP2: Carlos.




   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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sfc