Skip to main content

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

Yes

Gunter Van de Velde

No Objection

Andy Newton
Erik Kline
Gorry Fairhurst
Paul Wouters
Roman Danyliw

Recuse


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

Gunter Van de Velde
Yes
Jim Guichard
Yes
Comment (2025-03-31 for -06) Sent
Thank you for a clearly written and useful document. I have no substantive comments that have not alreadyy been highlighted by other reviewers.
Mohamed Boucadair
Yes
Comment (2025-03-25 for -06) Sent
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
Andy Newton
No Objection
Deb Cooley
No Objection
Comment (2025-03-28 for -06) Not sent
Thanks to Mike Ounsworth for the secdir review and follow-up.
Erik Kline
No Objection
Gorry Fairhurst
No Objection
Mahesh Jethanandani
No Objection
Comment (2025-03-31 for -06) Sent
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.
Mike Bishop
No Objection
Comment (2025-03-26 for -06) Sent
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.
Orie Steele
No Objection
Comment (2025-04-01 for -06) Sent
# 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.
Paul Wouters
No Objection
Roman Danyliw
No Objection
Éric Vyncke
No Objection
Comment (2025-04-01 for -06) Sent
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 ?
Ketan Talaulikar
Recuse
Comment (2025-03-30 for -06) Not sent
I am one of the co-authors on this document.