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

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

Please see some comments inline.
Marko 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of jguichar
> Sent: 1. maaliskuuta 2005 22:00
> To: Kulmala, Marko; 'Pedro Roque Marques'
> Cc: [email-masked]
> Subject: RE: Please comment draft-kulmala-l3vpn-aggregation-pe-00
> 
> Marko,
> 
> Please see my comments inline ..
>  
> > > > 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.
> 
> 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 ?

Yes, main difference compared to InterAS option A is that VPN-IPv4
routes are re-advertised.
The benefits over A are: One BGP session one logical interface needed
between ASBR's.

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

What I remember about HOPE proposal is that it was similar type than
this but not the same.
So issues may be different as well. Can you point something where I can
see the issues ?

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

The fundamental difference in this concept compared to option B is that
the MPLS domains are separated since we go to IP level. This
loadbalancing is just one application example.

> 
> Regards, Jim
> 
> > 
> > > 
> > > 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 
> > ============================================================
> > 
> > 
> 
============================================================
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: "Kulmala, Marko" <[email-masked]>
Date: Thu, 3 Mar 2005 09:01:06 +0200

Robert, 

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

In our proposal we make import to VRF and export from VRF. This is not
modification on a per VPN prefix granularity.
But yes, RT:s and RD:s need to be selected in proper manner for VRFs as
normal. The fact that RTs and RDs are changed comes from the goal to
separate mpls domains by having IP layer between the domains at ASBR. RD
and the attributes of the routes that are advertised to the neighboring
AS are configured only in ASBR.  

Regards,
Marko

---

From: "Kulmala, Marko" <[email-masked]>
Date: Fri, 4 Mar 2005 08:52:47 +0200

Pedro,

It may be possible to get many features by building them on top of
option B. But I do not think that it is right way to go. I agree with
Robert when he said that it will be operationally difficult to do modify
action in some mid point on a per VPN prefix granularity. Also I agree
with you that those things break current option B.

That is why we like to standardize this new method. It is fundamentally
different compared to option B, even though at the first glance it seems
pretty much alike. In my opinion the proposed method is straightforward
and easy from operational point of view: We have VFRs at ASBR, just like
in option A. But we make it possible to have mpls network between ASBRs.

One comment about option B and C. When Autonomous Systems are connected
by using those options they will share common MPLS domain. Is that good
if applied as an Inter Provider solution ? The main conceptual point in
our proposal is that the MPLS domains are isolated.

Marko

> From: Pedro Roque Marques [mailto:[email-masked]] 
> Sent: 2. maaliskuuta 2005 22:26
> To: Kulmala, Marko
> Cc: [email-masked]; [email-masked]
> 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. 
> 
>

---

From: "Fang, Luyuan, ALABS" <[email-masked]>
Date: Mon, 7 Mar 2005 14:44:17 -0600

Marko,

> if applied as an Inter Provider solution ?

Option B does not share common MPLS domain. Many providers implemented
Option B as Inter-provider solution already. 

Option C requires providing PE reachability to the connecting
ASes/providers. It is an excellent solution for intra company
connections. For Inter-provider, there are more security concerns, I
don't know if anyone is using it for Inter-provider connections. 

Luyuan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Friday, March 04, 2005 12:07 PM
To: [email-masked]
Subject: L3vpn Digest, Vol 11, Issue 4

Send L3vpn mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/l3vpn
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of L3vpn digest..."

Today's Topics:

   1. RE: Please comment draft-kulmala-l3vpn-aggregation-pe-00
      (Kulmala, Marko)
   2. slides (Ronald Bonica)

----------------------------------------------------------------------

Message: 1
Date: Fri, 4 Mar 2005 08:52:47 +0200
From: "Kulmala, Marko" <[email-masked]>
Subject: RE: Please comment draft-kulmala-l3vpn-aggregation-pe-00
To: "Pedro Roque Marques" <[email-masked]>
Cc: [email-masked], [email-masked]
Message-ID:
	
<[email-masked]
c.net>
	
Content-Type: text/plain;	charset="us-ascii"

Pedro,

Marko

------------------------------

Message: 2
Date: Fri, 04 Mar 2005 11:00:21 -0500
From: Ronald Bonica <[email-masked]>
Subject: slides
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Folks,

If you are presenting to our meeting on Monday, please send your slides 
to me in advance so that we won't have to move the projector from PC to 
PC at the beginning of each presentation.

                                   Ron

------------------------------

_______________________________________________
L3vpn mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l3vpn

End of L3vpn Digest, Vol 11, Issue 4
************************************

---

From: "Kulmala, Marko" <[email-masked]>
Date: Tue, 8 Mar 2005 17:56:40 +0200

Robert,

In option B there is label switched path leading from a packet's ingress
PE to its egress PE as explicitly stated in RFC2547bis chapter 10 b).

Or are you saying that there is error in RFC2547bis ? I think it is
correct and that the LSP is the one that is  established by BGP VPN
label distribution. Right ?

Marko

> On Behalf Of Robert Raszuk
> Sent: 8. maaliskuuta 2005 16:02
> To: Kulmala, Marko
> Cc: Fang, Luyuan, ALABS; [email-masked]
> Subject: Re: Please comment draft-kulmala-l3vpn-aggregation-pe-00
> 
> Marko,
> 
> > Option B requires that there is a label switched path 
> leading from a 
> > packet's ingress PE to its egress PE as stated in 
> RFC2547bis. There is 
> > no IP layer forwarding at ASBR. In my mind that is then the 
> same mpls 
> > domain, but word "domain" may mean different things to us.
> 
> Nope ... LSP terminates when the next hop is being changed. 
> In option B ASBRs change next hops on the vpnv4 routes so LSP 
> terminates there. The LSP switching looks like:
> 
> PEing --- ASBR --- ASBR ---- PEegr
> 
> or
> 
> PEing --- ASBR --------------PEegr
> 
> depending on how you deal with next hop configuration on ASBRs.
> 
> In option C indeed there is no next hop change across domains 
> and one could say that it requires inter-mpls LSP to work 
> between ing & egr PEs.
> 
> Let me also point out that MPLS LSP is not a must requirement for any
> 2547 inter-as (or intra as) transport. You can easily 
> substitute it with IP tunnels which therefor would not 
> require any MPLS state in the domain chain of PE-PE path.
> 
> > But anyways there is LSP connectivity between routers in 
> different ASes.
> > As stated earlier I think that what we propose would give better 
> > isolation than option B.
> 
> I think I still haven't seen why option A is not sufficient 
> then if strong intra-domain isolation is a requirement ? It 
> seems to me it is very close to what you are proposing ... 
> especially when draft provides an example of the complete 
> modifications to the RD & RTs.
> 
> Cheers,
> R.
> 
>