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

From: "Kulmala, Marko" <[email-masked]>
Date: Tue, 1 Mar 2005 21:31:08 +0200

Pedro,

See my comments inline.

Marko 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Pedro Roque Marques
> Sent: 26. helmikuuta 2005 1:28
> To: Kulmala, Marko
> Cc: [email-masked]
> Subject: RE: Please comment draft-kulmala-l3vpn-aggregation-pe-00
> 
> 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.

In Aggregation PE concept path selection is done in normal manner to the
routes that are imported to the VRFs.
The RD will change when the route is re-advertised. Note that the routes
that are imported into VRF can be received either as normal IPv4 routes
or as VPN-IPv4 routes. Route selection is done at VRF context. This can
not be achieved just by RD assignment plan.

> 
> Are you claiming that there is a sustantial problem w/ 
> coordinating RD assignment that it justifies developping an 
> entire new "rd-aggregation" mechanism ? 

I guess that coordinating RDs would come tricky as well. But as stated
above proper RD assingment does not do the same thing. 

> Or do you have some other motivation ?

The motivation are the applications that are outlined in the draft.
Operator can use this as their inter provider solution and this give
some benefits over option B: RT filtering is done by configured VRFs,
loadbalancing (see below). Another application is to use this within
operators network in analogous way as H-VPLS. MPLS network is utilized
in access/regional network. There can be router with VRFs closer to the
customer and it has MP-eBGP session and mpls connectivity to the PE
router that acts as aggregation PE. That PE router can also have
attachment circuits from L2 access to VRFs. Path selection is done in
VRF context. The PE hides the fact of the mpls access from other PEs
around the core.

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

See above. One application is to support mpls access/regional networks
when providing RFC2547bis services. 

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

Aggregation PE concept solves one of the problems. If two operators, A
and B, have two points of connection (ASBR A1
connected to ASBR B1 and ASBR A2 connected to ASBR B2) then by using
option B packets' ingress PE router will get only one of the route
advertisements since the RD is the same and RR will drop one of the
routes.
When using aggregation PE function and assigning different RDs to VRFs
at ASBR1 and ASBR2 then RR will readvertise
both routes and packets' ingress PE router gets visibility to these two
connections between operators. This makes loadbalansing possible as
well.

> regards,
>   Pedro.
============================================================
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: "jguichar" <[email-masked]>
Date: Tue, 1 Mar 2005 15:00:07 -0500

Marko,

Please see my comments inline ..
 
> > > while in aggregation PE(A-PE) routes are advertised from VRF.

This is also the case for option A InterAS so I guess the main difference is
that you re-advertise the routes as VPNv4 routes rather than IPv4 - is this
correct ?
 
> Operator can use this as their inter provider solution and 
> this give some benefits over option B: RT filtering is done 
> by configured VRFs, loadbalancing (see below). Another 
> application is to use this within operators network in 
> analogous way as H-VPLS. MPLS network is utilized in 
> access/regional network. There can be router with VRFs closer 
> to the customer and it has MP-eBGP session and mpls 
> connectivity to the PE router that acts as aggregation PE. 
> That PE router can also have attachment circuits from L2 
> access to VRFs. Path selection is done in VRF context. The PE 
> hides the fact of the mpls access from other PEs around the core.

We went through this a couple of years ago with the HOPE submission. There
are a number of issues with this approach that really have not changed. 
 
> 
> Aggregation PE concept solves one of the problems. If two 
> operators, A and B, have two points of connection (ASBR A1 
> connected to ASBR B1 and ASBR A2 connected to ASBR B2) then 
> by using option B packets' ingress PE router will get only 
> one of the route advertisements since the RD is the same and 
> RR will drop one of the routes.
> When using aggregation PE function and assigning different 
> RDs to VRFs at ASBR1 and ASBR2 then RR will readvertise both 
> routes and packets' ingress PE router gets visibility to 
> these two connections between operators. This makes 
> loadbalansing possible as well.

So does rewriting the RD at the boundary but this may not be the optimal way
to deal with the loadbalancing issue.

Regards, Jim

> 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: Tue, 1 Mar 2005 12:11:27 -0800

Marko Kulmala writes:

> In Aggregation PE concept path selection is done in normal manner to
> the routes that are imported to the VRFs.  The RD will change when
> the route is re-advertised. Note that the routes that are imported
> into VRF can be received either as normal IPv4 routes or as VPN-IPv4
> routes.

Both your comments and the draft give me the impression that you
intend to (re)advertise PE-received routes to other PEs via iBGP. That
would defeat the current loop avoidance mechanism (split horizon
torwards VPN ibgp).

