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

Dhruv Dhody <dhruv.dhody@huawei.com> Mon, 22 September 2014 10:00 UTC

Return-Path: <dhruv.dhody@huawei.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639F61A1A92 for <ospf@ietfa.amsl.com>; Mon, 22 Sep 2014 03:00:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.287
X-Spam-Level:
X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xRKZyO7ercy for <ospf@ietfa.amsl.com>; Mon, 22 Sep 2014 03:00:31 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84AD41A1A91 for <ospf@ietf.org>; Mon, 22 Sep 2014 03:00:31 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJS10837; Mon, 22 Sep 2014 10:00:29 +0000 (GMT)
Received: from SZXEML457-HUB.china.huawei.com (10.82.67.200) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 22 Sep 2014 10:59:52 +0100
Received: from szxeml556-mbs.china.huawei.com ([169.254.4.112]) by szxeml457-hub.china.huawei.com ([10.82.67.200]) with mapi id 14.03.0158.001; Mon, 22 Sep 2014 17:59:45 +0800
From: Dhruv Dhody <dhruv.dhody@huawei.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, OSPF WG List <ospf@ietf.org>, "draft-ietf-ospf-te-metric-extensions@tools.ietf.org" <draft-ietf-ospf-te-metric-extensions@tools.ietf.org>
Thread-Topic: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)
Thread-Index: AQHP1DIEHMSGequlDk2aRIP+ttVfipwM3iIg
Date: Mon, 22 Sep 2014 09:59:44 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B865FACE0@szxeml556-mbs.china.huawei.com>
References: <D041E4D5.3539%acee@cisco.com>
In-Reply-To: <D041E4D5.3539%acee@cisco.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.146.248]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/a9oPhRscdohXgEoDA6i9_kkKzmM
Subject: Re: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Sep 2014 10:00:33 -0000

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 http://datatracker.ietf.org/doc/draft-ietf-pce-pcep-service-aware/
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).  
OLD:
   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.
NEW:
   Delay and delay variation values MUST be quantified in units of microseconds,
   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.. 

Nits
- 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 

Regards,
Dhruv
 
From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: 20 September 2014 01:49
To: OSPF WG List; draft-ietf-ospf-te-metric-extensions@tools.ietf.org
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: 

https://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions/

Thanks,
Acee and Abhay