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 |