Re: [sfc] Shepherd's review of draft-ietf-sfc-multi-layer-oam-21

[Greg Mirsky <[e-mail]>]

Hi Donald,
apologies for my sloppiness. Will take care of these glitches and be ready
for the gate to open.

Best regards,
Greg

On Mon, Jul 18, 2022 at 4:43 PM Donald Eastlake <[e-mail]> wrote:

> Hi Greg:
>
> I'm OK with the candidate version -22 you sent out except for the
> following trivial glitches. Suggest you fix these and upload next week
> when auto-submissions are re-enabled.
>
> "fieldand" -> "field and"
>
> Delete period in line below:
>   TTL expired (as per [RFC8300]) may be sending the Echo Reply. is
>
> "Figure 11Figure 10" -> "Figure 10"
>
> "ofSFC" -> "of SFC"
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  [e-mail]
>
> On Sun, Jul 17, 2022 at 3:07 PM Greg Mirsky <[e-mail]> wrote:
> >
> > Hi Donald,
> > thank you for your thorough and extremely helpful feedback. We accepted
> all the updates you've suggested. Attached, please find the diff
> highlighting the applied changes and the copy of the working version. I
> hope that I captured all proposed changes and applied updates correctly.
> >
> > Regards,
> > Greg
> >
> > On Sat, Jul 16, 2022 at 1:11 PM Donald Eastlake <[e-mail]>
> wrote:
> >>
> >> Hi,
> >>
> >> See below:
> >>
> >>       This document defines how active Operation, Administration and
> >>       Maintenance (OAM), per [RFC7799] definition of active OAM, is
> >>       identified when Network Service Header (NSH) is used as the SFC
> >>
> >> (NSH) -> (NSH [RFC8300])
> >>
> >>       encapsulation.  Following the analysis of SFC OAM in [RFC8924],
> this
> >>       document applies and, when necessary, extends requirements listed
> in
> >>       Section 4 of [RFC8924] for the use of active OAM in an SFP
> supporting
> >>       fault management and performance monitoring.  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.  This mechanism enables on-demand Continuity Check,
> >>
> >> "Check," -> "Check and"
> >>
> >>       Connectivity Verification, among other operations over SFC in
> >>
> >> "Verification," -> "Verification"
> >>
> >>       networks, addresses functionalities discussed in Sections 4.1,
> 4.2,
> >>
> >> ", addresses" -> " and addresses"
> >>
> >>       and 4.3 of [RFC8924].  SFC Echo Request and Echo Reply, defined in
> >>       this document, can be used with encapsulations other than NSH, for
> >>       example, using MPLS encapsulation, as described in [RFC8595].  The
> >>       applicability of the SFC Echo Request/Reply mechanism in SFC
> >>       encapsulations other than NSH is outside the scope of this
> document.
> >>
> >>
> >>          REQ#8: SFC OAM MUST be able to trigger on-demand FM with
> responses
> >>          being directed towards the initiator of such proxy request.
> >>
> >> Why is this a "proxy" request? Why not just "such a request."?
> >>
> >>
> >>    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
> >>
> >> Delete ", respectively".
> >>
> >>
> >>          The Echo Request Flags is a two-octet bit vector field.  Note
> that
> >>          a flag defined in the Flags field of the SFC Active OAM header
> in
> >>          Figure 2 has no implication of those defined in the Echo
> Request
> >>          Flags field of an Echo Request/Reply message.
> >>
> >>  Editorial: suggest replacement paragraph:
> >>
> >>          The Echo Request Flags is a two-octet bit vector field.  A
> >>          flag defined in the Flags field of the SFC Active OAM header
> >>          in Figure 2 has no implication for those defined in the Echo
> >>          Request Flags field of an Echo Request/Reply message.
> >>
> >>
> >>
> >>          Return Codes and Subcodes are one-octet fields each.  These
> can be
> >>          used to inform the sender about the result of processing its
> >>          request.  Initial Return Code values are provided in Table 1.
> >>          For
> >>
> >> Delete "Initial".
> >>
> >>          all Return Code values defined in this document, the value of
> the
> >>          Return Subcode field MUST be set to zero.
> >>
> >>          The Sender's Handle is a four-octet field.  It MUST be filled
> in
> >>          by the sender of the Echo Request and returned unchanged by the
> >>          Echo Reply sender (if a reply mandated).  The sender of the
> Echo
> >>
> >> "reply mandated" -> "replay is mandated"
> >>
> >>          Request SHOULD use a pseudo-random number generator to set the
> >>          value of the Sender's Handle field.
> >>
> >> "generator to" -> "generator [RFC4086] to"
> >>
> >>
> >>          The Sequence Number is a four-octet field, and it is assigned
> by
> >>          the sender and can be, for example, used to detect missed
> replies.
> >>          Initial Sequence Number MUST be randomly generated and then
> SHOULD
> >>
> >> Replace beginning of above line with
> >>          The initial Sequence Number MUST be pseudo-randomly generated
> [RFC4086]
> >>
> >>          be monotonically increasing in the course of the test session.
> >>
> >>
> >>       TLV is a variable-length construct.  Multiple TLVs MAY be placed
> in
> >>       an SFC Echo Request/Reply packet.  None, one or more sub-TLVs may
> be
> >>       enclosed in a TLV, subject to the semantics of the (outer) TLV.
> >>
> >> "in a TLV" -> "in the value part of a TLV"
> >>
> >>       Figure 4 presents the format of an SFC Echo Request/Reply TLV,
> where
> >>       fields are defined as follows:
> >>
> >>
> >>          Type - a one-octet field that characterizes the interpretation
> of
> >>          the Value field.  The value of the Type field determines its
> >>          interpretation and encoding.  Type values allocated according
> to
> >>          Section 10.4.
> >>
> >> In the above paragraph, the 2nd sentence seems redundant and could be
> >> deleted. Also "values allocated" -> "values are allocated"
> >>
> >>
> >>          Length - a two-octet field equal to the Value field's length in
> >>          octets.
> >>
> >> Suggest "octets." -> "octets as an unsigned integer."
> >>
> >>
> >>    6.1.  Return Codes
> >>
> >>       The value of the Return Code field is set to zero by the sender
> of an
> >>
> >> How about"is set" -> "MUST be set"
> >>
> >>       Echo Request.  The receiver of said Echo Request can set it to
> one of
> >>       the values listed in Table 1 in the corresponding Echo Reply that
> it
> >>       generates (in cases when the reply is requested).
> >>
> >>
> >>    6.2.  Authentication in Echo Request/Reply
> >>
> >>       Authentication can be used to protect the integrity of the
> >>       information in SFC Echo Request and/or Echo Reply.  In the
> [RFC9145]
> >>       a variable-length Context Header has been defined to protect the
> >>       integrity of the NSH and the payload.  The header can also be used
> >>       for the optional encryption of sensitive metadata.  MAC#1 (Message
> >>       Authentication Code) Context Header is more suitable for the
> >>       integrity protection of active SFC OAM, particularly of the
> defined
> >>       in this document SFC Echo Request and Echo Reply.  On the other
> hand,
> >>
> >> I think the lines above read better if "defined in this document" is
> >> moved to the end of the sentence.
> >>
> >>       using MAC#2 Context Header allows the detection of mishandling of
> the
> >>       O-bit by a transient SFC element.
> >>
> >>
> >>       Value of the Reply Mode field MAY be set to:
> >>
> >> -> "Value of the Reply Mode field MUST be set to one of the following:"
> >>
> >>       *  Do Not Reply (1) if one-way monitoring is desired.  If the Echo
> >>          Request is used to measure synthetic packet loss, the receiver
> may
> >>          report loss measurement results to a remote node.  Note that
> ways
> >>
> >> "Note that ways" -> "Ways"
> >>
> >>          of learning the identity of that node are outside the scope of
> >>          this specification.
> >>
> >>       *  Reply via an IPv4/IPv6 UDP Packet (2) value likely will be the
> >>          most used.
> >>
> >> -> "Reply via an IPv4/IPv6 UDP packet (2). This will likely be the
> >> most common value."
> >>
> >>       *  Reply via Application-Level Control Channel (3) value if the
> SFP
> >>          may have bi-directional paths.
> >>
> >> -> "Reply via Application-Level Control Channel (3). Useful if the SFP
> >> has bi-directional paths."
> >>
> >>       *  Reply via Specified Path (4) value to enforce the use of the
> >>
> >> "(4) value to enforce the" -> "(4). This value requests the"
> >>
> >>          particular return path specified in the included TLV to verify
> bi-
> >>          directional continuity and also increase the robustness of
> >>          the
> >>
> >> "and also" -> "and may also"
> >>
> >>          monitoring by selecting a more stable path.  Section 6.5.1
> >>          provides an example of communicating an explicit path for the
> Echo
> >>          Reply.
> >>
> >>       *  Reply via an IPv4/IPv6 UDP Packet with the data integrity
> >>          protection (5) value to enforce use of the MAC Context Header
> >>
> >> "(5) value to enforce use" -> "(5). This value requests the use"
> >>
> >>          [RFC9145].
> >>
> >>       *  Reply via Application-Level Control Channel with the data
> >>          integrity protection (6) value to enforce use of the MAC
> Context
> >>
> >> "(6) value to enforce use" -> "(6). This value requests the use"
> >>
> >>          Header [RFC9145].
> >>
> >>       *  Reply via Specified Path with the the data integrity protection
> >>          (7) value to enforce use of the MAC Context Header [RFC9145].
> >>
> >> "(7) value to enforce use" -> "(7). This value requests the use"
> >>
> >>    6.3.1.  Source TLV
> >>
> >>       Responder to the SFC Echo Request encapsulates the SFC Echo Reply
> >>
> >> "Responder" -> "The responder"
> >>
> >>       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).
> >>
> >>
> >>       A single Source ID TLV for each address family, i.e., IPv4 and
> IPv6,
> >>       MAY be present in an SFC Echo Request message.  If the Source TLVs
> >>       for both address families are present in an SFC Echo Request
> message,
> >>       the SFF MUST NOT replicate an SFC Echo Reply but choose the
> >>       destination IP address for the SFC Echo Reply based on the local
> >>
> >> "the SFC Echo Reply based" -> "the one SFC Echo Reply it sends based"
> >>
> >>       policy.  If more than one Source ID TLV per the address family is
> >>       present, the receiver MUST use the first TLV and ignore the rest.
> >>
> >>
> >>    6.4.  SFC Echo Request Reception
> >>
> >>       Punting received SFC Echo Request to the control plane is
> triggered
> >>
> >> "Punting received" -> "Punting a received"
> >>
> >>       by one of the following packet processing exceptions: NSH TTL
> >>       expiration, NSH Service Index (SI) expiration, or the receiver is
> the
> >>       terminal SFF for an SFP.
> >>
> >>       Firstly, if the SFC Echo Request is integrity-protected, the
> >>       receiving SFF first MUST verify the authentication.  Then the
> >>       receiver SFF MUST validate the Source TLV, as defined in
> >>       Section 6.3.1.  Suppose the authentication validation has failed
> and
> >>       the Source TLV is considered properly formatted.  In that case,
> the
> >>       SFF MUST send to the system identified in the Source TLV (see
> >>       Section 6.5), according to a rate-limit control mechanism, an SFC
> >>       Echo Reply with the Return Code set to "Authentication failed" and
> >>       the Subcode set to zero.  If the Source TLV is determined
> malformed,
> >>       the received SFC Echo Request processing is stopped, the message
> is
> >>       dropped, and the event SHOULD be logged, according to a
> rate-limiting
> >>       control for logging.  Then, the SFF that has received an SFC Echo
> >>       Request verifies the rest of the received packet's general sanity.
> >>       If the packet is not well-formed, the receiver SFF SHOULD send an
> SFC
> >>       Echo Reply with the Return Code set to "Malformed Echo Request
> >>       received" and the Subcode set to zero under the control of the
> rate-
> >>       limiting mechanism to the system identified in the Source TLV (see
> >>       Section 6.5).  If there are any TLVs that the SFF does not
> >>       understand, the SFF MUST send an SFC Echo Reply with the Return
> Code
> >>       set to 2 ("One or more TLVs was not understood") and set the
> Subcode
> >>       to zero.  In the latter case, the SFF MAY include an Errored TLVs
> TLV
> >>       (Section 6.4.1) that, as sub-TLVs, contains only the misunderstood
> >>       TLVs.  Sender's Handle and Sequence Number fields are not examined
> >>       but are included in the SFC Echo Reply message.  If the sanity
> check
> >>       of the received Echo Request succeeded, then the SFF at the end of
> >>       the SFP MUST set the Return Code value to 5 ("End of the SFP") and
> >>       the Subcode set to zero.  If the SFF is not at the end of the SFP
> and
> >>       the TTL value is 1, the value of the Return Code MUST be set to 4
> >>       ("TTL Exceeded") and the Subcode set to zero.  In all other cases,
> >>       SFF MUST set the Return Code value to 0 ("No Return Code") and the
> >>       Subcode set to zero.
> >>
> >> The above paragraph is very long and, I think, would be better
> >> reformatted as a numbered list or the like.
> >>
> >>
> >>          The Sub-TLV's Type the copy of the first octet of the not
> >>          understood or failed to be parced TLV.
> >>
> >> "Type the copy" -> "Type - a copy"
> >> "parced" -> "parsed"
> >>
> >>
> >>          The Sub-TLV Value field contains data that follow the Legth
> field
> >>          in the errored TLV.
> >>
> >> "Legth" -> "Length"
> >>
> >>    6.5.  SFC Echo Reply Transmission
> >>
> >>       The "Reply Mode" field directs whether and how the Echo Reply
> message
> >>       should be sent.  The Echo Request sender MAY use TLVs to request
> that
> >>       the corresponding Echo Reply be transmitted over the specified
> path.
> >>       Section 6.5.1 provides an example of a TLV that specifies the
> return
> >>       path of the Echo Reply.  Value 1 is the "Do not reply" mode and
> >>       suppresses the Echo Reply packet transmission.  The default value
> (2)
> >>       for the Reply mode field requests the responder to send the Echo
> >>       Reply packet out-of-band as IPv4 or IPv6 UDP packet.
> >>
> >> "requests the responder to send the" -> "requests sending the"
> >> "as IPv4" -> "as an IPv4"
> >>
> >>
> >>       The SFC Reply Path TLV carries the information that sufficiently
> >>       identifies the return SFP that the SFC Echo Reply message is
> expected
> >>       to follow.  The format of SFC Reply Path TLV is shown in Figure 8.
> >>
> >> Above and in this document below, there are many occurrences of
> >> "SFC Reply Path TLV" that I think should be globally changed to
> >> "Reply Service Function Path TLV".
> >>
> >>
> >>       *  SFC Reply Path Type: is a one-octet field, indicates the TLV
> that
> >>          contains information about the SFC Reply path.  IANA is
> requested
> >>          to assign value 3,
> >>
> >> Replacement point for the above:
> >>
> >>       *  Reply Service Function Path Type (3): This is is a one-octet
> >>          fieldand indicates the TLV that contains information about
> >>          the SFC Reply path.
> >>
> >>       *  Reserved - one-octet field.  The field MUST be zeroed on
> >>          transmission and ignored on receipt.
> >>
> >> " -" -> ": "
> >>
> >>       *  Length: is a two-octet field, MUST be equal to 4
> >>
> >>       *  Reply Service Function Path is used to describe the return path
> >>          that an SFC Echo Reply is requested to follow.
> >>
> >>       The format of the Reply Service Function Path field displayed in
> >>       Figure 9.
> >>
> >>
> >>            0                   1                   2                   3
> >>            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
> 0 1
> >>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>           |    Reply Service Function Path Identifier     | Service
> Index |
> >>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>
> >>              Figure 9: Reply Service Function Path Field Format
> >>
> >> I don't see any reason for Figure 9 to be separate from Figure 8. They
> >> could be integrated.
> >>
> >>
> >>       The destination SFF of the SFP being tested or the SFF at which
> SFC
> >>       TTL expired (as per [RFC8300]) may be sending the Echo Reply.  The
> >>       processing described below equally applies to both cases and is
> >>       referred to as responding SFF.
> >>
> >> I think things got slightly scrambled above. How about:
> >>
> >>       The destination SFF of the SFP being tested or the SFF at which
> >>       SFC TTL expired (as per [RFC8300]) may be sending the Echo Reply
> >>       is referred to as responding SFF.  The processing described
> >>       below equally applies to both cases.
> >>
> >>
> >>       *  if the matching to the Echo Request found, the value of the
> >>
> >> Replace above line with:
> >>
> >>       *  the matching SFC Echo Request is found, that is, the value of
> the
> >>
> >>          Sender's Handle in the Echo Request sent is equal to the value
> of
> >>          Sender's Handle in the Echo Reply received;
> >>
> >>       *  if all checks passed, the SFF checks if the Sequence Number
> >>          in the
> >>
> >> Replace above with:
> >>
> >>       *  all other checks and and the Sequence Number
> >>
> >>          Echo Request sent matches to the Sequence Number in the Echo
> Reply
> >>          received.
> >>
> >>
> >>       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
> >>
> >> How about "MAY" -> "SHOULD"?
> >>
> >>       OAM traffic.  Doing so is meant to induce the SFC Echo Request to
> >>       follow the same RSP as the monitored flow.
> >>
> >>    6.6.  Verification of the SFP Consistency
> >>
> >>       The consistency of an SFP can be verified by comparing the view of
> >>       the SFP from the control or management plane with information
> >>       collected from traversed by an SFC NSH Echo Request message.
> Every
> >>
> >> "traversed" -> "traversing"
> >>
> >>       SFF that receives the Consistency Verification Request (CVReq)
> >>
> >> "the Consistency" -> "a Consistency"
> >>
> >>       (specified in Section 6.6.1) MUST perform the following actions:
> >>
> >>       *  Collect information of the traversed by the CVReq packet SFs
> and
> >>
> >> Replace above line with:
> >>
> >>       *  Collect information about the SFs traversed by the CVReq
> packet and
> >>
> >>          send it to the ingress SFF as CVRep packet over IP network;
> >>
> >>       *  Forward the CVReq to the next downstream SFF if the one exists.
> >>
> >>       As a result, the ingress SFF collects information about all
> traversed
> >>       SFFs and SFs, information on the actual path the CVReq packet has
> >>       traveled.  That information is used to verify the SFC's path
> >>
> >> "is used" -> "can be used"
> >>
> >>       consistency.  The mechanism for the SFP consistency verification
> is
> >>       outside the scope of this document.
> >>
> >>
> >>    6.6.1.  SFP Consistency Verification packet
> >>
> >>       For the verification of an SFP consistency, two new types of
> messages
> >>       to the SFC Echo Request/Reply operation defined in Section 6 with
> the
> >>       following values detailed in Section 10.3.2:
> >>
> >> Replace above paragraph with the following:
> >>
> >>       For the verification of an SFP consistency, two types of SFC
> Active OAM
> >>       messages are defined in addition to the SFC Echo Request/Reply
> messages.
> >>       Their SFC Echo Request/Echo Response Message Types are as follows:
> >>
> >>       *  3 - SFP Consistency Verification Request
> >>
> >>       *  4 - SFP Consistency Verification Reply
> >>
> >>
> >>    6.6.2.  SFF Information Record TLV
> >>
> >>       For the received CVReq, an SFF is expected to include in the CVRep
> >>       message the information about SFs that are mapped to that SFF.
> The
> >>
> >> "mapped to" -> "available from"?
> >>
> >>       SFF MUST include SFF Information Record TLV (Figure 10) in CVRep
> >>       message.  Every SFF sends back a single CVRep message, including
> >>       information on all the SFs attached to the SFF on the SFP, as
> >>
> >> "the SFF" -> "that SFF"
> >>
> >>       requested in the received CVReq message using the SF Information
> sub-
> >>       TLV (Section 6.6.3).
> >>
> >>
> >>       The SFF Information Record TLV is a variable-length TLV that
> includes
> >>       the information of all SFs mapped to the particular SFF instance
> for
> >>
> >> "mapped to" -> "available from"
> >>
> >>       the specified SFP.  Figure 10 presents the format of an SFF
> >>       Information Record TLV, where fields are defined as the following:
> >>
> >>
> >>       If the NSH of the received SFC Echo Reply includes the MAC Context
> >>       Header [RFC9145], the authentication of the packet MUST be
> verified
> >>       before using any data.  If the verification fails, the receiver
> MUST
> >>       stop processing the SFF Information Record TLV and notify an
> >>       operator.  The notification mechanism SHOULD include control of
> rate-
> >>       limiting messages.  Specification of the notification mechanism is
> >>
> >> "limiting messages" -> "limited messages"
> >>
> >>       outside the scope of this document.
> >>
> >>    6.6.3.  SF Information Sub-TLV
> >>
> >>       Every SFF receiving CVReq packet MUST include the SF
> characteristic
> >>
> >> "receiving CVReq" -> "receiving a CVReq"
> >>
> >>       data into the CVRep packet.  The format of an SF Information
> sub-TLV,
> >>       included in a CVRep packet, is shown in Figure 11.
> >>
> >>
> >>          SF sub-TLV Type: Two-octets long field.  The value is (5)
> >>
> >> "Two" -> "one"
> >> since the first word after the colon is not capitalized in any of the
> cases
> >> below it should not be capitalized here or they should all be
> capitalized.
> >>
> >>          (Section 10.4).
> >>
> >>
> >>    6.6.4.1.  Multiple SFs as Hops of an SFP
> >>
> >>       Multiple SFs attached to the same SFF can be the hops of the SFP.
> >>       The service indexes of these SFs on thatSFP will be different.
> >>       Service function types of these SFs could be different or be the
> >>       same.  Information about all SFs MAY be included in the CVRep
> >>       message.  Information about each SF MUST be listed as separate SF
> >>       Information sub-TLVs in the CVRep message.
> >>
> >> Suggest adding to the end of the above paragraph: "The same SF can even
> >> appear more than once in an SFP with a different service index."
> >>
> >>
> >>    6.6.4.2.  Multiple SFs for load balance
> >>
> >>       Multiple SFs may be attached to the same SFF to spread the load;
> in
> >>       other words, that means that the particular traffic flow will
> >>       traverse only one of these SFs.  These SFs have the same Service
> >>       Function Type and Service Index.  For this case, the SF
> identifiers
> >>       and SF ID Type of all these SFs will be listed in the SF
> Identifiers
> >>       field and SF ID Type in a single SF information sub-TLV of the
> CVRep
> >>       message.  The number of these SFs can be calculated using the SF
> ID
> >>       Type and the value of the Length field of the sub-TLV.
> >>
> >> I found the second half of the above paragraph somewhat confusing.
> >> Sounds like the SF ID Type would be included for each of the SFs but
> >> their ID Types will all be the same. I suggest replacing the 2nd part
> >> of this paragraph after the first two sentences with something like
> >> the following:
> >>
> >>       For this case, the SF ID Type, which must be the same for all of
> >>       these SFs, appears once but all of their SF Identifiers will
> >>       appear concatenated in the SF Identifier area of the Sub-TLV
> >>       (see Figure 11). The number of these SFs can be calculated from
> >>       the SF ID Type and the value of the Length field of the sub-TLV.
> >>
> >>
> >>       It is RECOMMENDED that implementations throttle the SFC ping
> traffic
> >>       going to the control plane to mitigate potential Denial-of-Service
> >>       attacks.
> >>
> >> I found the occurrence of "ping" here to be startling. There are two
> >> other occurrences of "ping" in this document, both earlier in this
> >> Security Considerations section, but in a different context.
> >> Otherwise, ping does not occur anywhere else. My guess is that you
> >> means SFC Echo Request/Echo Reply. I suggest you use that here instead
> >> of "ping". Alternatively, you could make the major change of carefully
> >> and prominently defining ping and using it throughout the document.
> >>
> >>
> >>       SFC NSH Echo Request/Reply provides essential OAM functions for
> >>       network operators.  SFC NSH Echo Request/Reply is intended to
> detect
> >>       and localize defects in an SFC.  For example, by comparing
> results of
> >>       the trace function in operational and failed states, an operator
> can
> >>       locate the defect, e.g., the connection between SFF1 and SFF2
> >>       (Figure 1).  Note that a more specific failure location can be
> >>
> >> "Note that" -> "After narrowing down a failure to an overlay link,"
> >>
> >>       determined using OAM tools in the underlay network.  The mechanism
> >>       defined in this document can be used on-demand or for periodic
> >>       validation of an SFP or RSP.  Because the protocol uses
> information
> >>       in the SFC control plane, an operator must have the ability to
> >>       control the frequency of transmitted Echo Request and Reply
> messages.
> >>
> >> Assuming I understand the above sentence, how about replacing it with
> >> the following:
> >>
> >>       Because the protocol makes use of the control plane which may
> >>       have limited capacity, an operator must be able to rate limit
> >>       Echo Request and Echo Reply messages.
> >>
> >>
> >>    10.  IANA Considerations
> >>
> >> Suggest inserting here:
> >>
> >>       "The terms used in the IANA Considerations below are intended to
> >>       be consistent with [RFC8126]."
> >>
> >>
> >>       [RFC Editor, please update all occurrences of TBA1 with the value
> >>       assigned by IANA Action.]
> >>
> >> The above RFC Editor note is unnecessary and could be deleted.
> >>
> >>
> >>    10.2.  SFC Active OAM
> >>
> >>       IANA is requested to create a new SFC Active OAM registry.
> >>
> >> If you are asking IANA to "create" something, the word "new" is
> >> redundant. If it wasn't "new", then you would be asking IANA to
> >> "change" something, not "create" it. Suggest the following replacement
> >> for the above sentence:
> >>
> >>       IANA is requested to create an SFC Active OAM registry
> >>       containing the sub-registries listed below.
> >>
> >> Do you actually mean "web page" rather than registry? There doesn't
> >> seem to be anything in this "registry" other than "sub-registries". Of
> >> course, the RFC/IANA terminology for all this is highly inconsistent...
> >>
> >>
> >>    10.2.1.  SFC Active OAM Message Type
> >>
> >>       IANA is requested to create in the SFC Active OAM registry a new
> sub-
> >>       registry as follows:
> >>
> >> "new" -> ""
> >>
> >> So, the problem with the sub-registry below is that the SFC Active OAM
> >> Message Type file looks to me like it has only six bits, not 16 bits,
> >> so there are only 64 values. Given that, I suggest making it all "IETF
> >> Review". You could do something like changing the 2nd half from "First
> >> Come First Served" to "Specification Required" but that would require
> >> the appointment of experts. I generally favor liberal IANA assignment
> >> criterion but, as I say, in this case I think IETF Review might be
> >> best.
> >>
> >>
> >>          Sub-registry Name: SFC Active OAM Message Type.
> >>
> >>          Assignment Policy:
> >>
> >>          2-32767 IETF Review
> >>
> >> "23767" -> "31"
> >>
> >>          32768-65530 First Come First Served
> >>
> >> -> "32-62"
> >>
> >> Similar changes in table below with final Reserved value being 63.
> >>
> >>          Reference: [this document]
> >>
> >>          +===============+=============================+===============+
> >>          | Value         |         Description         | Reference     |
> >>          +===============+=============================+===============+
> >>          | 0             |           Reserved          | This document |
> >>          +---------------+-----------------------------+---------------+
> >>          | 1             | SFC Echo Request/Echo Reply | This document |
> >>          +---------------+-----------------------------+---------------+
> >>          | 2 - 32767     |          Unassigned         | This document |
> >>          +---------------+-----------------------------+---------------+
> >>          | 32768 - 65530 |          Unassigned         | This document |
> >>          +---------------+-----------------------------+---------------+
> >>          | 65531 - 65534 |          Unassigned         | This document |
> >>          +---------------+-----------------------------+---------------+
> >>          | 65535         |           Reserved          | This document |
> >>          +---------------+-----------------------------+---------------+
> >>
> >>                        Table 3: SFC Active OAM Message Type
> >>
> >>
> >>    10.2.2.  SFC Active OAM Header Flags
> >>
> >>       IANA is requested to create in the SFC Active OAM registry the new
> >>
> >> "registry the new" -> "Registry the"
> >>
> >>       sub-registry SFC Active OAM Flags.
> >>
> >>
> >>    10.3.  SFC Echo Request/Echo Reply Parameters
> >>
> >>       IANA is requested to create a new SFC Echo Request/Echo Reply
> >>       Parameters registry.
> >>
> >> I would put this 10.3 stuff and the 10.4 stuff under the SFC Action
> >> OAM registry rather than trying to nest deeper. Depending on how IANA
> >> interprets this, it may result in multiple short IANA web pages, which
> >> is kind of a pain in my mind. Better to have fewer web pages with more
> >> registries per page.
> >>
> >>
> >>    10.3.1.  SFC Echo Request Flags
> >>
> >>       IANA is requested to create in the SFC Echo Request/Echo Reply
> >>       Parameters registry the new sub-registry SFC Echo Request Flags.
> >>
> >> "new" -> ""
> >>
> >> I'm not sure what will happen or what you think will happen with IANA
> >> web pages / Registries / Sub-Registries"...
> >>
> >>       This sub-registry tracks the assignment of 16 flags in the SFC
> Echo
> >>       Request Flags field of the SFC Echo Request message.  The flags
> are
> >>       numbered from 0 (most significant bit, transmitted first) to 15.
> >>
> >>       New entries are assigned by Standards Action.
> >>
> >>                   +============+=============+===============+
> >>                   | Bit Number | Description | Reference     |
> >>                   +============+=============+===============+
> >>                   | 15-0       |  Unassigned | This document |
> >>                   +------------+-------------+---------------+
> >>
> >>                         Table 5: SFC Echo Request Flags
> >>
> >>    10.3.2.  SFC Echo Request/Echo Reply Message Types
> >>
> >>       IANA is requested to create in the SFC Echo Request/Echo Reply
> >>       Parameters registry the new sub-registry as follows:
> >>
> >> "new" -> ""
> >>
> >>          Sub-registry Name: Message Types
> >>
> >>          Assignment Policy:
> >>
> >>          5 - 175 IETF Review
> >>
> >>          176 - 239 First Come First Served
> >>
> >>          240 - 251 Experimental
> >>
> >>          252 - 254 Private Use
> >>
> >> Delete above two lines.
> >>
> >> I think "Assignment Policy" normally only lists those ranges for which
> >> assignment is possible so doesn't list Private Use or Reserved or
> >> Experimental.
> >>
> >>          Reference: [this document]
> >>
> >>
>  +===========+======================================+===============+
> >>       | Value     |             Description              | Reference
>  |
> >>
>  +===========+======================================+===============+
> >>       | 0         |               Reserved               | This
> document |
> >>
>  +-----------+--------------------------------------+---------------+
> >>       | 1         |           SFC Echo Request           | This
> document |
> >>
>  +-----------+--------------------------------------+---------------+
> >>       | 2         |            SFC Echo Reply            | This
> document |
> >>
>  +-----------+--------------------------------------+---------------+
> >>       | 3         | SFP Consistency Verification Request | This
> document |
> >>
>  +-----------+--------------------------------------+---------------+
> >>       | 4         |  SFP Consistency Verification Reply  | This
> document |
> >>
>  +-----------+--------------------------------------+---------------+
> >>       | 5 - 175   |              Unassigned              | This
> document |
> >>
>  +-----------+--------------------------------------+---------------+
> >>       | 176 - 239 |              Unassigned              | This
> document |
> >>
>  +-----------+--------------------------------------+---------------+
> >>       | 240 - 251 |              Unassigned              | This
> document |
> >>
> >> "Unassigned" - "Experimental"
> >>
> >>
>  +-----------+--------------------------------------+---------------+
> >>       | 252 - 254 |              Unassigned              | This
> document |
> >>
> >> "Unassigned" -> "Private Use"
> >>
> >>
>  +-----------+--------------------------------------+---------------+
> >>       | 255       |               Reserved               | This
> document |
> >>
>  +-----------+--------------------------------------+---------------+
> >>
> >>                Table 6: SFC Echo Request/Echo Reply Message Types
> >>
> >>    10.3.3.  SFC Echo Reply Modes
> >>
> >>       IANA is requested to create in the SFC Echo Request/Echo Reply
> >>       Parameters registry the new sub-registry as follows:
> >>
> >>          Sub-registry Name: Reply Mode
> >>
> >>          Assignment Policy:
> >>
> >>
> >>
> >>    Mirsky, et al.           Expires 10 January 2023               [Page
> 28]
> >>
> >>    Internet-Draft             Active OAM for SFC                  July
> 2022
> >>
> >>
> >>          8 - 175 IETF Review
> >>
> >>          176 - 239 First Come First Served
> >>
> >>          240 - 251 Experimental
> >>
> >>          252 - 254 Private Use
> >>
> >> Delete above two lines.
> >>
> >> I think "Assignment Policy" normally only lists those ranges for which
> >> assignment is possible so doesn't list Private Use or Reserved or
> >> Experimental.
> >>
> >>          Reference: [this document]
> >>
> >>
> >>          +=======+====================================+===============+
> >>          | Value |            Description             | Reference     |
> >>          +=======+====================================+===============+
> >>          | 0     |              Reserved              | This document |
> >>          +-------+------------------------------------+---------------+
> >>          | 1     |            Do Not Reply            | This document |
> >>          +-------+------------------------------------+---------------+
> >>          | 2     | Reply via an IPv4/IPv6 UDP Packet  | This document |
> >>          +-------+------------------------------------+---------------+
> >>          | 3     |    Reply via Application-Level     | This document |
> >>          |       |          Control Channel           |               |
> >>          +-------+------------------------------------+---------------+
> >>          | 4     |      Reply via Specified Path      | This document |
> >>          +-------+------------------------------------+---------------+
> >>          | 5     | Reply via an IPv4/IPv6 UDP Packet  | This document |
> >>          |       | with the data integrity protection |               |
> >>          +-------+------------------------------------+---------------+
> >>          | 6     |    Reply via Application-Level     | This document |
> >>          |       |   Control Channel with the data    |               |
> >>          |       |        integrity protection        |               |
> >>          +-------+------------------------------------+---------------+
> >>          | 7     | Reply via Specified Path with the  | This document |
> >>          |       |     data integrity protection      |               |
> >>          +-------+------------------------------------+---------------+
> >>          | 8 -   |             Unassigned             | IETF Review   |
> >>
> >> "IETF Review" -> "This document"
> >>
> >>          | 175   |                                    |               |
> >>          +-------+------------------------------------+---------------+
> >>          | 176 - |             Unassigned             | First Come    |
> >>          | 239   |                                    | First Served  |
> >>
> >> "First Come First Served" -> "This document"
> >>
> >>          +-------+------------------------------------+---------------+
> >>
> >> In both entries below, "Description" column should have value
> >> currently in the "Reference" column and the "Reference" column should
> >> say "This document".
> >>
> >>          | 240 - |             Unassigned             | Experimental  |
> >>          | 251   |                                    |               |
> >>          +-------+------------------------------------+---------------+
> >>          | 252 - |             Unassigned             | Private Use   |
> >>          | 254   |                                    |               |
> >>          +-------+------------------------------------+---------------+
> >>          | 255   |              Reserved              | This document |
> >>          +-------+------------------------------------+---------------+
> >>
> >>                           Table 7: SFC Echo Reply Mode
> >>
> >>    10.3.4.  SFC Echo Return Codes
> >>
> >>       IANA is requested to create in the SFC Echo Request/Echo Reply
> >>       Parameters registry the new sub-registry as follows:
> >>
> >> "new" -> ""
> >>
> >>          Sub-registry Name: Return Codes
> >>
> >>          Assignment Policy:
> >>
> >>          9 - 191 IETF Review
> >>
> >>          192 - 251 First Come First Served
> >>
> >>          252 - 254 Private Use
> >>
> >> Delete above line.
> >>
> >> I think "Assignment Policy" normally only lists those ranges for which
> >> assignment is possible so doesn't list Private Use or Reserved or
> >> Experimental.
> >>
> >>          Reference: [this document]
> >>
> >>           +=========+=================================+===============+
> >>           | Value   |           Description           | Reference     |
> >>           +=========+=================================+===============+
> >>           | 0       |          No Return Code         | This document |
> >>           +---------+---------------------------------+---------------+
> >>           | 1       | Malformed Echo Request received | This document |
> >>           +---------+---------------------------------+---------------+
> >>           | 2       | One or more of the TLVs was not | This document |
> >>           |         |            understood           |               |
> >>           +---------+---------------------------------+---------------+
> >>           | 3       |      Authentication failed      | This document |
> >>           +---------+---------------------------------+---------------+
> >>           | 4       |           TTL Exceeded          | This document |
> >>           +---------+---------------------------------+---------------+
> >>           | 5       |          End of the SFP         | This document |
> >>           +---------+---------------------------------+---------------+
> >>           | 6       | Reply Path TLV is missing       | This document |
> >>           +---------+---------------------------------+---------------+
> >>           | 7       | Reply SFP was not found         | This document |
> >>           +---------+---------------------------------+---------------+
> >>           | 8       | Unverifiable Reply Path         | This document |
> >>           +---------+---------------------------------+---------------+
> >>           | 9 -191  |            Unassigned           | This document |
> >>           +---------+---------------------------------+---------------+
> >>           | 192-251 |            Unassigned           | This document |
> >>           +---------+---------------------------------+---------------+
> >>           | 252-254 |            Unassigned           | This document |
> >>
> >> "Unassigned" -> "Private Use"
> >>
> >>           +---------+---------------------------------+---------------+
> >>           | 255     |             Reserved            | This document |
> >>           +---------+---------------------------------+---------------+
> >>
> >>                           Table 8: SFC Echo Return Codes
> >>
> >>    10.4.  SFC Active OAM TLV Type
> >>
> >>       IANA is requested to create the new registry as follows:
> >>
> >>          Registry Name: SFC Active OAM TLV Type
> >>          Assignment Policy:
> >>
> >>          6 -175 IETF Review
> >>
> >>          176 - 239 First Come First Served
> >>
> >>          240 - 251 Experimental
> >>
> >>          252 - 254 Private Use
> >>
> >> Delete above two lines.
> >>
> >> I think "Assignment Policy" normally only lists those ranges for which
> >> assignment is possible so doesn't list Private Use or Reserved or
> >> Experimental.
> >>
> >>          Reference: [this document]
> >>
> >>            +===========+=============================+===============+
> >>            | Value     |         Description         | Reference     |
> >>            +===========+=============================+===============+
> >>            | 0         |           Reserved          | This document |
> >>            +-----------+-----------------------------+---------------+
> >>            | 1         |        Source ID TLV        | This document |
> >>            +-----------+-----------------------------+---------------+
> >>            | 2         |         Errored TLVs        | This document |
> >>            +-----------+-----------------------------+---------------+
> >>            | 3         | SFC Reply Path Type         | This document |
> >>            +-----------+-----------------------------+---------------+
> >>            | 4         | SFF Information Record Type | This document |
> >>            +-----------+-----------------------------+---------------+
> >>            | 5         |        SF Information       | This document |
> >>            +-----------+-----------------------------+---------------+
> >>            | 6 - 175   |          Unassigned         | This document |
> >>            +-----------+-----------------------------+---------------+
> >>            | 176 - 239 |          Unassigned         | This document |
> >>            +-----------+-----------------------------+---------------+
> >>            | 240 - 251 |          Unassigned         | This document |
> >>
> >> "Unassigned" -> "Experimental"
> >>
> >>            +-----------+-----------------------------+---------------+
> >>            | 252 - 254 |          Unassigned         | This document |
> >>
> >> "Unassigned" -> "Private Use"
> >>
> >>            +-----------+-----------------------------+---------------+
> >>            | 255       |           Reserved          | This document |
> >>            +-----------+-----------------------------+---------------+
> >>
> >>                     Table 9: SFC Active OAM TLV Type Registry
> >>
> >>    10.5.  SF Identifier Types
> >>
> >>       IANA is requested to create in the SF Types registry the new sub-
> >>       registry as follows:
> >>
> >> "new" -> ""
> >>
> >>          Registry Name: SF Identifier Types
> >>
> >>          Assignment Policy:
> >>
> >>
> >>
> >>    Mirsky, et al.           Expires 10 January 2023               [Page
> 32]
> >>
> >>    Internet-Draft             Active OAM for SFC                  July
> 2022
> >>
> >>
> >>          4 -191 IETF Review
> >>
> >>          192 - 251 First Come First Served
> >>
> >>          252 - 254 Private Use
> >>
> >> delete above line.
> >>
> >> I think "Assignment Policy" nomrally only lists those ranges for which
> >> assignment is possible so doesn't list Private Use or Reserved or
> >> Experimenal.
> >>
> >>          Reference: [this document]
> >>
> >>                     +=========+=============+===============+
> >>                     | Value   | Description | Reference     |
> >>                     +=========+=============+===============+
> >>                     | 0       |   Reserved  | This document |
> >>                     +---------+-------------+---------------+
> >>                     | 1       |     IPv4    | This document |
> >>                     +---------+-------------+---------------+
> >>                     | 2       |     IPv6    | This document |
> >>                     +---------+-------------+---------------+
> >>                     | 3       |     MAC     | This document |
> >>                     +---------+-------------+---------------+
> >>                     | 4 -191  |  Unassigned | This document |
> >>                     +---------+-------------+---------------+
> >>                     | 192-251 |  Unassigned | This document |
> >>                     +---------+-------------+---------------+
> >>                     | 252-254 |  Unassigned | This document |
> >>
> >> "Unassigned" -> "Private Use"
> >>
> >>                     +---------+-------------+---------------+
> >>                     | 255     |   Reserved  | This document |
> >>                     +---------+-------------+---------------+
> >>
> >>                            Table 10: SF Identifier Type
> >>
> >>
> >>    11.2.  Informative References
> >>
> >>  Add Informative References [RFC4086] and [RFC8126].
> >>
> >> Thanks,
> >> Donald
> >> ===============================
> >>  Donald E. Eastlake 3rd   [phone] (cell)
> >>  2386 Panoramic Circle, Apopka, FL 32703 USA
> >>  [e-mail]
>