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" <[email protected]> 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:[email protected]] On Behalf Of Acee Lindem (acee) >Sent: 20 September 2014 01:49 >To: OSPF WG List; [email protected] >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 > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
