Skip to main content

OSPFv3 Link State Advertisement (LSA) Extensibility
RFC 8362

Revision differences

Document history

Date Rev. By Action
2018-12-19
23 (System)
Received changes through RFC Editor sync (changed abstract to 'OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement …
Received changes through RFC Editor sync (changed abstract to 'OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described in RFC 5340. Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separate LSAs and correlated to the fixed-format LSAs. This document extends the LSA format by encoding the existing OSPFv3 LSA information in Type-Length-Value (TLV) tuples and allowing advertisement of additional information with additional TLVs. Backward-compatibility mechanisms are also described.

This document updates RFC 5340, "OSPF for IPv6", and RFC 5838, "Support of Address Families in OSPFv3", by providing TLV-based encodings for the base OSPFv3 unicast support and OSPFv3 address family support.')
2018-04-05
23 (System) IANA registries were updated to include RFC8362
2018-04-03
23 (System)
Received changes through RFC Editor sync (created alias RFC 8362, changed title to 'OSPFv3 Link State Advertisement (LSA) Extensibility', changed abstract to 'OSPFv3 requires …
Received changes through RFC Editor sync (created alias RFC 8362, changed title to 'OSPFv3 Link State Advertisement (LSA) Extensibility', changed abstract to 'OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described in RFC 5340. Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separate LSAs and correlated to the fixed-format LSAs. This document extends the LSA format by encoding the existing OSPFv3 LSA information in Type-Length-Value (TLV) tuples and allowing advertisement of additional information with additional TLVs. Backward-compatibility mechanisms are also described.', changed pages to 33, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2018-04-03, changed IESG state to RFC Published, created updates relation between draft-ietf-ospf-ospfv3-lsa-extend and RFC 5340, created updates relation between draft-ietf-ospf-ospfv3-lsa-extend and RFC 5838)
2018-04-03
23 (System) RFC published
2018-03-30
23 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2018-03-27
23 Alvaro Retana Notification list changed to Peter Psenak <ppsenak@cisco.com>, aretana.ietf@gmail.com from Peter Psenak <ppsenak@cisco.com>
2018-03-27
23 Alvaro Retana Shepherding AD changed to Alvaro Retana
2018-03-19
23 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2018-03-06
23 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2018-02-02
23 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2018-01-31
23 Tero Kivinen Closed request for Last Call review by SECDIR with state 'No Response'
2018-01-31
23 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2018-01-31
23 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-01-31
23 (System) IANA Action state changed to In Progress from Waiting on Authors
2018-01-31
23 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-01-29
23 (System) IANA Action state changed to In Progress
2018-01-29
23 (System) RFC Editor state changed to EDIT
2018-01-29
23 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2018-01-29
23 (System) Announcement was received by RFC Editor
2018-01-29
23 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2018-01-29
23 Amy Vezza IESG has approved the document
2018-01-29
23 Amy Vezza Closed "Approve" ballot
2018-01-29
23 Amy Vezza Ballot approval text was generated
2018-01-25
23 Alia Atlas Necessary improvement has been made.  This is ready to go to the RFC Editor.
2018-01-25
23 Alia Atlas IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed
2018-01-25
23 Cindy Morgan IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation::AD Followup
2018-01-25
23 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2018-01-25
23 Acee Lindem New version available: draft-ietf-ospf-ospfv3-lsa-extend-23.txt
2018-01-25
23 (System) New version approved
2018-01-25
23 (System) Request for posting confirmation emailed to previous authors: Dirk Goethals , Abhay Roy , Veerendranatha Vallem , Acee Lindem , Fred Baker
2018-01-25
23 Acee Lindem Uploaded new revision
2018-01-25
22 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2018-01-24
22 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2018-01-24
22 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2018-01-24
22 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-01-24
22 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2018-01-24
22 Acee Lindem New version available: draft-ietf-ospf-ospfv3-lsa-extend-22.txt
2018-01-24
22 (System) New version approved
2018-01-24
22 (System) Request for posting confirmation emailed to previous authors: Dirk Goethals , Abhay Roy , Veerendranatha Vallem , Acee Lindem , Fred Baker
2018-01-24
22 Acee Lindem Uploaded new revision
2018-01-24
21 Warren Kumari
[Ballot comment]
Just for my information -- the document says: "In order to provide backward compatibility, new LSA codes must be allocated."
I get that …
[Ballot comment]
Just for my information -- the document says: "In order to provide backward compatibility, new LSA codes must be allocated."
I get that this *should* not cause older implementations to go "boom", but was wondering if it had been tested at all?

Thanks to Alvaro et al for the other comments - he covered much of what I was going to write!
2018-01-24
21 Warren Kumari Ballot comment text updated for Warren Kumari
2018-01-24
21 Warren Kumari
[Ballot comment]
Just for my information -- the document says: "In order to provide backward compatibility, new LSA codes must be allocated."
I get that …
[Ballot comment]
Just for my information -- the document says: "In order to provide backward compatibility, new LSA codes must be allocated."
I get that this *should* not cause older implementations to go "boom", but was wondering if it had been tested at all?
2018-01-24
21 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2018-01-24
21 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2018-01-24
21 Alia Atlas IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2018-01-24
21 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-01-24
21 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2018-01-24
21 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2018-01-24
21 Suresh Krishnan
[Ballot comment]
* Section 3.10 and 3.11

What does the sub-TLV length mean here? Are values other than 4 and 16 permitted? If not, how …
[Ballot comment]
* Section 3.10 and 3.11

What does the sub-TLV length mean here? Are values other than 4 and 16 permitted? If not, how is the packet treated (sub TLV is ignored?)
2018-01-24
21 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-01-24
21 Alvaro Retana
[Ballot comment]
Thanks for doing this work!!

All my comments (below) are non-blocking, but I would like to see them addressed before publication.

(1) Please …
[Ballot comment]
Thanks for doing this work!!

All my comments (below) are non-blocking, but I would like to see them addressed before publication.

(1) Please include in an explicit indication of what in rfc5340/rfc5838 is Updated by this document.

(2) It seems to me that the setting of the U-bit is treated too lightly: "the U-bit will be set"; maybe be more prescriptive: "the U-bit MUST be set".

(3) I'm confused, why is the N-bit needed?  The description indicates when to use it, but is also says that the "advertising router MAY choose NOT to set [it]", so it doesn't sound that important.  Further down, there are other conditions when it is set...but no other text in the document about checking it, or what happens if it is not set. Finally, the text gives an application example: "identifying the prefixes corresponding to Node Segment Identifiers (SIDs) in Segment Routing" -- I checked the reference, but didn't find a mention of the N-bit there either.

(4) s/The IPv4 Forwarding Address TLV is The IPv4 Forwarding Address TLV/The IPv4 Forwarding Address TLV

(5) s/IPv3/IPv4

(6) The figures in 3.10 and 3.11 have the wrong tittle.

(7) From 4.1:
  Depending on the implementation, it is perfectly valid for an E-
  Router-LSA to not contain any Router-Link TLVs.  However, this would
  imply that the OSPFv3 router doesn't have any active interfaces in
  the corresponding area and such E-Router-LSA would never be flooded
  to other OSPFv3 routers in the area.

I can imagine that a starting/restarting router could have a local E-Router-LSA with no active interfaces, are there other cases?  What should a router do if it receives an E-Router-LSA with no Router-Link TLVs?

(8) s/Inter-Area-Router-LSAE/Inter-Area-Router-LSA

(9) sparse mode is called "spare mode" in a couple of places...or maybe it's the other way around. ;-)

(10) In many OSPF-related documents the Appendixes are Normative, so I'm assuming they are Normative here too.  Only A and B are referenced from the main text -- C is titled "Deprecated LSA Extension Backward Compatibility"; deprecated??  Does that mean that C is an old behavior that lived at some point in the history of this document?  The content of C doesn't seem to conflict with what is in A and B, and there is some important information there -- for example the transition process in C.1.  But C.2. and C.3. clearly overlap with A and B.  Please clarify the role of the Appendixes.

[The following comments are related to the Appendixes and their relevance depends on my comment above.]

(11) The appendixes contain several places where the text says that a new parameter "will be added" -- in reality this document adds those parameters.  Please update.

(12) In Appendix B: s/If ExtendedLSASupport is enabled/If AreaExtendedLSASupport is enabled

(13) "...disabling AreaExtendedLSASupport when ExtendedLSASupport is enabled is contradictory and MAY be prohibited by the implementation."  I'm not sure I understand this text.

Can AreaExtendedLSASupport be enabled without enabling ExtendedLSASupport?  I'm assuming that's the case (from 6.1: "Individual OSPF Areas can be migrated separately...accomplished by enabled AreaExtendedLSASupport").  If so, then the text above is confusing...

If not prohibited by the implementation, what if it happens (AreaExtendedLSASupport is disabled while ExtendedLSASupport is enabled)?  From the previous paragraphs, it seems to me that the network could lose external routes (if only Legacy LSAs have that information)-- is that true? 

OTOH, what if the implementation does prohibit the state -- does that mean that external routes will not be used if they're not derived from Legacy LSAs?  I think the text could use some clarification.

(14) C.1.1. says that "The configuration of ExtendedLSASupport will apply to AS-External LSAs even when AreaExtendedLSASupport takes precedence."  But Appendix B says that "Legacy AS-Scoped LSAs will still be originated and used for the AS External LSA computation."  That seems like a contradiction to me.

(15) In C.1.1 s/MixedModeOriginate/MixedModeOriginateOnly
2018-01-24
21 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2018-01-23
21 Ben Campbell [Ballot comment]
-1.1: There are instances of lower case 2119 keywords. Please consider using the boilerplate from RFC 8174.
2018-01-23
21 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2018-01-22
21 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-01-19
21 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2018-01-19
21 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2018-01-19
21 Acee Lindem New version available: draft-ietf-ospf-ospfv3-lsa-extend-21.txt
2018-01-19
21 (System) New version approved
2018-01-19
21 (System) Request for posting confirmation emailed to previous authors: Dirk Goethals , Abhay Roy , Veerendranatha Vallem , Acee Lindem , Fred Baker
2018-01-19
21 Acee Lindem Uploaded new revision
2018-01-19
20 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2018-01-18
20 (System) IANA Review state changed to IANA - Not OK from IANA OK - Actions Needed
2018-01-18
20 Eric Rescorla
[Ballot comment]
  The IPv4 Forwarding Address TLV is to be used with IPv3 address
  families as defined in [OSPFV3-AF] It MUST be ignored …
[Ballot comment]
  The IPv4 Forwarding Address TLV is to be used with IPv3 address
  families as defined in [OSPFV3-AF] It MUST be ignored for other
  address families.

Do you mean IPv4?
2018-01-18
20 Eric Rescorla [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla
2018-01-18
20 Alia Atlas Ballot has been issued
2018-01-18
20 Alia Atlas [Ballot Position Update] New position, Yes, has been recorded for Alia Atlas
2018-01-18
20 Alia Atlas Created "Approve" ballot
2018-01-18
20 Alia Atlas Ballot writeup was changed
2018-01-18
20 Alia Atlas IESG state changed to IESG Evaluation from Waiting for Writeup
2018-01-12
20 Joel Halpern Request for Last Call review by GENART Completed: Ready. Reviewer: Joel Halpern. Sent review to list.
2018-01-11
20 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2018-01-11
20 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2018-01-11
20 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2018-01-11
20 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-ospf-ospfv3-lsa-extend-19. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-ospf-ospfv3-lsa-extend-19. If any part of this review is inaccurate, please let us know.

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

NOTE: One of the registration procedures proposed below for one the ranges is "FCFS subject to IETF expert review", we suggest that it should just be "Expert Review".

First, in the OSPFv3 LSA Function Codes registry on the Open Shortest Path First v3 (OSPFv3) Parameters registry page located at:

https://www.iana.org/assignments/ospfv3-parameters/

nine, new function codes are to be added to the registry as follows:

Value LSA Function Code Name Reference
------------+----------------------------------------+----------------
33 E-Router-LSA [ RFC-to-be ]
34 E-Network-LSA [ RFC-to-be ]
35 E-Inter-Area-Prefix-LSA [ RFC-to-be ]
36 E-Inter-Area-Router-LSA [ RFC-to-be ]
37 E-AS-External-LSA [ RFC-to-be ]
38 Unused (Not to be allocated) [ RFC-to-be ]
39 E-Type-7-LSA [ RFC-to-be ]
40 E-Link-LSA [ RFC-to-be ]
41 E-Intra-Area-Prefix-LSA [ RFC-to-be ]

Second, in the OSPFv3 Prefix Options (8 bits) registry also on the Open Shortest Path First v3 (OSPFv3) Parameters regsitry page located at:

https://www.iana.org/assignments/ospfv3-parameters/

a single, new value is to be registered as follows:

Value: [ TBD-at-Registration ]
Description: N-bit
Reference: [ RFC-to-be ]

We note that the authors have suggested a value of 0x20 for this registration.

Third, a new registry is to be created called the OSPFv3 Extended-LSA TLV Registry. The new registry will be placed on the Open Shortest Path First v3 (OSPFv3) Parameters regsitry page located at:

https://www.iana.org/assignments/ospfv3-parameters/

There are initial registrations in the new registry as follows:

Value Description Reference
-----+----------------------------+--------------
0 Reserved [ RFC-to-be ]
1 Router-Link TLV [ RFC-to-be ]
2 Attached-Routers TLV [ RFC-to-be ]
3 Inter-Area Prefix TLV [ RFC-to-be ]
4 Inter-Area Router TLV [ RFC-to-be ]
5 External Prefix TLV [ RFC-to-be ]
6 Intra-Area Prefix TLV [ RFC-to-be ]
7 IPv6 Link-Local Address TLV [ RFC-to-be ]
8 IPv4 Link-Local Address TLV [ RFC-to-be ]

The registration procedures for the new registry are as follows:

0-8 Initial registrations from this approved draft
9-32767 IETF Consensus or IESG Approval
32768-33023 Experimental use not registered by IANA
33024-45055 FCFS subject to IETF expert review
45056-65535 Reserved and not assigned

Before any assignments can be made in the 33024-65535 range, there MUST be an IETF specification that specifies IANA Considerations that covers the range being assigned.

Fourth, a new registry is to be created called the OSPFv3 Extended-LSA sub-TLV Registry. The new registry will be placed on the Open Shortest Path First v3 (OSPFv3) Parameters regsitry page located at:

https://www.iana.org/assignments/ospfv3-parameters/

There are initial registrations in the new registry as follows:

Value Description Reference
-----+-------------------------------+--------------
0 Reserved [ RFC-to-be ]
1 IPv6 Forwarding Address sub-TLV [ RFC-to-be ]
2 IPv4 Forwarding Address sub-TLV [ RFC-to-be ]
3 Route Tag sub-TLV [ RFC-to-be ]

The registration procedures for the new registry are as follows:

0-4 Initial registrations from this approved draft
4-32767 IETF Consensus or IESG Approval
32768-33023 Experimental use not registered by IANA
33024-45055 FCFS subject to IETF expert review
45056-65535 Reserved and not assigned

Before any assignments can be made in the 33024-65535 range, there MUST be an IETF specification that specifies IANA Considerations that covers the range being assigned.

The IANA Services 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 only to confirm the list of actions that will be performed.


Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2018-01-11
20 (System) IESG state changed to Waiting for Writeup from In Last Call
2018-01-10
20 Jouni Korhonen Assignment of request for Last Call review by GENART to Jouni Korhonen was rejected
2018-01-08
20 Mehmet Ersue Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Mehmet Ersue. Sent review to list.
2017-12-31
20 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Mehmet Ersue
2017-12-31
20 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Mehmet Ersue
2017-12-28
20 Tero Kivinen Request for Last Call review by SECDIR is assigned to Paul Wouters
2017-12-28
20 Tero Kivinen Request for Last Call review by SECDIR is assigned to Paul Wouters
2017-12-26
20 Acee Lindem New version available: draft-ietf-ospf-ospfv3-lsa-extend-20.txt
2017-12-26
20 (System) New version approved
2017-12-26
20 (System) Request for posting confirmation emailed to previous authors: Dirk Goethals , Abhay Roy , Veerendranatha Vallem , Acee Lindem , Fred Baker
2017-12-26
20 Acee Lindem Uploaded new revision
2017-12-20
19 Jean Mahoney Request for Last Call review by GENART is assigned to Jouni Korhonen
2017-12-20
19 Jean Mahoney Request for Last Call review by GENART is assigned to Jouni Korhonen
2017-12-19
19 Cindy Morgan IANA Review state changed to IANA - Review Needed
2017-12-19
19 Cindy Morgan
The following Last Call announcement was sent out (ends 2018-01-11):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ospf-ospfv3-lsa-extend@ietf.org, akatlas@gmail.com, ospf@ietf.org, Peter Psenak , …
The following Last Call announcement was sent out (ends 2018-01-11):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ospf-ospfv3-lsa-extend@ietf.org, akatlas@gmail.com, ospf@ietf.org, Peter Psenak , ospf-chairs@ietf.org, ppsenak@cisco.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (OSPFv3 LSA Extendibility) to Proposed Standard


The IESG has received a request from the Open Shortest Path First IGP WG
(ospf) to consider the following document: - 'OSPFv3 LSA Extendibility'
  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
ietf@ietf.org mailing lists by 2018-01-11. 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


  OSPFv3 requires functional extension beyond what can readily be done
  with the fixed-format Link State Advertisement (LSA) as described in
  RFC 5340.  Without LSA extension, attributes associated with OSPFv3
  links and advertised IPv6 prefixes must be advertised in separate
  LSAs and correlated to the fixed-format LSAs.  This document extends
  the LSA format by encoding the existing OSPFv3 LSA information in
  Type-Length-Value (TLV) tuples and allowing advertisement of
  additional information with additional TLVs.  Backward compatibility
  mechanisms are also described.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend/ballot/


No IPR declarations have been submitted directly on this I-D.




2017-12-19
19 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2017-12-19
19 Alia Atlas Placed on agenda for telechat - 2018-01-25
2017-12-19
19 Alia Atlas Last call was requested
2017-12-19
19 Alia Atlas IESG state changed to Last Call Requested from Last Call Requested::Revised I-D Needed
2017-12-19
19 Alia Atlas Last call announcement was changed
2017-12-19
19 Alia Atlas Last call was requested
2017-12-19
19 Alia Atlas Last call announcement was generated
2017-12-19
19 Alia Atlas Ballot approval text was generated
2017-12-19
19 Alia Atlas Ballot writeup was generated
2017-12-19
19 Alia Atlas
As is customary, I have done my AD review of draft-ietf-ospf-ospfv3-lsa-extend-19.  First, I would like to thank the authors - Acee, Abhay, Dirk, Veerendranatha, and …
As is customary, I have done my AD review of draft-ietf-ospf-ospfv3-lsa-extend-19.  First, I would like to thank the authors - Acee, Abhay, Dirk, Veerendranatha, and Fred- and the implementors at Nokia and Huawei (who have enabled us to move forward on this critical document) and the WG.  This draft is very important for adding improved  flexiblity to OSPFv3 for IPv6 compared to what we enjoy for OSPFv2.

I do have some minor concerns and nits - as listed below. I am going to put this document into a 3 week IETF Last Call (given the holiday season) and place it on the telechat for Jan 25, 2018.  Please do respond and update the draft in a timely fashion (given I'm on vacation until 2018).

1)  Given the extensive changes to OSPFv3 and the expectation that implementations of OSPFv3 will support this, the draft should update RFC 5340 (and mention that in the abstract as well).

2) In Sec 3: it would be helpful to indicate how many levels of nesting of TLVs are supported.  There are clearly TLVs and sub-TLVs.  Can there be sub-sub-TLVs?  Can there be an arbitrarily deep level of sub-TLVs?  Please just clarify - b/c it can affect folks implementations and also assumptions for how to define the various sub-TLVs.

3) Sec 3.3: Is there a reason that sub-TLVs aren't listed in the figure?  I see them in the figures for sec 3.2 and 3.4 without explanation.  Consistency would be good. I could picture it being helpful to include, for instance, an SRLG or other information.

4) Sec 4.1: Please clarify whether an E-Router-LSA is malformed if it does not contain at least one Router-Link TLV.

5) Sec 4.7: I believe it is possible to have multiple IPv6 link-local addresses. I do see that RFC 5340 restricted OSPFv3 to advertising just one.  Is there a strong reason that if additional are sent  "Instances following the first MUST be ignored." ?  Perhaps this could be a SHOULD - to allow for flexibility?

