Subject: RE: Please comment draft-kulmala-l3vpn-aggregation-pe-00

From: "Kulmala, Marko" <[email-masked]>
Date: Fri, 25 Feb 2005 11:20:22 +0200

Ron,

The fundamental difference between aggregation PE and option B is that
with option B ASBR advertises routes from Loc-RIB to other AS, while in
aggregation PE(A-PE) routes are advertised from VRF. In other words
option B extends LSPs from original PEs to other AS without knowledge of
relationships between routes. Aggregation PE advertises VRF tables to
other AS, and hence A-PE has knowledge of VRF associations of the routes
and breaks the (conceptual) LSP.

In control plane this is purely change in the RFC2547bis advertisement
algorithm -- BGP line protocol is not modified.

Aggregation PE does not necessarily have to change data plane forwarding
(although routes might of course be selected differently). However to
gain maximum advantage of this method, A-PE will propably handle packets
with more behaviour than with simple SWAP -- now that VPN association of
the packets is known, more complex QoS and PSN tunnel selection methods
can be performed on per packet basis.

Example:

     PE 1 ------+     RD 5:5   RD 6:6
                +-----ASBR1----ASBR2---PE 3
     PE 2 ------+

If routing table is:
    PE1 1:1:1.2.3.4/32
        1:1:5.6.7.8/32
    PE2 2:2:1.2.3.4/32
        2:2:9.10.11.12/32
    ASBR1 
        1:1:1.2.3.4/32
        1:1:5.6.7.8/32
        2:2:1.2.3.4/32
        2:2:9.10.11.12/32

In option B ASBR2 would have identical routing table with ASBR1
(assuming no filtering takes place). This allows PE3 to see each route
in original as they are, but from ASBR1 point of view all of the routes
are unrelated LSPs and there is no way to do VPN specific behaviour.

When acting as Aggregation PE ASBR1 imports routes to VRF. Lets assume
that all of the above routes are part of one VPN (simple example,
obviously there are multiple VRFs in each ASBR, each which can import
multiple route targets):

    ASBR1 VRF 1
        1:1:1.2.3.4/32
        1:1:5.6.7.8/32
        2:2:9.10.11.12/32

ASBR2 now sees exported routes from VRF
        5:5:1.2.3.4/32
        5:5:5.6.7.8/32
        5:5:9.10.11.12/32

And PE3 sees same (with RD 6:6).

Now ASBR1 can do VPN specific handling of forwarded packets (as
association is known). Also more information about AS1 has been hidden
as each VPN has been "collapsed" to minimum set of routes. If there were
another connection between ASs, it would be possible to to load
balancing, as it would be possible to assign RD per ASBR (instead of per
origin PE).

So this difference in behaviuour allows the advantages (versus opt B)
described in my earlier mail.

Marko 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Ronald Bonica
> Sent: 24. helmikuuta 2005 18:20
> To: Kulmala, Marko
> Cc: [email-masked]
> Subject: Re: Please comment draft-kulmala-l3vpn-aggregation-pe-00
> 
> Marko,
> 
> I am not clear on the difference between your proposal and 
> interprovider 
>    Option B. In your proposal, if I were to monitor the link 
> between ASBR's what would I see on the forwarding plane? On 
> the control plane? 
> How would that be different from interprovider Option B?
> 
>                                     (as individual contributor)
>                                        Ron
> 
> 
> Kulmala, Marko wrote:
> > Hi,
> >  
> > We have submitted
> > 
> http://www.ietf.org/internet-drafts/draft-kulmala-l3vpn-aggreg
> ation-pe-00.txt.
> >  
> > This proposal defines a new way to implement inter-as MPLS 
> VPNs. The 
> > method resembles a hybdrid of RFC2547bis ch 10 option A and 
> B (more B 
> > than A). This proposal allows easy and secure way to 
> partition access 
> > networks in separate AS. Partitioning access networks removes full 
> > mesh LSP requirement and allows partitioning IGP without losing 
> > capability for end-to-end TE.  Another good thing regarding 
> security 
> > is that implicit RT filtering is provided by configured VRF.
> >  
> > One application for this is to build IP/MPLS regional 
> networks pretty 
> > much in analogous way than with H-VPLS. In that application 
> there are 
> > many benefits compared to option B:
> > 
> >>  - Hides core network structure (RTs and RDs)
> >> -  Per VPN QoS handling is possible
> >> - Per VPN aggregation is possible
> >> - Per VPN filtering is possible
> >> - Per VPN PSN tunnel selection is possible (e.g. separate 
> some VPNs 
> >> to separate RSVP tunnels in access, and use LDP in core) 
> -End to end 
> >> traffic engrineering is possible, even when access networks are in 
> >> separate IGP areas (and reduced number of LSPs allows 
> using RSVP-TE 
> >> without unresonable overhead).
> > 
> > All comments are appreciated.
> >  
> > Best Regards,
> > Marko Kulmala
> > 
> >>  
> >> "Abstract
> >>
> >>    This document describes operation of aggregation PE and 
> applications
> >>    for it.
> >>
> >>    Aggregation PE installs VPN-IPv4 routes into VRFs and 
> acts as BGP
> >>    next hop when it readvertises VPN-IPv4 routes with 
> MP-BGP to other
> >>    PE routers. This eliminates the need to LSP 
> connectivity (or some
> >>    other type of tunnels) between packet's ingress and egress PE. 
> >>    
> >>    Aggregation PE function can be used in multi AS 
> backbones. If routing
> >>    peering between the ASes is done between aggregation PE 
> routers then
> >>    ingress PE in one AS does not need to know reachability 
> information
> >>    to egress PE in other AS. Security is enhanced because no LSP is
> >>    needed between packet's ingress and egress PEs.
> >>
> >>    Another application for aggregation PE is the support 
> of distinct
> >>    IP/MPLS regional networks. It enables access network to 
> be separate
> >>    area or domain which makes the network more scalable. "
> >>  
> > 
> > 
> > ============================================================
> > The information contained in this message may be privileged and 
> > confidential and protected from disclosure. If the reader of this 
> > message is not the intended recipient, or an employee or agent 
> > responsible for delivering this message to the intended 
> recipient, you 
> > are hereby notified that any reproduction, dissemination or 
> > distribution of this communication is strictly prohibited. 
> If you have 
> > received this communication in error, please notify us 
> immediately by 
> > replying to the message and deleting it from your computer. 
> Thank you. 
> > Tellabs ============================================================
> 
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================

---

From: Pedro Roque Marques <[email-masked]>
Date: Fri, 25 Feb 2005 15:28:12 -0800

Marko Kulmala writes:

> Ron, The fundamental difference between aggregation PE and option B
> is that with option B ASBR advertises routes from Loc-RIB to other
> AS, while in aggregation PE(A-PE) routes are advertised from VRF.

So you do path selection without the RD... but you can achieve this
with option B simply by configuring the same RD in the PE VRFs that
you wish to be eligible for path selection.

Are you claiming that there is a sustantial problem w/ coordinating RD
assignment that it justifies developping an entire new
"rd-aggregation" mechanism ? Or do you have some other motivation ?

It is not clear to me what the application is. It would be nice if you
could elaborate on this a bit.

In fact, i'm more used to hearing service providers concerned about
the inverse problem: making sure that RD assingment is different so
that they can have visibility for multiple alternative path for the
same IP prefix.

regards,
  Pedro.