> Route selection is done at VRF context. This can not be
> achieved just by RD assignment plan.

I'm sorry, but i don't quite understand why readvertising routes post VRF
path selection is an advantage. Can you please elaborate ?

> some benefits over option B: RT filtering is done by configured
> VRFs

This is an advantage ? i would assume it would be a drawback.

>, loadbalancing (see below). Another application is to use this
> within operators network in analogous way as H-VPLS. MPLS network is
> utilized in access/regional network. There can be router with VRFs
> closer to the customer and it has MP-eBGP session and mpls

On the access/regional scenarion it is not clear to me what is being
aggregated... if you where proposing an IP lookup on the VRF (a scheme
which some networks use) in order to avoid advertising all the VRF
routes downstream, i would understand it. But the way i read your
draft, you are still propagating all routes and doing a labeled switch
decision.

So what are you aggregating on the access / regional context ?

The diagram that you include in the draft is equivalent to using same
RD on all PEs and configuring what you call "aggregation PEs" as RRs
torwards the "PE close to the customer site". i.e. this is what route
reflection does, by default.

Howeveer, typically in a VPN context the number of multiple alternate
paths to the same prefix tends to be small compared to the total
number of prefixes.

> See above. One application is to support mpls access/regional
> networks when providing RFC2547bis services.

We should compare the advantages of your proposal vs existing
mechanisms. at the moment it is not clear to me what those are, in
this scenario.

> Aggregation PE concept solves one of the problems. If two operators,
> A and B, have two points of connection (ASBR A1 connected to ASBR B1
> and ASBR A2 connected to ASBR B2) then by using option B packets'
> ingress PE router will get only one of the route advertisements
> since the RD is the same and RR will drop one of the routes.

Yes this is a problem when the network uses RRs that have a different
view of the network topology than their rr-clients. imho, a reason not
to deploy RRs in such a way... but i'm sure others will differ.

However the same issue could be addressed via RD-rewrite inbound on
the network which design imposes such requirement.

  Pedro.

---

From: Ville Hallivuori <[email-masked]>
Date: Wed, 2 Mar 2005 00:12:30 +0200

