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

[Vishnu Pavan Beeram <[e-mail]>]

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


***