Re: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)

[John E Drake <[e-mail]>]

Comments inline

Yours Irrespectively,

John

> -----Original Message-----
> From: Acee Lindem (acee) [mailto:[e-mail]]
> Sent: Thursday, October 16, 2014 11:52 AM
> To: [e-mail]
> Cc: Dhruv Dhody; OSPF WG List
> Subject: Re: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE)
> Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)
> 
> Authors,
> Can we get these issues taken care of in the version which will go through the
> next phase of reviews?
> Thanks,
> Acee
> 
> On 9/22/14, 5:59 AM, "Dhruv Dhody" <[e-mail]> wrote:
> 
> >Hi All,
> >
> >Fully support moving this work along.
> >
> >I have following comments/suggestions, which can handled along with
> >other last call comments.
> >
> >(1) Sec 1: Introduction
> >
> >   This document describes extensions to OSPF TE (hereafter called "OSPF
> >   TE Metric Extensions"), that can be used to distribute network
> >   performance information (such as link delay, delay variation, packet
> >   loss, residual bandwidth, and available bandwidth).
> >
> >Utilized Bandwidth can also be added in the above list.

[JD]  Okay 

> >
> >(2) A reference to PCE should also be added along with the mention of
> >ALTO server. See
> >http://datatracker.ietf.org/doc/draft-ietf-pce-pcep-service-aware/
> >In fact the steps mentioned for the ingress in section 3 are applicable
> >for a stateful PCE as well.

[JD]  Why? 

> >
> >(3)Is there a particular reason to reference RFC6375, which is MPLS-TP
> >document below? Or the intention was to use 6374?
> >
> >   The methods for initially gathering that
> >   performance information, such as [RFC6375], or acting on it once it
> >   is distributed are outside the scope of this document.  Example
> >   mechanisms to measure latency, delay variation, and loss in an MPLS
> >   network are given in [RFC6374].

[JD]  I will delete the reference to RFC 6375 

> >
> >(4) Suggested change to add delay variation and to update packet-loss
> >to just say percentage (the unit).
> >OLD:
> >   Delay values MUST be quantified in units of microseconds,
> >   packet loss MUST be quantified as a percentage of packets sent, and
> >   bandwidth MUST be sent as bytes per second.
> >NEW:
> >   Delay and delay variation values MUST be quantified in units of
> >microseconds,
> >   packet loss MUST be quantified as a percentage, and
> >   bandwidth MUST be sent as bytes per second.
> >

[JD]  Okay 

> >(5) Sec 4.2.7. Reserved
> >
> >   This field is reserved for future use. It MUST be set to 0 when sent
> >   and MUST be ignored when received.
> >
> >   When only an average delay value is sent, this field is not present
> >   in the TLV.
> >
> >I think you meant to say that the Min/Max Unidirectional Link Delay
> >Sub-TLV is not present instead of reserved field.

[JD]  Okay 

> >
> >(6) Sec 4.3. Unidirectional Delay Variation Sub-TLV
> >
> >   The delay variation advertised by
> >   this sub-TLV MUST be the delay from the local neighbor to the remote
> >   one (i.e. the forward path latency).
> >
> >We should say 'forward path latency-variation' in this case.

[JD]  Okay

> >
> >(7) Sec 11. Security Considerations
> >Since the network performance metric might be considered extra
> >sensitive in some deployments it should be strongly suggested that this
> >information must be protected from tampering using existing mechanism.

[JD]  Okay  

> >
> >(8) Sec 12. IANA Considerations
> >This section needs updating with the list of the TLVs

[JD]  Okay

> >
> >(9) A reference to RFC5392 for Inter-AS-TE-v2 LSA should be added to
> >avoid any confusion to the reader..

[JD]  I don't see any reason to put in a plug for this particular RFC

> >
> >Nits
> >- Remove reference from abstract for [RFC3630]
> >- Update [Alto] reference to [RFC7285]
> >- Expand CSPF, RSVP-TE, LSA on first use
> >- Min/Max delay and Low/High delay are used interchangeably, suggest to
> >use only one

[JD]   Okay

> >
> >Regards,
> >Dhruv
> >