Subject: [Idr] draft on "Tunnel Endpoints in BGP"

From: Paul Francis <[email-masked]>
Date: Tue, 28 Oct 2008 06:40:57 -0400

Gang,

Just wanted to point out the following draft, which basically provides an
optimization for stretch in virtual aggregation.  I suspect that this will
open a can of worms (either because folks hate inter-domain tunnels, or
because they like the idea but the scope of this is too narrow), but at least
want to have a discussion about it in Minn.  

PF

A new version of I-D, draft-xu-idr-tunnel-00.txt has been successfuly
submitted by Paul Francis and posted to the IETF repository.

Filename:        draft-xu-idr-tunnel
Revision:        00
Title:           Tunnel Endpoints in BGP
Creation_date:   2008-10-26
WG ID:           Independent Submission
Number_of_pages: 9

Abstract:
Virtual Aggregation (VA) is a mechanism for shrinking the size of the
DFZ FIB in routers [I-D.francis-idr-intra-va].  VA can result in
longer paths and increased load on routers within the ISP that
deploys VA.  This document describes a mechanism that allows an AS
that originates a route to associate a tunnel endpoint terminating at
itself with the route.  This allows routers in a remote AS to tunnel
packets to the originating AS.  If transit ASes between the remote AS
and the originating AS install the prefixes associated with tunnel
endpoints in their FIBs, then tunneled packets that transit through
them will take the shortest path.  This results in reduced load for
the transit AS, and better performance for the customers at the
source and destination.

The IETF Secretariat.
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Nathan Ward <[email-masked]>
Date: Wed, 29 Oct 2008 00:00:31 +1300

Paul,

I haven't read the draft, but this sounds like what I'm doing right  
now, except only for IPv6. I'll read the full draft and comment further.

If one uses BGP over 6to4 you get this effect. All that is required is  
to not modify next-hop when re-advertising prefixes.

6to4 get the destination IPv4 address from the next-hop address when  
the destination IPv6 address is not in 2002::/16 and the packet wants  
to go out the 6to4 interface. If I have a prefix in BGP with a next- 
hop of say 2002:102:304:: then the destination IPv4 address used to  
reach that prefix is 1.2.3.4.

