OSPFv2 Prefix/Link Attribute Advertisement
draft-ietf-ospf-prefix-link-attr-13

[Ballot comment]

- The opaque ID field descriptions in sections 2 and 3 read a
little oddly to me. What happens if someone decides to use up
ID=0? Does that mean they can't overwrite that value until
much later maybe? And what if a whole bunch of routers choose
the same value (because it's configured or hard-coded)? I
think you need a bit more text on that. And with only 24 bits
the probability of a collision if you just pick randomly isn't
that low, so I'm not sure if random selection is a good plan
here either. (How often will a new one of these be seen?)

- Do these opaque values get forwarded widely? If so, then I
guess they may provide a covert channel. I didn't see that
mentioned in the security considerations of RFC5250. Is it
mentioned elsewhere? If not, is it worth a mention here?
(Probably not, but thought I'd ask.)

- Thanks for section 5. Nice to see. (Makes me wonder what
those implementations do with the opaque ID though:-)

[Ballot comment]

- The opaque ID field descriptions in sections 2 and 3 read a
little oddly to me. What happens if someone decides to use up
ID=0? Does that mean they can't overwrite that value until
much later maybe? And what if a whole bunch of routers choose
the same value (because it's configured or hard-coded)? I
think you need a bit more text on that. And with only 24 bits
the probability of a collision if you just pick randomly isn't
that low, so I'm not sure if random selection is a good plan
here either. (How often will a new of these be seen?)

- Do these opaque values get forwarded widely? If so, then I
guess they may provide a covert channel. I didn't see that
mentioned in the security considerations of RFC5250. Is it
mentioned elsewhere? If not, is it worth a mention here?
(Probably not, but thought I'd ask.)

- Thanks for section 5. Nice to see. (Makes me wonder what
those implementations do with the opaque ID though:-)

[Ballot comment]
More a comment for IESG discussion, this draft has six authors (exceeds five author limit). I didn't see any notes in the shepherd writeup to support the need to exceed the limit (my former AD required a strong argument for exceeding). What guidelines are we following? I have many drafts coming along which exceed the limit and wondering what to do.

[Ballot comment]
I concur with Kathleen's DISCUSS and Alvaro's comment about the security considerations.

Other comments:

-- 2.1, definition of N-Flag

There are a couple of occurrences of "NOT" in caps that are not combined with other 2119 keywords. I assume those are not intentional?

-- 2.1, 4th paragraph from end, last sentence (also occurs in 3.1):

The 2119 MAY here doesn’t seem helpful, since this is internal to a router and does not impact seem interoperability. I suggest it be restated without 2119 language, unless you want to make it a SHOULD or stronger.  (I am not a stickler that
2119 keywords never be used for things that are not observable by a peer, but MAYs seem especially useless in that context. I did not object to the SHOULD in the prior paragraph, since that might have operational value.)

[Ballot discuss]
Thanks for your work on this draft.

I have questions along the lines that Alvaro raised on the last sentence of the Security Considerations section, but in context of security, this is something that should be discussed.

  "Additionally,
  implementations must assure that malformed TLV and Sub-TLV
  permutations do not result in errors that cause hard OSPF failures."

It would be very helpful to expand upon this statement.  Are there exploits that could result as well?  Should this instead be scoped in terms of what is valid so that the appropriate actions occur consistently when an invalid or malformed TLV or sub-TLV are received?  I would think the answer to the last question would clarify this enough for this security consideration and if that's not possible, can you explain what I'm missing?

Thank you.

[Ballot comment]
Some minor comments, just some clarifications... and a question about the registries.

-- Section 2 --
There is no explanation of the "length" field in the OSPFv2 Extended Prefix Opaque LSA.  I guess it's the total size, in bytes, of all the TLV data that follows, including any alignment bytes.  But you should make that clear.

-- Section 3 --
The same comment as for Section 2 applies here for the OSPFv2 Extended Link Opaque LSA.

-- Section 7.1 --

  Types in the range 33024-65535 are not to be assigned at this time.
  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.

A question here (I'm not hoping for any particular answer, just asking the question): When you say "an IETF specification", I take that to mean an RFC in the IETF stream, which can be Standards Track *or* Informational *or* Experimental.  Is that what you want?

The same question applies to the registries in the subsequent sections (7.2, 7.3, 7.4).

[Ballot comment]
This is a good document, but I have some comments (and nits) that I would really like to see addressed before publication.  I don't think my comments raise to the level of a DISCUSS, but I am specially interested in the actions when errors are detected.


1. Sections 2 and 3. 

a. RFC5250 used the name Opaque ID instead of Instance.  Please be consistent.  If there’s a really good reason to not use the “official” name, please at least write in the description of Instance that rfc5250 calls it Opaque ID.

b. “…the attributes from the Opaque LSA with the lowest Instance will be used.”  This sounds to me like a good place to be a little bit more prescriptive and s/will/MUST


2. Section 2.1. (OSPFv2 Extended Prefix TLV) 

a. For the Route Type, are those the only allowed values?  What happens if something else is used?

b. Flags
- What are the defined flags used for?  Since (according to Section 5) they are not supported in all implementations then I’m assuming there’s a specific application in mind. [I know there are other ID’s in progress that use the TLVs defined here.  Is the use of these bits general to those applications?]

- How should the rest of the flags be assigned?  The IANA section says nothing about that.

c. "Address Prefix    The prefix itself encoded as a 32-bit value.”  It is variable, not fixed.  I know that only IPv4 is currently supported, but as explained in the AF section, there may be future extensions.


3. Section 3.1. (OSPFv2 Extended Link TLV)  What should happen if an unknown/incorrect Link-Type/Link-ID/Link Data value is received?


4. Section 6. (Security Considerations)

a. I think you should also point the readers at the considerations in rfc5250.

b. “…implementations must assure that malformed TLV and Sub-TLV permutations do not result in errors that cause hard OSPF failures.”  What does that mean?  That the software should be resilient?  Or are you pointing at just ignoring the information if there is a malformed TLV/sub-TLV (that is somehow salvageable)?  It would be vey nice is this draft set the example by specifying what to do in some cases (maybe not malformed, but incorrect/unknown as mentioned above).


5. Section 7.  (IANA Considerations)  Is there a significant reason why in all cases the assignment policy for the 33024-65535 range is not being defined upfront?


Nits:
1. In Sections 2 and 3  s/differential/differentiate

2. In Section 2. (OSPFv2 Extended Prefix Opaque LSA), the figure that shows the TLV format seems to show a Value field of only 32 bits.  The description (below the figure), which looks like an exact copy from rfc3630, describes the field correctly.  It would be nice to either copy over the whole text from rfc3630 (including the figure that shows that the Value may be longer) or just leave out that text completely (which is my preference).  The text saying that the TLV format is the same as in rfc3630 is enough.
- In Section 3 you write: "The format of the TLVs within the body of the OSPFv2 Extended Link Opaque LSA is the same as described in Section 2.”  One more level of indirection..

3. 2.1. (OSPFv2 Extended Prefix TLV) 
a. The description of “Flags” is misaligned (it looks like a sub-paragraph of AF).
b. s/originated by the different/originated by different

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA's reviewer has the following comments/questions about draft-ietf-ospf-prefix-link-attr-06:

IANA has a recurring question about some of the actions requested in the IANA Considerations section of this document. In addition, the

IANA understands that, upon approval of this document, there are six actions which need to be completed.

First, in the Opaque Link-State Advertisements (LSA) Option Types subregistry of the Open Shortest Path First (OSPF) Opaque Link-State Advertisements (LSA) Option Types registry located at:

http://www.iana.org/assignments/ospf-opaque-types/

the temporary registration for value 7, OSPFv2 Extended Prefix Opaque LSA will be made permanent and the reference will be changed to [ RFC-to-be ].

Second, also in the Opaque Link-State Advertisements (LSA) Option Types subregistry of the Open Shortest Path First (OSPF) Opaque Link-State Advertisements (LSA) Option Types registry located at:

http://www.iana.org/assignments/ospf-opaque-types/

the temporary registration for value 8, OSPFv2 Extended Link Opaque LSA will be made permanent and the reference will be changed to [ RFC-to-be ].

Third, a new registry is to be created called the OSPF Extended Prefix Opaque LSA TLV Registry.

IANA Question -> The authors request that the new registry be placed in the existing OSPF IANA registry. However, there are several OSPF IANA registries. Specifically which of the existing OSPF registries should be used as the home for this new registry? For an index of existing registries, please see http://www.iana.org/protocols.

The registration rules for the new registry are listed as IETF Consensus or IESG Approval as defined in RFC 5226. However, the term "IETF Consensus" has been replaced with "IETF Review." This should be updated in the document.

IANA understands that types in the range 32768-33023 will be marked as for experimental use only. Types in the range 33024-65535 are not to be assigned at this time and will be marked "Reserved."

There are initial registrations in the new registry as follows:

Value Description Reference
0 Reserved [ RFC-to-be ]
1 OSPF Extended Prefix TLV [ RFC-to-be ]
2-32767 Unassigned
32768- 33023 For experimental use
33024-65535 Reserved [ RFC-to-be ]

Fourth, a new registry is to be created called the OSPF Extended Prefix TLV Sub-TLV Registry.

IANA Question -> The authors request that the new registry be placed in the existing OSPF IANA registry. However, there are several OSPF IANA registries. Specifically which of the existing OSPF registries should be used as the home for this new registry? For an index of existing registries, please see http://www.iana.org/protocols.

The registration rules for the new registry are listed as IETF Consensus or IESG Approval as defined in RFC 5226. However, the term "IETF Consensus" has been replaced with "IETF Review." This should be updated in the document.

IANA understands that types in the range 32768-33023 will be marked as for experimental use only. Types in the range 33024-65535 are not to be assigned at this time and will be marked "Reserved."

There are initial registrations in the new registry as follows:

Value Description Reference
0 Reserved [ RFC-to-be ]
1-32767 Unassigned
32768- 33023 For experimental use
33024-65535 Reserved [ RFC-to-be ]

Fifth, a new registry is to be created called the OSPF Extended Link Opaque LSA TLV Registry.

IANA Question -> The authors request that the new registry be placed in the existing OSPF IANA registry. However, there are several OSPF IANA registries. Specifically which of the existing OSPF registries should be used as the home for this new registry? For an index of existing registries, please see http://www.iana.org/protocols.

The registration rules for the new registry are listed as IETF Consensus or IESG Approval as defined in RFC 5226. However, the term "IETF Consensus" has been replaced with "IETF Review." This should be updated in the document.

IANA understands that types in the range 32768-33023 will be marked as for experimental use only. Types in the range 33024-65535 are not to be assigned at this time and will be marked "Reserved."

There are initial registrations in the new registry as follows:

Value Description Reference
0 Reserved [ RFC-to-be ]
1 OSPFv2 Extended Link TLV [ RFC-to-be ]
2-32767 Unassigned
32768- 33023 For experimental use
33024-65535 Reserved [ RFC-to-be ]

Sixth, a new registry is to be created called the OSPF Extended Link TLV Sub-TLV Registry.

IANA Question -> The authors request that the new registry be placed in the existing OSPF IANA registry. However, there are several OSPF IANA registries. Specifically which of the existing OSPF registries should be used as the home for this new registry? For an index of existing registries, please see http://www.iana.org/protocols.

The registration rules for the new registry are listed as IETF Consensus or IESG Approval as defined in RFC 5226. However, the term "IETF Consensus" has been replaced with "IETF Review." This should be updated in the document.

IANA understands that types in the range 32768-33023 will be marked as for experimental use only. Types in the range 33024-65535 are not to be assigned at this time and will be marked "Reserved."

There are initial registrations in the new registry as follows:

Value Description Reference
0 Reserved [ RFC-to-be ]
1-32767 Unassigned
32768- 33023 For experimental use
33024-65535 Reserved [ RFC-to-be ]

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 what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (OSPFv2 Prefix/Link Attribute Advertisement) to Proposed Standard


The IESG has received a request from the Open Shortest Path First IGP WG
(ospf) to consider the following document:
- 'OSPFv2 Prefix/Link Attribute Advertisement'
  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 2015-08-13. 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


  OSPFv2 requires functional extension beyond what can readily be done
  with the fixed-format Link State Advertisements (LSAs) as described
  in RFC 2328.  This document defines OSPF opaque LSAs based on Type-
  Length-Value (TLV) tuples that can be used to associate additional
  attributes with prefixes or links.  Dependent on the application,
  these prefixes and links may or not be advertised in the fixed-format
  LSAs.  The OSPF opaque LSAs are optional and fully backward
  compatible.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ospf-prefix-link-attr/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ospf-prefix-link-attr/ballot/


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

comments from AD review to be addressed in parallel:

Minor issues:

On p. 6, it says " AF Address family for the prefix.  Currently, the
only supported value is 0 for IPv4 unicast."  Please clarify VERY
CLEARLY why this restriction exists.  Not everyone reading this will
be familiar with support for IPv6 in various protocols and we are really
finally heading towards lots more IPv6.

On p. 6 and 8.:
"The Instance field is an arbitrary value used to maintain multiple
Extended Prefix Opaque LSAs.  A maximum of 16777216 Extended Prefix
Opaque LSAs may be sourced by a single OSPF instance.": This doesn't
really give normative behavior.  I assume that what you mean is that
the advertising router has a number space for the Instance which has
no significance outside of that advertising router and can have
arbitrary values allocated from it.  Each of these LSAs is identified
uniquely by its Instance number.  Please provide good text for what
MUST be done and indicate that the value may be used for tie-breaking
("In this case, the Extended-Prefix-TLV in the Extended Prefix Opaque
LSA with the smallest Instance is used by receiving OSPFv2 Routers. ")
and there's an assumption that the values will be allocated from
smallest to largest.

On p. 6 for the Route Type, it would be useful to have a reference to
where these type values are pulled from.  I'd also like to see some
text about whether other values could be valid in the future and how
so.  For instance, I'm assuming that you are basically pulling the
values from the OSPFv2 Link State (LS) Type
(http://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xhtml#ospfv2-parameters-5)
- so perhaps you could simply say so or clarify for what are valid
values.

On p. 9: For Link-Type, could you also put a reference to the IANA
registry?  I'd prefer it to be clear that if (unlikely as it seems)
there were a new Link-Type added, it would apply here too.

In Sec 5, pleaes add an RFC Editor note that Section 5 will be removed
upon publication.  That's the intent wtih RFC 6982.  Thanks for
including this section in the draft.  If the information wants to move
to the OSPF WG wiki, that would give it a place to survive after this
draft is submitted to the RFC Editor.

Nits:

In Sec 2, there's an "e.g., mapping server deployment".  Could you add
a reference?  This tells me nothing...

In Sec 2, In the packet format, could you clarify Opaque type = 7? Same
for on p.8 for opaque type = 8 ?

Since you are creating the registry for the TLVs, please clearly state
that value 1 is being used earlier - instead of "suggested value" as
on p.9