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
