Re: Working Group Last Call for draft-ietf-rtgwg-lf-conv-frmwk-03
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Working Group Last Call for draft-ietf-rtgwg-lf-conv-frmwk-03



John G. Scudder wrote:
Folks,

This is to begin working group last call for draft-ietf-rtgwg-lf-conv-frmwk-03, " Framework for Loop-free Convergence". Please send comments by December 12, 2008.

Thanks,

--John
_______________________________________________
rtgwg mailing list
rtgwg at ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

John,

I have received some comments regarding draft-ietf-rtgwg-lf-conv-frmwk

1. The draft gives the impression that a fast reroute protection solution only makes sense if a micro-loop avoidance techFrom rtgwg-bounces at ietf.org Fri Dec 12 07:00:50 2008
Return-Path: <rtgwg-bounces at ietf.org>
X-Original-To: rtgwg-archive at optimus.ietf.org
Delivered-To: ietfarch-rtgwg-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id BDB2828C12E;
	Fri, 12 Dec 2008 07:00:50 -0800 (PST)
X-Original-To: rtgwg at core3.amsl.com
Delivered-To: rtgwg at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 977C83A6B1B
	for <rtgwg at core3.amsl.com>; Fri, 12 Dec 2008 07:00:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id Dew+-JAK-Yqs for <rtgwg at core3.amsl.com>;
	Fri, 12 Dec 2008 07:00:48 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140])
	by core3.amsl.com (Postfix) with ESMTP id 572BD3A6B06
	for <rtgwg at ietf.org>; Fri, 12 Dec 2008 07:00:48 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.36,211,1228089600"; d="scan'208";a="28479820"
Received: from ams-dkim-2.cisco.com ([144.254.224.139])
	by ams-iport-1.cisco.com with ESMTP; 12 Dec 2008 15:00:40 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150])
by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBCF0e3N015129; Fri, 12 Dec 2008 16:00:40 +0100
Received: from [10.61.107.199] (dhcp-10-61-107-199.cisco.com [10.61.107.199])
	by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBCF0e8r014179;
	Fri, 12 Dec 2008 15:00:40 GMT
Message-ID: <49427C96.5040103 at cisco.com>
Date: Fri, 12 Dec 2008 15:00:38 +0000
From: mike shand <mshand at cisco.com>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: "John G. Scudder" <jgs at juniper.net>
Subject: Re: Working Group Last Call for draft-ietf-rtgwg-lf-conv-frmwk-03
References: <6591EC15-DC09-4C4D-935B-119BB89DD819 at juniper.net>
In-Reply-To: <6591EC15-DC09-4C4D-935B-119BB89DD819 at juniper.net>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1377; t=1229094040;
	x=1229958040; c=relaxed/simple; s=amsdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=mshand at cisco.com;
	z=From:=20mike=20shand=20<mshand at cisco.com>
	|Subject:=20Re=3A=20Working=20Group=20Last=20Call=20for=20d
	raft-ietf-rtgwg-lf-conv-frmwk-03 |Sender:=20;
	bh=ryzrvQn+n2JMm0MxXGlcVnmhuyIfSbqJb9NmuhAiWP4=;
	b=VieIkGE6jrciwyhigWvjLgVxUJNu9jrEAFNQmi6SLBcDjZjpGiiVtkABmT
	4gGVI+tlUV0UzYeCilk5EYKGtZFEOoXayY/TBkqslpkO8Vbz6YZYrTQRJ3ts
	lWxE8rKrVT;
Authentication-Results: ams-dkim-2; header.From=mshand at cisco.com; dkim=pass (
sig from cisco.com/amsdkim2001 verified; ); Cc: rtgwg at ietf.org
X-BeenThere: rtgwg at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>,
	<mailto:rtgwg-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtgwg>
List-Post: <mailto:rtgwg at ietf.org>
List-Help: <mailto:rtgwg-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>,
	<mailto:rtgwg-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: rtgwg-bounces at ietf.org
Errors-To: rtgwg-bounces at ietf.org

John G. Scudder wrote:
Folks,

This is to begin working group last call for draft-ietf-rtgwg-lf-conv-frmwk-03, " Framework for Loop-free Convergence". Please send comments by December 12, 2008.

Thanks,

--John
_______________________________________________
rtgwg mailing list
rtgwg at ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

John,

I have received some comments regarding draft-ietf-rtgwg-lf-conv-frmwk

1. The draft gives the impression that a fast reroute protection solution only makes sense if a micro-loop avoidance technique isnique is also deployed. There are cases, for example in highly meshed networks, where the incidence of micro-loops is very low, or even non-existent. The draft should make it clear that in those cases IPFRR can be deployed without a micro-loop avoidance technique.

2. The draft does not list improvements to the speed of conventional re-convergence as a valuable micro-loop mitigation technique. By reducing the duration of micro-loops it reduces their impact. It should be added to the list of mitigation techniques.

3. The draft does not mention that using a full mesh MPLS FRR is another method of avoiding microloops.


These all look like reasonable improvements to the document. We'll generate some suitable text and produced a revised version.

   Mike
_______________________________________________
rtgwg mailing list
rtgwg at ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg


also deployed. There are cases, for example in highly meshed networks, where the incidence of micro-loops is very low, or even non-existent. The draft should make it clear that in those cases IPFRR can be deployed without a micro-loop avoidance technique.

2. The draft does not list improvements to the speed of conventional re-convergence as a valuable micro-loop mitigation technique. By reducing the duration of micro-loops it reduces their impact. It should be added to the list of mitigation techniques.

3. The draft does not mention that using a full mesh MPLS FRR is another method of avoiding microloops.


These all look like reasonable improvements to the document. We'll generate some suitable text and produced a revised version.

   Mike
_______________________________________________
rtgwg mailing list
rtgwg at ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.