Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-link-overload-03.txt

Karsten Thomann <karsten_thomann@linfre.de> Wed, 15 February 2017 20:01 UTC

Return-Path: <karsten_thomann@linfre.de>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA23129AA9 for <ospf@ietfa.amsl.com>; Wed, 15 Feb 2017 12:01:08 -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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 tB_tyRnRsAyL for <ospf@ietfa.amsl.com>; Wed, 15 Feb 2017 12:01:07 -0800 (PST)
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 158C7129A9C for <ospf@ietf.org>; Wed, 15 Feb 2017 12:01:00 -0800 (PST)
Received: from linne.localnet (85.16.192.70) by linfreserv (Axigen) with (ECDHE-RSA-AES256-SHA encrypted) ESMTPSA id 210D79; Wed, 15 Feb 2017 21:00:52 +0100
From: Karsten Thomann <karsten_thomann@linfre.de>
To: ospf@ietf.org
Message-ID: <4365704.q9EF1xarLV@linne>
User-Agent: KMail/4.13.0.22 (Windows/6.1; KDE/4.14.3; i686; git-c97962a; 2016-07-14)
In-Reply-To: <BN3PR05MB2706EA303194E3C9D6FB6BCBD5580@BN3PR05MB2706.namprd05.prod.outlook.com>
References: <148696612940.6290.973095830249984185.idtracker@ietfa.amsl.com> <BN3PR05MB2706EA303194E3C9D6FB6BCBD5580@BN3PR05MB2706.namprd05.prod.outlook.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
X-AXIGEN-DK-Result: No records
DomainKey-Status: no signature
X-AxigenSpam-Level: 7
Date: Wed, 15 Feb 2017 12:01:00 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/BY7PFkQ2J5hmYpteT1TWsfKEZiQ>
Subject: Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-link-overload-03.txt
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 15 Feb 2017 20:01:09 -0000

Hi Shraddha,

I have some typos and comments...

3.1 [RFC7684] . (space before the point)
3.2 Section 4.The (two missing spaces)
3.2 ipv4 address.The (two missing spaces)
4.2 for OSPFv3.  or in (I think it should be a comma)
5 identified in by (would delete "in")
6 compatible.It is
6 applicable.  .
7.1 directions.The link 
7.2 each link.The
7.2 capacity.  and 


Generally I would clean up the used version of some words as there are many 
different versions like:
Sub-TLV, sub-tlv, sub-TLV
link-overload, Link overload, link overload
ipv4, IP4, IPv4

Reference to I-D.ietf-ospf-ospfv3-lsa-extend should be updated to latest 
version.

Is there a reason why the text for MAX-TE-METRIC wasn't repeated in 5.3?

The section 7.1 isn't really clear, at least for me, as it sounds like that 
the service provider is signaling something within the customers L2 circuit.

Regards
Karsten


Am Dienstag, 14. Februar 2017, 03:34:25 schrieb Shraddha Hegde:
> Hi All,
> 
> New version of the ospf-link-overload draft is submitted and has below
> changes
> > Area level link-overload sub-TLV reverted back to extended link opaque
> > LSA.
> > minor editorial corrections.
> 
> Let me know if you have any comments.
> 
> Rgds
> Shraddha
> 
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Monday, February 13, 2017 11:39 AM
> To: Shraddha Hegde <shraddha@juniper.net>; Pushpasis Sarkar
> <pushpasis.ietf@gmail.com>; Mohan Nanduri <mnanduri@microsoft.com>; Hannes
> Gredler <hannes@gredler.at>; Luay Jalil <luay.jalil@verizon.com> Subject:
> New Version Notification for draft-ietf-ospf-link-overload-03.txt
> 
> 
> A new version of I-D, draft-ietf-ospf-link-overload-03.txt
> has been successfully submitted by Shraddha Hegde and posted to the IETF
> repository.
> 
> Name:		draft-ietf-ospf-link-overload
> Revision:	03
> Title:		OSPF Link Overload
> Document date:	2017-02-12
> Group:		ospf
> Pages:		11
> URL:           
> https://www.ietf.org/internet-drafts/draft-ietf-ospf-link-overload-03.txt
> Status:        
> https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/ Htmlized:  
>     https://tools.ietf.org/html/draft-ietf-ospf-link-overload-03 Diff:     
>      https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-link-overload-03
> 
> Abstract:
>    When a link is being prepared to be taken out of service, the traffic
>    needs to be diverted from both ends of the link.  Increasing the
>    metric to the highest metric on one side of the link is not
>    sufficient to divert the traffic flowing in the other direction.
> 
>    It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be
>    able to advertise a link being in an overload state to indicate
>    impending maintenance activity on the link.  This information can be
>    used by the network devices to re-route the traffic effectively.
> 
>    This document describes the protocol extensions to disseminate link
>    overload information in OSPFv2 and OSPFv3.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf