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

["Adrian Farrel" <[e-mail]>]

Hi Acee,

> 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?

There's a float-32, a float-64, and a float-128.

I think 32 bits is adequate.
All you need to change is to add the citations.

Adrian

> On Dec 12, 2014, at 1:16 PM, Adrian Farrel <[e-mail]> 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:[e-mail]]
> >> Sent: 12 December 2014 18:14
> >> To: t.p.
> >> Cc: [e-mail];
> > [e-mail];
> >> [e-mail]
> >> 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. <[e-mail]> 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" <[e-mail]>
> >>> To: <[e-mail]>
> >>> Cc: <[e-mail]>; <[e-mail]>
> >>> 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.
> >>>>
> >>>>
> >>>>
> >>>
> >