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

["Acee Lindem (acee)" <[e-mail]>]

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.
>
>(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.
>
>(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].
>
>(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.
>
>(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.
>
>(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.
>
>(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.
>
>(8) Sec 12. IANA Considerations
>This section needs updating with the list of the TLVs
>
>(9) A reference to RFC5392 for Inter-AS-TE-v2 LSA should be added to
>avoid any confusion to the reader..
>
>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 
>
>Regards,
>Dhruv
> 
>From: OSPF [mailto:[e-mail]] On Behalf Of Acee Lindem (acee)
>Sent: 20 September 2014 01:49
>To: OSPF WG List; [e-mail]
>Subject: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE)
>Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)
>
>
>After more than 3 years of discussion and revision, the chairs feel that
>we are ready for a WG last call on the OSPF TE Metric extensions. While
>it is only one piece of an end-to-end delay/loss aware routing solution,
>we believe that the draft, as scoped, is ready. The WG last call will end
>at 12:00 AM PDT on Oct 4th, 2014. For your convenience, here is a URL:
>
>https://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions/
>
>Thanks,
>Acee and Abhay 
>