Re: [Teas] <draft-ietf-teas-te-metric-recording-04>: Review

["Zafar Ali (zali)" <[e-mail]>]

Hi Pavan-

Thanks for your review comments. We shall address them in the next revision.

Thanks

Regards ... Zafar

From: Vishnu Pavan Beeram <[e-mail]<mailto:[e-mail]>>
Date: Monday, June 6, 2016 at 1:41 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, TEAS WG <[e-mail]<mailto:[e-mail]>>
Subject: <draft-ietf-teas-te-metric-recording-04>: Review
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: zali <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Resent-Date: Monday, June 6, 2016 at 1:41 AM

Authors, WG, Hi!

I have reviewed the current version of this document. There are a few items (listed below) that I would like to see get discussed in the WG before taking this document to the next step.

(a) Additive vs Non-Additive Attributes: With the protocol extensions proposed by this document, the end-points of an inter-domain LSP can learn (via signaling) a few network-performance attributes from each hop traversed by the LSP. If this inter-domain LSP were to be advertised as a TE-link, then the end-points of this LSP could use this set of "learnt" attribute-lists, apply some policy and come up with a corresponding set of composite attributes that can then be advertised for the TE -ink. This document discusses the collection of 3 attributes - cost, delay and delay variation. Cost and delay can be treated as additive attributes (it needs to be pointed out that some in the past - see CCAMP WG list archives - have expressed concerns on the utility of adding up costs in an inter domain scenario); delay-variation is not an additive attribute. The document does say that the computation of the composite/macro attributes is beyond the scope of the draft. But I would like to hear from the WG if there are any concerns regarding the collection(/use) of any of the attributes discussed in this document.

(b) Other Network Performance Attributes: If we do allow the collection of  "delay-variation", then should we also consider allowing the collection of other network performance attributes specified in [RFC7471] and [RFC7810]?

(c) Generic "Hop Attribute Collection" mechanism: We have now opened up the door to collect any per-hop TE-attribute via signaling. We already have a generic mechanism to specify attributes that can be applied to each hop [hop-attributes sub-object, RFC7570]. Do we now need a generic mechanism to "collect" attributes from each hop [say, a hop-attributes-collection sub-object]? Or is the mechanism specified in the SRLG-Collect document and in this document acceptable to all?

Please do weigh in with your thoughts.

Regards,
-Pavan
ps: I also found a few editorial nits (pasted below) - @Authors, please see if you can take care of them in the next version.

***
Editorial Nits:


Header:

- Update the list of authors/editors in the first page as per the guidance provided in https://tools.ietf.org/html/rfc7322#section-4.1. (please see if you can adhere to the "5 authors" limit; as an alternative, consider having just one or two editors with others listed in the Contributors/Acknowledgements section)


1. Introduction:

- substitute /"[DRAFT-ISIS-TE-METRIC]"/ with /"[RFC7810]"/.

- substitute /"Consequently, in cases where that an LSP is advertised as a TE-Link,"/ with /"Consequently, in cases where an LSP is advertised as a TE-Link,"/

- The document does have a "Use Cases" section. So, consider removing the following sentence: "Note that specification of the use of the collected cost, delay and delay variation information is outside the scope of this document"


1.1 Use Cases

This section needs a scrub. This solution is not needed in all GMPLS scenarios - the initial sentence in 1.1.1 is misleading. You can cleanup a majority of this section if you just say that this is used for inter-domain TE LSPs.


1.1.2 Inter-area tunnels with loose-hops

- substitute /"When a LSP is established over multiple IGP-areas using loose hops in the ERO, the ingress node may only has knowledge"/ with /"When a LSP is established over multiple IGP-areas using loose hops in the ERO, the ingress node may only have knowledge .."/


2.2 Cost, Delay and Delay Variation Collection

- substitute /"Cost and/ or delay and/ or delay variation information is for each hop is added to the Path RRO during Path message processing."/ with /"Cost and/ or delay and/ or delay variation information is added by each hop to the Path RRO during Path message processing".

- Consider removing the following line [Comment - it doesn't seem to be adding any value]:
The endpoints of the LSP can make use of the collected SRLG information, for example, for routing, sharing and TE link configuration purposes.


9.1 Normative References

- substitute /[DRAFT-ISIS-TE-METRIC]/ with /[RFC7810]/.


***