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

From: "Martin Halstead" <[email-masked]>
Date: Tue, 18 Apr 2006 11:34:31 +0100

Ron

Thanks for the excellent suggestions - we will incorporate them in the
next version of the draft and issue it shortly. 

Many thanks to the other contributors - any further
clarifications/additions to the draft, please let us know.

Regards

Martin
[email-masked]

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

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

> 
> 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: Tue, 18 Apr 2006 14:36:41 -0400

Martin,

BTW, would Option D play well with Constrained VPN Route Distribution (
                draft-ietf-l3vpn-rt-constrain)?

                                Ron