Skip to main content

Active Operations, Administration, and Maintenance (OAM) for Service Function Chaining (SFC)
draft-ietf-sfc-multi-layer-oam-28

Revision differences

Document history

Date Rev. By Action
2024-01-26
28 Gunter Van de Velde Request closed, assignment withdrawn: Jon Mitchell Last Call OPSDIR review
2024-01-26
28 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue
2023-11-15
28 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2023-10-30
28 (System) RFC Editor state changed to AUTH48
2023-09-19
28 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2023-07-19
28 Barry Leiba Closed request for Last Call review by ARTART with state 'Overtaken by Events': Document has finished IESG processing
2023-07-19
28 Barry Leiba Assignment of request for Last Call review by ARTART to Darrel Miller was marked no-response
2023-07-17
28 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2023-07-17
28 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2023-07-17
28 (System) IANA Action state changed to In Progress from Waiting on Authors
2023-07-14
28 (System) IANA Action state changed to Waiting on Authors from In Progress
2023-07-10
28 (System) RFC Editor state changed to EDIT
2023-07-10
28 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2023-07-10
28 (System) Announcement was received by RFC Editor
2023-07-10
28 (System) IANA Action state changed to In Progress
2023-07-10
28 Amy Vezza Downref to RFC 7665 approved by Last Call for draft-ietf-sfc-multi-layer-oam-28
2023-07-10
28 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2023-07-10
28 Amy Vezza IESG has approved the document
2023-07-10
28 Amy Vezza Closed "Approve" ballot
2023-07-10
28 Amy Vezza Ballot approval text was generated
2023-07-10
28 Andrew Alston IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2023-07-07
28 (System) Removed all action holders (IESG state changed)
2023-07-07
28 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2023-07-07
28 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-28.txt
2023-07-07
28 Greg Mirsky New version accepted (logged-in submitter: Greg Mirsky)
2023-07-07
28 Greg Mirsky Uploaded new revision
2023-07-06
27 (System) Changed action holders to Greg Mirsky, Wei Meng, Ting Ao, Bhumip Khasnabish, Kent Leung, Gyan Mishra (IESG state changed)
2023-07-06
27 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2023-07-06
27 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2023-07-05
27 Robert Wilton
[Ballot comment]
Hi,

Thanks for this document.  I found various points in the document to be unclear.  Please consider whether addressing these comments would improve …
[Ballot comment]
Hi,

Thanks for this document.  I found various points in the document to be unclear.  Please consider whether addressing these comments would improve the clarity of the document.


(1) p 5, sec 3.  Requirements for Active OAM in SFC

  Once the SFF1 detects the defect, the objective of the SFC OAM
  changes from the detection of a defect to defect characterization and
  localization.

It wasn't clear to me why it is SFF1 that detects the defect, rather than say, "Once an SFF detects the defect"?


(2) p 6, sec 3.  Requirements for Active OAM in SFC

  *  REQ#8: Can be addressed by an extension of the SFC Echo Request/
      Reply described in this document adding proxy capability.

Does this mean that requirement 8 isn't actually addressed by this specification?  If so, this seems to conflict with the sentence above: "The above listed requirements are satisfied in this specification as follows:"


(3) p 7, sec 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) and [RFC8029] are examples of broadly used active OAM
  protocols based on the Echo Request/Reply principle.  The SFC Echo
  Request/Reply control message format is presented in Figure 3.

I didn't entirely follow how these headers fit together.  Is the "SFC Echo Request/Reply Format" an instance of an "SFC Active OAM Control Packet" that is used in the "SFC Active OAM Header" above?  If so, then it would probably be helpful for this to be explicitly stated.


(4) p 10, sec 6.1.  Return Codes

                      Table 1: SFC Echo Return Codes

It is unclear to me whether the SFC Echo Return Codes are those defined in this table, or the ones specified in section 10.3.4.  Perhaps it would be better for this section to just reference 10.3.4 rather than having duplicate normative content?


(5) p 13, sec 6.4.  Processing Received SFC Echo Request

      1.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.

Does this effectively mean that even if authentication fails, some level of SFC Echo Request/Reply is supported (e.g., at least to the first SFF)?  I was wondering whether in this case, it wouldn't be safer to treat this like step 2.1.  I.e., an error is logged but no response is sent back?


(6) p 14, sec 6.4.  Processing Received SFC Echo Request

      8.  In all other cases, SFF MUST set the Return Code value to 0
      ("No Error, End of Path Reached") and the Subcode set to zero.

Some of these steps are very explicit in that they send a responce back, but others, like 6, 7, and 8 do not explicitly indicate that they send a reply.


(7) p 14, sec 6.4.  Processing Received SFC Echo Request

      8.  In all other cases, SFF MUST set the Return Code value to 0
      ("No Error, End of Path Reached") and the Subcode set to zero.

I didn't understand the distinction between "End of the SFP" and "No Error, End of Path Reached".  Is the difference that in one case reaching the end is expected, and the other is that it is not?  Perhaps worth clarifying.



Nit level comments:

(8) p 12, sec 6.3.1.  Source TLV

      Source ID - the value MUST be 1 Section 10.4.

Perhaps "MUST be 1, as per Section 10.4."

