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

[Lixia Zhang <[e-mail]>]

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
> -----Original Message-----
> From: Robert Raszuk [mailto:[e-mail]]
> Sent: Tue 10/28/2008 7:39 AM
> To: Paul Francis
> Cc: [e-mail]; Lixia Zhang; Enke Chen
> Subject: Re: [Idr] draft on "Tunnel Endpoints in BGP"
>
> <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
> >
> >
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/idr
>
>

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