Re: [renum] I-D Action:draft-boot-brdp-framework-00.txt

Teco Boot <teco@inf-net.nl> Mon, 21 February 2011 12:30 UTC

Return-Path: <teco@inf-net.nl>
X-Original-To: renum@core3.amsl.com
Delivered-To: renum@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ED453A70EE for <renum@core3.amsl.com>; Mon, 21 Feb 2011 04:30:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 Mtucx7XomjMz for <renum@core3.amsl.com>; Mon, 21 Feb 2011 04:30:07 -0800 (PST)
Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by core3.amsl.com (Postfix) with ESMTP id E98F13A70EA for <renum@ietf.org>; Mon, 21 Feb 2011 04:30:06 -0800 (PST)
Received: by eyg7 with SMTP id 7so566670eyg.27 for <renum@ietf.org>; Mon, 21 Feb 2011 04:30:48 -0800 (PST)
Received: by 10.14.22.80 with SMTP id s56mr1490349ees.6.1298291447774; Mon, 21 Feb 2011 04:30:47 -0800 (PST)
Received: from [172.16.4.187] ([188.205.88.52]) by mx.google.com with ESMTPS id t50sm4861201eeh.0.2011.02.21.04.30.45 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Feb 2011 04:30:46 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Teco Boot <teco@inf-net.nl>
In-Reply-To: <4D603810.3060003@gmail.com>
Date: Mon, 21 Feb 2011 13:30:44 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8B648CB6-A134-47F1-85E2-838D1B79DD1E@inf-net.nl>
References: <20110131123001.9503.36699.idtracker@localhost> <4D603810.3060003@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1082)
Cc: renum@ietf.org, draft-boot-brdp-framework@tools.ietf.org
Subject: Re: [renum] I-D Action:draft-boot-brdp-framework-00.txt
X-BeenThere: renum@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Renumbering discussion mailing list." <renum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/renum>, <mailto:renum-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/renum>
List-Post: <mailto:renum@ietf.org>
List-Help: <mailto:renum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/renum>, <mailto:renum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Feb 2011 12:30:08 -0000

Hi Brian,

Op 19 feb 2011, om 22:37 heeft Brian E Carpenter het volgende geschreven:

> Hi,
> 
> I had a quick look at this interesting proposal. As far as the RENUM
> BOF goes, I think it is just a point of information as we really don't
> expect to discuss solutions in Prague. But it's a very interesting
> approach to the problem. A couple of general questions:
> 
> How does this relate to the techniques in draft-v6ops-multihoming-without-nat66?
This work also includes scenarios and problem statement. It is highly related. BRDP is defined for multi-hop edge networks, particularly MANETs. So the scenario's do differ somewhat.

Source address selection and next-hop selection is addressed by BRDP. I assume DNS server selection is addressed by MIF.

I think requirements for policy enforcement can be implemented in the BRDP Framework. I'll wait on what Fred Baker brings in. 

On solutions, IMHO BRDP differs from other proposals. It suggests a cooperation between hosts and routers. Hosts may select any address it has configured, routers direct sent packets to gateways that corresponds to the source address. Routers provide hints for address and next-hop selection. This enables powerful tools like MPTCP, for all scenario's in draft-v6ops-multihoming-without-nat66.
Maybe add the BRDP approach in this document?
[Fred has also ideas, with similar approach. Not written down yet. Correct?]


> Will it work OK with NPTv6 (draft-mrw-nat66, which is not about NAT66)?
It is OK when Border Routers uses NPTv6.
BRDP suggests a prefix per border router. This brings MPTCP, guidance for DNS server selection etc. But needs modified routers, and evolutionary updated hosts for full functionality.
NPTv6 is based on GSE, so same family as ILNP. I'll include NPTv6 in a next version.


> Is there any prototype code?
In simulation. 
Intentions to have running code, for the MANET case.


Thanks, Teco
  
> 
> Regards
>   Brian Carpenter
> 
> On 2011-02-01 01:30, Internet-Drafts@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> 
>> 	Title           : BRDP Framework
>> 	Author(s)       : T. Boot, A. Holtzer
>> 	Filename        : draft-boot-brdp-framework-00.txt
>> 	Pages           : 24
>> 	Date            : 2011-01-31
>> 
>> This document describes the Border Router Discovery Protocol (BRDP)
>> framework.  This framework enables multi-homing for small to medium
>> sites, using Provider Aggregatable IPv6 addresses.  It describes a
>> mechanism for automated IP address configuration and renumbering, a
>> mechanism for optimized source address selection and a new paradigm
>> for packet forwarding.  The BRDP framework prevents ingress filtering
>> problems with multi-homed sites and supports load-balancing for
>> multi-path transport protocols.  This work also prevents routing
>> scalability problems in the provider network and Internet Default
>> Free Zone because small to medium multi-homed size sites would not
>> need to request Provider Independent address blocks.
>> 
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-boot-brdp-framework-00.txt
> _______________________________________________
> renum mailing list
> renum@ietf.org
> https://www.ietf.org/mailman/listinfo/renum