Path Segment Identifier in MPLS Based Segment Routing Network
draft-ietf-spring-mpls-path-segment-22
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-02-22
|
(System) | Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-spring-mpls-path-segment and RFC 9545, changed IESG state to RFC … Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-spring-mpls-path-segment and RFC 9545, changed IESG state to RFC Published) |
|
2024-02-21
|
22 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2024-02-16
|
22 | (System) | RFC Editor state changed to AUTH48 |
2024-01-29
|
22 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2024-01-26
|
22 | Gunter Van de Velde | Request closed, assignment withdrawn: Carlos Martínez Last Call OPSDIR review |
2024-01-26
|
22 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue |
2023-12-15
|
22 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'Overtaken by Events' |
2023-12-15
|
22 | Tero Kivinen | Assignment of request for Last Call review by SECDIR to Michael Jones was marked no-response |
2023-12-04
|
22 | (System) | RFC Editor state changed to EDIT |
2023-12-04
|
22 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2023-12-04
|
22 | (System) | Announcement was received by RFC Editor |
2023-12-01
|
22 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2023-12-01
|
22 | (System) | IANA Action state changed to In Progress |
2023-12-01
|
22 | (System) | Removed all action holders (IESG state changed) |
2023-12-01
|
22 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2023-12-01
|
22 | Cindy Morgan | IESG has approved the document |
2023-12-01
|
22 | Cindy Morgan | Closed "Approve" ballot |
2023-12-01
|
22 | Cindy Morgan | Ballot approval text was generated |
2023-11-30
|
22 | Jim Guichard | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2023-11-30
|
22 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation |
2023-11-30
|
22 | Paul Wouters | [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters |
2023-11-30
|
22 | Andrew Alston | [Ballot comment] Many thanks for addressing the previous discuss that can be found in the history in such a prompt manner! |
2023-11-30
|
22 | Andrew Alston | [Ballot Position Update] Position for Andrew Alston has been changed to No Objection from Discuss |
2023-11-30
|
22 | Cheng Li | New version available: draft-ietf-spring-mpls-path-segment-22.txt |
2023-11-30
|
22 | Cheng Li | New version accepted (logged-in submitter: Cheng Li) |
2023-11-30
|
22 | Cheng Li | Uploaded new revision |
2023-11-30
|
21 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2023-11-30
|
21 | Cheng Li | New version available: draft-ietf-spring-mpls-path-segment-21.txt |
2023-11-30
|
21 | Cheng Li | New version accepted (logged-in submitter: Cheng Li) |
2023-11-30
|
21 | Cheng Li | Uploaded new revision |
2023-11-30
|
20 | Lars Eggert | [Ballot comment] # GEN AD review of draft-ietf-spring-mpls-path-segment-20 CC @larseggert Thanks to Stewart Bryant for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/8Y8zdymWO5b2jAqASpybK3TbVHU). … [Ballot comment] # GEN AD review of draft-ietf-spring-mpls-path-segment-20 CC @larseggert Thanks to Stewart Bryant for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/8Y8zdymWO5b2jAqASpybK3TbVHU). ## Comments ### Section 1, paragraph 3 ``` However, to support various use-cases in SR-MPLS networks, such as Performance MeasurementSection 3.1, bidirectional path Section 3.2, and end-to-end 1+1 path protection (Live-Live case) Section 3.3, the ability to implement path identification on the egress node is a pre- requisite. ``` This paragraph is really incomprehensible. ### Section 2, paragraph 2 ``` A PSID is used to identify a Segment List. However, one PSID can be used to identify multiple Segment Lists in some use cases if needed. For example, one single PSID MAY be used to identify some or all Segment lists in a Candidate path or an SR policy, if an operator would like to aggregate these Segment Lists in operation. ``` This is confusing. Either a PSID (uniquely?) identifies *one* segment list, or it does not. If it can identify multiple (disjoint?) segment lists, the details of how this works need to be described much more clearly. ### Section 3, paragraph 0 ``` 3. Use cases ``` I assume this section is informational? It would be good to say so explicitly. ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### URLs These URLs in the document did not return content: * https://www.fiberhome.com/operator/product/products/294.aspx.htm ### Grammar/style #### Section 3.2, paragraph 3 ``` trusted domain that spans three sub-domains (Access, Aggregation and Core do ^^^^^^^^^^^ ``` This word is normally spelled as one. #### Section 3.2, paragraph 4 ``` of three sub-paths, one in each sub-domain (sub-path (A->B), sub-path (B->C ^^^^^^^^^^ ``` This word is normally spelled as one. #### Section 3.3, paragraph 1 ``` ub-path is associated with a BSID and a s-PSID. The SID list of the end-to-e ^ ``` Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". #### Section 3.4, paragraph 8 ``` PSID from an egress nodes to an ingress nodes is performed within an SR tru ^^^^^^^^^^^^^^^^ ``` The plural noun "nodes" cannot be used with the article "an". #### Section 5.1, paragraph 3 ``` auses have been implemented in above mentioned New H3C Products(running Versi ^^^^^^^^^^^^^^^ ``` The adjective "above-mentioned" is spelled with a hyphen. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool |
2023-11-30
|
20 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2023-11-29
|
20 | Andrew Alston | [Ballot discuss] I'd like to have a discussion as regards how this will function in scenarios using UHP. My understanding is that by default SR-MPLS … [Ballot discuss] I'd like to have a discussion as regards how this will function in scenarios using UHP. My understanding is that by default SR-MPLS implements PHP - so the router that receives a packet with a PSID will normally find the PSID at top of stack (it may be the only label but it will be top stack). This however changes in the case of explicit NULL - which may or may not be BoS. Normally explicit NULL would be popped on egress - however, in this case the explicit NULL would have to be "ignored (stepped over)" such that the PSID could be processed - and then on egress the explicit NULL and the PSID would have to be popped. Alternatively, the explicit NULL would need to be popped, the PSID processed, and then the PSID popped. I'm not quite sure what the implications of this would be, though, at minimum, this could potentially result in significant performance degradation. Either way, lets discuss because I think this scenario does need addressing. |
2023-11-29
|
20 | Andrew Alston | [Ballot comment] Firstly, thanks for the document, I found this a relatively easy read. A few nits and comments below. Section 1 3rd paragraph is … [Ballot comment] Firstly, thanks for the document, I found this a relatively easy read. A few nits and comments below. Section 1 3rd paragraph is missing a space on the second line, and that paragraph may actually be easier to read if you put the Sectional references in brackets, such that Section 3.1 becomes (Section 3.1) etc. In Section 2 you write "The value of the TTL field in the MPLS label stack entry containing a PSID can be set to any value except 0. If a PSID is the bottom label, the S bit MUST be set." Now, I am presuming that the the PSID does NOT need to be at the bottom of stack. This is based on my reading of section 3.4. In the example, you are pushing s-PSID followed by two BSID's and then a final e-PSID. Am I correct in thinking you could have a situation which each BSID is followed by a PSID, such that you are including the s-PSID for B->C and the s-PSID for C->D? If I am correct in this reading - I would suggest that you explicitly state that if the PSID is NOT the bottom label, the S bit must NOT be set. (So as suggested text, "If a PSID is the bottom label, the S bit MUST be set. Conversely if the PSID is followed by subsequent labels, the S bit MUST NOT be set" As another random note - it may be worth working with the authors of draft-ietf-idr-segment-routing-te-policy to add PSID into the SR Policy Encoding in the same way that BSID's are specified. |
2023-11-29
|
20 | Andrew Alston | [Ballot Position Update] New position, Discuss, has been recorded for Andrew Alston |
2023-11-29
|
20 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2023-11-29
|
20 | Cheng Li | New version available: draft-ietf-spring-mpls-path-segment-20.txt |
2023-11-29
|
20 | Cheng Li | New version accepted (logged-in submitter: Cheng Li) |
2023-11-29
|
20 | Cheng Li | Uploaded new revision |
2023-11-28
|
19 | John Scudder | [Ballot comment] # John Scudder, RTG AD, comments for draft-ietf-spring-mpls-path-segment-19 CC @jgscudder Thanks for this document. I have a few non-blocking comments, below. ## COMMENTS … [Ballot comment] # John Scudder, RTG AD, comments for draft-ietf-spring-mpls-path-segment-19 CC @jgscudder Thanks for this document. I have a few non-blocking comments, below. ## COMMENTS ### Applicability to SRv6 Since SRv6 also doesn't guarantee to propagate the SID list all the way to the egress node, might PSID functionality potentially also be required in SRv6? The way it's defined in this document, it's tightly bound to SR-MPLS, might this create added complication in the future if an SRv6 instantiation is desired? I'm not at all suggesting you define such an SRv6 instantiation in this document. At most, maybe you would revise some of the text in Section 2, to leave open the possibility for such an instantiation in the future. ### Terminology It's probably worth saying somewhere that you assume knowledge of the definitions in Section 2 of RFC 8402. For example, "Local Segment" isn't defined in your document, presumably you're relying on the RFC 8402 definition. I didn't carefully track whether there are other terms similarly in need of definition. ### Section 1.2, orphan and near-orphan definitions Some abbreviations are never used, maybe these were used in a previous version of the document, I don't know. Anyway, I think they can be removed from the section now. Some abbreviations are used only once. In my opinion, it would be better to just spell them out where used, instead of introducing an abbreviation and then only using it once. Never used: DM LM SL Used once: PM SRLB Used twice, in the same paragraph, so IMO not needed to be listed in the abbreviations section: MSD ### Section 2, "below MPLS label" I don't understand what precisely you mean by, "The addition of the PSID will require the egress to read and process the PSID label in addition to the regular processing (such as a below MPLS label or the MPLS payload)." What's a "below MPLS label"? I also think "MPLS payload", would be clearer as just "payload" -- using "MPLS" as an adjective doesn't seem to add value in this context. Ironically, I would find the sentence perfectly clear if the portion inside parentheses were removed. ### Section 2, is PSID always the bottom label, or not? Figure 1 implies PSID is always the bottom label. A few paragraphs about that, though, you have "If a PSID is the bottom label, the S bit MUST be set." The "if" implies the PSID doesn't have to be the bottom level. It seems that either Figure 1 or the quoted text should be updated, to make them consistent. Based on Section 3.4, I guess the text is right and Figure 1 is wrong, or at least misleading. One possible fix could be, OLD: The label stack with PSID is shown in Figure 1: NEW: An example label stack with PSID is shown in Figure 1: ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments |
2023-11-28
|
19 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2023-11-28
|
19 | Cheng Li | New version available: draft-ietf-spring-mpls-path-segment-19.txt |
2023-11-28
|
19 | Cheng Li | New version accepted (logged-in submitter: Cheng Li) |
2023-11-28
|
19 | Cheng Li | Uploaded new revision |
2023-11-28
|
18 | Zaheduzzaman Sarker | [Ballot comment] Thanks for working on this specification. I have no objection from transport protocol point of view. |
2023-11-28
|
18 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2023-11-28
|
18 | Robert Wilton | [Ballot comment] Hi, Thanks for this document. I found is pretty easy to read, and have a couple of very minor (editorial) comments: Nit level … [Ballot comment] Hi, Thanks for this document. I found is pretty easy to read, and have a couple of very minor (editorial) comments: Nit level comments: (1) p 6, sec 3.1. PSID for Performance Measurement PSID can also be used for In-situ OAM[RFC9197] for SR-MPLS to identify the SR Path associated with the in-situ data fields in the data packets on the egress node. PSID can also be used for In-band PM for SR-MPLS to identify the SR Path associated with the collected performance metrics. Just cosmetic, but given the repetition, perhaps put the last 3 sentences in this section into a list, e.g., starting with "PSID can also be used:" (2) p 7, sec 3.4. Nesting of PSIDs Binding SID (BSID) [RFC8402] can be used for SID list compression. With BSID, an end-to-end SR path in a trusted domain can be split into several sub-paths, each sub-path is identified by a BSID. Then an end-to-end SR path can be identified by a list of BSIDs, therefore, it can provide better scalability. BSID and PSID can be combined to achieve both sub-path and end-to-end path monitoring. A reference model for such a combination in (Figure 2) shows an end-to-end path (A->D) in a trusted domain that spans three sub-domains (Access, Aggregation and Core domain) and consists of three sub-paths, one in each sub-domain (sub-path (A->B), sub-path (B->C) and sub-path (C->D)). Each sub-path is associated with a BSID and a s-PSID. As a minor nit, s-PSID is used above, but not defined until the following paragraph. Regards, Rob |
2023-11-28
|
18 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2023-11-27
|
18 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2023-11-27
|
18 | Cheng Li | New version available: draft-ietf-spring-mpls-path-segment-18.txt |
2023-11-27
|
18 | Cheng Li | New version accepted (logged-in submitter: Cheng Li) |
2023-11-27
|
18 | Cheng Li | Uploaded new revision |
2023-11-25
|
17 | Erik Kline | [Ballot comment] # Internet AD comments for draft-ietf-spring-mpls-path-segment-17 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Nits … [Ballot comment] # Internet AD comments for draft-ietf-spring-mpls-path-segment-17 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Nits ### S1.2 * "a part of the a path" -> "a part of the path" |
2023-11-25
|
17 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2023-11-24
|
17 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2023-11-22
|
17 | Éric Vyncke | [Ballot comment] # Éric Vyncke, INT AD, comments for draft-ietf-spring-mpls-path-segment-17 Thank you for the work put into this document. Please find below some non-blocking COMMENT … [Ballot comment] # Éric Vyncke, INT AD, comments for draft-ietf-spring-mpls-path-segment-17 Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Bruno Decraene (one WG chair) for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Abstract and title If the goal is to identify a specific SR path, then why not adding "identification" in the title and the abstract ? PSID is used in the rest of the document and would benefit from being used also in the abstract/title. In `A sub-set of segments from the segment list cannot distinguish one SR path from another as they may be partially congruent`, suggest s/cannot distinguish/cannot be leveraged to distinguish/ ## Lack of extensibility ? As PSID seems to be solely identified by its position (the last label), does it prevent the use of a similar mechanism for future extension of SR list ? Should there be a syntax in this last label to identify it as a PSID? ## Section 2 `However, one PSID can be used to identify multiple Segment Lists in some use cases if needed.` seems like an oxymoron to me (bear with my lack of expertise in SR-MPLS)... Usually "identify" refers to a single identity, i.e., a single segment list in this case. ## Section 2.1 Suggest to introduce ECMP in the title and not in the 3rd paragraph *after* its first use. ## Section 3 Please use PSID rather than "path segment". ## Section 3.1 s/existing implementation on the egress node can be leveraged for measuring/existing implementation on the egress node can leverage PSID for measuring/ ? ## Section 3.2 An informative reference will be useful to the reader about `obile backhaul transport networks, there are requirements to support bidirectional paths`. ## Section 3.4 What is meant by `in a trusted domain` ? Is it rather a common operation ? To be honest, I was about to ballot a DISCUSS on the following point... but I am trusting the RTG AD ;), how can a global PSID be used for perf measurement (and other use cases) when the sub-domains can expenad the BSID at their will ? I.e., PSID does not represent a real hop-by-hop path but more a sub-domain to sub-domain path... ## Section 4 `The intermediate nodes of this path will not learn it.` is it true for the first node ? I.e., it knows where it is coming from and have the full view on the segment list. ## Operational considerations The last paragraph of section 4 should rather be in an "operational considerations" section. # NITS (non-blocking / cosmetic) ## Section 1.2 s/A sub-path is a part of the a path/A sub-path is a part of a path/ ? ## Section 2 s/intermedate node/intermediate node/ ## Section 3 s/can leveage/can leverage/ |
2023-11-22
|
17 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2023-11-17
|
17 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2023-11-16
|
17 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2023-11-16
|
17 | Cheng Li | New version available: draft-ietf-spring-mpls-path-segment-17.txt |
2023-11-16
|
17 | Cheng Li | New version accepted (logged-in submitter: Cheng Li) |
2023-11-16
|
17 | Cheng Li | Uploaded new revision |
2023-11-15
|
16 | Matthew Bocci | Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Matthew Bocci. Sent review to list. |
2023-10-31
|
16 | Daniam Henriques | Request for Last Call review by RTGDIR is assigned to Matthew Bocci |
2023-10-31
|
16 | Daniam Henriques | Assignment of request for Last Call review by RTGDIR to Zhaohui Zhang was withdrawn |
2023-10-26
|
16 | Jim Guichard | Placed on agenda for telechat - 2023-11-30 |
2023-10-26
|
16 | Jim Guichard | Ballot has been issued |
2023-10-26
|
16 | Jim Guichard | [Ballot Position Update] New position, Yes, has been recorded for Jim Guichard |
2023-10-26
|
16 | Jim Guichard | Created "Approve" ballot |
2023-10-26
|
16 | Jim Guichard | IESG state changed to IESG Evaluation from Waiting for Writeup |
2023-10-26
|
16 | Jim Guichard | Ballot writeup was changed |
2023-10-26
|
16 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2023-10-25
|
16 | Stewart Bryant | Request for Last Call review by GENART Completed: Ready. Reviewer: Stewart Bryant. Sent review to list. |
2023-10-24
|
16 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2023-10-24
|
16 | David Dong | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-spring-mpls-path-segment-16, which is currently in Last Call (we had also reviewed draft-ietf-spring-mpls-path-segment-08 in … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-spring-mpls-path-segment-16, which is currently in Last Call (we had also reviewed draft-ietf-spring-mpls-path-segment-08 in a previous Last Call), and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. For definitions of IANA review states, please see: https://datatracker.ietf.org/help/state/draft/iana-review Thank you, David Dong IANA Services Sr. Specialist |
2023-10-19
|
16 | Jean Mahoney | Request for Last Call review by GENART is assigned to Stewart Bryant |
2023-10-19
|
16 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'Withdrawn' |
2023-10-17
|
16 | Haomian Zheng | Request for Last Call review by RTGDIR is assigned to Zhaohui Zhang |
2023-10-17
|
16 | Haomian Zheng | Assignment of request for Last Call review by RTGDIR to Stewart Bryant was rejected |
2023-10-17
|
16 | Haomian Zheng | Request for Last Call review by RTGDIR is assigned to Stewart Bryant |
2023-10-13
|
16 | Jim Guichard | Requested Last Call review by RTGDIR |
2023-10-13
|
16 | Jim Guichard | Requested Last Call review by SECDIR |
2023-10-12
|
16 | Cindy Morgan | The following Last Call announcement was sent out (ends 2023-10-26): From: The IESG To: IETF-Announce CC: bruno.decraene@orange.com, draft-ietf-spring-mpls-path-segment@ietf.org, james.n.guichard@futurewei.com, spring-chairs@ietf.org, spring@ietf.org … The following Last Call announcement was sent out (ends 2023-10-26): From: The IESG To: IETF-Announce CC: bruno.decraene@orange.com, draft-ietf-spring-mpls-path-segment@ietf.org, james.n.guichard@futurewei.com, spring-chairs@ietf.org, spring@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Path Segment in MPLS Based Segment Routing Network) to Proposed Standard The IESG has received a request from the Source Packet Routing in Networking WG (spring) to consider the following document: - 'Path Segment in MPLS Based Segment Routing Network' 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-10-26. 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 Segment Routing (SR) path is identified by an SR segment list. A sub-set of segments from the segment list cannot distinguish one SR path from another as they may be partially congruent. SR path identification is a pre-requisite for various use-cases such as Performance Measurement (PM), and end-to-end 1+1 path protection. In SR for MPLS data plane (SR-MPLS), an Egress node cannot determine on which SR path a packet traversed the network from the label stack because the segment identifiers are removed from the label stack as the packet transits the network. This document defines Path Segment to identify an SR path on the egress node of the path. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3492/ https://datatracker.ietf.org/ipr/5895/ https://datatracker.ietf.org/ipr/5063/ https://datatracker.ietf.org/ipr/5009/ https://datatracker.ietf.org/ipr/3455/ |
2023-10-12
|
16 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested::AD Followup |
2023-10-12
|
16 | Cindy Morgan | Last call announcement was generated |
2023-10-12
|
16 | Jim Guichard | Last call was requested |
2023-10-12
|
16 | (System) | Changed action holders to Jim Guichard (IESG state changed) |
2023-10-12
|
16 | Jim Guichard | IESG state changed to Last Call Requested::AD Followup from AD Evaluation::AD Followup |
2023-10-12
|
16 | (System) | Changed action holders to Jim Guichard, Mach Chen (IESG state changed) |
2023-10-12
|
16 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2023-10-12
|
16 | Cheng Li | New version available: draft-ietf-spring-mpls-path-segment-16.txt |
2023-10-12
|
16 | Cheng Li | New version accepted (logged-in submitter: Cheng Li) |
2023-10-12
|
16 | Cheng Li | Uploaded new revision |
2023-10-09
|
15 | Jim Guichard | https://mailarchive.ietf.org/arch/msg/spring/ic3aTXox78qoYycx0RMGShJZNn0/ AD review comments. |
2023-10-09
|
15 | (System) | Changed action holders to Weiqiang Cheng, Han Li, Cheng Li, Rakesh Gandhi, Royi Zigler, Mach Chen (IESG state changed) |
2023-10-09
|
15 | Jim Guichard | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2023-10-09
|
15 | Jim Guichard | AD review for draft-ietf-spring-mpls-path-segment-15 ### https://mailarchive.ietf.org/arch/msg/spring/ic3aTXox78qoYycx0RMGShJZNn0/ ### |
2023-10-05
|
15 | (System) | Changed action holders to Jim Guichard, Mach Chen (IESG state changed) |
2023-10-05
|
15 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2023-10-05
|
15 | Cheng Li | New version available: draft-ietf-spring-mpls-path-segment-15.txt |
2023-10-05
|
15 | Cheng Li | New version accepted (logged-in submitter: Cheng Li) |
2023-10-05
|
15 | Cheng Li | Uploaded new revision |
2023-09-25
|
14 | Jim Guichard | Waiting for final reviewer comments to be addressed before moving document forward to final AD review. |
2023-09-25
|
14 | (System) | Changed action holders to Mach Chen, Han Li, Weiqiang Cheng, Rakesh Gandhi, Royi Zigler, Cheng Li (IESG state changed) |
2023-09-25
|
14 | Jim Guichard | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2023-09-21
|
14 | Cheng Li | New version available: draft-ietf-spring-mpls-path-segment-14.txt |
2023-09-21
|
14 | (System) | New version approved |
2023-09-21
|
14 | (System) | Request for posting confirmation emailed to previous authors: Cheng Li , Han Li , Rakesh Gandhi , Royi Zigler , Weiqiang Cheng |
2023-09-21
|
14 | Cheng Li | Uploaded new revision |
2023-09-21
|
13 | Cheng Li | New version available: draft-ietf-spring-mpls-path-segment-13.txt |
2023-09-21
|
13 | (System) | New version approved |
2023-09-21
|
13 | (System) | Request for posting confirmation emailed to previous authors: Cheng Li , Han Li , Rakesh Gandhi , Royi Zigler , Weiqiang Cheng |
2023-09-21
|
13 | Cheng Li | Uploaded new revision |
2023-09-13
|
12 | Cheng Li | New version available: draft-ietf-spring-mpls-path-segment-12.txt |
2023-09-13
|
12 | Cheng Li | New version accepted (logged-in submitter: Cheng Li) |
2023-09-13
|
12 | Cheng Li | Uploaded new revision |
2023-09-13
|
11 | Bruno Decraene | Document History Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or … Document History Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? The document has been significantly reviewed and is partially implemented. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? No controversy. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. 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)? There are implementations and they are reported in the document (as RFC 7942 recommends). Additional Reviews Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. The document closely interacts with technology defined in the MPLS WG but does not change MPLS specifications. It defines a new type of Local Segment for Segment Routing MPLS. (Local Segment are defined in RFC 8402, SR-MPLS is defined in RFC 8660. Both are a product of the SPRING WG) Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The document has no MIB, YANG module, media type, URI type, or formal language. 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? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342? No YANG module. 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, etc. No formal language. Document Shepherd Checks 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. Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? An early RTGDIR and GENART review has been performed. An early OPSDIR and SECDIR review has been requested but not performed. 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? STD Track is requested. This is reflected in the data tracker and front page of the document. This seems appropriate to define a new type of Segment Routing segment (the Path Segment) which will likely need protocol extensions in YANG models, signaling and routing protocols (e.g. draft-ietf-pce-sr-path-segment) 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. There are five IPR disclosures reported in the datatracker. No relevant discussion in the WG. One IPR filed late that was of concern to the chairs but a satisfactory explaination was provided to the chairs by the filer. Authors have been asked to indicate whether they know of any undisclosed IPR https://mailarchive.ietf.org/arch/msg/spring/SkghkLE5JZvw9JGaAOSKRym-toM/ Missing authors have been asked again https://mailarchive.ietf.org/arch/msg/spring/3DvyDu6VnGihxWXn68Y6EsT2UtY/ Following replies have been received: W. Cheng https://mailarchive.ietf.org/arch/msg/spring/yBrg0SJTUu5yCzFsZJglRxSYCZs/ H. Li https://mailarchive.ietf.org/arch/msg/spring/gEtpviOJWMFwDqzd2uEw9yAgYEU/ C. Li https://mailarchive.ietf.org/arch/msg/spring/U_PJl3-i9Ot1qk7jNFsjg101g1U/ R. Gandhi https://mailarchive.ietf.org/arch/msg/spring/IFJqpu4MCGdxcg5wn2RqKE1_MXI/ R. Zigler https://mailarchive.ietf.org/arch/msg/spring/aMyvnakERbEkasT-jfGFOTr__Ro/ Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. Total number of authors is five. No author and no contributor have complained about being listed as such. All authors are aware that they are listed as authors as they have replied to the IPR call. Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) IdNits runs fine. "Content Guidelines" have been reviewed. Shepherd have reviewed the document multiple times (and as a result have found nits multiple times, so unfortunately that's not an indicate that there is no remaining nits) Two different consecutive shepherds have reviewed the document. Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References. References look fine to me. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? None. Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them. No Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? No. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. The publication of this document will not change the status of existing RFCs. 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). IANA section is empty, which is correct. 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. No new IANA registry. |
2023-09-13
|
11 | Bruno Decraene | Document History Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or … Document History Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? The document has been significantly reviewed and is implemented and deployed. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? No controversy. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. 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)? There are implementations and they are reported in the document (as RFC 7942 recommends). Additional Reviews Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. The document closely interacts with technology defined in the MPLS WG but does not change MPLS specifications. It defines a new type of Local Segment for Segment Routing MPLS. (Local Segment are defined in RFC 8402, SR-MPLS is defined in RC 8660. Both are a product of the SPRING WG) Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The document has no MIB, YANG module, media type, URI type, or formal language. 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? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342? No YANG module. 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, etc. No formal language. Document Shepherd Checks 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. Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? An early RTGDIR and GENART review has been performed. An early OPSDIR and SECDIR review has been requested but not performed. 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? STD Track is requested. This is reflected in the data tracker and front page of the document. This seems appropriate to define a new type of Segment Routing segment (the Path Segment) which will likely need protocol extensions in YANG models, signaling and routing protocols (e.g. draft-ietf-pce-sr-path-segment) 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. There are five IPR disclosures reported in the datatracker. No relevant discussion in the WG. One IPR filed late that was of concern to the chairs but a satisfactory explaination was provided to the chairs by the filer. Authors have been asked to indicate whether they know of any undisclosed IPR https://mailarchive.ietf.org/arch/msg/spring/SkghkLE5JZvw9JGaAOSKRym-toM/ Missing authors have been asked again https://mailarchive.ietf.org/arch/msg/spring/3DvyDu6VnGihxWXn68Y6EsT2UtY/ Following replies have been received: W. Cheng https://mailarchive.ietf.org/arch/msg/spring/yBrg0SJTUu5yCzFsZJglRxSYCZs/ H. Li C. Li https://mailarchive.ietf.org/arch/msg/spring/U_PJl3-i9Ot1qk7jNFsjg101g1U/ R. Gandhi https://mailarchive.ietf.org/arch/msg/spring/IFJqpu4MCGdxcg5wn2RqKE1_MXI/ R. Zigler https://mailarchive.ietf.org/arch/msg/spring/aMyvnakERbEkasT-jfGFOTr__Ro/ /TODO Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. Total number of authors is five. No author and no contributor have complained about being listed as such. /TODO All authors are aware that they are listed as authors as they have replied to the IPR call. Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) IdNits runs fine. "Content Guidelines" have been reviewed. Shepherd have reviewed the document multiple times (and as a result have found nits multiple times, so unfortunately that's not an indicate that there is no remaining nits) Two different consecutive shepherds have reviewed the document. Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References. References look fine to me. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? None. Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them. No Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? No. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. The publication of this document will not change the status of existing RFCs. 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). IANA section is empty, which is correct. 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. No new IANA registry. |
2023-08-29
|
11 | Cheng Li | New version available: draft-ietf-spring-mpls-path-segment-11.txt |
2023-08-29
|
11 | Cheng Li | New version accepted (logged-in submitter: Cheng Li) |
2023-08-29
|
11 | Cheng Li | Uploaded new revision |
2023-07-31
|
10 | Cheng Li | New version available: draft-ietf-spring-mpls-path-segment-10.txt |
2023-07-31
|
10 | (System) | New version approved |
2023-07-31
|
10 | (System) | Request for posting confirmation emailed to previous authors: Cheng Li , Han Li , Rakesh Gandhi , Royi Zigler , Weiqiang Cheng |
2023-07-31
|
10 | Cheng Li | Uploaded new revision |
2023-06-26
|
09 | (System) | Changed action holders to Jim Guichard, Mach Chen (IESG state changed) |
2023-06-26
|
09 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2023-06-26
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2023-06-26
|
09 | Cheng Li | New version available: draft-ietf-spring-mpls-path-segment-09.txt |
2023-06-26
|
09 | Rakesh Gandhi | New version approved |
2023-06-26
|
09 | (System) | Request for posting confirmation emailed to previous authors: Han Li , Mach Chen , Rakesh Gandhi , Royi Zigler , Weiqiang Cheng , spring-chairs@ietf.org |
2023-06-26
|
09 | Cheng Li | Uploaded new revision |
2023-05-12
|
08 | (System) | Changed action holders to Jim Guichard, Weiqiang Cheng, Han Li, Mach Chen, Rakesh Gandhi, Royi Zigler (IESG state changed) |
2023-05-12
|
08 | Jim Guichard | IESG state changed to AD Evaluation::Revised I-D Needed from Waiting for Writeup |
2023-05-09
|
08 | Andrew Alston | Changed action holders to Jim Guichard (Changing responsible AD) |
2023-05-09
|
08 | Andrew Alston | Shepherding AD changed to Jim Guichard |
2023-05-09
|
08 | Bruno Decraene | Notification list changed to james.n.guichard@futurewei.com, bruno.decraene@orange.com from james.n.guichard@futurewei.com because the document shepherd was set |
2023-05-09
|
08 | Bruno Decraene | Document shepherd changed to Bruno Decraene |
2023-01-12
|
Jenny Bui | Posted related IPR disclosure Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-idr-sr-policy-path-segment and draft-ietf-spring-mpls-path-segment | |
2022-11-21
|
08 | Stewart Bryant | Request for Last Call review by GENART Completed: Not Ready. Reviewer: Stewart Bryant. Sent review to list. |
2022-11-20
|
08 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2022-11-18
|
08 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2022-11-18
|
08 | David Dong | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-spring-mpls-path-segment-08, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-spring-mpls-path-segment-08, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. For definitions of IANA review states, please see: https://datatracker.ietf.org/help/state/draft/iana-review Thank you, David Dong IANA Services Specialist |
2022-11-11
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Mike Jones |
2022-11-11
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Mike Jones |
2022-11-10
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Stewart Bryant |
2022-11-10
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Stewart Bryant |
2022-11-09
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Martínez |
2022-11-09
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Martínez |
2022-11-06
|
08 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2022-11-06
|
08 | Cindy Morgan | The following Last Call announcement was sent out (ends 2022-11-20): From: The IESG To: IETF-Announce CC: andrew-ietf@liquid.tech, draft-ietf-spring-mpls-path-segment@ietf.org, james.n.guichard@futurewei.com, spring-chairs@ietf.org, spring@ietf.org … The following Last Call announcement was sent out (ends 2022-11-20): From: The IESG To: IETF-Announce CC: andrew-ietf@liquid.tech, draft-ietf-spring-mpls-path-segment@ietf.org, james.n.guichard@futurewei.com, spring-chairs@ietf.org, spring@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Path Segment in MPLS Based Segment Routing Network) to Proposed Standard The IESG has received a request from the Source Packet Routing in Networking WG (spring) to consider the following document: - 'Path Segment in MPLS Based Segment Routing Network' 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 2022-11-20. 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 Segment Routing (SR) path is identified by an SR segment list. Only the complete segment list can identify the end-to-end SR path, and a sub-set of segments from the segment list cannot distinguish one SR path from another as they may be partially congruent. SR path identification is a pre-requisite for various use-cases such as Performance Measurement (PM), bidirectional paths correlation, and end-to-end 1+1 path protection. In SR for MPLS data plane (SR-MPLS), the segment identifiers are stripped from the packet through label popping as the packet transits the network. This means that when a packet reaches the egress of the SR path, it is not possible to determine on which SR path it traversed the network. This document defines a new type of segment that is referred to as Path Segment, which is used to identify an SR path in an SR-MPLS network. When used, it is inserted by the ingress node of the SR path and immediately follows the last segment identifier in the segment list of the SR path. The Path Segment is preserved until it reaches the egress node for SR path identification and correlation. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/5009/ https://datatracker.ietf.org/ipr/3492/ https://datatracker.ietf.org/ipr/3455/ https://datatracker.ietf.org/ipr/5063/ |
2022-11-06
|
08 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2022-11-06
|
08 | Andrew Alston | Last call was requested |
2022-11-06
|
08 | Andrew Alston | Last call announcement was generated |
2022-11-06
|
08 | Andrew Alston | Ballot approval text was generated |
2022-11-06
|
08 | Andrew Alston | Ballot writeup was generated |
2022-11-06
|
08 | Andrew Alston | IESG state changed to Last Call Requested from AD Evaluation |
2022-09-28
|
08 | Weiqiang Cheng | New version available: draft-ietf-spring-mpls-path-segment-08.txt |
2022-09-28
|
08 | (System) | New version approved |
2022-09-28
|
08 | (System) | Request for posting confirmation emailed to previous authors: Han Li , Mach Chen , Rakesh Gandhi , Royi Zigler , Weiqiang Cheng |
2022-09-28
|
08 | Weiqiang Cheng | Uploaded new revision |
2022-06-13
|
07 | Matthew Bocci | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Matthew Bocci. Sent review to list. |
2022-06-01
|
07 | Luc André Burdet | Request for Last Call review by RTGDIR is assigned to Matthew Bocci |
2022-06-01
|
07 | Luc André Burdet | Request for Last Call review by RTGDIR is assigned to Matthew Bocci |
2022-05-24
|
07 | Andrew Alston | Requested Last Call review by RTGDIR |
2022-05-05
|
07 | (System) | Changed action holders to Andrew Alston (IESG state changed) |
2022-05-05
|
07 | Andrew Alston | IESG state changed to AD Evaluation from Publication Requested |
2022-03-23
|
07 | Amy Vezza | Shepherding AD changed to Andrew Alston |
2021-12-23
|
07 | Jim Guichard | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Standards Track RFC. Correctly reflected in the title page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document defines a new type of segment that is referred to as Path Segment, which is used to identify an SR path in an SR-MPLS network. When used, it is inserted by the ingress node of the SR path and immediately follows the last segment identifier in the segment list of the SR path. The Path Segment will not be popped off until it reaches the egress node of the SR path. The Path Segment then can be used by the egress node to implement SR path identification and correlation. Working Group Summary: This document has been largely reviewed by the WG, commented on and supported by the working group. Document Quality: No concerns with quality of the document. Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel: The Document Shepherd is James N Guichard. The Responsible Area Director is Martin Vigoureux. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The whole document has been reviewed before and after the WGLC. Numberous comments sent and addressed by the document authors. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. There have been a lot of reviews and comments from SPRING contributors and all outstanding comments have been addressed. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No specific concerns as the document has been widely reviewed by the WG. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Four IPR disclosures have been filed as required by IETF policy. No WG discussion on this IPR. One IPR filed late that was of concern to the chairs but a satisfactory explaination was provided to the chairs by the filer. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? WG as a whole understands and agrees with the document based upon extensive review. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No nits found for this document and tool runs clean. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The document has no MIB, Yang model, media type or URI type. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? All normative references are already RFCs. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). The IANA considerations seem consistent with the body of the document. No additional comments or concerns. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. The document has no sections written in formal language. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? The document does not define a YANG module. |
2021-12-23
|
07 | Jim Guichard | Responsible AD changed to Martin Vigoureux |
2021-12-23
|
07 | Jim Guichard | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2021-12-23
|
07 | Jim Guichard | IESG state changed to Publication Requested from I-D Exists |
2021-12-23
|
07 | Jim Guichard | IESG process started in state Publication Requested |
2021-12-23
|
07 | Jim Guichard | Changed consensus to Yes from Unknown |
2021-12-23
|
07 | Jim Guichard | Intended Status changed to Proposed Standard from None |
2021-12-20
|
07 | Weiqiang Cheng | New version available: draft-ietf-spring-mpls-path-segment-07.txt |
2021-12-20
|
07 | (System) | New version approved |
2021-12-20
|
07 | (System) | Request for posting confirmation emailed to previous authors: Han Li , Mach Chen , Rakesh Gandhi , Royi Zigler , Weiqiang Cheng |
2021-12-20
|
07 | Weiqiang Cheng | Uploaded new revision |
2021-12-15
|
06 | Jim Guichard | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Standards Track RFC. Correctly reflected in the title page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document defines a new type of segment that is referred to as Path Segment, which is used to identify an SR path in an SR-MPLS network. When used, it is inserted by the ingress node of the SR path and immediately follows the last segment identifier in the segment list of the SR path. The Path Segment will not be popped off until it reaches the egress node of the SR path. The Path Segment then can be used by the egress node to implement SR path identification and correlation. Working Group Summary: This document has been largely reviewed by the WG, commented on and supported by the working group. Document Quality: No concerns with quality of the document. Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel: The Document Shepherd is James N Guichard. The Responsible Area Director is Martin Vigoureux. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The whole document has been reviewed before and after the WGLC. Numberous comments sent and addressed by the document authors. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. There have been a lot of reviews and comments from SPRING contributors and all outstanding comments have been addressed. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No specific concerns as the document has been widely reviewed by the WG. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Four IPR disclosures have been filed as required by IETF policy. No WG discussion on this IPR. One IPR filed late that was of concern to the chairs but a satisfactory explaination was provided to the chairs by the filer. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? WG as a whole understands and agrees with the document based upon extensive review. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No nits found for this document and tool runs clean. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The document has no MIB, Yang model, media type or URI type. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? All normative references are already RFCs. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). The IANA considerations seem consistent with the body of the document. No additional comments or concerns. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. The document has no sections written in formal language. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? The document does not define a YANG module. |
2021-12-13
|
06 | Weiqiang Cheng | New version available: draft-ietf-spring-mpls-path-segment-06.txt |
2021-12-13
|
06 | (System) | New version approved |
2021-12-13
|
06 | (System) | Request for posting confirmation emailed to previous authors: Han Li , Mach Chen , Rakesh Gandhi , Royi Zigler , Weiqiang Cheng |
2021-12-13
|
06 | Weiqiang Cheng | Uploaded new revision |
2021-09-01
|
05 | Jim Guichard | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2021-08-25
|
Jenny Bui | Posted related IPR disclosure Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-pce-sr-path-segment and draft-ietf-spring-mpls-path-segment | |
2021-08-21
|
05 | Weiqiang Cheng | New version available: draft-ietf-spring-mpls-path-segment-05.txt |
2021-08-21
|
05 | (System) | New version accepted (logged-in submitter: Weiqiang Cheng) |
2021-08-21
|
05 | Weiqiang Cheng | Uploaded new revision |
2021-07-15
|
Jenny Bui | Posted related IPR disclosure China Mobile Communications Corporation's Statement about IPR related to draft-ietf-spring-mpls-path-segment | |
2021-07-07
|
04 | Jim Guichard | Notification list changed to james.n.guichard@futurewei.com because the document shepherd was set |
2021-07-07
|
04 | Jim Guichard | Document shepherd changed to Jim Guichard |
2021-07-07
|
04 | Jim Guichard | IETF WG state changed to In WG Last Call from WG Document |
2021-04-11
|
04 | Weiqiang Cheng | New version available: draft-ietf-spring-mpls-path-segment-04.txt |
2021-04-11
|
04 | (System) | New version approved |
2021-04-11
|
04 | (System) | Request for posting confirmation emailed to previous authors: Han Li , Mach Chen , Rakesh Gandhi , Royi Zigler , Weiqiang Cheng |
2021-04-11
|
04 | Weiqiang Cheng | Uploaded new revision |
2021-03-28
|
03 | (System) | Document has expired |
2020-09-24
|
03 | Weiqiang Cheng | New version available: draft-ietf-spring-mpls-path-segment-03.txt |
2020-09-24
|
03 | (System) | New version approved |
2020-09-24
|
03 | (System) | Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Han Li , Royi Zigler , Weiqiang Cheng , Mach Chen |
2020-09-24
|
03 | Weiqiang Cheng | Uploaded new revision |
2020-08-29
|
02 | (System) | Document has expired |
2020-02-26
|
02 | Rakesh Gandhi | New version available: draft-ietf-spring-mpls-path-segment-02.txt |
2020-02-26
|
02 | (System) | New version accepted (logged-in submitter: Rakesh Gandhi) |
2020-02-26
|
02 | Rakesh Gandhi | Uploaded new revision |
2019-09-16
|
01 | Weiqiang Cheng | New version available: draft-ietf-spring-mpls-path-segment-01.txt |
2019-09-16
|
01 | (System) | New version approved |
2019-09-16
|
01 | (System) | Request for posting confirmation emailed to previous authors: Mach Chen , Rakesh Gandhi , Weiqiang Cheng , Royi Zigler , Han Li |
2019-09-16
|
01 | Weiqiang Cheng | Uploaded new revision |
2019-09-12
|
00 | (System) | Document has expired |
2019-03-11
|
00 | Bruno Decraene | This document now replaces draft-cheng-spring-mpls-path-segment instead of None |
2019-03-11
|
00 | Weiqiang Cheng | New version available: draft-ietf-spring-mpls-path-segment-00.txt |
2019-03-11
|
00 | (System) | WG -00 approved |
2019-03-10
|
00 | Weiqiang Cheng | Set submitter to "Weiqiang Cheng ", replaces to (none) and sent approval email to group chairs: spring-chairs@ietf.org |
2019-03-10
|
00 | Weiqiang Cheng | Uploaded new revision |