Skip to main content

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