Re: [Idr] draft-uttaro-idr-add-paths-guidelines-02

Uli Bornhauser <ub@cs.uni-bonn.de> Thu, 29 July 2010 14:04 UTC

Return-Path: <ub@cs.uni-bonn.de>
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4241528C0EC for <idr@core3.amsl.com>; Thu, 29 Jul 2010 07:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.835
X-Spam-Level:
X-Spam-Status: No, score=-3.835 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 xwICCwPnb6d7 for <idr@core3.amsl.com>; Thu, 29 Jul 2010 07:04:50 -0700 (PDT)
Received: from postfix.iai.uni-bonn.de (postfix.iai.uni-bonn.de [131.220.8.4]) by core3.amsl.com (Postfix) with ESMTP id 95C3B3A6901 for <idr@ietf.org>; Thu, 29 Jul 2010 07:04:49 -0700 (PDT)
X-IAI-Env-From: <ub@cs.uni-bonn.de> : [130.129.133.238]
Received: from dhcp-85ee.meeting.ietf.org (dhcp-85ee.meeting.ietf.org [130.129.133.238]) by postfix.iai.uni-bonn.de (Postfix) with ESMTP id 6F5335C82C; Thu, 29 Jul 2010 16:05:12 +0200 (MEST) (envelope-from ub@cs.uni-bonn.de) (envelope-to VARIOUS) (4) (internal use: ta=1, tu=1, te=1, am=P, au=ub)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Uli Bornhauser <ub@cs.uni-bonn.de>
In-Reply-To: <4C4D4AA4.2040300@uclouvain.be>
Date: Thu, 29 Jul 2010 16:05:11 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6F6ABF42-6845-48FE-9717-A1DEE2EC443F@cs.uni-bonn.de>
References: <4C4D4AA4.2040300@uclouvain.be>
To: pierre.francois@uclouvain.be
X-Mailer: Apple Mail (2.1081)
Cc: Inter-Domain Routing List <idr@ietf.org>, Martin Horneffer <Martin.Horneffer@telekom.de>
Subject: Re: [Idr] draft-uttaro-idr-add-paths-guidelines-02
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Jul 2010 14:04:52 -0000

Hi Pierre, all,

as we discussed yesterday, my thoughts and remarks with respect to the draft version:

In section 4.2, the authors mention that receiving multiple paths improves convergence (cf. MED/IGP oscillation section) and Expressiveness (cf. Path optimality section). At this point, you could also mention that path diversity generally improves the consistency. As far as I see, this pro-argument is not covered by the remarks.

With respect to the Path Selection Modes, cf. section 4.3.1: After reading the draft, it seems reasonable to say that the mode described in section 4.3.1.5,

"Advertising Neighbor-AS Group Best Path", is a natural generalization of the common best path advertisement to all neighbor-AS groups.

From my point of view, exchanging best external paths between domains as described in [1] is also a very interesting concept. As this document is a work group draft, I assume that I am not the only one who things so. Similar to the scheme described in section 4.3.1.5., from my point of view, it seems reasonable to generalize the concept of advertising best external paths to all neighbor-AS groups. I.e., I think an interesting path selection mode could be 

"Advertising Neighbor-AS Group Best External Path". Analogously to 4.3.1.5, this could be understood as a generalization of the best external path advertisement scheme [1] to all neighbor-AS groups. According to the draft, the basic idea is simple. Using this scheme, "a speaker"

- advertises its best domain external path for each neighbor-AS group into the own domain, and
- advertises its best domain internal path for each neighbor-AS group to the external domains.

As thoroughly described in [1], a domain can be a Route Reflection cluster (in this case "the speaker" is a RR) or the AS (in that case "the speaker" is an ASBR). This concept would combine the advantages of advertising best external paths and the availability of group best paths. Comments to this idea are of course welcome. I something did not become clear, feel free to ask.

All in all, I think that besides the one scheme I mentioned, the draft covers all important and interesting modes that can be to applied upon add-path. So far, a very good and substantial work.

Best Regards

Uli

[1] http://tools.ietf.org/id/draft-ietf-idr-best-external-01.txt

Am 26.07.2010 um 10:43 schrieb Pierre Francois:

> 
> 
> Hi,
> 
> For those who are impatient to read the latest version of the add-paths-guidelines draft, and couldn't find it :
> 
> http://inl.info.ucl.ac.be/system/files/draft-uttaro-idr-add-paths-guidelines-02.txt
> 
> Regards,
> 
> Pierre.
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

-- 
_______________________________________________________
ULI BORNHAUSER
University of Bonn - Institute of Computer Science IV
c/o Bonn-Aachen International Center for Information Technology B-IT 
Dahlmannstr. 2 - D-53113 Bonn - Germany

Web: www.cs.bonn.edu/IV/ub
Email: ub@cs.uni-bonn.de			
Phone: +49 (228) 2699-154
Fax: +49 (228) 73 - 4571