Prefix Flag Extension for OSPFv2 and OSPFv3
draft-ietf-lsr-ospf-prefix-extended-flags-07

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-lsr-ospf-prefix-extended-flags and RFC 9792, changed IESG state to RFC Published)

[Ballot comment]
# Orie Steele, ART AD, comments for draft-ietf-lsr-ospf-prefix-extended-flags-06
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-lsr-ospf-prefix-extended-flags-06.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### MUST be considered malformed

```
127   MUST be a multiple of 4 octets.  If the length is not a multiple of 4
128   octets, the LSA MUST be considered malformed.
```

This could be accomplished with "is malformed".

I also wonder if there is some exception that MUST (or MUST NOT) be raised here?

Sounds like perhaps malformed things are supposed to be ignored.

[Ballot comment]
Thanks for the work done in this document, simple but efficient and needed !

Two COMMENTs about section 2:

```
Length: Variable, dependent on the included Prefix Attribute Flags.
  This indicates the length of the value portion in bytes.  The length
  MUST be a multiple of 4 octets.  If the length is not a multiple of 4
  octets, the LSA MUST be considered malformed.
```

While I can guess what the "value portion" is, why not clearly specifying the "prefix attributes flags" ? Also, why not being consistent and using "octet" only (i.e., no "byte").

Do both OSPFv2 and OSPFv3 specify what to do with malformed TLV ?

[Ballot comment]
Section 2, paragraph 7
>    Prefix Attribute Flags: Variable.  The extended flag field.  This
>    contains a variable number of 32-bit flags.  Currently, no bits are
>    defined in this document.

Thanks to Tony Li for his OPSDIR review. In that review, he points out a few nits, which have been agreed upon with the authors. Just putting it here so it can be tracked and checked once the next version of the draft has been posted.

[Ballot comment]
A nice simple escape hatch for an exhausted flags space. Two minor nits in Section 2:

- s/prefixs/prefixes/
- "Currently, no bits are defined in this document." Given that we're in IESG Review, it seems unlikely that this document will be modified to define bits further in the process. Drop the "Currently" and just state that this document doesn't define/allocate any of the bits.

[Ballot comment]
Hi Ran, Detao, Peter, Ketan, and Liyan,

Thank you for the effort put into this specification. This is an important piece of work.

I definitely support this. I have some few comments that I’d like to be addressed, especially the first three comments and the comment in Section 3.

# General

## Should we have a recommendation whether the remaining flags are assigned first vs. use of the sub-TLV? I think we need a guidance (not rigid, though).

## Not sure if this is assumed, but is it allowed that a group of bits (e.g., 2 bits) may be allocated for one single purpose? The current description seems to assume that flags will be allocated individually.

## Should we have configuration parameters to control the use of the flags (e.g., rfc8362#appendix-A)?

## (nit) Please use terms to be consistent with the use in RFC8362 (sub-TLV, etc.).

## (nit) Use explicit references (with sections) to help readers to find where to look.

## (nit) Be consistent with the IANA registry names

# Abstract: Please indicate that the sub-TLV applies for both versions

OLD:
  Each OSPF prefix can be advertised with an 8-bit field to indicate
  specific properties of that prefix.  However, all the OSPFv3 Prefix
  Options bits have already been assigned and only a few bits remain
  unassigned in the flags field of the OSPFv2 Extended Prefix TLV.

  This document solves the problem of insufficient prefix options bits
  by defining variable-length Prefix Attribute Flags Sub-TLV for OSPF.

NEW:
  Each OSPF prefix can be advertised with an 8-bit field to indicate
  specific properties of that prefix.  However, all the OSPFv3 Prefix
  Options bits have already been assigned and only a few bits remain
  unassigned in the flags field of the OSPFv2 Extended Prefix TLV.

  This document solves this problem by defining variable-length Prefix
  Attribute Flags sub-TLV for OSPF. This sub-TLV is applicable to OSPFv2
  and OSPFv3.

