Re: Ideas for IPv6 BGP and tunnelling

Robert Raszuk <robert@raszuk.net> Sat, 25 April 2009 08:31 UTC

Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C10013A6A39 for <ietfarch-v6ops-archive@core3.amsl.com>; Sat, 25 Apr 2009 01:31:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.197
X-Spam-Level:
X-Spam-Status: No, score=-1.197 tagged_above=-999 required=5 tests=[AWL=-1.302, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.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 3gvjuqsYCsPF for <ietfarch-v6ops-archive@core3.amsl.com>; Sat, 25 Apr 2009 01:31:08 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B4F663A6A9A for <v6ops-archive@lists.ietf.org>; Sat, 25 Apr 2009 01:30:45 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1LxdDf-000PYW-Hf for v6ops-data0@psg.com; Sat, 25 Apr 2009 08:26:43 +0000
Received: from [76.162.254.37] (helo=mail37.opentransfer.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from <robert@raszuk.net>) id 1LxdDT-000PX8-7K for v6ops@ops.ietf.org; Sat, 25 Apr 2009 08:26:37 +0000
Received: (qmail 7153 invoked by uid 399); 25 Apr 2009 08:26:29 -0000
Received: from unknown (HELO ?192.168.1.53?) (83.24.15.30) by mail37.opentransfer.com with SMTP; 25 Apr 2009 08:26:29 -0000
Message-ID: <49F2C930.5050205@raszuk.net>
Date: Sat, 25 Apr 2009 01:26:24 -0700
From: Robert Raszuk <robert@raszuk.net>
Reply-To: robert@raszuk.net
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: Eric Levy-Abegnoli <elevyabe@cisco.com>, Ole Troan <otroan@employees.org>, IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: Ideas for IPv6 BGP and tunnelling
References: <20090422020001.5A1013A6FF2@core3.amsl.com> <49EE7DC1.2090008@gmail.com> <49EF1EF8.1090206@spaghetti.zurich.ibm.com> <49EF91AC.1080308@gmail.com> <49EFEB97.8040807@mesh.ad.jp> <49F0396E.1040608@aaisp.net.uk> <alpine.BSF.2.00.0904231235460.48529@mignon.ki.iif.hu> <49F04E93.8090905@aaisp.net.uk> <alpine.LRH.2.00.0904231507420.32331@netcore.fi> <2bbba3c10904230602p44df97cfl5f5cb2c48a496364@mail.gmail.com> <49F0FAD0.2050605@gmail.com> <49F17DB4.60909@cisco.com> <49F22434.3080300@gmail.com>
In-Reply-To: <49F22434.3080300@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Hi Brian,

>> That sort of became RFC4798, with focus on MPLS tunnelling
> 
> Exactly; the non-MPLS methods were thrown away, although they
> seem to be completely valid. Why isn't there an informational
> or BCP RFC describing them? 

I am not sure if they were thrown away. RFC4798 cames from L3VPN 
paradigm and is sort of additional plug in for interconnect IPv6 islands 
over IPv4 core.

And since it is very much based on 2547/4364 any transport which applies 
to this would also apply to 4798. For example 
draft-ietf-l3vpn-gre-ip-2547-05 defines IP tunneling support.

Of course some vendors support automated multipoint GRE technic where 
your encapsulation header is automatically learned from BGP next hops 
allowing for very easy IP tunneling. For those vendors the very same 
functionality could be used for RFC4798.

 > It really seems like a gap.

I agree with you 100%. Unfortunately for some people dreaming about 
world of MPLS only core routers which are not able to route/switch even 
single IP packet this would be not a gap but a great feature :).

Cheers,
R.