Regards,
Rob
2023-07-05
27 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2023-07-05
27 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2023-07-05
27 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from No Record
2023-07-05
27 Roman Danyliw [Ballot comment]
Thank you to Russ Mundy for the SECDIR review.
2023-07-05
27 Roman Danyliw Ballot comment text updated for Roman Danyliw
2023-07-05
27 Warren Kumari
[Ballot comment]
Thank you very much for this document; I'd like to take a moment to mention that this is one of the best written …
[Ballot comment]
Thank you very much for this document; I'd like to take a moment to mention that this is one of the best written drafts that I've read in a long time.
Thank you!
2023-07-05
27 Warren Kumari [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari
2023-07-05
27 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2023-07-05
27 Martin Duke [Ballot comment]
Thanks to Olivier for the TSVART review.
2023-07-05
27 Martin Duke Ballot comment text updated for Martin Duke
2023-07-05
27 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2023-07-05
27 Éric Vyncke
[Ballot comment]
Thanks to the authors for the work and for the prompt reaction and discussions to my previous DISCUSS ballot at:
https://mailarchive.ietf.org/arch/msg/sfc/av2LpDU2jw3o9ErIeM5c20K11ts/

I sincerely …
[Ballot comment]
Thanks to the authors for the work and for the prompt reaction and discussions to my previous DISCUSS ballot at:
https://mailarchive.ietf.org/arch/msg/sfc/av2LpDU2jw3o9ErIeM5c20K11ts/

I sincerely think that -27 is an improved version of -26.

Regards

-éric
2023-07-05
27 Éric Vyncke [Ballot Position Update] Position for Éric Vyncke has been changed to No Objection from Discuss
2023-07-05
27 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2023-07-05
27 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-27.txt
2023-07-05
27 Greg Mirsky New version accepted (logged-in submitter: Greg Mirsky)
2023-07-05
27 Greg Mirsky Uploaded new revision
2023-07-04
26 Paul Wouters
[Ballot comment]
NIT:

  0                  1                  2      …
[Ballot comment]
NIT:

  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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Source ID  |  Reserved1  |          Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Port Number          |          Reserved2          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        IP Address                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The last box for IP Address should use ~ instead of | as it can be either 4 octets of 16 octets.
2023-07-04
26 Paul Wouters [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters
2023-07-03
26 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2023-07-03
26 Russ Mundy Request for Telechat review by SECDIR Completed: Ready. Reviewer: Russ Mundy. Sent review to list.
2023-07-02
26 Éric Vyncke
[Ballot comment]

# COMMENTS

## Multi-layer ?

I wonder what is "multi-layer" (per the I-D title) aspect in the specification. Suggest to either explain the …
[Ballot comment]

# COMMENTS

## Multi-layer ?

I wonder what is "multi-layer" (per the I-D title) aspect in the specification. Suggest to either explain the "multi-layer" aspect or drop it from the draft title.

## Section 3

Suggest to write that SFFI stands for SFF Instance in Figure 1.

Isn't `FM SFC OAM` a pleonasm ? I.e., either "FM" or "OAM" are redundant.

`(e.g., NSH)` why `e.g.` when section 1 states the focus of this I-D to NSH ?

About REQ#1, should this be a "MUST" rather than a "SHOULD" ?

In REQ#8, `the initiator of such a request` should probably be more specific.

## Section 4

Isn't RFC 8300 a better reference for the O bit rather than an IETF draft ?

## Section 5

Please add a justification / actual data about `But extra IP/UDP headers, especially in an IPv6 network, add noticeable overhead.`

I am really concerned by having only 2 bits to indicate the version while there are 8 bits reserved on the side. This does not look too good for revisions.

When can an implementation deviate from the SHOULD in Sender's Handle: `The sender of the Echo Request SHOULD use a pseudo-random number generator ` ? While I understand that this is an opaque value, and using a random number prevents fingerprinting, I would assume that some implementations would like to add some private semantics to this number.

## Section 6

Suggest adding some text about the absence of TLVs based on the length of the SFC OAM header.

## Section 6.1

To avoid confusion s/TTL Exceeded/NSH TTL Exceeded/ (even if explained later in the text).

In `The receiver of said Echo Request can set it to one of the values` should the "can" be replaced by a "MUST" ?

## Section 6.3

`If the NSH is used,` but section 1 specifies that this I-D is only about NSH.

`Reply via an IPv4/IPv6 UDP Packet` is unclear when reading it. Please add a forward reference to section 6.3.1 (I would also prefer to have 6.3.1 earlier in the flow

## Section 6.5.2

How `If the NSH of the received SFC Echo Request includes the MAC Context Header, the packet's authentication MUST be verified before using any data. `is different to the text of section 6.4 about the MAC ?

`Sequence Number in the Echo Request sent matches to the Sequence Number in the Echo Reply received` should it rather be a window of sequence number ? I.e., pipelined requests could be sent.

## Section 6.6

`Consistency Verification Request` this message is not defined before this section and not in RFC 8300. If specified in this section, may I suggest to rename the section to be about CVReq ?

## Section 7

`if the underlay is an IPv6 network` what about IPv4 ? I would assume that IPv[46] underlays can support AH/ESP.

Should this be a SHOULD in `an implementation MAY check that the source of the Echo Request is indeed part of the SFP`?
2023-07-02
26 Éric Vyncke Ballot comment text updated for Éric Vyncke
2023-07-02
26 Éric Vyncke
[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-sfc-multi-layer-oam-26

Thank you for the work put into this document.

Please find below one blocking DISCUSS …
[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-sfc-multi-layer-oam-26

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (very easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Other thanks to Carlos Bernardos, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-sfc-multi-layer-oam-26-intdir-telechat-bernardos-2023-06-28/ (and I have read Greg's reply, still waiting for a revised I-D though)

Special thanks to Don Eastlake for the shepherd's detailed write-up including the WG consensus and the justification of the intended status and the author counts.

I hope that this review helps to improve the document,

Regards,

-éric


# DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

## Section 6

As there two V header fields defined (one for Echo message and one for all OAM messages), it is unclear whether the Echo V-field is set back to 0 when SFC OAM header Version is incremented? Or in other words, should Echo with V=0 but with OAM V != 0 be interpreted as specified in this document ?

Are the TLV type depending on the Version being 0 ?
2023-07-02
26 Éric Vyncke
[Ballot comment]

# COMMENTS

## Section 3

Suggest to write that SFFI stands for SFF Instance in Figure 1.

Isn't `FM SFC OAM` a pleonasm …
[Ballot comment]

# COMMENTS

## Section 3

Suggest to write that SFFI stands for SFF Instance in Figure 1.

Isn't `FM SFC OAM` a pleonasm ? I.e., either "FM" or "OAM" are redundant.

`(e.g., NSH)` why `e.g.` when section 1 states the focus of this I-D to NSH ?

About REQ#1, should this be a "MUST" rather than a "SHOULD" ?

In REQ#8, `the initiator of such a request` should probably be more specific.

## Section 4

Isn't RFC 8300 a better reference for the O bit rather than an IETF draft ?

## Section 5

Please add a justification / actual data about `But extra IP/UDP headers, especially in an IPv6 network, add noticeable overhead.`

I am really concerned by having only 2 bits to indicate the version while there are 8 bits reserved on the side. This does not look too good for revisions.

When can an implementation deviate from the SHOULD in Sender's Handle: `The sender of the Echo Request SHOULD use a pseudo-random number generator ` ? While I understand that this is an opaque value, and using a random number prevents fingerprinting, I would assume that some implementations would like to add some private semantics to this number.

## Section 6

Suggest adding some text about the absence of TLVs based on the length of the SFC OAM header.

## Section 6.1

To avoid confusion s/TTL Exceeded/NSH TTL Exceeded/ (even if explained later in the text).

In `The receiver of said Echo Request can set it to one of the values` should the "can" be replaced by a "MUST" ?

## Section 6.3

`If the NSH is used,` but section 1 specifies that this I-D is only about NSH.

`Reply via an IPv4/IPv6 UDP Packet` is unclear when reading it. Please add a forward reference to section 6.3.1 (I would also prefer to have 6.3.1 earlier in the flow

## Section 6.5.2

How `If the NSH of the received SFC Echo Request includes the MAC Context Header, the packet's authentication MUST be verified before using any data. `is different to the text of section 6.4 about the MAC ?

`Sequence Number in the Echo Request sent matches to the Sequence Number in the Echo Reply received` should it rather be a window of sequence number ? I.e., pipelined requests could be sent.

## Section 6.6

`Consistency Verification Request` this message is not defined before this section and not in RFC 8300. If specified in this section, may I suggest to rename the section to be about CVReq ?

## Section 7

`if the underlay is an IPv6 network` what about IPv4 ? I would assume that IPv[46] underlays can support AH/ESP.

Should this be a SHOULD in `an implementation MAY check that the source of the Echo Request is indeed part of the SFP`?
2023-07-02
26 Éric Vyncke [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke
2023-06-30
26 Jim Guichard [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard
2023-06-29
26 Tero Kivinen Request for Telechat review by SECDIR is assigned to Russ Mundy
2023-06-28
26 Carlos Jesús Bernardos Request for Telechat review by INTDIR Completed: Ready with Issues. Reviewer: Carlos Bernardos. Sent review to list.
2023-06-27
26 Bernie Volz Request for Telechat review by INTDIR is assigned to Carlos Bernardos
2023-06-27
26 Éric Vyncke Requested Telechat review by INTDIR
2023-06-27
26 Andrew Alston Placed on agenda for telechat - 2023-07-06
2023-06-27
26 Andrew Alston Ballot has been issued
2023-06-27
26 Andrew Alston [Ballot Position Update] New position, Yes, has been recorded for Andrew Alston
2023-06-27
26 Andrew Alston Created "Approve" ballot
2023-06-27
26 Andrew Alston IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2023-06-27
26 Andrew Alston Ballot writeup was changed
2023-06-24
26 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-26.txt
2023-06-24
26 Greg Mirsky New version accepted (logged-in submitter: Greg Mirsky)
2023-06-24
26 Greg Mirsky Uploaded new revision
2023-06-23
25 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-25.txt
2023-06-23
25 Greg Mirsky New version accepted (logged-in submitter: Greg Mirsky)
2023-06-23
25 Greg Mirsky Uploaded new revision
2023-06-05
24 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2023-06-05
24 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-24.txt
2023-06-05
24 Greg Mirsky New version accepted (logged-in submitter: Greg Mirsky)
2023-06-05
24 Greg Mirsky Uploaded new revision
2023-05-30
23 David Dong IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2023-05-30
23 David Dong IANA Experts State changed to Expert Reviews OK from Reviews assigned
2023-05-22
23 Olivier Bonaventure Request for Last Call review by TSVART Completed: Ready with Nits. Reviewer: Olivier Bonaventure. Sent review to list.
2023-05-19
23 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2023-05-16
23 Russ Mundy Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Russ Mundy. Sent review to list.
2023-05-16
23 David Dong IANA Experts State changed to Reviews assigned
2023-05-16
23 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2023-05-16
23 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-sfc-multi-layer-oam-23. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-sfc-multi-layer-oam-23. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about the fifth action requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are ten actions which we must complete.

First, in the NSH Next Protocol registry on the Network Service Header (NSH) Parameters registry page located at:

https://www.iana.org/assignments/nsh/

a single new registration will be made as follows:

Value: [ TBD-at-Registration ]
Description: SFC Active OAM
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, a new entry on the IANA Matrix is to be created called Service Function Chaining Active Operations, Administration and Management. The new registry page will be located at:

https://www.iana.org/protocols

Third, on the new Service Function Chaining Active Operations, Administration and Management registry page created in action two above, a new registry is to be created called the SFC Active OAM registry. The assignment policy for the new registry is:

0: Reserved
1-31: IETF Review
32-62: First Come, First Served
63: Reserved

Values 0 and 63 are to be marked reserved. There is a single initial registration in the new registry as follows:

Value: 1
Description: SFC Echo Request/Echo Reply
Reference: [ RFC-to-be ]

Fourth, on the new Service Function Chaining Active Operations, Administration and Management registry page created in action two above, a new registry is to be created called the SFC Active OAM Flags registry.

The registry is to be made up of 8 flags, numbered 0 through 7. The registry is to be managed via Standards Action as defined by RFC8126.

There are no initial registrations in the new registry and all values are to be marked "unassigned."

Fifth, on the new Service Function Chaining Active Operations, Administration and Management registry page created in action two above, a new registry is to be created called the SFC Echo Request/Echo Reply Parameters registry.


IANA QUESTION --> In the IANA Considerations section (Section 10.3) of the current draft, the authors request the creation of the SFC Echo Request/Echo Reply Parameters registry. Then, in Section 10.3.2, 10.3.3, and 10.3.4 (IANA actions 6, 7 and 8 below) three registries related to that registry. Is the intention to have these related registries on the same registry page that was created by the second IANA Action above? Do the authors find the approach of simply grouping the related "sub-registries" together on the same registry page acceptable?


The registry is to be made up of 16 flags, numbered 0 through 15. The registry is to be managed via Standards Action as defined by RFC8126.

There are no initial registrations in the new registry and all values are to be marked "unassigned."

Sixth, on the new Service Function Chaining Active Operations, Administration and Management registry page created in action two above, a new registry is to be created called the SFC Echo Request/Echo Reply Message Types registry.

The registry has 256 values numbered 0 through 255. The registry is to be managed via the following policies as defined by RFC8126:

0: Reserved
1-239: IETF Review
240-251 Experimental
252-254: Private Use
255: Reserved

There are four initial registrations in the new registry as follows:

Value: 1
Description: SFC Echo Request
Reference: [ RFC-to-be ]

Value: 2
Description: SFC Echo Reply
Reference: [ RFC-to-be ]

Value: 3
Description: SFP Consistency Verification Request
Reference: [ RFC-to-be ]

Value: 4
Description: SFP Consistency Verification Reply
Reference: [ RFC-to-be ]

Seventh, on the new Service Function Chaining Active Operations, Administration and Management registry page created in action two above, a new registry is to be created called the SFC Echo Request/Echo Reply Parameters registry.

The registry has 256 values numbered 0 through 255. The registry is to be managed via the following policies as defined by RFC8126:

0: Reserved
1-239: IETF Review
240-251 Experimental
252-254: Private Use
255: Reserved

There are seven initial registrations in the new registry as follows:

Value: 1
Description: Do Not Reply
Reference: [ RFC-to-be ]

Value: 2
Description: Reply via an IPv4/IPv6 UDP Packet
Reference: [ RFC-to-be ]

Value: 3
Description: Reply via Application-Level Control Channel
Reference: [ RFC-to-be ]

Value: 4
Description: Reply via Specified Path
Reference: [ RFC-to-be ]

Value: 5
Description: Reply via an IPv4/IPv6 UDP Packet with the data integrity protection
Reference: [ RFC-to-be ]

Value: 6
Description: Reply via Application-Level Control Channel with the data integrity protection
Reference: [ RFC-to-be ]

Value: 7
Description: Reply via Specified Path with the data integrity protection
Reference: [ RFC-to-be ]

Eighth, on the new Service Function Chaining Active Operations, Administration and Management registry page created in action two above, a new registry is to be created called the SFC Echo Return Codes registry.

The registry has 256 values numbered 0 through 255. The registry is to be managed via the following policies as defined by RFC8126:

0-251: IETF Review
252-254: Private Use
255: Reserved

There are nine initial registrations in the new registry as follows:

Value: 0
Description: No Return Code
Reference: [ RFC-to-be ]

Value: 1
Description: Malformed Echo Request received
Reference: [ RFC-to-be ]

Value: 2
Description: One or more of the TLVs was not understood
Reference: [ RFC-to-be ]

Value: 3
Description: Authentication failed
Reference: [ RFC-to-be ]

Value: 4
Description: TTL Exceeded
Reference: [ RFC-to-be ]

Value: 5
Description: End of the SFP
Reference: [ RFC-to-be ]

Value: 6
Description: Reply Service Function Path TLV is missing
Reference: [ RFC-to-be ]

Value: 7
Description: Reply SFP was not found
Reference: [ RFC-to-be ]

Value: 8
Description: Unverifiable Reply Service Function Path
Reference: [ RFC-to-be ]

Ninth, on the new Service Function Chaining Active Operations, Administration and Management registry page created in action two above, a new registry is to be created called the SFC Active OAM TLV Type registry.

The registry has 256 values numbered 0 through 255. The registry is to be managed via the following policies as defined by RFC8126:

0: Reserved
1-239: IETF Review
240-251: Experimental
252-254: Private Use
255: Reserved

There are five initial registrations in the new registry as follows:

Value: 1
Description: Source ID TLV
Reference: [ RFC-to-be ]

Value: 2
Description: Errored TLVs
Reference: [ RFC-to-be ]

Value: 3
Description: Reply Service Function Path Type
Reference: [ RFC-to-be ]

Value: 4
Description: SFF Information Record Type
Reference: [ RFC-to-be ]

Value: 5
Description: SF Information
Reference: [ RFC-to-be ]

Tenth, on the new Service Function Chaining Active Operations, Administration and Management registry page created in action two above, a new registry is to be created called the SF Identifier Types registry.

The registry has 256 values numbered 0 through 255. The registry is to be managed via the following policies as defined by RFC8126:

0: Reserved
0-251: IETF Review
252-254: Private Use
255: Reserved

There are three initial registrations in the new registry as follows:

Value: 1
Description: IPv4
Reference: [ RFC-to-be ]

Value: 2
Description: IPv6
Reference: [ RFC-to-be ]

Value: 3
Description: MAC
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist
2023-05-15
23 Behcet Sarikaya Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Behcet Sarikaya. Sent review to list.
2023-05-09
23 Barry Leiba Request for Last Call review by ARTART is assigned to Darrel Miller
2023-05-09
23 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jon Mitchell
2023-05-08
23 Darren Dukes Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Darren Dukes. Sent review to list.
2023-05-08
23 Magnus Westerlund Request for Last Call review by TSVART is assigned to Olivier Bonaventure
2023-05-04
23 Tero Kivinen Request for Last Call review by SECDIR is assigned to Russ Mundy
2023-05-04
23 Jean Mahoney Request for Last Call review by GENART is assigned to Behcet Sarikaya
2023-05-03
23 Cindy Morgan IANA Review state changed to IANA - Review Needed
2023-05-03
23 Cindy Morgan
The following Last Call announcement was sent out (ends 2023-05-17):

From: The IESG
To: IETF-Announce
CC: andrew-ietf@liquid.tech, d3e3e3@gmail.com, donald.eastlake@futurewei.com, draft-ietf-sfc-multi-layer-oam@ietf.org, sfc-chairs@ietf.org …
The following Last Call announcement was sent out (ends 2023-05-17):

From: The IESG
To: IETF-Announce
CC: andrew-ietf@liquid.tech, d3e3e3@gmail.com, donald.eastlake@futurewei.com, draft-ietf-sfc-multi-layer-oam@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Active OAM for Service Function Chaining (SFC)) to Proposed Standard


The IESG has received a request from the Service Function Chaining WG (sfc)
to consider the following document: - 'Active OAM for Service Function
Chaining (SFC)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-05-17. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sfc-multi-layer-oam/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3338/





2023-05-03
23 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2023-05-03
23 Andrew Alston Last call was requested
2023-05-03
23 Andrew Alston Ballot approval text was generated
2023-05-03
23 Andrew Alston Ballot writeup was generated
2023-05-03
23 Andrew Alston IESG state changed to Last Call Requested from AD Evaluation
2023-05-03
23 Andrew Alston Last call announcement was generated
2023-04-22
23 Haomian Zheng Request for Last Call review by RTGDIR is assigned to Darren Dukes
2023-04-13
23 Andrew Alston Requested Last Call review by RTGDIR
2023-04-13
23 (System) Changed action holders to Andrew Alston (IESG state changed)
2023-04-13
23 Andrew Alston IESG state changed to AD Evaluation from Publication Requested
2023-03-26
23 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-23.txt
2023-03-26
23 Greg Mirsky New version accepted (logged-in submitter: Greg Mirsky)
2023-03-26
23 Greg Mirsky Uploaded new revision
2022-08-23
22 Jenny Bui Intended Status changed to Proposed Standard from None
2022-08-22
22 Joel Halpern
Shepherd Review of draft-ietf-sfc-multi-layer-oam-22.txt

1. Does the working group (WG) consensus represent the strong concurrence
of a few individuals, with others being silent, or did …
Shepherd Review of draft-ietf-sfc-multi-layer-oam-22.txt

1. Does the working group (WG) consensus represent the strong concurrence
of a few individuals, with others being silent, or did it reach broad
agreement?

  There is broad agreement in the WG to publish this draft. Note that
  it was the merger of three preceeding draft and there has been
  discussion of those as well as this draft.

2. Was there controversy about particular points, or were there decisions
where the consensus was particularly rough?

  No.

3. Has anyone threatened an appeal or otherwise indicated extreme
discontent?

  No.

4. For protocol documents, are there existing implementations of the
contents of the document? Have a significant number of potential
implementers indicated plans to implement? Are any existing
implementations reported somewhere, either in the document itself (as
RFC 7942 recommends) or elsewhere (where)?

  No completed implementations are known to the Shepherd.

5. Does this document need review from other IETF working groups or
external organizations?

  No.

6. Describe how the document meets any required formal expert review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.

  No such formal expert review required.

7. If the document contains a YANG module, has the final version of
the module been checked with any of the recommended validation tools
for syntax and formatting validation?

  The document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate
sections of the final version of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL,
ASN.1 modules, etc.  Document Shepherd Checks.

  No formal language review required. Shepherd's review:
  https://mailarchive.ietf.org/arch/msg/sfc/-FAoZG2HIPf985WwBggU84TmQxE/
  WG participants have reviewed the draft and their comments have been
  resolved.

9. Based on the shepherd's review of the document, is it their opinion
that this document is needed, clearly written, complete, correctly
designed, and ready to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled lists of common issues that
their reviewers encounter. Do any such issues remain that would merit
specific attention from subsequent reviews?

  I have reviewed the draft in light of
  https://trac.ietf.org/trac/rtg/wiki/RtgADNits and do not see
  problems.

11. What type of RFC publication is being requested on the IETF stream
(Best Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this
intent?

  As stated on the title page, Standrds Track is requested. This is
  appropriate for an OAM protocol that is augmenting a standardized
  and deployed IETF Standards Track Protocol, i.e., Service Function
  Chaining.

12. Have reasonable efforts been made to remind all authors of the
intellectual property rights (IPR) disclosure obligations described in
BCP 79? To the best of your knowledge, have all required disclosures
been filed? If not, explain why. If yes, summarize any relevant
discussion, including links to publicly-available messages when
applicable.

  Yes. See IPR statments by authors and listed contributors:
https://mailarchive.ietf.org/arch/msg/sfc/93GbhFxx0gUD_pJgiigTDb_8gDk/
https://mailarchive.ietf.org/arch/msg/sfc/VXG6Z_adulRM6rKScMr5vSA4SdM/
https://mailarchive.ietf.org/arch/msg/sfc/8HBnkE4wmtaGR3uc-V6XllVp65M/
https://mailarchive.ietf.org/arch/msg/sfc/IyCWQxuPsOUCqJqZx3E96pD71eM/
https://mailarchive.ietf.org/arch/msg/sfc/Uc71eGdiyMX6wdfOpW4jGsbhFCM/
https://mailarchive.ietf.org/arch/msg/sfc/3Zq1-nhbF6qVRzo4Mtb7-HdYoFg/
https://mailarchive.ietf.org/arch/msg/sfc/RsDeKQ81ej6hK6DinpsQdBXYS_0/
https://mailarchive.ietf.org/arch/msg/sfc/8Rde86WqbqyOebGdBIDCtdj4JE8/
(Linda Wang and Cui Wang are the same person.)

13. Has each Author or Contributor confirmed their willingness to be
listed as such? If the number of Authors/Editors on the front page is
greater than 5, please provide a justification.

  This draft is the result of merging three drafts:
    draft-wang-sfc-multi-layer-oam
    draft-ao-sfc-oam-path-consistency
    draft-ao-sfc-oam-return-path-specified
  Six authors are listed to provide appropriate credit.

14. Identify any remaining I-D nits in this document. (See the idnits
tool and the checkbox items found in Guidelines to Authors of
Internet-Drafts). Simply running the idnits tool is not enough; please
review the entire guidelines document.

  The reference to draft-ietf-sfc-nsh-tlv should be updated to
  reference RFC 9263.

15. Should any informative references be normative or vice-versa?

  I believe the references are correcly clasified as informative and
  normative.

16. List any normative references that are not freely available to
anyone.

  There are none.

17. Are there any normative downward references (see RFC 3967, BCP
97
)? If so, list them.

  No.

18. Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If they exist, what
is the plan for their completion?

  This document is normatively dependent on draft-ietf-sfc-oam-packet
  which has passed WG Consensus, had publication requested, and is
  currently in AD Review.

19. Will publication of this document change the status of any
existing RFCs?

  No.

20. Describe the document shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of
the document. Confirm that all aspects of the document requiring IANA
assignments are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that each newly created IANA registry
specifies its initial contents, allocations procedures, and a
reasonable name (see RFC 8126).

  The IANA Considerations section allocates one value from the
  existing SFC NSH Next Protocol registry for SFC Active OAM. It then
  defines a number of registries/sub-registries related to such
  messages.  The initial contents of such new registried are specified
  along with reasonable allocation procedures and registry name.

21. List any new IANA registries that require Designated Expert Review
for future allocations. Are the instructions to the Designated Expert
clear? Please include suggestions of designated experts, if
appropriate.

  The draft creates a number of registries/sub-registries but in all
  cases the assignment criterion are Standards Action, IETF Review, or
  First Come First Served so no Designated Experts are required.
2022-08-22
22 Joel Halpern Responsible AD changed to Andrew Alston
2022-08-22
22 Joel Halpern IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2022-08-22
22 Joel Halpern IESG state changed to Publication Requested from I-D Exists
2022-08-22
22 Joel Halpern IESG process started in state Publication Requested
2022-08-22
22 Donald Eastlake
Network Working Group                                        M. Blanchet
Internet-Draft  …
Network Working Group                                        M. Blanchet
Internet-Draft                                                  Viagenie
Intended status: Standards Track                        January 13, 2014
Expires: July 17, 2014

      Finding the Authoritative Registration Data (RDAP) Service
                  draft-ietf-weirds-bootstrap-00.txt

Abstract

  This document specifies a method to find which Registration Data
  Access Protocol (RDAP) server is authoritative to answer queries for
  a requested scope, such as domain names, IP addresses or Autonomous
  System numbers, using data available in IANA registries.

Status of This Memo

  This Internet-Draft is submitted in full conformance with the
  provisions of BCP 78 and BCP 79.

  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF).  Note that other groups may also distribute
  working documents as Internet-Drafts.  The list of current Internet-
  Drafts is at http://datatracker.ietf.org/drafts/current/.

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time.  It is inappropriate to use Internet-Drafts as reference
  material or to cite them other than as "work in progress."

  This Internet-Draft will expire on July 17, 2014.

Copyright Notice

  Copyright (c) 2014 IETF Trust and the persons identified as the
  document authors.  All rights reserved.

  This document is subject to BCP 78 and the IETF Trust's Legal
  Provisions Relating to IETF Documents
  (http://trustee.ietf.org/license-info) in effect on the date of
  publication of this document.  Please review these documents
  carefully, as they describe your rights and restrictions with respect
  to this document.  Code Components extracted from this document must
  include Simplified BSD License text as described in Section 4.e of
  the Trust Legal Provisions and are provided without warranty as
  described in the Simplified BSD License.

Blanchet                  Expires July 17, 2014                [Page 1]
Internet-Draft    Finding Authoritative RDAP service      January 2014

Table of Contents

  1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  2
  2.  Domain Name RDAP Registry . . . . . . . . . . . . . . . . . .  2
  3.  Internet Numbers RDAP Registries  . . . . . . . . . . . . . .  3
    3.1.  IPv4 Address Space RDAP Registry  . . . . . . . . . . . .  3
    3.2.  IPv6 Address Space RDAP Registry  . . . . . . . . . . . .  3
    3.3.  Autonomous Systems RDAP Registry  . . . . . . . . . . . .  3
  4.  Nameserver  . . . . . . . . . . . . . . . . . . . . . . . . .  4
  5.  Entity  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
  6.  Non-existent Entries or RDAP URL Values . . . . . . . . . . .  4
  7.  Deployment Considerations . . . . . . . . . . . . . . . . . .  4
  8.  Security Considerations . . . . . . . . . . . . . . . . . . .  5
  9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  5
  10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  6
  11. Non-Normative References  . . . . . . . . . . . . . . . . . .  6
  Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  7

1.  Introduction

  Querying and retrieving registration data from registries are defined
  in the Registration Data Access Protocol(RDAP)[I-D.ietf-weirds-rdap-q
  uery][I-D.ietf-weirds-using-http][I-D.ietf-weirds-json-response].
  These documents do not specify where to send the queries.  This
  document specifies a method to find which server is authoritative to
  answer queries for the requested scope.

  The proposed mechanism is based on that allocation data for domain
  names and IP addresses are maintained by IANA, are publicly available
  and are in a structured format.  The mechanism assumes some data
  structure within these registries and request IANA to modify or
  create these registries for the specific purpose of RDAP use.  An
  RDAP client fetches the registries, extract the data and then do a
  match with the query data to find the authoritative registration data
  server and appropriate query base URL.

2.  Domain Name RDAP Registry

  The domain names authoritative registration data service is found by
  doing the longest match of the target domain name with the values of
  the Domain column in the IANA Domain Name RDAP registry as defined in
  section Section 9.  The value of the "RDAP URL" column is the base
  RDAP url as described in [I-D.ietf-weirds-rdap-query].

  For example, a RDAP query for example.com matches the .com entry in
  the Domain column of the registry.  The RDAP server URL for this
  address is located in the corresponding "RDAP URL" column for that
  entry, which could be http://rdap.example.org/rdap.  Therefore the

Blanchet                  Expires July 17, 2014                [Page 2]
Shepherd Review of draft-ietf-sfc-multi-layer-oam-22.txt

1. Does the working group (WG) consensus represent the strong concurrence
of a few individuals, with others being silent, or did it reach broad
agreement?

  There is broad agreement in the WG to publish this draft. Note that
  it was the merger of three preceeding draft and there has been
  discussion of those as well as this draft.

2. Was there controversy about particular points, or were there decisions
where the consensus was particularly rough?

  No.

3. Has anyone threatened an appeal or otherwise indicated extreme
discontent?

  No.

4. For protocol documents, are there existing implementations of the
contents of the document? Have a significant number of potential
implementers indicated plans to implement? Are any existing
implementations reported somewhere, either in the document itself (as
RFC 7942 recommends) or elsewhere (where)?

  No completed implementations are known to the Shepherd.

5. Does this document need review from other IETF working groups or
external organizations?

  No.

6. Describe how the document meets any required formal expert review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.

  No such formal expert review required.

7. If the document contains a YANG module, has the final version of
the module been checked with any of the recommended validation tools
for syntax and formatting validation?

  The document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate
sections of the final version of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL,
ASN.1 modules, etc.  Document Shepherd Checks.

  No formal language review required. Shepherd's review:
  https://mailarchive.ietf.org/arch/msg/sfc/-FAoZG2HIPf985WwBggU84TmQxE/
  WG participants have reviewed the draft and their comments have been
  resolved.

9. Based on the shepherd's review of the document, is it their opinion
that this document is needed, clearly written, complete, correctly
designed, and ready to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled lists of common issues that
their reviewers encounter. Do any such issues remain that would merit
specific attention from subsequent reviews?

  I have reviewed the draft in light of
  https://trac.ietf.org/trac/rtg/wiki/RtgADNits and do not see
  problems.

11. What type of RFC publication is being requested on the IETF stream
(Best Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this
intent?

  As stated on the title page, Standrds Track is requested. This is
  appropriate for an OAM protocol that is augmenting a standardized
  and deployed IETF Standards Track Protocol, i.e., Service Function
  Chaining.

12. Have reasonable efforts been made to remind all authors of the
intellectual property rights (IPR) disclosure obligations described in
BCP 79? To the best of your knowledge, have all required disclosures
been filed? If not, explain why. If yes, summarize any relevant
discussion, including links to publicly-available messages when
applicable.

  Yes. See IPR statments by authors and listed contributors:
https://mailarchive.ietf.org/arch/msg/sfc/93GbhFxx0gUD_pJgiigTDb_8gDk/
https://mailarchive.ietf.org/arch/msg/sfc/VXG6Z_adulRM6rKScMr5vSA4SdM/
https://mailarchive.ietf.org/arch/msg/sfc/8HBnkE4wmtaGR3uc-V6XllVp65M/
https://mailarchive.ietf.org/arch/msg/sfc/IyCWQxuPsOUCqJqZx3E96pD71eM/
https://mailarchive.ietf.org/arch/msg/sfc/Uc71eGdiyMX6wdfOpW4jGsbhFCM/
https://mailarchive.ietf.org/arch/msg/sfc/3Zq1-nhbF6qVRzo4Mtb7-HdYoFg/
https://mailarchive.ietf.org/arch/msg/sfc/RsDeKQ81ej6hK6DinpsQdBXYS_0/
https://mailarchive.ietf.org/arch/msg/sfc/8Rde86WqbqyOebGdBIDCtdj4JE8/
(Linda Wang and Cui Wang are the same person.)

13. Has each Author or Contributor confirmed their willingness to be
listed as such? If the number of Authors/Editors on the front page is
greater than 5, please provide a justification.

  This draft is the result of merging three drafts:
    draft-wang-sfc-multi-layer-oam
    draft-ao-sfc-oam-path-consistency
    draft-ao-sfc-oam-return-path-specified
  Six authors are listed to provide appropriate credit.

14. Identify any remaining I-D nits in this document. (See the idnits
tool and the checkbox items found in Guidelines to Authors of
Internet-Drafts). Simply running the idnits tool is not enough; please
review the entire guidelines document.

  The reference to draft-ietf-sfc-nsh-tlv should be updated to
  reference RFC 9263.

15. Should any informative references be normative or vice-versa?

  I believe the references are correcly clasified as informative and
  normative.

16. List any normative references that are not freely available to
anyone.

  There are none.

17. Are there any normative downward references (see RFC 3967, BCP
97
)? If so, list them.

  No.

18. Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If they exist, what
is the plan for their completion?

  This document is normatively dependent on draft-ietf-sfc-oam-packet
  which has passed WG Consensus, had publication requested, and is
  currently in AD Review.

19. Will publication of this document change the status of any
existing RFCs?

  No.

20. Describe the document shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of
the document. Confirm that all aspects of the document requiring IANA
assignments are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that each newly created IANA registry
specifies its initial contents, allocations procedures, and a
reasonable name (see RFC 8126).

  The IANA Considerations section allocates one value from the
  existing SFC NSH Next Protocol registry for SFC Active OAM. It then
  defines a number of registries/sub-registries related to such
  messages.  The initial contents of such new registried are specified
  along with reasonable allocation procedures and registry name.

21. List any new IANA registries that require Designated Expert Review
for future allocations. Are the instructions to the Designated Expert
clear? Please include suggestions of designated experts, if
appropriate.

  The draft creates a number of registries/sub-registries but in all
  cases the assignment criterion are Standards Action, IETF Review, or
  First Come First Served so no Designated Experts are required.
2022-08-15
22 Donald Eastlake
Shepherd Review of draft-ietf-sfc-multi-layer-oam-22.txt

1. Does the working group (WG) consensus represent the strong concurrence
of a few individuals, with others being silent, or did …
Shepherd Review of draft-ietf-sfc-multi-layer-oam-22.txt

1. Does the working group (WG) consensus represent the strong concurrence
of a few individuals, with others being silent, or did it reach broad
agreement?

  There is broad agreement in the WG to publish this draft. Note that
  it was the merger of three preceeding draft and there has been
  discussion of those as well as this draft.

2. Was there controversy about particular points, or were there decisions
where the consensus was particularly rough?

  No.

3. Has anyone threatened an appeal or otherwise indicated extreme
discontent?

  No.

4. For protocol documents, are there existing implementations of the
contents of the document? Have a significant number of potential
implementers indicated plans to implement? Are any existing
implementations reported somewhere, either in the document itself (as
RFC 7942 recommends) or elsewhere (where)?

  tbd

5. Does this document need review from other IETF working groups or
external organizations?

  No.

6. Describe how the document meets any required formal expert review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.

  No such formal expert review required.

7. If the document contains a YANG module, has the final version of
the module been checked with any of the recommended validation tools
for syntax and formatting validation?

  The document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate
sections of the final version of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL,
ASN.1 modules, etc.  Document Shepherd Checks.

  No formal language review required. Shepherd's review:
  https://mailarchive.ietf.org/arch/msg/sfc/-FAoZG2HIPf985WwBggU84TmQxE/
  WG participants have reviewed the draft and their comments have been resolved.

9. Based on the shepherd's review of the document, is it their opinion
that this document is needed, clearly written, complete, correctly
designed, and ready to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled lists of common issues that
their reviewers encounter. Do any such issues remain that would merit
specific attention from subsequent reviews?

  I have reviewed the draft in light of
  https://trac.ietf.org/trac/rtg/wiki/RtgADNits

11. What type of RFC publication is being requested on the IETF stream
(Best Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this
intent?

  As stated on the title page, Standrds Track is requested. This is
  appropriate for an OAM protocol that is augmenting a standardized
  and deployed IETF Standards Track Protocol, i.e., Service Function
  Chaining.

12. Have reasonable efforts been made to remind all authors of the
intellectual property rights (IPR) disclosure obligations described in
BCP 79? To the best of your knowledge, have all required disclosures
been filed? If not, explain why. If yes, summarize any relevant
discussion, including links to publicly-available messages when
applicable.

  Yes. See IPR statments by authors and listed contributors:
https://mailarchive.ietf.org/arch/msg/sfc/93GbhFxx0gUD_pJgiigTDb_8gDk/
https://mailarchive.ietf.org/arch/msg/sfc/VXG6Z_adulRM6rKScMr5vSA4SdM/
https://mailarchive.ietf.org/arch/msg/sfc/8HBnkE4wmtaGR3uc-V6XllVp65M/
https://mailarchive.ietf.org/arch/msg/sfc/IyCWQxuPsOUCqJqZx3E96pD71eM/
https://mailarchive.ietf.org/arch/msg/sfc/Uc71eGdiyMX6wdfOpW4jGsbhFCM/
https://mailarchive.ietf.org/arch/msg/sfc/3Zq1-nhbF6qVRzo4Mtb7-HdYoFg/
https://mailarchive.ietf.org/arch/msg/sfc/RsDeKQ81ej6hK6DinpsQdBXYS_0/
- - still needed: Kent Leung
(Linda Wang and Cui Wang are the same person.)

13. Has each Author or Contributor confirmed their willingness to be
listed as such? If the number of Authors/Editors on the front page is
greater than 5, please provide a justification.

  This draft is the result of merging three drafts:
    draft-wang-sfc-multi-layer-oam
    draft-ao-sfc-oam-path-consistency
    draft-ao-sfc-oam-return-path-specified
  Six authors are listed to provide appropriate credit.

14. Identify any remaining I-D nits in this document. (See the idnits
tool and the checkbox items found in Guidelines to Authors of
Internet-Drafts). Simply running the idnits tool is not enough; please
review the entire guidelines document.

  The reference to draft-ietf-sfc-nsh-tlv should be updated to
  reference RFC 9263.

15. Should any informative references be normative or vice-versa?

  I believe the references are correcly clasified as informative and
  normative.

16. List any normative references that are not freely available to
anyone.

  There are none.

17. Are there any normative downward references (see RFC 3967, BCP
97
)? If so, list them.

  No.

18. Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If they exist, what
is the plan for their completion?

  This document is normatively dependent on draft-ietf-sfc-oam-packet
  which has passed WG Consensus, had publication requested, and is
  currently in AD Review.

19. Will publication of this document change the status of any
existing RFCs?

  No.

20. Describe the document shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of
the document. Confirm that all aspects of the document requiring IANA
assignments are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that each newly created IANA registry
specifies its initial contents, allocations procedures, and a
reasonable name (see RFC 8126).

  The IANA Considerations section allocates one value from the
  existing SFC NSH Next Protocol registry for SFC Active OAM. It then
  defines a number of registries/sub-registries related to such
  messages.  The initial contents of such new registried are specified
  along with reasonable allocation procedures and registry name.

21. List any new IANA registries that require Designated Expert Review
for future allocations. Are the instructions to the Designated Expert
clear? Please include suggestions of designated experts, if
appropriate.

  The draft creates a number of registries/sub-registries but in all
  cases the assignment criterion are Standards Action, IETF Review, or
  First Come First Served so no Designated Experts are required.
2022-08-14
22 Donald Eastlake Notification list changed to donald.eastlake@futurewei.com, d3e3e3@gmail.com from donald.eastlake@futurewei.com
2022-07-25
22 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-22.txt
2022-07-25
22 Greg Mirsky New version accepted (logged-in submitter: Greg Mirsky)
2022-07-25
22 Greg Mirsky Uploaded new revision
2022-07-09
21 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-21.txt
2022-07-09
21 Greg Mirsky New version accepted (logged-in submitter: Greg Mirsky)
2022-07-09
21 Greg Mirsky Uploaded new revision
2022-06-27
20 Joel Halpern Notification list changed to donald.eastlake@futurewei.com because the document shepherd was set
2022-06-27
20 Joel Halpern Document shepherd changed to Donald E. Eastlake 3rd
2022-06-27
20 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-20.txt
2022-06-27
20 Greg Mirsky New version accepted (logged-in submitter: Greg Mirsky)
2022-06-27
20 Greg Mirsky Uploaded new revision
2022-06-27
19 Joel Halpern The authors will be posting a revision to reflect WG last call comments.
2022-06-27
19 Joel Halpern IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2022-03-31
19 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-19.txt
2022-03-31
19 (System) New version accepted (logged-in submitter: Greg Mirsky)
2022-03-31
19 Greg Mirsky Uploaded new revision
2021-12-20
18 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-18.txt
2021-12-20
18 (System) New version accepted (logged-in submitter: Greg Mirsky)
2021-12-20
18 Greg Mirsky Uploaded new revision
2021-11-26
17 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-17.txt
2021-11-26
17 (System) New version accepted (logged-in submitter: Greg Mirsky)
2021-11-26
17 Greg Mirsky Uploaded new revision
2021-10-19
16 Joel Halpern
This document has been discussed in the working group extensively.  It was just revised to include some content from other drafts, and that was discussed.  …
This document has been discussed in the working group extensively.  It was just revised to include some content from other drafts, and that was discussed.  Now we are looking to finish this up.  Please speak up if you consider that it is done and ready for publication as a Proposed Standard.  Alternatively, if you see difficulties or reasons why it should not be published as a PS, please speak up.  Preferably with an explanation of the concerns you have.

Thank you.  This call will last until 3-November-2021.


Yours,
Joel and Jim
2021-10-19
16 Joel Halpern IETF WG state changed to In WG Last Call from WG Document
2021-10-19
16 Joel Halpern Changed consensus to Yes from Unknown
2021-10-19
16 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-16.txt
2021-10-19
16 (System) New version accepted (logged-in submitter: Greg Mirsky)
2021-10-19
16 Greg Mirsky Uploaded new revision
2021-10-15
15 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-15.txt
2021-10-15
15 (System) New version accepted (logged-in submitter: Greg Mirsky)
2021-10-15
15 Greg Mirsky Uploaded new revision
2021-10-08
14 Greg Mirsky This document now replaces draft-wang-sfc-multi-layer-oam, draft-ao-sfc-oam-path-consistency, draft-ao-sfc-oam-return-path-specified instead of draft-wang-sfc-multi-layer-oam
2021-10-08
14 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-14.txt
2021-10-08
14 (System) New version accepted (logged-in submitter: Greg Mirsky)
2021-10-08
14 Greg Mirsky Uploaded new revision
2021-06-16
13 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-13.txt
2021-06-16
13 (System) New version approved
2021-06-16
13 (System) Request for posting confirmation emailed to previous authors: "Cui(Linda) Wang" , Bhumip Khasnabish , Greg Mirsky , Wei Meng
2021-06-16
13 Greg Mirsky Uploaded new revision
2021-06-03
12 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-12.txt
2021-06-03
12 (System) New version approved
2021-06-03
12 (System) Request for posting confirmation emailed to previous authors: "Cui(Linda) Wang" , Bhumip Khasnabish , Greg Mirsky , Wei Meng
2021-06-03
12 Greg Mirsky Uploaded new revision
2021-05-25
11 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-11.txt
2021-05-25
11 (System) New version approved
2021-05-25
11 (System) Request for posting confirmation emailed to previous authors: "Cui(Linda) Wang" , Bhumip Khasnabish , Greg Mirsky , Wei Meng
2021-05-25
11 Greg Mirsky Uploaded new revision
2021-03-30
10 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-10.txt
2021-03-30
10 (System) New version approved
2021-03-30
10 (System) Request for posting confirmation emailed to previous authors: "Cui(Linda) Wang" , Bhumip Khasnabish , Greg Mirsky , Wei Meng
2021-03-30
10 Greg Mirsky Uploaded new revision
2021-02-11
09 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-09.txt
2021-02-11
09 (System) New version approved
2021-02-11
09 (System) Request for posting confirmation emailed to previous authors: "Cui(Linda) Wang" , Bhumip Khasnabish , Greg Mirsky , Wei Meng
2021-02-11
09 Greg Mirsky Uploaded new revision
2021-01-19
08 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-08.txt
2021-01-19
08 (System) New version approved
2021-01-19
08 (System) Request for posting confirmation emailed to previous authors: "Cui(Linda) Wang" , Bhumip Khasnabish , Greg Mirsky , Wei Meng
2021-01-19
08 Greg Mirsky Uploaded new revision
2020-12-14
07 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-07.txt
2020-12-14
07 (System) New version approved
2020-12-14
07 (System) Request for posting confirmation emailed to previous authors: Greg Mirsky , "Cui(Linda) Wang" , Bhumip Khasnabish , Wei Meng
2020-12-14
07 Greg Mirsky Uploaded new revision
2020-12-04
06 (System) Document has expired
2020-06-02
06 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-06.txt
2020-06-02
06 (System) New version accepted (logged-in submitter: Greg Mirsky)
2020-06-02
06 Greg Mirsky Uploaded new revision
2020-05-20
05 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-05.txt
2020-05-20
05 (System) New version approved
2020-05-20
05 (System) Request for posting confirmation emailed to previous authors: Greg Mirsky , Bhumip Khasnabish , Wei Meng , "Cui(Linda) Wang"
2020-05-20
05 Greg Mirsky Uploaded new revision
2019-11-18
04 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-04.txt
2019-11-18
04 (System) New version approved
2019-11-18
04 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Bhumip Khasnabish , Wei Meng , "Cui\(Linda\) Wang" , sfc-chairs@ietf.org
2019-11-18
04 Greg Mirsky Uploaded new revision
2019-11-18
03 (System) Document has expired
2019-05-08
03 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-03.txt
2019-05-08
03 (System) New version approved
2019-05-08
03 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Bhumip Khasnabish , Wei Meng , "Cui\(Linda\) Wang" , sfc-chairs@ietf.org
2019-05-08
03 Greg Mirsky Uploaded new revision
2019-03-27
02 Tal Mizrahi Added to session: IETF-104: sfc  Thu-1610
2019-03-08
02 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-02.txt
2019-03-08
02 (System) New version approved
2019-03-08
02 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Bhumip Khasnabish , Wei Meng , "Cui\(Linda\) Wang" , sfc-chairs@ietf.org
2019-03-08
02 Greg Mirsky Uploaded new revision
2019-01-28
01 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-01.txt
2019-01-28
01 (System) New version approved
2019-01-28
01 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Wei Meng , "Cui\(Linda\) Wang" , sfc-chairs@ietf.org, Bhumip Khasnabish
2019-01-28
01 Greg Mirsky Uploaded new revision
2018-11-13
Jenny Bui Posted related IPR disclosure: Orange's Statement about IPR related to draft-ietf-sfc-multi-layer-oam
2018-11-04
00 Joel Halpern This document now replaces draft-wang-sfc-multi-layer-oam instead of None
2018-11-04
00 Greg Mirsky New version available: draft-ietf-sfc-multi-layer-oam-00.txt
2018-11-04
00 (System) WG -00 approved
2018-11-04
00 Greg Mirsky Set submitter to "Greg Mirsky ", replaces to draft-wang-sfc-multi-layer-oam and sent approval email to group chairs: sfc-chairs@ietf.org
2018-11-04
00 Greg Mirsky Uploaded new revision