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

John E Drake <jdrake@juniper.net> Tue, 04 November 2014 14:34 UTC

Return-Path: <jdrake@juniper.net>
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 C3D171A888D for <ospf@ietfa.amsl.com>; Tue, 4 Nov 2014 06:34:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 19TZNqtgrQEl for <ospf@ietfa.amsl.com>; Tue, 4 Nov 2014 06:34:04 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0127.outbound.protection.outlook.com [207.46.100.127]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 258D31A88DB for <ospf@ietf.org>; Tue, 4 Nov 2014 06:34:03 -0800 (PST)
Received: from BLUPR05MB561.namprd05.prod.outlook.com (10.141.202.139) by BLUPR05MB499.namprd05.prod.outlook.com (10.141.29.22) with Microsoft SMTP Server (TLS) id 15.1.11.14; Tue, 4 Nov 2014 14:34:02 +0000
Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB561.namprd05.prod.outlook.com (10.141.202.139) with Microsoft SMTP Server (TLS) id 15.1.11.14; Tue, 4 Nov 2014 14:34:00 +0000
Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.01.0011.000; Tue, 4 Nov 2014 14:34:00 +0000
From: John E Drake <jdrake@juniper.net>
To: "Acee Lindem (acee)" <acee@cisco.com>, "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: AQHP1kwRt2W4kADXMU+3Wez32PlegZwzN9QAgB2RjpA=
Date: Tue, 4 Nov 2014 14:34:00 +0000
Message-ID: <9cf84f74ab614b9e81f1ca4107b31be9@BLUPR05MB562.namprd05.prod.outlook.com>
References: <D041E4D5.3539%acee@cisco.com> <23CE718903A838468A8B325B80962F9B865FACE0@szxeml556-mbs.china.huawei.com> <D0658BA1.567F%acee@cisco.com>
In-Reply-To: <D0658BA1.567F%acee@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [66.129.241.14]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB561;UriScan:;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 03853D523D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(53754006)(377454003)(479174003)(199003)(13464003)(189002)(164054003)(51704005)(37854004)(24454002)(99286002)(19580395003)(20776003)(107046002)(40100003)(64706001)(106356001)(105586002)(62966003)(106116001)(76576001)(66066001)(95666004)(19580405001)(31966008)(33646002)(92566001)(15975445006)(86362001)(230783001)(108616004)(122556002)(99396003)(54356999)(97736003)(2656002)(50986999)(87936001)(21056001)(15202345003)(46102003)(74316001)(76176999)(101416001)(120916001)(4396001)(77156002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB561; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB499;
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/EwvWgxkfaElqM03F-U2DV_uoyJw
Cc: OSPF WG List <ospf@ietf.org>
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: Tue, 04 Nov 2014 14:34:06 -0000

Comments inline

Yours Irrespectively,

John

> -----Original Message-----
> From: Acee Lindem (acee) [mailto:acee@cisco.com]
> Sent: Thursday, October 16, 2014 11:52 AM
> To: draft-ietf-ospf-te-metric-extensions@tools.ietf.org
> Cc: Dhruv Dhody; 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)
> 
> Authors,
> Can we get these issues taken care of in the version which will go through the
> next phase of reviews?
> Thanks,
> Acee
> 
> On 9/22/14, 5:59 AM, "Dhruv Dhody" <dhruv.dhody@huawei.com> 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.

[JD]  Okay 

> >
> >(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.

[JD]  Why? 

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

[JD]  I will delete the reference to RFC 6375 

> >
> >(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.
> >

[JD]  Okay 

> >(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.

[JD]  Okay 

> >
> >(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.

[JD]  Okay

> >
> >(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.

[JD]  Okay  

> >
> >(8) Sec 12. IANA Considerations
> >This section needs updating with the list of the TLVs

[JD]  Okay

> >
> >(9) A reference to RFC5392 for Inter-AS-TE-v2 LSA should be added to
> >avoid any confusion to the reader..

[JD]  I don't see any reason to put in a plug for this particular RFC

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

[JD]   Okay

> >
> >Regards,
> >Dhruv
> >