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

From: "Kulmala, Marko" <[email-masked]>
Date: Wed, 2 Mar 2005 16:50:48 +0200

Pedro,

See comments inline.

Regards,
Marko

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Pedro Roque Marques
> Sent: 2. maaliskuuta 2005 2:17
> To: [email-masked]
> Cc: Kulmala, Marko; [email-masked]
> Subject: Re: Please comment draft-kulmala-l3vpn-aggregation-pe-00
> 
> Ville Hallivuori writes:
> 
> > 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.
> 
> 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
> 
> > 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.
> 
> 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.

This is one example of the functionality that is achievable with this
concept.
The concept is pretty straightforward: We propose that we go to IP layer
at the ASBR and still utilize mpls between ASBRs. There are other things
(not yet mentioned) that are achievable: gathering traffic statistic per
VPN at ASBR, IP level ACLs per VPN at ASBR. 

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

You may be able to solve one of the application examples like this,
although to me it does not sound very easy. 

> 
> > 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),
> 
> 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).
> 
> > 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).
> 
> 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.
> 
> > See the example above. So our proposal is needed if hierarchy is 
> > 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.

New model is not our target. 
But we like to have the solution where MPLS domains are clearly
separated.
And I think that conceptually this requires IP layer at ASBR. 
Our proposal works with option B; ASBR in one AS acts as we propose and
neighboring ASBR according to option B.
Could this be introduced as variant to option B ?

> 
> 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 this respect ASBR is pretty much like any other PE. If you create new
VPN to the network, you need to create supporting VRF.

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

We are not claiming that there are no disadvatages compared to any other
options or solutions.
Having the VRF gives features, but yes, you have to pay little for it.

>   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: Pedro Roque Marques <[email-masked]>
Date: Wed, 2 Mar 2005 12:25:47 -0800

Marko Kulmala writes:

> This is one example of the functionality that is achievable with
> this concept.  The concept is pretty straightforward: We propose
> that we go to IP layer at the ASBR and still utilize mpls between
> ASBRs. There are other things (not yet mentioned) that are
> achievable: gathering traffic statistic per VPN at ASBR, IP level
> ACLs per VPN at ASBR.

Marko,
I think we need to disentangle several aspects being discussed.

There are several topics in this discussion, some of them are
orthogonal.

Let me try to make a list... please correct me if there is something
we wish to add.

a) IP forwarding lookup on an ASBR or route reflector.
b) RT re-write.
c) RD re-write.
d) "spliting" a prefix, so that it gets advertised w/ 2 different RDs
and RT sets.
e) advertising to ebgp post vrf path selection (?)

a) gives you most of the features you quote above: possibility to
suppress more specific routes to downstream peers; IP level
(re)classification and accounting, etc.

As i mentioned previously, it can be implemented as a implementation
extension on top of option B (or route reflection). In a transparent
way. This is also the bit that imposes higher costs in terms of
management.

I think we agree that this can be useful. I just believe it need not
be standardized.

b) & c) can be achieved in several different ways... specially RD
rewrite can be tricky regarding diagnostics.

d) can be done either at the originator (another extension is current
implementations) or in the middle of the network as you propose.

But the stuff that really makes me uneasy is e), specially when
combined w/ an RD rewrite. i don't think this is a necessary part of a
solution, in my mind it breaks the current option B model and it can
be tricky. For instance, one has to be really careful to assume that a
PE-received route doesn't end up getting reflected back to the ibgp
mesh after its RD is modified.

imho a) though d) can be implemented as implementation extensions on
top of an option B model.

  Pedro.