[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Please comment draft-kulmala-l3vpn-aggregation-pe-00



On Tue, Mar 08, 2005 at 03:02:15PM +0100, Robert Raszuk wrote:
> 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:

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.

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

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][vph at iki.fi][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]