# Section 2:

## (nits) Fix several nits

OLD:
  This document defines variable-Length Prefix Attribute Flags Sub-TLVs
  for OSPFv2 and OSPFv3.  These Sub-TLVs specify the variable-flag
  fields to advertise additional attributes associated with OSPF
  prefixs i.e., the advertisement and processing of the existing fixed-
  size prefix attribute flags remains unchanged.

NEW:
  This document defines variable-Length Prefix Attribute Flags sub-TLV
  for OSPFv2 and OSPFv3.  Such Sub-TLV specifies the variable-flag
  fields to advertise additional attributes associated with OSPF
  prefixes. The advertisement and processing of the existing fixed-
  size prefix attribute flags remain unchanged.

## (nit) Add caption  and call them in the text. For example, 

OLD:
  The format of OSPFv2/OSPFv3 Prefix Attribute Flags Sub-TLVs is:

      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Type            |            Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                              |
    //                Prefix Attribute Flags (Variable)          //
    |                                                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NEW:
  The format of OSPFv2/OSPFv3 Prefix Attribute Flags sub-TLV is shown in Figure 1.

      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Type            |            Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                              |
    //                Prefix Attribute Flags (Variable)          //
    |                                                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of OSPFv2/OSPFv3 Prefix Attribute Flags Sub-TLV

## I don’t parse what is meant by “defined prefix flags” in the following:

CURRENT:
  Defined prefix flags that are not
  transmitted due to being beyond the transmitted length MUST be
  treated as being set to 0.

# Should the event covered in this part be logged?

CURRENT:
  When multiple instances of an OSPFv2/OSPFv3 Prefix Attribute Flags
  Sub-TLVs are received within the same TLV, an implementation MUST use
  only the first occurrence of the Sub-TLV and MUST ignore all
  subsequent instances of the Sub-TLV.

(nit) Maybe better to reword as follows:

NEW:
  When multiple instances of the OSPFv2/OSPFv3 Prefix Attribute Flags
  sub-TLV are received within the same TLV, an implementation MUST use
  only the first occurrence of the sub-TLV and MUST ignore all
  subsequent instances of the sub-TLV.

# Section 3: MUST seems redundant with “Unrecognized TLVs and sub-TLVs are ignored” stated in rfc8362#section-6

CURRENT:
  The Prefix Attribute Flags Sub-TLVs defined in this document does not
  introduce any backward compatibility issues.  An implementation that
  does not recognize the OSPFv2/OSPFv3 Prefix Attribute Flags Sub-TLV
  MUST ignore the Sub-TLV.

(nit) We may consider: s/The Prefix Attribute Flags Sub-TLVs defined in this document/The Prefix Attribute Flags sub-TLV does not

# Section 5: We may add subsections for each OSPF version to better organize the actions (and also avoid orphan subsections):

OLD:
    5.1.  OSPFv2 Prefix Attribute Flags Sub-TLV Registry
      5.1.1.  OSPFv2 Prefix Extended Flags Field Registry
    5.2.  OSPFv3 Prefix Attribute Flags Sub-TLV Registry
      5.2.1.  OSPFv3 Prefix Extended Flags Field Registry

NEW
    5.1.  OSPFv2
      5.1.1.  OSPFv2 Prefix Attribute Flags Sub-TLV Registry
      5.1.2.  OSPFv2 Prefix Extended Flags Field Registry
    5.2.  OSPFv3
      5.2.1. OSPFv3 Prefix Attribute Flags Sub-TLV Registry
      5.2.2. OSPFv3 Prefix Extended Flags Field Registry

# FWIW, the full review with other minor edits/nits can be found at:

* pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-lsr-ospf-prefix-extended-flags-06-rev%20Med.pdf
* doc: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-lsr-ospf-prefix-extended-flags-06-rev%20Med.doc

Feel free to grab whatever useful there.

