OSPFv3 Link State Advertisement (LSA) Extensibility
RFC 8362

Note: This ballot was opened for revision 20 and is now closed.

(Alia Atlas) Yes

Alvaro Retana Yes

Comment (2018-01-24 for -21)
No email
send info
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

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2018-01-23 for -21)
No email
send info
-1.1: There are instances of lower case 2119 keywords. Please consider using the boilerplate from RFC 8174.

(Benoît Claise) No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Suresh Krishnan) No Objection

Comment (2018-01-24 for -21)
No email
send info
* 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?)

Warren Kumari No Objection

Comment (2018-01-24 for -21)
No email
send info
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!

(Mirja Kühlewind) No Objection

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

(Eric Rescorla) No Objection

Comment (2018-01-18 for -20)
No email
send info
   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?

(Adam Roach) No Objection