<snip>
rs1.akl1.tui# sh ipv6 bgp 2402:6000::/32
BGP routing table entry for 2402:6000::/32
Paths: (2 available, best #2, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  2001:7fa:4:c0cb::9a03 2002:82d8:f616:: 2002:ca7c:73ec::  
2002:cb93:6d01::
  45163 18203
    2002:ca35:bce9:: from 2002:cb93:6d01:: (203.147.109.1)
      Origin IGP, localpref 100, valid, external
      Community: 24021:2 45163:2 45163:3
      Last update: Sat Oct 11 05:39:11 2008

  18203
    2002:ca35:bce9:: from 2002:ca35:bce9::1 (202.53.188.233)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: 24021:2 24021:3
      Last update: Sat Sep  6 12:50:34 2008
</snip>

IPv4 destination address for packets going to 2402:6000::/32 is  
202.53.188.233 (taken from 2002:ca35:bce9::1).

I've got this sort of overlay network going on that I'm calling "Tui".  
See http://www.braintrust.co.nz/tui/ for some sort of info about it.
Also Geoff wrote about it here: http://ispcolumn.isoc.org/2008-02/tui.html
It's useful for places where native IPv6 doesn't exist between  
everywhere, tunnels over long pipes are painful, maintaining a full  
mesh is hard, and central tunnel servers are costly for someone.

On 28/10/2008, at 11:40 PM, Paul Francis wrote:

>
>
> Gang,
>
> Just wanted to point out the following draft, which basically  
> provides an optimization for stretch in virtual aggregation.  I  
> suspect that this will open a can of worms (either because folks  
> hate inter-domain tunnels, or because they like the idea but the  
> scope of this is too narrow), but at least want to have a discussion  
> about it in Minn.
>
> PF
>
>
> A new version of I-D, draft-xu-idr-tunnel-00.txt has been  
> successfuly submitted by Paul Francis and posted to the IETF  
> repository.
>
> !DSPAM:22,4906ec4d299181117116800!
> !DSPAM:22,4906ec4d299181117116800!

--
Nathan Ward

--
Nathan Ward

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 28 Oct 2008 04:39:37 -0700

<adding Lixia & Enke>

Hi Paul/Xu ..

This draft is just a middle step to what I and Enke Chen have been 
working on few years back regarding tunneling to numerical equivalent of 
4 byte AS number IP address distributed as plain IPv4 address.

It is also an anycast address and each ASBR if before had advertised it 
can decapsulate packets to it and switch internally. It has a number of 
nice properties as ASBR failures are not fatal and can be repaired by 
closed by peering ASes. It also have the drawbacks of in the simple case 
of one IP address per as not flexible peering BGP TE.

I think this is important to take step back at this point as this is 
also very much along the lines of APT approach Lixia and her team from 
UCLA are driving into. IMHO this should be discussed at the next RRG 
meeting in MSP.

In other words we may be just approaching bigger fish to catch here ...

Cheers,
R.

> Gang,
> 
> Just wanted to point out the following draft, which basically provides 
> an optimization for stretch in virtual aggregation.  I suspect that this 
> will open a can of worms (either because folks hate inter-domain 
> tunnels, or because they like the idea but the scope of this is too 
> narrow), but at least want to have a discussion about it in Minn. 
> 
> PF
> 
> 
> ------------------------------------------------------------------------
>

---

From: Paul Francis <[email-masked]>
Date: Tue, 28 Oct 2008 09:09:40 -0400

I agree that there are bigger fish.  I kinda view this draft as a focused
statement about one specific need (more efficient paths for VA).  But we know
that there are a wider set of requirements.

In fact, we have also put together this draft:
http://tools.ietf.org/html/draft-francis-mapped-bgp-design-00.

I will be presenting Mapped-BGP at some length in the RRG meeting.  I had
thought about trying to present it at IDR, but I think it is premature.
Among other things we need to produce some numbers to back up our claims.
You'll note that that draft puts forth a solution to inter-AS traffic
engineering.  It also has something to say about aggregation.

My hope is that Mapped-BGP will appeal to some of the more conservative
elements of IDR, because it operates very much in the spirit of BGP, but
tries to make it more efficient.

If you think that IDR would be interested in seeing this work, I'll propose
that to Yakov and Sue.

PF

-----Original Message-----
From: Robert Raszuk [mailto:[email-masked]]
Sent: Tue 10/28/2008 7:39 AM
To: Paul Francis
Cc: [email-masked]; Lixia Zhang; Enke Chen
Subject: Re: [Idr] draft on "Tunnel Endpoints in BGP"
 
<adding Lixia & Enke>

Hi Paul/Xu ..

Cheers,
R.

---

From: Paul Francis <[email-masked]>
Date: Tue, 28 Oct 2008 09:15:43 -0400

By the way Robert, embedded in the Mapped-BGP document is the following text
about policies.  Do you think this is accurate?

   We can divide policies into two types: policies that act at the
   granularity of ASes, and those that act at the granularity of
   prefixes.  AS-level policies are preserved in Mapped-BGP, because
   these policies can be applied to TE-routes (of which there are,
   roughly, one per AS).  Indeed, AS-granularity policies become cheaper
   to enact, because there are fewer routes to deal with.  Examples of
   AS-based policies are: prefer routes to customers over other routes.
   Prefer routes to peers over routes to providers.  Do not export
   routes received from peers to non-customers.

   Most policies that act at the granularity of prefixes are for the
   purpose of traffic engineering.  There are a number of such examples.
   For instance, one ISP may give per-prefex MEDs to its neighbor in
   order to influence how packets enter each peering point.  This may be
   done either for the purpose of load balance, or in order to minimize
   the distance that packets need to travel within the receiving ISP.
   Likewise an ISP might set loc-prefs on a per prefix basis to
   influence the outgoing load on each peering point.  A multi-homed
   site might deaggregate its prefix, and then use community attributes
   offered by its provider to do per-prefix path prepending or route
   filtering to influence the load on its incoming access links.

PF

-----Original Message-----
From: Robert Raszuk [mailto:[email-masked]]
Sent: Tue 10/28/2008 7:39 AM
To: Paul Francis
Cc: [email-masked]; Lixia Zhang; Enke Chen
Subject: Re: [Idr] draft on "Tunnel Endpoints in BGP"
 
<adding Lixia & Enke>

Hi Paul/Xu ..

Cheers,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 28 Oct 2008 06:16:36 -0700

Hi Paul,

I see no harm in proposing this to IDR. In fact I see no harm in a lot 
of elements from RRG being reflushed by IDR to be accepted as wg docs or 
as BCP docs ...

To be very honest I think RRG is working on revolution. IMHO here we are 
just about to construct an evolution bridge. I am very happy that so 
many folks are seeing the same path now.

Let's work offline till MSP and try to iron down the ideas.

Cheers,
R.

> I agree that there are bigger fish.  I kinda view this draft as a focused statement about one specific need (more efficient paths for VA).  But we know that there are a wider set of requirements.
> 
> In fact, we have also put together this draft:  http://tools.ietf.org/html/draft-francis-mapped-bgp-design-00.
> 
> I will be presenting Mapped-BGP at some length in the RRG meeting.  I had thought about trying to present it at IDR, but I think it is premature.  Among other things we need to produce some numbers to back up our claims.  You'll note that that draft puts forth a solution to inter-AS traffic engineering.  It also has something to say about aggregation.
> 
> My hope is that Mapped-BGP will appeal to some of the more conservative elements of IDR, because it operates very much in the spirit of BGP, but tries to make it more efficient.
> 
> If you think that IDR would be interested in seeing this work, I'll propose that to Yakov and Sue.
> 
> PF
> 
> 
> 
>

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 28 Oct 2008 15:13:32 +0100

Paul,

> I agree that there are bigger fish.  I kinda view this draft as a
> focused statement about one specific need (more efficient paths for
> VA).  But we know that there are a wider set of requirements.
> 
> I will be presenting Mapped-BGP at some length in the RRG meeting.  I
> had thought about trying to present it at IDR, but I think it is
> premature.  Among other things we need to produce some numbers to back
> up our claims.  You'll note that that draft puts forth a solution to
> inter-AS traffic engineering.  It also has something to say about
> aggregation.

I hope to find time to read mapped BGP this week, but in the mean time
you might be interested by the BGP-based tunneling technique that we
developped a few years ago. Our simulations showed the benefits of using
interdomain tunnels from a traffic engineering viewpoint. They might
apply to your solution as well.

B. Quoitin and O. Bonaventure.  A Cooperative Approach to Interdomain
Traffic Engineering. 1st Conference on Next Generation Internet Networks
Traffic Engineering (NGI 2005), Rome, Italy, April 18-20th 2005.
http://inl.info.ucl.ac.be/publications/cooperative-approach-interdomain-traf

Olivier

-- 
http://inl.info.ucl.ac.be , UCLouvain, Belgium
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Paul Francis <[email-masked]>
Date: Tue, 28 Oct 2008 10:27:39 -0400

Certainly looks relevent.  Sorry about not being familiar with this work...it
probalby could have been referenced in the 2006 CRIO paper (among others).
I'll have a look later this week.

PF

-----Original Message-----
From: Olivier Bonaventure [mailto:[email-masked]]
Sent: Tue 10/28/2008 10:13 AM
To: Paul Francis
Cc: [email-masked]; [email-masked]; Lixia Zhang; Bruno Quoitin
Subject: Re: [Idr] draft on "Tunnel Endpoints in BGP"
 
Paul,

Olivier