> would defeat the current loop avoidance mechanism (split horizon

Normal AS-path loop detection mechanism should ensure that no loops
are created. 

Also in most of our scenarios we have configured PEs in
access networks not to re-advertised eBGP learned routes to iBGP
neighbours (although this is purely a performance optimisation -- 
on smaller access networks there is no need to RR, so all PEs in
access networks are usually ASBRs).

> path selection is an advantage. Can you please elaborate ?

Because this allows ASBR to perform per VRF operations, such as PSN
tunnel selection and aggregation (via routing lookup for forwarded
packets).

It is not possible to configure per-VRF "things" (instructions for PSN
tunnel selection, QoS parameters, etc) in option B ASBR, as same
RD-prefix pair can belong to multiple VRFs (and hence there is no
unique VRF to associate it with... with our option each route is
advertised per VRF, and hence unique association is available).

Because all VPN routes have VRF associations, we can accomplish
end-to-end traffic engineering for VPN routes without inter-area TE
extensions -- PSN tunnels do not exceed area boundaries (link
ASBR->access network belongs to access network IGP) and PSN tunnel
selection can be done per VRF basis in N-PE.

> draft, you are still propagating all routes and doing a labeled switch

We do not require in our draft support for IP lookup for forwarded
packets (allows route aggregation), however it is indeed beneficial,
as it allows aggregation. In our implementation we have support for IP
lookup for packets forwarded using this proposal. Aggregation is not
specified in this draft, because it is part of normal BGP policy
mechanism that implementation may support.

> So what are you aggregating on the access / regional context ?

VPN routes can be aggregated. However number of routes is not the
primary issues we are trying to solve with this draft -- we are trying
to reduce number of PSN tunnels. While LDP can handle almost unlimited
number of PSN tunnels, if operator wants to use traffic engineering
(with L-LSPs or separating sets of VPNs to separate PSN tunnels so
that there is more than one pair of tunnels between PEs) number of
tunnels grows quickly to such height that use of RSVP-TE is no longer
reasonable. By introducing hierarchy this proposal reduces number of
peering PEs (directly or via RR) and hence reduces number of LSPs
needed.

Reduced number of LSPs allows using granular traffic engineering with
RSVP-TE in much larger networks than is currently possible.

-- 
[Ville Hallivuori][[email-masked]][http://www.iki.fi/vph/]
[ID 8E1AD461][FP16=C9 50 E2 DF 48 F6 33 62  5D 87 47 9D 3F 2B 07 5D]
[ID 58543419][FP20=8731 941D 15AB D4A0 88A0  FC8F B55C F4C4 5854 3419]
[ID 8061C24E][FP20=C722 12DA 841E D811 DBFE  2FB3 174C E291 8061 C24E]

---

From: Pedro Roque Marques <[email-masked]>
Date: Tue, 1 Mar 2005 14:53:42 -0800

> tunnel selection and aggregation (via routing lookup for forwarded

The draft gives the impression that you are doing a label switch
decision. You are saying that you are doing an IP fowarding
decision...

could you please clarify the fowarding decision that you propose ?

> It is not possible to configure per-VRF "things" (instructions for
> PSN tunnel selection, QoS parameters, etc) in option B ASBR

i'm sorry but i'm going to have to diagree w/ you here.

At least w/ JunOS implementation, you can configure a PE, such
that it behaves as an option B asbr but it is able to do per VRF
forwarding decisions, including an IP based lookup.

I suspect other implementations also have such extensions. The model
for interoperability is option B... but that model allows for
implementation specific extensions that achieve, imho, the
functionality you are asking for.

>, as same

> selection can be done per VRF basis in N-PE.

All this you can do withing the option B framework, w/o the need to
rewrite the RD or to create any sort of protocol extensions.

> as it allows aggregation.

Without an IP lookup, where is the aggregation ? You call your
proposal "aggregation PE". So, far the only difference i see compared
to option B is the rewriting of RDs... the IP lookup, which we agree
can provide aggregation, has been implemented also in option B and
route reflection.

> VPN routes can be aggregated.

Please define aggregation. what does it mean for you ?

does it mean 

1. if
    10.0.1/24	from a igp distance 20
    10.0.1/24   from b igp distance 10
   then
    select path b only

2. if
    10.0.1/24
    10.0.1/30
   then
    advertise less specific only.

or something else maybe ?

> However number of routes is not the
> primary issues we are trying to solve with this draft -- we are
> trying to reduce number of PSN tunnels. While LDP can handle almost
> unlimited number of PSN tunnels, if operator wants to use traffic
> engineering (with L-LSPs or separating sets of VPNs to separate PSN
> tunnels so that there is more than one pair of tunnels between PEs)
> number of tunnels grows quickly to such height that use of RSVP-TE
> is no longer reasonable. By introducing hierarchy this proposal
> reduces number of peering PEs (directly or via RR) and hence reduces
> number of LSPs needed.

> Reduced number of LSPs allows using granular traffic engineering
> with RSVP-TE in much larger networks than is currently possible.

that is all good. but you don't need to create a new mechanism for
that. route reflection or option already have the ability to do
"next-hop self". that would seem to satisfy your requirement above.

  Pedro.

---

From: Ville Hallivuori <[email-masked]>
Date: Wed, 2 Mar 2005 01:36:23 +0200

> could you please clarify the fowarding decision that you propose ?

The draft allows both (to ensure that all routers can implement
it). However IP forwarding decision is better way to do it, as it
allows aggregation. Other (than route aggregation) benefits of the
draft can be achieved with label switching.

> functionality you are asking for.

Option B does not work in this case. Lets take an example:
       ASBR receives:
		1:1:1.2.3.4/32 RT 1:1

This route is imported at the router behind ASBR to two VRFs. Lets
assume that these VRFs are configured to use different PSN tunnels.

With our proposal routes could be re-advertise routes from ASBR as:
		2:2:1.2.3.4/32 RT 2:2
		3:2:1.2.3.4/32 RT 3:3

ASBR can now differentiate between packets to 1.2.3.4 from VRFs 1 and
2 and for example select different PSN tunnel for them.

With option B ASBR would advertise
		1:1:1.2.3.4/32 RT 1:1

and would hence be unable to select correct tunnel based on VRF.

Unless JunOS allows duplicating same route, with different RD/RTs (and
advertised label), you can not choose different forwarding behaviour
for different VRFs -- all VRFs that import RT 1:1 would get same
forwarding behaviour (the fact that you can rewrite RD and RT does not
change this).

> rewrite the RD or to create any sort of protocol extensions.

See the above example. Without re-writing RD you can not handle the
case where same route is imported to multiple VRFs (and per VRF
specific behaviour is required for the route). 

> can provide aggregation, has been implemented also in option B and

Perhaps the aggregation PE is a poor choice of a name. The aggregation
refers to the reduction of number of LSPs that is archived using this
draft to introduce a hierarchy to the networ.

Option B is not used by this proposal, because it would not allow VPN
specific traffic engineering.

> "next-hop self". that would seem to satisfy your requirement above.

Your nexhop-self works correctly, only if:
     -Forwarding behaviour for same route (RD:prefix) is same for all
      VRFs
   OR
     -Multiple VRFs do not import same route

See the example above. So our proposal is needed if hierarchy is
introduced and other than the trivial case of VPNs is used.

---

From: Pedro Roque Marques <[email-masked]>
Date: Tue, 1 Mar 2005 16:16:41 -0800

> draft can be achieved with label switching.

Ok, so it is not a misrepresentation to say that (aggregation == IP
forwarding decision). w/o that... you get a PE that does an RD
rewrite, but no aggregration.

> Option B does not work in this case. Lets take an example: ASBR
> receives: 1:1:1.2.3.4/32 RT 1:1

> 2:2:1.2.3.4/32 RT 2:2 3:2:1.2.3.4/32 RT 3:3

> ASBR can now differentiate between packets to 1.2.3.4 from VRFs 1
> and 2 and for example select different PSN tunnel for them.

Indeed. We agree that your proposal can do that... and the method i
described can't.

But what are the semantics of doing so ? i.e. why is this
functionality important and why is it important to acomplish it this
way.

First of all, i hope we agree that we are not talking about the common
case, which we should be optimizing for.

I assume the semantics you are looking for is something like:
from set of customers A, traffic to this destination, is treated
differently than traffic for same destination for set of customers B.
Agree ?

This can easily be achieve today, by having the ingress PE advertise
this same route with two different RDs from two different VRFs, or by
doing source address based classification at the ASBR.

> With option B ASBR would advertise 1:1:1.2.3.4/32 RT 1:1

> Unless JunOS allows duplicating same route, with different RD/RTs
> (and advertised label),

It does, at the originator.

> you can not choose different forwarding
> behaviour for different VRFs -- all VRFs that import RT 1:1 would
> get same forwarding behaviour (the fact that you can rewrite RD and
> RT does not change this).

> specific behaviour is required for the route).

I agree that having multiple routes for the same "egress" allows you
to play w/ packets a bit. But to me that doesn't really imply that we
should do this de-aggregation in the middle of the network.

> Perhaps the aggregation PE is a poor choice of a name. The
> aggregation refers to the reduction of number of LSPs that is
> archived using this draft to introduce a hierarchy to the networ.

That is orthogonal to "aggregation" and "de-aggregation"
(i.e. RD-rewrite). That you get from the ability to stich LSP via BGP
"next-hop self".

> Option B is not used by this proposal, because it would not allow
> VPN specific traffic engineering.

I beg to differ on this one.

> Your nexhop-self works correctly, only if: -Forwarding behaviour for
> same route (RD:prefix) is same for all VRFs OR -Multiple VRFs do not
> import same route

Or if the forwarding behaviour can be determined by:
  - destination (egress CE/prefix)
  - an and optional classification policy, such as IP DSCP, IP source
address, etc.

The latter is rather common place.

Additionally one can "de-aggregate" the prefix being advertised at the
originator, rather than to do so the way you propose via RD rewrite in
the middle of the network.

> introduced and other than the trivial case of VPNs is used.

mho is that we already have 2 frameworks for this sort of
functionality: route reflection and option B. There are some
interesting ideas in your proposal, but i'd try to encorage you to
incorporate them in the existing models, rather than create yet
another model.

For instance, within a network of the same administrative auth
(i.e. what you call the access network scenarion), i believe there are
disadvantages in using ebgp (and path preprending) vs route
reflection.

And from an operation point of view, will you have the requirement to
modify the configuration on the ASBRs whenever a VRF is added on a PE
?

In a previous exchange it seemed to me that the answer is "yes" and
this was being considered a feature. That may be considered
undesirable by some operators.

  Pedro.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 02 Mar 2005 09:58:20 -0800

Hi Ville,

> With our proposal routes could be re-advertise routes from ASBR as:

So among other things indicated in your draft you are adding the ability 
to modify RDs as well as RTs there. I must say that to do such a thing 
on the ASBRs (or for that matter anywhere else then on the sender) is a 
VERY BAD IDEA.

Operationally it is hard as now you not only need to worry about
import/export (which alone is in many cases is already complex) but also 
consequences of modify action in some mid point on a per VPN prefix 
granularity.

As an alternative you can mark routes with BGP communities and use that 
on the receivers for your tunnel selection or anything else one may wish.

Thx,
R.