ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-ospf-te-metric-extensions-08.txt> (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard

2014-12-16 11:59:38
Hi Adrian, Tom, 
Can you guys indicate how you would like to see this comment reflected in the 
draft? Are you suggesting to change he encoding to 64 bits for the new 
bandwidth sub-TLVs? 
Thanks,
Acee
On Dec 12, 2014, at 1:16 PM, Adrian Farrel 
<adrian(_at_)olddog(_dot_)co(_dot_)uk> wrote:

Good catch Tom,

Acee, the trick is to go to 6340 and look in the references :-)

  [IEEE.754.2008]  Institute of Electrical and Electronics Engineers,
                   "Standard for Floating-Point Arithmetic",
                   IEEE Standard 754, August 2008.

A

-----Original Message-----
From: Acee Lindem (acee) [mailto:acee(_at_)cisco(_dot_)com]
Sent: 12 December 2014 18:14
To: t.p.
Cc: adrian(_at_)olddog(_dot_)co(_dot_)uk;
draft-ietf-ospf-te-metric-extensions(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org
Subject: Re: Last Call: <draft-ietf-ospf-te-metric-extensions-08.txt> (OSPF
Traffic
Engineering (TE) Metric Extensions) to Proposed Standard

Hi Tom,

On Dec 12, 2014, at 1:08 PM, t.p. <daedulus(_at_)btconnect(_dot_)com> wrote:

On the question of Floating-Point, there is now 754-2008, which is a
tighter spec and is used in RFC6340.

What is 754-2008?

Thanks,
Acee




At a tangent, the issue of floating-point support has surfaced a number
of times in YANG and, to date, has always been rejected, reckoning that
suppport for 64-bit decimal is adequate for data modelling.  The
interactions with XPath (which is used as a basis for YANG constraint
statements), where floating-point is allowed, have caused a number of
discussions, some ongoing, about the comparison of a floating-point
number to a 64-bit decimal one. Something to be aware of should you ever
want to model this in YANG.

Tom Petch


----- Original Message -----
From: "Adrian Farrel" <adrian(_at_)olddog(_dot_)co(_dot_)uk>
To: 
<draft-ietf-ospf-te-metric-extensions(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org>
Cc: <ospf(_at_)ietf(_dot_)org>; <ietf(_at_)ietf(_dot_)org>
Sent: Wednesday, December 10, 2014 11:07 PM

All,

I reviewed this document as AD and found a few small points that I
have asked
the authors to address as IETF last call comments.

Adrian

===

Please look for places where you have "proposed" something and change
that to "defined".

---

It would be good to include a reference for encoding floating point
integers. The usual is (I think)...

      IEEE, "IEEE Standard for Binary Floating-Point Arithmetic",
      Standard 754-1985, 1985 (ISBN 1-5593-7653-8).

---

Section 4.2.5

 Implementations MAY also permit the configuration of a static (non
 dynamic) offset value (in microseconds) to be added to the measured
 delay value, to facilitate the communication of operator specific
 delay constraints.

On the third reading I got it! I'm slow (I have a high delay :-)

The point here is that the measured value and the static value are
added
together and the sum is transmitted in this field. I'd suggest...

 Implementations MAY also permit the configuration of a static (non
 dynamic) offset value (in microseconds) to be added to the measured

 delay value before encoding into this TLV, to facilitate the
 communication of operator specific delay constraints.

Similarly in 4.2.6.

---

4.2.7 appears out of sequence. But since it repeats the content of
4.2.4 I suggest you merge them and talk about the plurality of fields.

---

Section 7

"Sections 6 and 7 provide" should be 5 and 6.

---

Section 10

 "As per (RFC3630), unrecognized TLVs should be silently ignored"

There has been confusion about what 3630 means by "silently ignored".
In particular, some enthusiastic implementations thought this meant
the
TLVs should be stripped from the LSA before it is propagated. I think
it
is worth the few words to explicitly state that this is not the case.

---

Section 13

RFC 4203 is used in a normative way, please move it to the other
section.