Subject: RE: draft-kulmala-l3vpn-interas-option-d-02

From: "Martin Halstead" <[email-masked]>
Date: Thu, 13 Apr 2006 17:13:52 +0100

Ron

Thanks for the question. Option 'a' requires an IPV4 peer between
attached VRF pairs at each ASBR. Each ASBR must therefore support at
least one IPV4 peer per VPN. As the number of VPNs increase, so do the
number of peers giving rise to convergence and complexity issues. If a
service provider wants to associate all VPN traffic with at least one
VRF (as some do for security, per VPN route learning, per VPN ACL
support reasons etc), then at the moment 'option a' and all those
associated IPV4 peers is the only way to go. Configuring 'option b' on
the same ASBR pair will not help here as there is no way to set up paths
for 'option b' learned VPN-IPV4 routes for VPN traffic flowing across
per VRF ACs (unless you implement this additional option ;-). There
isn't really much point in configuring more than a single option 'b'
interface between ASBRs though as a single interface supports multiple
VPNs and additional interfaces do not need to be configured as the
number of VPNs increase.

Regards

Martin Halstead
[email-masked]

-----Original Message-----
From: Ron Bonica [mailto:[email-masked]] 
Sent: 13 April 2006 16:12
To: Martin Halstead
Cc: [email-masked]
Subject: Re: draft-kulmala-l3vpn-interas-option-d-02

Martin,

Could you explain the motivation for private interface forwarding? I
don't understand which problems it solves that could not be solved with
an equal number of Option A and Option B interfaces between ASBR's

                           Ron
                           /as individual contributror

---

From: Ron Bonica <[email-masked]>
Date: Thu, 13 Apr 2006 13:07:06 -0400

Martin Halstead wrote:
> number of peers giving rise to convergence and complexity issues.

I understand this much....

 If a
> VPNs and additional interfaces do not need to be configured as the

I would like to propose another alternative. Assume that two Service
Providers (SP1 and SP2) share five customers (C1, C2, C3, C4 and C5).
C1, C2 and C3 are happy to share bandwidth on a common link between SP1
and SP2. However, C4 and C5 each want dedicated bandwidth between the
SPs. (I think that this is the problem that you want to solve?)

The SPs might solve this problem as follows:

Establish three links (LG, L4 and L5) between SP1 and SP2. LG is in the
general routing instance, L4 is in C4's VRF and L5 is in C5's VRF.
Configure an mp-ebgp peering session on LG (as per Interprovider Option
B). However, do not advertise routes belonging to C4 and C5.

Then configure L4 and L5 as per Interprovider Option A.

The drawback of this solution is that it may require two extra bgp
peering sessions. The benefits are a) that it doesn't separate the
control and data planes and b) that it doesn't require a new option.

                                     -r
                                     /as individual contributor