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

From: "Kulmala, Marko" <[email-masked]>
Date: Tue, 8 Mar 2005 08:30:43 +0200

Luyuan,

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.

Option B does not require PSN tunnels between the packet's ingress and
ergess PEs but it will establish LSP by VPN label distributed by BGP.
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.

Regards,
Marko  

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Fang, Luyuan, ALABS
> Sent: 7. maaliskuuta 2005 22:44
> To: [email-masked]
> Subject: RE: Please comment draft-kulmala-l3vpn-aggregation-pe-00
> 
> Marko,
> 
> > 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 ?
> 
> 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]
.tellabsin
> c.net>
> 	
> Content-Type: text/plain;	charset="us-ascii"
> 
> 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
> 
> > -----Original Message-----
> > From: Pedro Roque Marques [mailto:[email-masked]]
> > Sent: 2. maaliskuuta 2005 22:26
> > To: Kulmala, Marko
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: Please comment draft-kulmala-l3vpn-aggregation-pe-00
> > 
> > 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. 
> > 
> > 
> ============================================================
> 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 
> ============================================================
> 
> 
> 
> ------------------------------
> 
> 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
> ************************************
> 
> 
============================================================
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: Robert Raszuk <[email-masked]>
Date: Tue, 08 Mar 2005 15:02:15 +0100

Marko,

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

> As stated earlier I think that what we propose would give better

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.

---

From: Ville Hallivuori <[email-masked]>
Date: Tue, 8 Mar 2005 17:20:31 +0200

> LSP switching looks like:

Marko refers to inner LSP -- with option B there has to be SWAP
operation for VPN routes in ASBR. With our option SWAP can be replaced
with POP + route lookup (not that this is very relevant, as our draft
allows both methods). If IP lookup is used in ASBR, one can perform
IP aggregation and traffic filtering.

> an example of the complete modifications to the RD & RTs.

Our proposal is primarily intended for separating access networks in
to sub-ASs. Therefore there is no L2 connectivity between N-PEs and
U-PEs -- there is MPLS access network between them. Each U-PE is also ASBR
(unless RR is used in access network).

Example:
  [Core MPLS network]----N-PE---[Access MPLS network]-----U-PE----CE

If you missed my presentation on l3vpn session, you can see better
picture from the slides available at:
    http://www.iki.fi/vph/files/aggregation-pe-ietf62.pdf

Our proposal can also be used between ASs of different operators
(with the normal arrangement of two directly connected ASBRs), where
our proposal has the security advantages over option B, that Marko
mentioned. In that application using  option A would require running N
routing protocol sessions over channellized interface, witch would be
rather inefficient (and in addition one would have to configure N
subinterfaces...). I do not believe that option A is realistic option
as a inter-as method, if thousands of VPNs are shared between ASs.

-- 
[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]