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

From: "Martin Halstead" <[email-masked]>
Date: Fri, 14 Apr 2006 10:49:05 +0100

Ron

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.

MH: Ah, I see what you meant by the previous question! You are right,
this is another alternative. Some issues though with that solution:
- It is highly unusual to have 'option a' and 'option b' on the same
ASBR pair linking a common pair of SPs. Typically each SP to SP link has
a single interconnect option supported. This is due to operational
complexity of running separate multi-AS options on the same ASBR pairs.
- Hopefully the service will scale i.e. numbers of shared VPNs will
increase. What if SP1 and SP2 decide to connect more VPNs by using
'option a'? Your solution does not prevent additional peers (at least
one per additional VPN) from being configured. Also, as the number of
VPNs increase, you will also have to deal with additional per VPN route
filtering to prevent route 'leakage' across the 'option b' link.
- There is an operational knock-on effect within each SPs VPN domain.
SP1 and SP2 will have to concurrently operate different RT import/export
policies at PEs. Some RTs will be shared across SPs via the 'option b'
VPNs, and some RTs will come from each SPs own separate RT pool ie
'option a' VPNs. Again, operational issues here.

Regards

Martin
[email-masked]

---

From: Ron Bonica <[email-masked]>
Date: Mon, 17 Apr 2006 16:55:58 -0400

Martin,

I am coming around to your point of view regarding Option D, but still
have a few comments.

- The draft needs a section that describes its motivation. You might
want to say something like the following:

"Interprovider Options A, B and C all require SPs to co-ordinate RDs.
Interprovider Option D relaxes this requirement by re-assigning RDs at
the ASBR.

Also, interprovider Options A, B, and C provide no mechanism through
which SPs can dedicate bandwidth between ASBRs to a particular VPN.
Interprovider Option D solves this problem through Private Interface
Forwarding. In this approach, the SP dedicates a logical interface
between ASBRs to each VPN and forces VPN traffic over the appropriate
interface by manipulating BGP next-hops".

- Also, your might want to explore approaches to the second problem that
do not separate the forwarding path from the control path. I realize
that the approach described in my last email may not suite all SPs. So,
I will suggest another variation on that theme.

Instead of establishing multiple layer 3 interfaces between the ASBRs,
establish a single interface and run multiple, single-hop LSPs over
that. Police and rate-limit each LSP as per VPN policy. As in your
original proposal, run a single mp-ebgp peering session between the two
ASBRs and force traffic over the correct LSP by manipulating BGP next-hops.

The advantage of this approach is that it doesn't separate the
forwarding path from the control path. Also, it consumes fewer logical
interfaces.

- If you must separate the forwarding and control paths, please add a
section to the draft describing what might happen if the forwarding path
goes down and the control path does not. Also describe mitigation
techniques.

                           ron
                           /as individual contributor