RE: Last Call: <draft-ietf-ospf-te-metric-extensions-08.txt> (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard
"Adrian Farrel" <adrian@olddog.co.uk> Wed, 10 December 2014 23:07 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92CB81A1AB6; Wed, 10 Dec 2014 15:07:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 qY04OJYicWlM; Wed, 10 Dec 2014 15:07:17 -0800 (PST)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B37351A1A99; Wed, 10 Dec 2014 15:07:16 -0800 (PST)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBAN7Ea8027624; Wed, 10 Dec 2014 23:07:14 GMT
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBAN7DLQ027612 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2014 23:07:14 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org
Subject: RE: Last Call: <draft-ietf-ospf-te-metric-extensions-08.txt> (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard
Date: Wed, 10 Dec 2014 23:07:08 -0000
Message-ID: <018b01d014ce$06215290$1263f7b0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdAUzgRtbjhNr7FGTP+6Nt7S5T90Cg==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21168.000
X-TM-AS-Result: No--10.997-10.0-31-10
X-imss-scan-details: No--10.997-10.0-31-10
X-TMASE-MatchedRID: hls5oAVArl8zx9GDMr0HvzYTypjB3iDVuikHZcC6ceATVJPv0YKEKViN xVLlNmEJqfCLrIKbnQdeB/1Ewo8I25SL8e/MGApZvHKClHGjjr3MmaoHJ8BpLRjQD3m2MCf7nCV oYY7P13c/OKf/TcIu01Go54/BITPFjl2kmBb+Ta8a9NdQGl95NtSqEluSYtV7CqIJhrrDy29HZG kGAQcl8zOeKJ9f2YhH9jZuJ+IsfxALe4e10OySpeLdprnA5EQRhQaFqMRElgk5yqWxi+AoVa0Ro mhWPJaQZkLhmTuGQ/W0Bgm0CXGm5o9oUcx9VMLgOX/V8P8ail3Yr6U3ZlQkdsRB0bsfrpPIfiAq rjYtFiTv2VzAWQ7VszqymjNMJTnLvannU3YcsfNsR/KkA6+ocn7cGd19dSFd
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/xtGeoGC_FJR-pnN4RfZ9P5AhsFs
Cc: ospf@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Dec 2014 23:07:21 -0000
All, I reviewed this document as AD and found a few small points that I have asked the authors to address as IETF last call comments. Adrian === Please look for places where you have "proposed" something and change that to "defined". --- It would be good to include a reference for encoding floating point integers. The usual is (I think)... IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", Standard 754-1985, 1985 (ISBN 1-5593-7653-8). --- Section 4.2.5 Implementations MAY also permit the configuration of a static (non dynamic) offset value (in microseconds) to be added to the measured delay value, to facilitate the communication of operator specific delay constraints. On the third reading I got it! I'm slow (I have a high delay :-) The point here is that the measured value and the static value are added together and the sum is transmitted in this field. I'd suggest... Implementations MAY also permit the configuration of a static (non dynamic) offset value (in microseconds) to be added to the measured delay value before encoding into this TLV, to facilitate the communication of operator specific delay constraints. Similarly in 4.2.6. --- 4.2.7 appears out of sequence. But since it repeats the content of 4.2.4 I suggest you merge them and talk about the plurality of fields. --- Section 7 "Sections 6 and 7 provide" should be 5 and 6. --- Section 10 "As per (RFC3630), unrecognized TLVs should be silently ignored" There has been confusion about what 3630 means by "silently ignored". In particular, some enthusiastic implementations thought this meant the TLVs should be stripped from the LSA before it is propagated. I think it is worth the few words to explicitly state that this is not the case. --- Section 13 RFC 4203 is used in a normative way, please move it to the other section.
- RE: Last Call: <draft-ietf-ospf-te-metric-extensi… Adrian Farrel
- Re: Last Call: <draft-ietf-ospf-te-metric-extensi… t.p.
- RE: Last Call: <draft-ietf-ospf-te-metric-extensi… Adrian Farrel
- Re: Last Call: <draft-ietf-ospf-te-metric-extensi… Acee Lindem (acee)
- Re: Last Call: <draft-ietf-ospf-te-metric-extensi… Randy Presuhn
- RE: Last Call: <draft-ietf-ospf-te-metric-extensi… Adrian Farrel
- Re: Last Call: <draft-ietf-ospf-te-metric-extensi… Acee Lindem (acee)
- Re: Last Call: <draft-ietf-ospf-te-metric-extensi… t.p.
- Re: Last Call: <draft-ietf-ospf-te-metric-extensi… Acee Lindem (acee)