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

From: Lixia Zhang <[email-masked]>
Date: Sun, 2 Nov 2008 09:44:50 -0800

On Oct 28, 2008, at 4:39 AM, Robert Raszuk wrote:

> <adding Lixia & Enke>

thanks for that, Robert.
catching up email after a very looooong trip

> 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.

- The APT team is a collaboration among Memphis, CSU, Arizona and UCLA
- Robert is exactly right that APT team has been looking into this  
direction for an evolution path towards controllable BGP table/ 
dynamics growth

In fact after some discussions with Hitesh Ballani (Paul's student)  
Dan Jen (APT team) derived further development along this direction.

> IMHO this should be discussed at the next RRG meeting in MSP.

Yes, RRG has allocated one-hour slot for Paul.
The APT team originally planned on an RRG presentation about Dan Jen's  
results; now we'll collaborate/coordinate with all and see how best to  
proceed.

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

agree.

Lixia

>> 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

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

---

From: Lixia Zhang <[email-masked]>
Date: Sun, 2 Nov 2008 10:04:13 -0800

On Oct 28, 2008, at 6:16 AM, Robert Raszuk wrote:

> 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.

that's a very precise statement.

sorry to spam IDR list for this (though I assume many people here are  
also on RRG list): the solution direction that got more attraction  
than others in RRG is map-and-encap.  APT is one design in that  
direction, LISP is another, and much better known:-)

Over the last year or so, and inspired by Paul Francis work (started  
with CRIO, then virtual aggregation), we saw the light that map-n- 
encap does not have to be mapping space A to space B.  Look, the basic  
goal is to control the routing table growth, so map-n-encap should  
really be about mapping a big table to a smaller one, so that the  
latter can be used for routing.
This way of thinking opens an evolutionary path to roll out map-n-encap.

> I am very happy that so many folks are seeing the same path now.

I am even happier :-)

> 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
>> -----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 ..
>> 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.
>> from
>> UCLA are driving into. IMHO this should be discussed at the next RRG
>> meeting in MSP.
>> Cheers,
>> R.

---

From: Lixia Zhang <[email-masked]>
Date: Sun, 2 Nov 2008 11:16:18 -0800

On Oct 28, 2008, at 6:15 AM, Paul Francis wrote:
> 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
>
The above sounds accurate to me.

and the APT team holds the same view: we believed that the mapping  
function does not affect the BGP routing policy (in the terminology,  
the AS-granularity policies), and can support prefix-granularity  
policies in an explicit way (than what can be done with the current  
BGP routing, through specific declarations associated with each  
mapping entry). But draft-jen-apt-01 (section 7.1) did not manage to  
state it clearly.

Lixia
> it
> can decapsulate packets to it and switch internally. It has a number  
> of
> also very much along the lines of APT approach Lixia and her team from
> 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
> >
> >
> successfuly
> > submitted by Paul Francis and posted to the IETF repository.
> >
> > The IETF Secretariat.