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

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 6 Jun 2016 01:41:25 -0400

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]/.

***

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 6 Jun 2016 08:22:07 +0000

Hi Pavan-

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

Thanks

Regards ... Zafar

From: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Date: Monday, June 6, 2016 at 1:41 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, TEAS WG <[email-masked]<mailto:[email-masked]>>
Subject: <draft-ietf-teas-te-metric-recording-04>: Review
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: zali <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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?

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.

- 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 .."/

- 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

***