Comments inline Yours Irrespectively,
John > -----Original Message----- > From: Acee Lindem (acee) [mailto:[email protected]] > Sent: Thursday, October 16, 2014 11:52 AM > To: [email protected] > 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" <[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. [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 > > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
