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

[Donald Eastlake <[e-mail]>]

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]