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

"Acee Lindem (acee)" <> Thu, 16 October 2014 18:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8E17B1A871D for <>; Thu, 16 Oct 2014 11:51:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id df4m4_jKst85 for <>; Thu, 16 Oct 2014 11:51:37 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AAA2F1A8710 for <>; Thu, 16 Oct 2014 11:51:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4118; q=dns/txt; s=iport; t=1413485497; x=1414695097; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=w2UUlrGQl+hfybbVlYILgwuzQ7a8kPcXTeVAYl48YZg=; b=l1GW9X9P9mxIPDzvCRbMw6BQwcEYnLnyGH9DGZ7FuqNaj+HA7W8wypTW ixHXN2gYbpWSMiNdQwr1e4nGulRj7xrX7CYronsQrHsCyrSSqpF95O+Bu QGXroPvl6uC5Dyi8GAFWHJCf4WAjjqOp/irciOhGYTlKThFNECAkcOq99 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.04,733,1406592000"; d="scan'208";a="87585372"
Received: from ([]) by with ESMTP; 16 Oct 2014 18:51:36 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s9GIpam6001727 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Oct 2014 18:51:36 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 13:51:36 -0500
From: "Acee Lindem (acee)" <>
To: "" <>
Thread-Topic: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)
Thread-Index: AQHP6XI2Sx7MTStSfESS4x/G82JLsw==
Date: Thu, 16 Oct 2014 18:51:36 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: 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)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Oct 2014 18:51:41 -0000

Can we get these issues taken care of in the version which will go through
the next phase of reviews?

On 9/22/14, 5:59 AM, "Dhruv Dhody" <> 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.
>(2) A reference to PCE should also be added along with the mention of
>ALTO server. See 
>In fact the steps mentioned for the ingress in section 3 are applicable
>for a stateful PCE as well.
>(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].
>(4) Suggested change to add delay variation and to update packet-loss to
>just say percentage (the unit).
>   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.
>   Delay and delay variation values MUST be quantified in units of
>   packet loss MUST be quantified as a percentage, and
>   bandwidth MUST be sent as bytes per second.
>(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.
>(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.
>(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.
>(8) Sec 12. IANA Considerations
>This section needs updating with the list of the TLVs
>(9) A reference to RFC5392 for Inter-AS-TE-v2 LSA should be added to
>avoid any confusion to the reader..
>- 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 
>From: OSPF [] On Behalf Of Acee Lindem (acee)
>Sent: 20 September 2014 01:49
>To: OSPF WG List;
>Subject: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE)
>Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)
>After more than 3 years of discussion and revision, the chairs feel that
>we are ready for a WG last call on the OSPF TE Metric extensions. While
>it is only one piece of an end-to-end delay/loss aware routing solution,
>we believe that the draft, as scoped, is ready. The WG last call will end
>at 12:00 AM PDT on Oct 4th, 2014. For your convenience, here is a URL:
>Acee and Abhay