Cheers,
Med

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-lsr-ospf-prefix-extended-flags-06. If any part of this review is inaccurate, please let us know.

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

First, in the OSPFv2 Extended Prefix TLV Sub-TLVs registry in the Open Shortest Path First v2 (OSPFv2) Parameters registry group located at:

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

the registration for:

Value: 11
Description: OSPFv2 Prefix Attribute Flags

will have its reference changed to [ RFC-to-be ].

Second, a new registry is to be created called the OSPFv2 Prefix Extended Flag Field registry. The new registry will be located in the Open Shortest Path First v2 (OSPFv2) Parameters registry group located at:

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

The registry will be managed via IETF Review as defined by RFC8126. There are no initial registrations in the new registry. The registry will have three fields: Bit number; Description; and Reference. Bits 0-31 will initially be marked Unassigned.

Third, in the OSPFv3 Extended-LSA Sub-TLVs registry in the Open Shortest Path First v3 (OSPFv3) Parameters registry group located at:

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

the registration for:

Value: 37
Description: OSPFv3 Prefix Attribute Flags

will have its reference changed to [ RFC-to-be ].

Fourth, a new registry is to be created called the OSPFv3 Prefix Extended Flag Field registry. The new registry will be created in the Open Shortest Path First v3 (OSPFv3) Parameters registry group located at:

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

The registry will be managed via IETF Review as defined by RFC8126. There are no initial registrations in the new registry. The registry will have three fields: Bit number; Description; and Reference. Bits 0-31 will initially be marked Unassigned.

We understand 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.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-03-04):

From: The IESG
To: IETF-Announce
CC: acee.ietf@gmail.com, draft-ietf-lsr-ospf-prefix-extended-flags@ietf.org, gunter@vandevelde.cc, lsr-chairs@ietf.org, lsr@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Prefix Flag Extension for OSPFv2 and OSPFv3) to Proposed Standard


The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'Prefix Flag Extension for OSPFv2 and
OSPFv3'
  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 2025-03-04. 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


  Each OSPF prefix can be advertised with an 8-bit field to indicate
  specific properties of that prefix.  However, all the OSPFv3 Prefix
  Options bits have already been assigned and only a few bits remain
  unassigned in the flags field of the OSPFv2 Extended Prefix TLV.

  This document solves the problem of insufficient prefix options bits
  by defining variable-length Prefix Attribute Flags Sub-TLV for OSPF.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-extended-flags/



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

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  This is a simple OSPF maintanenace document that adds TLVs for OSPF prefixes.
  It is has LSR WG support although it didn't generate a lot of excitement.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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. 

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  Not yet - https://datatracker.ietf.org/doc/draft-ietf-lsr-anycast-flag/ requires
  the extensions.

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  N/A - this is a simple OSPF extension not requiring outside reviews.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  There has been a RTGDIR review and all comments have been addressed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

    N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  N/A

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

  N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    Proposed Standard is required since OSPF and OSPFv3 protocol encodings are
    defined.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    Yes.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

    Yes. There are five authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    None.
   

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    No.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    The document creates two new registries for the OSPF Extended flags.
    The allocation for both registries is "IETF Review or IESG
    Approval [RFC8126]".

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  This is a simple OSPF maintanenace document that adds TLVs for OSPF prefixes.
  It is has LSR WG support although it didn't generate a lot of excitement.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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. 

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  Not yet - https://datatracker.ietf.org/doc/draft-ietf-lsr-anycast-flag/ requires
  the extensions.

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  N/A - this is a simple OSPF extension not requiring outside reviews.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  There has been a RTGDIR review and all comments have been addressed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

    N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  N/A

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

  N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    Proposed Standard is required since OSPF and OSPFv3 protocol encodings are
    defined.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    Yes.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

    Yes. There are five authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    None.
   

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    No.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    The document creates two new registries for the OSPF Extended flags.
    The allocation for both registries is "IETF Review or IESG
    Approval [RFC8126]".