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

From: John E Drake <[email-masked]>
Date: Tue, 4 Nov 2014 14:34:00 +0000

Comments inline

Yours Irrespectively,

John

> -----Original Message-----
> From: Acee Lindem (acee) [mailto:[email-masked]]
> Sent: Thursday, October 16, 2014 11:52 AM
> To: [email-masked]
> 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-masked]> 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

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 4 Nov 2014 15:31:04 +0000

Hi John, 

Snip to the only open point..

(snip)

> > >In fact the steps mentioned for the ingress in section 3 are
> > >applicable for a stateful PCE as well.
> 
> [JD]  Why?
>
I feel just the following minor change should be fine in the introduction section.  

OLD:
   The data distributed by OSPF TE Metric Extensions is meant to be used
   as part of the operation of the routing protocol (e.g. by replacing
   cost with latency or considering bandwidth as well as cost), by
   enhancing CSPF, or for other uses such as supplementing the data used
   by an Alto server [Alto]. With respect to CSPF, the data distributed
   by OSPF TE Metric Extensions can be used to setup, fail over, and
   fail back data paths using protocols such as RSVP-TE [RFC3209].[
   Draft-ietf-mpls-te-express-path] describes some methods for using
   this information to compute Label Switched Paths (LSPs) at the LSP
   ingress.
NEW:
   The data distributed by OSPF TE Metric Extensions is meant to be used
   as part of the operation of the routing protocol (e.g. by replacing
   cost with latency or considering bandwidth as well as cost), by
   enhancing CSPF, or for other uses such as supplementing the data used
   by a PCE [RFC4655] or an Alto server [Alto]. With respect to CSPF, the data distributed
   by OSPF TE Metric Extensions can be used to setup, fail over, and
   fail back data paths using protocols such as RSVP-TE [RFC3209].[
   Draft-ietf-mpls-te-express-path] and [draft-ietf-pce-pcep-service-aware] 
   describes some methods for using
   this information to compute Label Switched Paths (LSPs) at the LSP
   ingress and PCE respectively.  

This would let the reader know that PCE can also use this information along with the Ingress/ALTO server. 
 
(snip)

Regards,
Dhruv