datatracker.ietf.org
Sign in
Version 5.13.0, 2015-03-25
Report a bug

OSPF Traffic Engineering (TE) Metric Extensions
draft-ietf-ospf-te-metric-extensions-11

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

Summary: Needs a YES. Has enough positions to pass.

Alissa Cooper

Comment (2015-01-06 for -10)

= Section 1 =

"While this document does not specify how the performance information
   should be obtained, the measurement of delay SHOULD NOT vary
   significantly based upon the offered traffic load.  Thus, queuing
   delays and/or loss SHOULD NOT be included in any dynamic delay
   measurement."

Agree with Stephen's comment here -- this is confusing. I'm not sure normative
language makes a whole lot of sense here at all if "the measurement" means "the
quantity you actually measure" as opposed to "the quantity that you report
after measuring."

Also, how would loss be reported in a delay measurement? (I can imagine ways,
but they seem contrived.)

= Section 4.2.7 =

"Implementations MAY also permit the configuration of an offset value
   (in microseconds) to be added to the measured delay value to
   advertise operator specific delay constraints."

Do I understand correctly that there is no way specified to communicate this
offset value? If this is a matter for local configuration, it seems a bit odd
to use normative language and describe it in the definition of the sub-TLV.

= Section 4.4.5 =

"When set to a value of all 1s (2^24 - 1), the link packet loss has
   not been measured."

I noted that in the case of delay, the way to signal that delay has not been
measured is to not send or withdraw the sub-TLV, whereas for loss it is to send
a specific value. Why do this differently for different measurements?

= Section 7 =

I agree with Barry's comments here.

Barry Leiba

Comment (2014-12-29 for -09)

A couple of minor, non-blocking comments, just looking for a little
clarification:

-- Section 7 --

I can't imagine that the "SHOULD" in the first paragraph is an appropriate 2119
key word: no one can tell whether or not care was taken, so this can't be a
protocol issue.  Please just say "Therefore it is important to set these values
carefully."

For the remaining "SHOULD"s, "SHOULD NOT", and "RECOMMENDED" in this section:
remembering that "SHOULD" means that "there may exist valid reasons in
particular circumstances to ignore a particular item, but the full implications
must be understood and carefully weighed before choosing a different course,"
how can someone reading this understand and weigh those implications?  I can't:
I have no idea why these recommendations are being made, and what the
implications are of making different choices.  Can you help me here?  Or are
these just recommended values, in the lower-case, plain English sense?

Benoit Claise

Comment (2015-01-08 for -10)

From an OPS point of view, I'm mainly interested in what is out of scope, as
written in the writeup: "There has been much discusson as to how these metrics
would be collected and how they will be used. These topics were deemed to to be
out of scope". So I'll wait for a companion document.

I agree with Alissa and Stephen that the following paragraph is confusing:

   "While this document does not specify how the performance information
   should be obtained, the measurement of delay SHOULD NOT vary
   significantly based upon the offered traffic load.  Thus, queuing
   delays and/or loss SHOULD NOT be included in any dynamic delay
   measurement."

Brian Haberman

Comment (2015-01-06 for -10)

I agree with Stephen that the specified use cases seem to warrant a stronger
recommendation to provide authentication and confidentiality.  The tools are
available, so why are they not being recommended in this instance?

Jari Arkko

Comment (2015-01-07 for -10)

Thank you for doing this work. It is very important and I can clearly see the
use cases.

I do have some comments though.

I think it would be useful to specify explicitly what the IEEE floating point
number format variant is being used. I assume binary32. (Also noted in the
Gen-ART review.)

I am a bit surprised by the A bit design. Would it be useful to add some
rationale for why this approach has been taken? As I read the document I find
it difficult to understand why the bit carries extra value for the receiver. It
does signal an exceptional condition, but at the same time, any real action
(e.g., Step B in Section 3) seems to be something that should be based on the
calculation of the actual bandwidths and delays rather than the flag itself. Or
did I misunderstand this?

Also, it would be useful to specify what information must be understood in the
network for the A bit usage. Do all nodes have to the same understanding of the
threshold throughout the network? Or just the sending node?

Finally, I would have preferred to see some defaults for the various
configurable values, and some discussion of the requirements for the values.
Again, do the measurement period for instance have to be aligned across a
network, or not? A section on management considerations might be appropriate.

Stephen Farrell

Comment (2015-01-05 for -10)

These are mainly nits or questions, other than the
first.  That would have been a discuss if I knew of a
specific threat, but since this is just a general
concern, it's not a discuss. I'd appreciate a bit of
a chat about it though.

- I'd have thought that these TLVs would be sent more
often than others, and that (if enormous amounts of
money are in play) then use of OSPF authentication might
be more likely needed (or some equivalent security
mechanisms). I'd even speculate that if enormous amounts
of money are in play, then confidentiality may become a
requirement (since if I can observe say A bit settings
then that might give me insight into traffic levels -
sort of a lights burning at night in central bank
implies interest-rate change attack). Can you say why
none of that needs to be mentioned at all? Was any of
that considered by the WG? (Can you send a relevant link
to the archive?)

- intro: "extremely large amounts of money" aren't
usually explicit motivations for protocol features and I
hope that that continues to be the case. I'd encourage
you to remove that phrase. Similarly, "faster" is a fine
requirement but "fast than the competition" is not, so a
bit more wordsmithing might be good. (Those are, I
think, defensible points as we ought not over-specialise
our requirements, but to be honest I'd also be happier
if protocol development was not explicitly motivated
soley by increasing already-enormous amounts of money.)

- intro: saying the "measurement of delay SHOULD NOT
vary significantly based upon the offered traffic load"
is odd. Clearly the delay experienced can vary based on
the load, so I'm not sure what you're saying. And nor is
it clear why this is a SHOULD NOT, as opposed to a MUST
NOT. Maybe you need to explain that some more?

- section 3: Doesn't the A bit definition assume that
both senders and receivers know the thresholds (or
enough about those). That seems a bit odd to me, but I
expect you've thought it through.  Same thing with the
averaging period I guess (though section 7 does specify
a 30s default as a SHOULD). Or am I missing that one
could calculate those from the various TLVs that are
defined?  (I think I'm also not understanding bullet
point 4 in section 5 which may be related.)

- section 3: I don't get what "cannot be used for
fail-over purposes" means. I think you mean "ought not"
since a receiver can do what they want in any case.

- The security considerations of RFC 3630, from 2003, is
11 lines long. Has nothing affected OSPF security in the
last decade+ that would be worth noting here?

- In one response to the secdir review, [1] path
shortening attacks were mentioned - I'm not clear myself
if that's a deal here, but is text on that needed? Some
text that was suggested is

"users of the lsas described in this document should be aware of how
they might be used in path shortening and other routing attacks."

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05354.html