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

Vishnu Pavan Beeram <vishnupavan@gmail.com> Mon, 06 June 2016 05:41 UTC

Return-Path: <vishnupavan@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id ADA8A12D0A1; Sun, 5 Jun 2016 22:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6QRMoTmo7iJq; Sun, 5 Jun 2016 22:41:29 -0700 (PDT)
Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 667E312B024; Sun, 5 Jun 2016 22:41:26 -0700 (PDT)
Received: by mail-vk0-x230.google.com with SMTP id c66so32001916vkb.3; Sun, 05 Jun 2016 22:41:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=Tjr8FlQzRj7Mgdc680RVEQZaGHKfgMYSBY8mAEEGbQg=; b=JPLoXUPYZeAAeuk55jieTaRKeENUWGcwYuWJMvNysfZOrnSg4AY75S75diaoro6OWv f4YjgvH0chYDhLKr5wz4dDxWMbUSTdSPBTEDxflcC01FarK7KO34V4nyfYzyA3grshjV /bVUKIeVBcGDUqDggWGdt6GdJfYfSD9k5/IrWZdQnX+39hF4AUoCc0GfBCqZ7idDHW27 E9xnuaXTug2mx7MP8a70YpZN0XSc24KjhQgs58MJHZSSz3Ggoy5wdSoMQLPTwkrLY2BK ABKsavPOd69BU+mRcW/1xEGyXnh9SRqC5asA7jt05zStv4cfoSPk6SOZJCu5yUPb/CwY Rvdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Tjr8FlQzRj7Mgdc680RVEQZaGHKfgMYSBY8mAEEGbQg=; b=VNS281Qkl6IpPobCZQQ8qOTVQyXwph1vGIkzHagq34jlG+0/XtDwCUTPDlXJ9XpwtT Skz1K0debtkFPG4JChVW44uIDid1WikKrWz4BPDC6HRtT0Vyv7ez2o08DhshOM9Lwr9l fTEpKHmVs1WffLmYyYcZHzqLfbvlwwgBh8dO8LtmBRSCHwUMS/VBpY/jKCcQB/be7Kki FG+ULeHJ1SEwQ4xop7dSOg5T1f+0TYjXY5PDAU+tGUACxPu6A1puDOucMV4fVv6YUXVo fxlTsENeH7hFCauA+r9J2FL6vyrPZME4FNslhMntD4b4qv4mt+XmSTuMrZYorjght4RX ZDjQ==
X-Gm-Message-State: ALyK8tLO6crJDMjLUTxWP6seKBS6Q7C72FM53FMIgV/mnDxCoDVlR4GT1DXy+VgdzVPEWkk72lAx/y/yb57MXw==
X-Received: by with SMTP id 139mr5524017vkg.33.1465191685407; Sun, 05 Jun 2016 22:41:25 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 5 Jun 2016 22:41:25 -0700 (PDT)
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Mon, 06 Jun 2016 01:41:25 -0400
Message-ID: <CA+YzgTvK7BbTzZ3jXavfAH=Q-mgcTNxsy8f0Sj6pP79rjZAm1w@mail.gmail.com>
To: draft-ietf-teas-te-metric-recording@ietf.org, "teas@ietf.org" <teas@ietf.org>
Content-Type: multipart/alternative; boundary="001a1143d506efc9e405349585f5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/EkvDNY0Sa4wUdlLYtg7fkNon0jA>
Subject: [Teas] <draft-ietf-teas-te-metric-recording-04>: Review
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jun 2016 05:41:32 -0000

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.

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:


- 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

- 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

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

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