Skip to main content

OSPF Traffic Engineering (OSPF-TE) Link Availability Extension for Links with Variable Discrete Bandwidth
RFC 8330


(Deborah Brungard)

No Objection

Warren Kumari
(Alissa Cooper)
(Benoît Claise)
(Eric Rescorla)
(Kathleen Moriarty)
(Spencer Dawkins)
(Suresh Krishnan)

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

Alvaro Retana
No Objection
Comment (2017-10-10 for -10)
(1) Please include draft file names in the references, not just abbreviations.  That will make it easier to track the relationship and dependencies.  For example, the draft uses the generalized format defined in draft-ietf-teas-gmpls-scsi, but the name of that draft (draft-ietf-teas-gmpls-scsi) doesn’t appear anywhere.  Also, the “References” and “Referenced by” tools in the datatracker don’t seem to work properly — in this case this document doesn’t appear to reference draft-ietf-teas-gmpls-scsi at all [A].


(2) Section 3.2. (Processing Procedures): “This information MAY be used for path calculation by the node(s).”  I think that the “MAY” is out of place because this document already indicated that the use of the information is out of scope: s/MAY/may

(3) Also from 3.2: 

   The Availability SCSI-TLV MUST NOT be sent in ISCDs with Switching
   Capability field values that have not been defined to support the
   Availability SCSI-TLV. Non-supporting nodes would see such as a
   malformed ISCD/LSA.

Where is this signaling defined?  How does a node know that others support the Availability ISCD/LSA?

(4) Section 4. (Security Considerations): “This document does not introduce security issues beyond those discussed in [RFC4203]…the extensions specified here have no direct effect on IP routing.”  But that is not true!  Even if out of scope of this document, the intent has already been established that the information can be used for route computation.  I think you should then expand on the impact that tampering/changing the LSAs could have.
Warren Kumari
No Objection
Deborah Brungard Former IESG member
Yes (for -08)

Adam Roach Former IESG member
(was Discuss) No Objection
No Objection (2017-11-09 for -11)
Thank you for addressing my discuss and most of my comments. I'll note that the following comment applied to two fields ("Availability level" and "LSP Bandwidth at Availability level n"), while the fix has only been applied to "Availability Level":

> Section 3.1 defines two fields as being "32-bit IEEE floaing point", which
> runs the risk of becoming ambiguous in the future (e.g., while no 32-bit
> decimal representations are currently defined, IEEE did define new, smaller
> formats in the most recent revision of IEEE 754). Additionally, byte ordering
> is important here. Recommend changing as:
> "This field is a binary32-format floating point number as defined by
> [IEEE754-2008]. The bytes are transmitted in network order; that is, the byte
> containing the sign bit is transmitted first."
Alexey Melnikov Former IESG member
No Objection
No Objection (2017-10-08 for -10)
This document should list the document that defines 32-bit IEEE floating point number as a Normative Reference, as it is required to implement the draft.
Alissa Cooper Former IESG member
No Objection
No Objection (for -10)

Ben Campbell Former IESG member
No Objection
No Objection (2017-10-10 for -10)
 I support Adam's DISCUSS.

It seems odd to find the terminology section before section 1.  Also, please consider using the boilerplate from 8174, especially since there are lower case instances of at least "should".

I think the reference to RFC5920 needs to be normative, since reading that document seems necessary to understand the security considerations.
Benoît Claise Former IESG member
No Objection
No Objection (for -10)

Eric Rescorla Former IESG member
No Objection
No Objection (for -10)

Kathleen Moriarty Former IESG member
No Objection
No Objection (for -10)

Mirja Kühlewind Former IESG member
No Objection
No Objection (2017-10-05 for -10)
This could lead to random outcomes
"If multiple are present, only the first Availability 
   SCSI-TLV for an availability level carried in the same ISCD SHALL be 
   processed. "
I would suggest the following instead:
"If multiple are present, the Availability 
   SCSI-TLV with the lowest bandwidth value SHALL be 
   processed. "

In section 3.1 you may actually specify the actual length value as done for the type:
"Length: A 16 bits field that expresses the length of the TLV in 
   bytes. "
"Length: 4 (bytes), 16 bits."
Spencer Dawkins Former IESG member
No Objection
No Objection (for -10)

Suresh Krishnan Former IESG member
No Objection
No Objection (for -10)