OSPFv3 Link State Advertisement (LSA) Extensibility
draft-ietf-ospf-ospfv3-lsa-extend-23

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.')

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)

[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!

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

[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?)

[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

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

(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

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.

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

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.