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

Karsten Thomann <karsten_thomann@linfre.de> Fri, 19 September 2014 19:36 UTC

Return-Path: <karsten_thomann@linfre.de>
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 316731A8858 for <ospf@ietfa.amsl.com>; Fri, 19 Sep 2014 12:36:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.203
X-Spam-Level:
X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, 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 2coM7Qt1AARh for <ospf@ietfa.amsl.com>; Fri, 19 Sep 2014 12:36:13 -0700 (PDT)
Received: from linfre.de (linfre.de [83.151.26.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF1D41A8888 for <ospf@ietf.org>; Fri, 19 Sep 2014 12:36:12 -0700 (PDT)
Received: from linne.localnet (91.97.111.198) by linfreserv.linfre (Axigen) with (AES256-SHA encrypted) ESMTPSA id 123184; Fri, 19 Sep 2014 21:36:01 +0200
From: Karsten Thomann <karsten_thomann@linfre.de>
To: ospf@ietf.org
Date: Fri, 19 Sep 2014 21:39:14 +0200
Message-ID: <17006974.MxzxdFyur2@linne>
User-Agent: KMail/4.10.4 (Windows/6.1; KDE/4.10.4; i686; ; )
In-Reply-To: <D041E4D5.3539%acee@cisco.com>
References: <D041E4D5.3539%acee@cisco.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="nextPart1592451.5Z32k3EgWx"
Content-Transfer-Encoding: 7Bit
X-AXIGEN-DK-Result: No records
DomainKey-Status: no signature
X-AxigenSpam-Level: 6
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/6PQNPASsNZk301f-DBbSIvxUj2k
Cc: "draft-ietf-ospf-te-metric-extensions@tools.ietf.org" <draft-ietf-ospf-te-metric-extensions@tools.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: Fri, 19 Sep 2014 19:36:15 -0000

Some Comments
- I personally don't like the word Anomalous Bit, I prefer something like Exceeded Bit
- why are some Sub TLVs are stated as do not send when not measured and others are set to all 
1's when not measured? Section 8 requires that every sub-TLV can be enabled and disabled 
individually.


Section 4.2
In my opinion the A bit should exist for the Min Delay and Max Delay Value and not only combined 
for both values, if not splitted to two Sub-TLV as there can be cases where a min delay must be 
met and others where there a max delay which should not be exeeded.

Section 4.7
"The bandwidth utilization advertised by this sub-TLV MUST be the bandwidth from the system 
originating this Sub-TLV."

I would like to change it to something like:
The bandwidth advertised by this sub-TLV MUST be the bandwidth utilization from the system 
originating this Sub-TLV.

Section 6
   Only the accelerated advertisement threshold mechanism described in
   section 6 may shorten the re-advertisement interval.

the mechanism is described in Section 5

Regards
Karsten


Am Freitag, 19. September 2014, 17:49:10 schrieb Acee Lindem:


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[1]/


Thanks,
Acee and Abhay 





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