6) Sec 5: "an LSA MUST be considered malformed if it does not include any required TLV or Sub-TLVs."  should be "...not include all of the required TLVs or sub-TLVs." or the equiv.

7) Sec 6.2: "Furthermore, the extended LSAs will only include those TLVs which require further specification for that new functionality.  Hence, this mode of compatibility is know as "sparse-mode"."  How does this interact with the Sec 5 that talks about malformed LSAs?  It seems like either this would be additional Extended LSAs (not defined in this draft) or it would have to include the mandatory information (but not for all links/ routers).

8) Sec 8.2: Is there a reason to not have a sub-TLV range for either Expert Review or FCFS?  There are a lot of values - and this would support experimentation.

9) Since this document is adding the "N" flag - an example for the usage would be helpful - and particularly articulating how it is different from the "LA" flag for usage.

Nits:

a) Sec 3.1.1:  sentence missing a complete verb  "The N-bit is to the Inter-Area-Prefix-TLV  (Section 3.4), External-Prefix-TLV (Section 3.6), and Intra-Area-
  Prefix-TLV (Section 3.7)"
b) typos: differnt  addtional
2017-12-19
19 Alia Atlas IESG state changed to Last Call Requested::Revised I-D Needed from AD Evaluation
2017-12-18
19 Acee Lindem New version available: draft-ietf-ospf-ospfv3-lsa-extend-19.txt
2017-12-18
19 (System) New version approved
2017-12-18
19 (System) Request for posting confirmation emailed to previous authors: Dirk Goethals , Abhay Roy , Veerendranatha Vallem , Acee Lindem , Fred Baker
2017-12-18
19 Acee Lindem Uploaded new revision
2017-12-18
18 Alia Atlas IESG state changed to AD Evaluation from Publication Requested
2017-11-26
18 Acee Lindem
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(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?

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  This document extends the OSPFv3 LSA format by encoding the existing
  OSPFv3 LSA information in Type-Length-Value (TLV) tuples and allowing
  advertisement of additional information with additional TLVs.  Backward
  compatibility mechanisms are also described.

Working Group Summary

  There has been significant discussion of the draft by the authors and
  the vendors implementing the draft (Nokia and Huawei). There have been
  numerous iterations and the backward compatibility scenarios have been
  simplified.

Document Quality

  The document has been implemented by a couple vendors and several
  OSPFv3 extensions are based on this document.  It has been stable
  for more than a year with only a couple minor encoding corrections.

Personnel

  Peter Psenak is the Document Shepherd.
  Alia Atlas is the Responsible Area Director.

(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 document shepherd has reviewed each revision of the document
    and followed the discussion on the OSPF mailing list. Additionally,
    the document shepherd has authored the OSPFv3 Segment Routing
    extensions based on this specification.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  None.

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

  No.

(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 consensus from the WG and others outside the WG that
  this document can progress.

(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 https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  Nits are all resolved.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  Not applicable.

(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 5226).

  The document adds nine function codes to the existing OSPFv3 LSA
  Function Codes registry for the new OSPFv3 extended LSA. Also,
  the existing OSPFv3 Prefix Options registry has an option
  allocation for the Prefix Node option (N-bit).

  Additionally, new registries are added for OSPFv3 Extended
  Top-level TLVs and Sub-TLVs.

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

  OSPFv3 Extended LSA Sub-TLV registry requires solely
  IETF review for code point allocation.

(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, etc.

  Not applicable.
2017-11-26
18 Acee Lindem Responsible AD changed to Alia Atlas
2017-11-26
18 Acee Lindem IETF WG state changed to Submitted to IESG for Publication from WG Document
2017-11-26
18 Acee Lindem IESG state changed to Publication Requested
2017-11-26
18 Acee Lindem IESG process started in state Publication Requested
2017-11-26
18 Acee Lindem Changed consensus to Yes from Unknown
2017-11-26
18 Acee Lindem Intended Status changed to Proposed Standard from None
2017-11-26
18 Peter Psenak Changed document writeup
2017-11-21
18 Acee Lindem New version available: draft-ietf-ospf-ospfv3-lsa-extend-18.txt
2017-11-21
18 (System) New version approved
2017-11-21
18 (System) Request for posting confirmation emailed to previous authors: Dirk Goethals , Abhay Roy , Veerendranatha Vallem , Acee Lindem , Fred Baker
2017-11-21
18 Acee Lindem Uploaded new revision
2017-11-09
17 Acee Lindem Notification list changed to Peter Psenak <ppsenak@cisco.com>
2017-11-09
17 Acee Lindem Document shepherd changed to Peter Psenak
2017-10-30
17 Acee Lindem New version available: draft-ietf-ospf-ospfv3-lsa-extend-17.txt
2017-10-30
17 (System) New version approved
2017-10-30
17 (System) Request for posting confirmation emailed to previous authors: Fred Baker , Dirk Goethals , Abhay Roy , ospf-chairs@ietf.org, Veerendranatha Vallem , Acee Lindem
2017-10-30
17 Acee Lindem Uploaded new revision
2017-10-28
16 Acee Lindem New version available: draft-ietf-ospf-ospfv3-lsa-extend-16.txt
2017-10-28
16 (System) New version approved
2017-10-28
16 (System) Request for posting confirmation emailed to previous authors: Dirk Goethals , Abhay Roy , Veerendranatha Vallem , Fred Baker , Acee Lindem
2017-10-28
16 Acee Lindem Uploaded new revision
2017-10-09
15 Acee Lindem New version available: draft-ietf-ospf-ospfv3-lsa-extend-15.txt
2017-10-09
15 (System) New version approved
2017-10-09
15 (System) Request for posting confirmation emailed to previous authors: Dirk Goethals , Abhay Roy , Veerendranatha Vallem , Fred Baker , Acee Lindem
2017-10-09
15 Acee Lindem Uploaded new revision
2017-05-05
14 Min Ye Request for Early review by RTGDIR Completed: Ready. Reviewer: IJsbrand Wijnands.
2017-04-13
14 Min Ye Request for Early review by RTGDIR is assigned to IJsbrand Wijnands
2017-04-13
14 Min Ye Request for Early review by RTGDIR is assigned to IJsbrand Wijnands
2017-04-13
14 Acee Lindem Requested Early review by RTGDIR
2017-04-13
14 Acee Lindem New version available: draft-ietf-ospf-ospfv3-lsa-extend-14.txt
2017-04-13
14 (System) New version approved
2017-04-13
14 (System) Request for posting confirmation emailed to previous authors: Sina Mirtorabi , Abhay Roy , Acee Lindem , Fred Baker , ospf-chairs@ietf.org
2017-04-13
14 Acee Lindem Uploaded new revision
2016-10-21
13 Acee Lindem New version available: draft-ietf-ospf-ospfv3-lsa-extend-13.txt
2016-10-21
13 (System) New version approved
2016-10-21
13 (System) Request for posting confirmation emailed to previous authors: "Acee Lindem" , "Sina Mirtorabi" , "Fred Baker" , "Abhay Roy"
2016-10-21
13 Acee Lindem Uploaded new revision
2016-10-21
13 (System) Request for posting confirmation emailed to previous authors: "Acee Lindem" , "Sina Mirtorabi" , "Fred Baker" , "Abhay Roy"
2016-10-21
13 Acee Lindem Uploaded new revision
2016-09-26
12 Acee Lindem New version approved
2016-09-26
12 Acee Lindem New version available: draft-ietf-ospf-ospfv3-lsa-extend-12.txt
2016-09-26
12 Acee Lindem Request for posting confirmation emailed to previous authors: "Acee Lindem" , "Sina Mirtorabi" , "Fred Baker" , "Abhay Roy"
2016-09-26
12 (System) Uploaded new revision
2016-09-26
11 Acee Lindem New version available: draft-ietf-ospf-ospfv3-lsa-extend-11.txt
2016-09-26
11 Acee Lindem New version approved
2016-09-26
11 Acee Lindem Request for posting confirmation emailed to previous authors: "Acee Lindem" , "Sina Mirtorabi" , "Fred Baker" , "Abhay Roy" , ospf-chairs@ietf.org
2016-09-26
11 (System) Uploaded new revision
2016-05-23
10 Acee Lindem New version available: draft-ietf-ospf-ospfv3-lsa-extend-10.txt
2015-11-19
09 Acee Lindem New version available: draft-ietf-ospf-ospfv3-lsa-extend-09.txt
2015-10-08
08 Acee Lindem New version available: draft-ietf-ospf-ospfv3-lsa-extend-08.txt
2015-08-11
07 Acee Lindem New version available: draft-ietf-ospf-ospfv3-lsa-extend-07.txt
2015-02-17
06 Acee Lindem New version available: draft-ietf-ospf-ospfv3-lsa-extend-06.txt
2014-11-24
05 Acee Lindem New version available: draft-ietf-ospf-ospfv3-lsa-extend-05.txt
2014-09-18
04 Acee Lindem New version available: draft-ietf-ospf-ospfv3-lsa-extend-04.txt
2014-05-29
03 Acee Lindem New version available: draft-ietf-ospf-ospfv3-lsa-extend-03.txt
2014-04-18
02 Acee Lindem New version available: draft-ietf-ospf-ospfv3-lsa-extend-02.txt
2014-02-10
01 Acee Lindem New version available: draft-ietf-ospf-ospfv3-lsa-extend-01.txt
2013-10-15
00 Acee Lindem New version available: draft-ietf-ospf-ospfv3-lsa-extend-00.txt