OSPF Prefix Originator Extensions
draft-ietf-lsr-ospf-prefix-originator-12
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-01-26
|
12 | Gunter Van de Velde | Request closed, assignment withdrawn: Joel Jaeggli Last Call OPSDIR review |
2024-01-26
|
12 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue |
2021-07-19
|
12 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-07-07
|
12 | (System) | RFC Editor state changed to AUTH48 |
2021-04-23
|
12 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2021-04-16
|
12 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2021-04-16
|
12 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2021-04-16
|
12 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2021-04-16
|
12 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-04-14
|
12 | (System) | RFC Editor state changed to EDIT |
2021-04-14
|
12 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2021-04-14
|
12 | (System) | Announcement was received by RFC Editor |
2021-04-14
|
12 | (System) | IANA Action state changed to In Progress |
2021-04-14
|
12 | (System) | Removed all action holders (IESG state changed) |
2021-04-14
|
12 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2021-04-14
|
12 | Amy Vezza | IESG has approved the document |
2021-04-14
|
12 | Amy Vezza | Closed "Approve" ballot |
2021-04-14
|
12 | Amy Vezza | Ballot approval text was generated |
2021-04-14
|
12 | Alvaro Retana | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2021-04-09
|
12 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-04-09
|
12 | Ketan Talaulikar | New version available: draft-ietf-lsr-ospf-prefix-originator-12.txt |
2021-04-09
|
12 | (System) | New version accepted (logged-in submitter: Ketan Talaulikar) |
2021-04-09
|
12 | Ketan Talaulikar | Uploaded new revision |
2021-04-08
|
11 | (System) | Changed action holders to Acee Lindem, Peter Psenak, Jie Dong, Aijun Wang, Ketan Talaulikar (IESG state changed) |
2021-04-08
|
11 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2021-04-07
|
11 | Murray Kucherawy | [Ballot comment] A note for the IESG: This is in the shepherd writeup: -- BEGIN -- (1) What type of RFC is being … [Ballot comment] A note for the IESG: This is in the shepherd writeup: -- BEGIN -- (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? Proposed Standard. -- END -- As I said on another document on this week's docket, this is increasingly common. There are three questions being asked, but only one is being answered, and not the most important one at that. I'd really like it if this started getting caught someplace in the review process before IESG Evaluation. Or, if we don't actually care about the answer anymore, we should simplify or remove the question. |
2021-04-07
|
11 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2021-04-07
|
11 | Roman Danyliw | [Ballot comment] Thank you to Watson Ladd for the SECDIR review. |
2021-04-07
|
11 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2021-04-07
|
11 | John Scudder | [Ballot comment] Thanks for the update to the document and the discussion. Many points are resolved, remaining discussion summarized below. And by the way, I … [Ballot comment] Thanks for the update to the document and the discussion. Many points are resolved, remaining discussion summarized below. And by the way, I wondered the same as Ben regarding "In the ECMP case is there a way to correlate (order of appearance?) the listed router-IDs with the listed reachable addresses?" 1. I've cleared my discuss but as mentioned in earlier email, would still suggest an update to the abstract: "I would prefer to see a sentence in the abstract as well, since for some people the abstract is the only look they’ll take at the document and for them, the question of “what is it for?” isn’t answered. I don’t insist on this, but I recommend it. The additional sentence, if you choose to add it, could be something like “this information does not change route computation but is expected to be useful for network analysis and troubleshooting”." 2. Section 2.1: For intra-area prefix advertisements, the Prefix Source OSPF Router- ID Sub-TLV MUST be considered invalid and ignored if the OSPF Router ID field is not the same as Advertising Router field in the containing LSA. Similar validation cannot be reliably performed for inter-area and external prefix advertisements. As discussed with Ketan, I'm not sure if "ignored" is vague only to me, or if it might be to other readers of the spec. I leave it to the authors' discretion whether and how to elaborate. 4. Section 3: When an ABR generates inter-area prefix advertisements into its non- backbone areas corresponding to an inter-area prefix advertisement from the backbone area, the only way to determine the originating node information is based on the Prefix Source OSPF Router-ID and Prefix Source Router Address Sub-TLVs present in the inter-area prefix advertisement originated into the backbone area by an ABR from another non-backbone area. The ABR performs its prefix calculation to determine the set of nodes that contribute to the best prefix reachability. It MUST use the prefix originator information only from this set of nodes. The ABR MUST NOT include the Prefix Source OSPF Router-ID or the Prefix Source Router Address Sub-TLVs when it is unable to determine the information of the best originating node. What is it supposed to do if there are N contributing routes but it can only determine the information for M < N of the contributors? Ketan replied (my paraphrase) that in such a case partial information is sent. My further question was "OK. And it’s considered fine that that information for some, but not all, of the contributors is included? It seems potentially problematic that the route only includes partial information, but the consumer of the route has no way to know this. The other obvious choices would have been to omit the information altogether if only partial information was available, or to mark it as partial somehow." |
2021-04-07
|
11 | John Scudder | [Ballot Position Update] Position for John Scudder has been changed to No Objection from Discuss |
2021-04-07
|
11 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2021-04-07
|
11 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2021-04-07
|
11 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-04-07
|
11 | Ketan Talaulikar | New version available: draft-ietf-lsr-ospf-prefix-originator-11.txt |
2021-04-07
|
11 | (System) | New version accepted (logged-in submitter: Ketan Talaulikar) |
2021-04-07
|
11 | Ketan Talaulikar | Uploaded new revision |
2021-04-06
|
10 | Benjamin Kaduk | [Ballot comment] In the ECMP case is there a way to correlate (order of appearance?) the listed router-IDs with the listed reachable addresses? Are there … [Ballot comment] In the ECMP case is there a way to correlate (order of appearance?) the listed router-IDs with the listed reachable addresses? Are there cases where you might choose to only advertise one but not the other of the prefix source Router-ID and address? Section 2.1 The parent TLV of a prefix advertisement MAY include more than one Prefix Source OSPF Router-ID sub-TLV, one corresponding to each of the Equal-Cost Multi-Path (ECMP) nodes that originated the given prefix. Is there any subtlety (or complexity, I guess) to how the advertising node knows about the other ECMP nodes advertising the same prefix? For example, would there be some transient discovery stage when first setting up the ECMP advertisement and only a subset of the ECMP nodes are actually listed in some advertisements that go out? Section 3 another non-backbone area. The ABR performs its prefix calculation to determine the set of nodes that contribute to the best prefix reachability. It MUST use the prefix originator information only from this set of nodes. The ABR MUST NOT include the Prefix Source OSPF Router-ID or the Prefix Source Router Address Sub-TLVs when it is unable to determine the information of the best originating node. I feel like this text might be hiding some subtlety as to the nature of determining the "nodes that contribute to the best prefix reachability" -- is this a concept that is well established in the core OSPF RFCs already (and thus doesn't need further explanation)? Section 4 We often consider privacy considerations as part of the security considerations section. Since routers are to some extent inherently "well known", they themselves may not have much privacy considerations but there may be something to say about propagating additional information about the internal structure of a given network. My understanding is that OSPF areas are all under a common administrative domain, so this mostly only seems relevant to the case of AS-external advertisement. One potential consideration would be if there is value in hiding that a set of prefixes are all advertised by the same router (the "linkability" of the prefixes, if you well). (Hmm, I guess this is somewhat related to the existing operational considerations discussion, but not entirely equivalent.) If we go into more detail on potential use cases, we might accordingly be able to go into more detail on the consequences of a rouge node injecting incorrect prefix source information. Section 5 protocol. Based on deployment design and requirements, a subset of prefixes may be identified for which the propagation of the originating node information across area boundaries is disabled at the ABRs. Per my previous comment, is this even more important at ASBRs than ABRs? NITS Section 1 The identification of the originating router for a prefix in OSPF varies by the type of the prefix and is currently not always possible. [...] (nit) my intuition is suggesting that the intent is that the "procedures for identification" vary and are not always possible; is that correct? (It seems to me that "the identification of the originating router varies by the type of prefix" would indicate that the actual identifier used for even the same advertising router will be different for the different type of prefix being advertised, which doesn't seem to be what the subsequent discussion describes.) address for the router. The IPv4/IPv6 Router Address as defined in [RFC3630] and [RFC5329] for OSPFv2 and OSPFv3 respectively provide an address to reach that router. (nit) Is it useful to indicate that these are TLVs, here? the core OSPF route computation functionality. They provide useful information for topology analysis and traffic engineering, especially on a controller when this information is advertised as an attribute of the prefixes via mechanisms such as Border Gateway Protocol Link- State (BGP-LS) [RFC7752] [I-D.ietf-idr-bgp-ls-segment-routing-ext]. The draft-ietf-idr-bgp-ls-segment-routing-ext reference seems rather unmotivated by the current prose leading up to it. Per John's Discuss some further exposition on the expected use case might help. |
2021-04-06
|
10 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2021-04-06
|
11 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2021-04-06
|
10 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2021-04-06
|
10 | John Scudder | [Ballot discuss] Although the document is largely clear and well-written (thanks for that), I was left with one burning question: what are these sub-TLVs *for*? … [Ballot discuss] Although the document is largely clear and well-written (thanks for that), I was left with one burning question: what are these sub-TLVs *for*? There’s no specification for what the router is supposed to do with them, only how to originate them. The only clue I get is buried down in Section 5: The identification of the node that is originating a specific prefix in the network may aid in debugging of issues related to prefix reachability within an OSPF network. If their purpose is to act as debugging aids, I think you should at least say so briefly in the abstract and introduction. If they have some purpose beyond that, it’s missing from the doc. |
2021-04-06
|
10 | John Scudder | Ballot discuss text updated for John Scudder |
2021-04-06
|
10 | John Scudder | [Ballot discuss] Although the document is largely clear and well-written (thanks for that), I was left with one burning question: what are these sub-TLVs *for*? … [Ballot discuss] Although the document is largely clear and well-written (thanks for that), I was left with one burning question: what are these sub-TLVs *for*? There’s no specification for what the router is supposed to do with them, only how to originate them. The only clue I get is buried down in Section 5: The identification of the node that is originating a specific prefix in the network may aid in debugging of issues related to prefix reachability within an OSPF network. If their purpose is to act as debugging aids, I think the least you should at least say so briefly in the abstract and introduction. If they have some purpose beyond that, it’s missing from the doc. |
2021-04-06
|
10 | John Scudder | [Ballot comment] 1. Section 2: This document defines the Prefix Source OSPF Router-ID and the Prefix Source Router Address Sub-TLVs for inclusion of … [Ballot comment] 1. Section 2: This document defines the Prefix Source OSPF Router-ID and the Prefix Source Router Address Sub-TLVs for inclusion of the Router ID and a reachable address information for the router originating the prefix as a prefix attribute. I found this sentence difficult to read. I think removing the redundant word “information” would help a little. Beyond that, it might help to break it into a couple sentences, as in: “This document defines the Prefix Source OSPF Router-ID and the Prefix Source Router Address Sub-TLVs. They are used, respectively, to include the Router ID of, and a reachable address of, the router that originates the prefix as a prefix attribute.” 2. Section 2.1: For intra-area prefix advertisements, the Prefix Source OSPF Router- ID Sub-TLV MUST be considered invalid and ignored if the OSPF Router ID field is not the same as Advertising Router field in the containing LSA. Similar validation cannot be reliably performed for inter-area and external prefix advertisements. What does it mean for the sub-TLV to be ignored? Since you haven’t specified any processing of the Sub-TLVs, there’s seemingly no ignoring to be done locally — so does this mean the sub-TLV isn’t even supposed to be stored? Flooded? 3. Section 3: If the originating node is advertising an OSPFv2 Router Address TLV [RFC3630] or an OSPFv3 Router IPv6 Address TLV [RFC5329], then the same address MUST be used in the Router Address field of the Prefix Source Router Address Sub-TLV. When the originating node is not advertising such an address, implementations can determine a unique and reachable address (i.e., advertised with the N-flag set [RFC7684] or N-bit set [RFC8362]) belonging to the originating node to set in the Router Address field. As I read this, if there’s no Router Address TLV, then the implementation has to use something it advertised with the N-flag set. I infer this because you used “i.e.” (which essentially means “in other words”). If you do mean the parenthetical to be limiting, why not make it a MUST? If you don’t mean it to be limiting, shouldn’t it be “e.g.” or better still, “for example”? (Looking at RFC 7684 it doesn’t seem as though it should be limiting, because RFC 7684 § 2.1 says the N-flag is optional even for local routes.) 4. Section 3: When an ABR generates inter-area prefix advertisements into its non- backbone areas corresponding to an inter-area prefix advertisement from the backbone area, the only way to determine the originating node information is based on the Prefix Source OSPF Router-ID and Prefix Source Router Address Sub-TLVs present in the inter-area prefix advertisement originated into the backbone area by an ABR from another non-backbone area. The ABR performs its prefix calculation to determine the set of nodes that contribute to the best prefix reachability. It MUST use the prefix originator information only from this set of nodes. The ABR MUST NOT include the Prefix Source OSPF Router-ID or the Prefix Source Router Address Sub-TLVs when it is unable to determine the information of the best originating node. What is it supposed to do if there are N contributing routes but it can only determine the information for M < N of the contributors? Also, should “node” be “nodes” (last word of last sentence)? 5. Section 5, nit: Consideration should be given to the operation impact of the increase s/operation/operational/ |
2021-04-06
|
10 | John Scudder | [Ballot Position Update] New position, Discuss, has been recorded for John Scudder |
2021-04-06
|
10 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2021-04-06
|
10 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2021-04-05
|
10 | Robert Wilton | [Ballot comment] Thanks for this. Not a comment that requires addressing in the text, but considering section 5 on the operational impact: Is there an … [Ballot comment] Thanks for this. Not a comment that requires addressing in the text, but considering section 5 on the operational impact: Is there an OSPF YANG model that is being updated to cover any additional configuration required to enable this functionality on a subset of prefixes, and/or are any changes to the operational YANG data model required to express the prefix source? Regards, Rob |
2021-04-05
|
10 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2021-04-05
|
10 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. Easy to see the added value for trouble shooting ! Please find below some … [Ballot comment] Thank you for the work put into this document. Easy to see the added value for trouble shooting ! Please find below some non-blocking COMMENT points (but replies would be appreciated). I hope that this helps to improve the document, Regards, -éric Thanks for fixing Warren Kumari's question in the latest -10. -- Section 1 -- Is the reference to RFC 5329 correct ? I fail to see the link of TE with this document. Should it be made clearer that the OSPFv3 router ID is a 32-bit value hence cannot be used in an IPv6-only network ? "it does not necessarily represent a reachable address for the router" is slightly ambiguous. -- Section 2.2 -- Thanks for fixing Warren Kumari's question in the latest -10. -- Section 4 -- Suggestion: made the sentence "A rogue node that can inject prefix..." in a separate paragraph. |
2021-04-05
|
10 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2021-04-04
|
10 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
2021-04-02
|
10 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2021-04-02
|
10 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-04-02
|
10 | Ketan Talaulikar | New version available: draft-ietf-lsr-ospf-prefix-originator-10.txt |
2021-04-02
|
10 | (System) | New version accepted (logged-in submitter: Ketan Talaulikar) |
2021-04-02
|
10 | Ketan Talaulikar | Uploaded new revision |
2021-04-02
|
09 | Vijay Gurbani | Request for Last Call review by GENART Completed: Ready. Reviewer: Vijay Gurbani. Sent review to list. |
2021-03-31
|
09 | Warren Kumari | [Ballot Position Update] Position for Warren Kumari has been changed to No Objection from No Record |
2021-03-30
|
09 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2021-03-30
|
09 | Warren Kumari | [Ballot comment] I'm balloting No Objection, but I really would like a response... 1: I'm assuming I'm just missing something obvious here, but Section 2.2 … [Ballot comment] I'm balloting No Objection, but I really would like a response... 1: I'm assuming I'm just missing something obvious here, but Section 2.2 sayeth: "A received Prefix Source Router Address Sub-TLV that has an invalid length (i.e. not consistent with the prefix's address family) or a Router Address containing an invalid IPv4 or IPv6 address (dependent on address family of the associated prefix) MUST be considered invalid and ignored. " What is an "invalid IPv4" address here? If the length is 4, and the route address is 00000001 or 0xc0a80001, how do you know that that's not what I'm using? Again, I suspect that there is something obvious that I'm missing here... 2: This presumable has the side effect of increasing the size of the lsdb, possibly by a fairly large margin. It seems like it would have been nice to include an operational considerations section noting this, and, while you are at it, that this document will significantly aid in debugging.... |
2021-03-30
|
09 | Warren Kumari | Ballot comment text updated for Warren Kumari |
2021-03-29
|
09 | Cindy Morgan | Placed on agenda for telechat - 2021-04-08 |
2021-03-29
|
09 | Alvaro Retana | Ballot has been issued |
2021-03-29
|
09 | Alvaro Retana | [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana |
2021-03-29
|
09 | Alvaro Retana | Created "Approve" ballot |
2021-03-29
|
09 | Alvaro Retana | IESG state changed to IESG Evaluation from Waiting for Writeup |
2021-03-29
|
09 | Alvaro Retana | Ballot writeup was changed |
2021-03-29
|
09 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2021-03-28
|
09 | Min Ye | Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Russ White. Submission of review completed at an earlier date. |
2021-03-27
|
09 | Min Ye | Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Russ White. |
2021-03-26
|
09 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2021-03-26
|
09 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-lsr-ospf-prefix-originator-08. 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-lsr-ospf-prefix-originator-08. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the OSPFv2 Extended Prefix TLV Sub-TLVs registry on the Open Shortest Path First v2 (OSPFv2) Parameters registry page located at: https://www.iana.org/assignments/ospfv2-parameters/ a new registration is to be made as follows: Value: [ TBD-at-Registration ] Description: Prefix Source Router Address Sub-TLV Reference: [ RFC-to-be ] And, in the same registry the early allocation for codepoint 4: Value: 4 Description: Prefix Source OSPF Router-ID Sub-TLV is to be made permanent and its reference changed to [ RFC-to-be ]. Second, Section 5 of the current document: "requests IANA for the allocation of the codepoints from the "OSPFv3 Extended Prefix TLV Sub-TLVs" registry under the "Open Shortest Path First v3 (OSPFv3) Parameters" registry." IANA notes that there is no such registry. IANA Question --> Do the authors mean the OSPFv3 Extended-LSA Sub-TLVs located at https://www.iana.org/assignments/ospfv3-parameters/ ? If so, in the OSPFv3 Extended-LSA Sub-TLVs located at https://www.iana.org/assignments/ospfv3-parameters/ a new registration is to be made as follows: Value: [ TBD-at-Registration ] Description: Prefix Source Router Address Sub-TLV Reference: [ RFC-to-be ] And, in the same registry the early allocation for codepoint 27: Value: 27 Description: Prefix Source OSPF Router-ID Sub-TLV is to be made permanent and its reference changed to [ 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. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2021-03-19
|
09 | Watson Ladd | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Watson Ladd. Sent review to list. |
2021-03-19
|
09 | Ketan Talaulikar | New version available: draft-ietf-lsr-ospf-prefix-originator-09.txt |
2021-03-19
|
09 | (System) | New version accepted (logged-in submitter: Ketan Talaulikar) |
2021-03-19
|
09 | Ketan Talaulikar | Uploaded new revision |
2021-03-19
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2021-03-19
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2021-03-18
|
08 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'Withdrawn' |
2021-03-18
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Watson Ladd |
2021-03-18
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Watson Ladd |
2021-03-15
|
08 | Min Ye | Request for Last Call review by RTGDIR is assigned to Russ White |
2021-03-15
|
08 | Min Ye | Request for Last Call review by RTGDIR is assigned to Russ White |
2021-03-12
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
2021-03-12
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
2021-03-11
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stephen Farrell |
2021-03-11
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stephen Farrell |
2021-03-10
|
08 | Alvaro Retana | Shepherding AD changed to Alvaro Retana |
2021-03-10
|
08 | Cindy Morgan | Shepherding AD changed to John Scudder |
2021-03-08
|
08 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2021-03-08
|
08 | Amy Vezza | The following Last Call announcement was sent out (ends 2021-03-29): From: The IESG To: IETF-Announce CC: Christian Hopps , aretana.ietf@gmail.com, chopps@chopps.org, draft-ietf-lsr-ospf-prefix-originator@ietf.org, … The following Last Call announcement was sent out (ends 2021-03-29): From: The IESG To: IETF-Announce CC: Christian Hopps , aretana.ietf@gmail.com, chopps@chopps.org, draft-ietf-lsr-ospf-prefix-originator@ietf.org, lsr-chairs@ietf.org, lsr@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (OSPF Prefix Originator Extensions) to Proposed Standard The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'OSPF Prefix Originator Extensions' 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 2021-03-29. 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 This document defines OSPF extensions to include information associated with the node originating a prefix along with the prefix advertisement. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3448/ https://datatracker.ietf.org/ipr/3418/ https://datatracker.ietf.org/ipr/3419/ https://datatracker.ietf.org/ipr/3420/ |
2021-03-08
|
08 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2021-03-08
|
08 | Alvaro Retana | Requested Last Call review by RTGDIR |
2021-03-08
|
08 | Alvaro Retana | Last call was requested |
2021-03-08
|
08 | Alvaro Retana | Ballot approval text was generated |
2021-03-08
|
08 | Alvaro Retana | Ballot writeup was generated |
2021-03-08
|
08 | (System) | Changed action holders to Alvaro Retana (IESG state changed) |
2021-03-08
|
08 | Alvaro Retana | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2021-03-08
|
08 | Alvaro Retana | Last call announcement was changed |
2021-03-08
|
08 | Alvaro Retana | Last call announcement was generated |
2021-03-08
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-03-08
|
08 | Ketan Talaulikar | New version available: draft-ietf-lsr-ospf-prefix-originator-08.txt |
2021-03-08
|
08 | (System) | New version accepted (logged-in submitter: Ketan Talaulikar) |
2021-03-08
|
08 | Ketan Talaulikar | Uploaded new revision |
2021-02-13
|
07 | Alvaro Retana | === AD Review of draft-ietf-lsr-ospf-prefix-originator-07 === https://mailarchive.ietf.org/arch/msg/lsr/k-wDIU2aWrgOU-_-sdnq9HR0a4c/ |
2021-02-13
|
07 | Alvaro Retana | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2021-01-21
|
07 | Alvaro Retana | IESG state changed to AD Evaluation from Publication Requested |
2021-01-21
|
07 | Alvaro Retana | Notification list changed to Christian Hopps <chopps@chopps.org>, aretana.ietf@gmail.com from Christian Hopps <chopps@chopps.org> |
2020-12-18
|
07 | Christian Hopps | https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/ Write-up for draft-ietf-lsr-ospf-prefix-originator-07 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, … https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/ Write-up for draft-ietf-lsr-ospf-prefix-originator-07 (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? Proposed Standard. (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: Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document defines OSPF extensions to include information associated with the node originating a prefix along with the prefix advertisement. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There was a drawn out discussion about a non-normative appendix that talked about a controversial use case. The WG (as well as some of the authors) did not support it's inclusion; it was removed. Document Quality: 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? This draft is a simple extension which mirrors similar functionality in IS-IS. It's filling a gap in LSR. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Shepherd: Christian Hopps AD: Alvaro Retana (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 shepherd has reviewed the latest versions of this document. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns based on the latest review. (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 broader review is required. (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 concerns. (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. IPR disclosure has been filed, no WG discussion. https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-lsr-ospf-prefix-originator (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? There is solid support for this document. (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. None. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. N/A (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? No. (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 section seems fine. It is allocating one sub-tlv code-point for OSPFv2 and OSPFv3. (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. None. (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. N/A (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? No YANG. |
2020-12-18
|
07 | Christian Hopps | Responsible AD changed to Alvaro Retana |
2020-12-18
|
07 | Christian Hopps | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2020-12-18
|
07 | Christian Hopps | IESG state changed to Publication Requested from I-D Exists |
2020-12-18
|
07 | Christian Hopps | IESG process started in state Publication Requested |
2020-12-18
|
07 | Christian Hopps | https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/ Write-up for draft-ietf-lsr-ospf-prefix-originator-07 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, … https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/ Write-up for draft-ietf-lsr-ospf-prefix-originator-07 (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? Proposed Standard. (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: Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document defines OSPF extensions to include information associated with the node originating a prefix along with the prefix advertisement. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There was a drawn out discussion about a non-normative appendix that talked about a controversial use case. The WG (as well as some of the authors) did not support it's inclusion; it was removed. Document Quality: 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? This draft is a simple extension which mirrors similar functionality in IS-IS. It's filling a gap in LSR. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Shepherd: Christian Hopps AD: Alvaro Retana (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 shepherd has reviewed the latest versions of this document. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns based on the latest review. (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 broader review is required. (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 concerns. (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. IPR disclosure has been filed, no WG discussion. https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-lsr-ospf-prefix-originator (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? There is solid support for this document. (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. None. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. N/A (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? No. (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 section seems fine. It is allocating one sub-tlv code-point for OSPFv2 and OSPFv3. (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. None. (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. N/A (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? No YANG. |
2020-11-25
|
07 | Christian Hopps | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2020-10-20
|
07 | Ketan Talaulikar | New version available: draft-ietf-lsr-ospf-prefix-originator-07.txt |
2020-10-20
|
07 | (System) | New version accepted (logged-in submitter: Ketan Talaulikar) |
2020-10-20
|
07 | Ketan Talaulikar | Uploaded new revision |
2020-10-14
|
06 | Christian Hopps | IETF WG state changed to In WG Last Call from WG Document |
2020-06-30
|
06 | Ketan Talaulikar | New version available: draft-ietf-lsr-ospf-prefix-originator-06.txt |
2020-06-30
|
06 | (System) | New version accepted (logged-in submitter: Ketan Talaulikar) |
2020-06-30
|
06 | Ketan Talaulikar | Uploaded new revision |
2020-05-27
|
05 | (System) | Document has expired |
2019-11-24
|
05 | Aijun Wang | New version available: draft-ietf-lsr-ospf-prefix-originator-05.txt |
2019-11-24
|
05 | (System) | New version approved |
2019-11-24
|
05 | (System) | Request for posting confirmation emailed to previous authors: Jie Dong , Peter Psenak , Acee Lindem , Aijun Wang , Ketan Talaulikar |
2019-11-24
|
05 | Aijun Wang | Uploaded new revision |
2019-09-12
|
04 | Acee Lindem | New version available: draft-ietf-lsr-ospf-prefix-originator-04.txt |
2019-09-12
|
04 | (System) | New version approved |
2019-09-12
|
04 | (System) | Request for posting confirmation emailed to previous authors: Jie Dong , Peter Psenak , Acee Lindem , Aijun Wang , Ketan Talaulikar |
2019-09-12
|
04 | Acee Lindem | Uploaded new revision |
2019-09-03
|
03 | Acee Lindem | Notification list changed to Christian Hopps <chopps@chopps.org> |
2019-09-03
|
03 | Acee Lindem | Document shepherd changed to Christian Hopps |
2019-08-26
|
03 | Aijun Wang | New version available: draft-ietf-lsr-ospf-prefix-originator-03.txt |
2019-08-26
|
03 | (System) | New version approved |
2019-08-26
|
03 | (System) | Request for posting confirmation emailed to previous authors: Jie Dong , Peter Psenak , Acee Lindem , Aijun Wang , Ketan Talaulikar |
2019-08-26
|
03 | Aijun Wang | Uploaded new revision |
2019-08-25
|
02 | Aijun Wang | New version available: draft-ietf-lsr-ospf-prefix-originator-02.txt |
2019-08-25
|
02 | (System) | New version approved |
2019-08-25
|
02 | (System) | Request for posting confirmation emailed to previous authors: Ketan Talaulikar , lsr-chairs@ietf.org, Peter Psenak , Acee Lindem , Jie Dong , Aijun Wang |
2019-08-25
|
02 | Aijun Wang | Uploaded new revision |
2019-06-30
|
01 | Aijun Wang | New version available: draft-ietf-lsr-ospf-prefix-originator-01.txt |
2019-06-30
|
01 | (System) | New version approved |
2019-06-30
|
01 | (System) | Request for posting confirmation emailed to previous authors: Jie Dong , Acee Lindem , Peter Psenak , Aijun Wang , Ketan Talaulikar |
2019-06-30
|
01 | Aijun Wang | Uploaded new revision |
2019-05-09
|
00 | Alvaro Retana | Changed consensus to Yes from Unknown |
2019-05-09
|
00 | Alvaro Retana | Intended Status changed to Proposed Standard from None |
2019-05-09
|
00 | Alvaro Retana | This document now replaces draft-wang-lsr-ospf-prefix-originator-ext instead of None |
2019-03-04
|
Jenny Bui | Posted related IPR disclosure: China Telecom's Statement about IPR related to draft-ietf-lsr-ospf-prefix-originator | |
2019-02-28
|
00 | Aijun Wang | New version available: draft-ietf-lsr-ospf-prefix-originator-00.txt |
2019-02-28
|
00 | (System) | WG -00 approved |
2019-02-28
|
00 | Aijun Wang | Set submitter to "Aijun Wang ", replaces to (none) and sent approval email to group chairs: lsr-chairs@ietf.org |
2019-02-28
|
00 | Aijun Wang | Uploaded new revision |