Subject: RE: draft-kulmala-l3vpn-interas-option-d-02 consensus (Pedro Roque Marques)

From: "Martin Halstead" <[email-masked]>
Date: Thu, 27 Apr 2006 09:50:46 +0100

Pedro

' There are existing deployments that use RT translation... with option
b) 
and c). RD translation would be highly undesirable from an 
implementation POV, imho. Which isn't to say that you need anything 
other than option b) / c) to do it.'

MH: The problem with RT translation is that that infernal software the
SPs use issues different numbers of RT values per VPN - some construct a
VPN as hub-and-spoke, other as fully meshed, some partial mesh. So - RT
translation is rather tricky in bilatereral relationship. For
multilateral it is not possible when SPs have different allocation
schemas. As for RDs, although option 'd' does not do RD 'translation',
would be interested to understand why iyho RD translation is not
desirable.

' That is not true. Naive network designs on the receiver that use 
centralized route reflectors (a solution that will not scale) cause 
problems such as lack of required path information. This is just a 
question of network design on the receiver... a problem for the receiver

to solve for sure.'

MH: Agreed that centralized RRs don't scale and the receiver should do
something about that ie distribute routes across RRs such that not all
RR clusters contain all routes for all VPNs. Could you please explain in
an option 'b' distributed RR implementation how a PE that has received a
single path via ASBR pairs in the same AS can load balance traffic? That
should address the optimal path issue I described next.

Thanks.

Martin

MH: 
-----Original Message-----
From: Pedro Roque Marques [mailto:[email-masked]] 
Sent: 26 April 2006 18:52
To: Martin Halstead
Cc: [email-masked]
Subject: Re: draft-kulmala-l3vpn-interas-option-d-02 consensus (Pedro
Roque Marques)

Martin Halstead wrote:

> Operational issues:
> Typically service providers have in-house or COTS based OSS systems
that
> address single domain VPN provisioning only. These OSS systems
allocate
> RT and RD values for a single domain only. When these service
providers
> partner and run option 'b' (not many if any run option 'c') typically
> they need to introduce manual processes to get around allocating RT
> values across AS borders i.e. using someone else's RT values.
> Unfortunately, that is not always possible due to some SPs inability
to
> change their automated systems and processes.

There are existing deployments that use RT translation... with option b)

and c). RD translation would be highly undesirable from an 
implementation POV, imho. Which isn't to say that you need anything 
other than option b) / c) to do it.

> 
> Load balancing:
> SPs use various traffic load-balancing techniques between customer
sites
> in order to optimize traffic flows within their own ASes. As described
> in RFC4364, this necessitates the use of different RD values
provisioned
> across VRFs to which the customer is multi-homed.

That is not true. Naive network designs on the receiver that use 
centralized route reflectors (a solution that will not scale) cause 
problems such as lack of required path information. This is just a 
question of network design on the receiver... a problem for the receiver

to solve for sure.

Again, even if the receiver wants to do RD translation (a very 
questionable choice) this does not require any standardization effort 
other than what is currently defined in 2547.

> Similar mechanisms
> SHOULD be available when ASes are multi-homed and a SP wants to load
> balance to ASBR pairs. This is not possible in option 'b' where SPs
run
> RRs.

Just not available with centralized RRs.

> 
> Optimal interconnect selection:
> Consider a customer site in the middle of the USA. It is connected to
an
> AS (AS1) that is interconnected to another AS (AS2) at interconnect
> points in both New York and Los Angeles. In order to minimize latency,
> traffic must be sent to a site in Tokyo (connected to AS2) via the LA
> interconnect point and not via New York. From a network utilization
> perspective, routing Tokyo-bound traffic via New York incurs an
> inefficient, resource-consuming round trip traversal of the planet.
> Similarly, the same site might also send traffic to London (also
> connected via AS2). The optimal route for this traffic must however be
> via New York rather than LA as in that case the traffic path is more
> optimal. Assuming AS2 uses RRs, this routing scenario cannot be
> supported by option 'b' for the same reasons as described for load
> balancing above.

You are assuming centralized RRs. Centralized RRs have all sort of 
issues on a large scale network... including this one. Rewriting RDs is 
not going to make centralized RRs work either, as far as i can see. But 
if supporting centralized RRs if the goal of your work, why don't you 
state it upfront ? We can then evaluate the proposal by its merits.

The current document as a inaccurate description of what the problem 
statement is. imho, this alone would be enough reason to conclude that 
the document is not ready for WG status.
> 
> RD overlap:
> The advertisement of RD values end-to-end between SPs, combined with
the
> customer's use of private [RFC1918] addressing could result in RRs
> making incorrect best path decisions for identical routes received
from
> external as well as internal PE network elements.

i don't believe the above is accurate. RDs are required to be assigned 
uniquely (this is completely independent of rfc1918 addressing). For RDs

to be unique they need to rely on a publicly assigned value... there are

2 options available as you know. AS or public IP. These seem to work for

pretty much everyone...

Specially the networks that have these big OSS systems that you refer to

in the beggining... i've never seen one deployment that doesn't unique 
RDs. Is there any ? can someone please step forward w/ an example ?

To rehash:
- Contrary to what the document states, option b) *does* allow per VRF 
route policy and traffic filtering decisions. There are existing 
deployments to prove this point.
- There is no clearly defined problem statement, imho, to support the 
introduction of this document as a WG item.

regards,
   Pedro.

---

From: Pedro Roque Marques <[email-masked]>
Date: Thu, 27 Apr 2006 11:06:35 -0700

Martin Halstead wrote:

> SPs use

I'm trying to figure out if that was a typo or intentional :-)

Regarding inter-as and route reflection interaction.

If one is to use a centralized design where each externally received 
path is advertised with a different RD, then for each of these prefixes 
we have multiplied the routing information M times, where M is the 
number of exchanges w/ a given peer. We know from experience that M can 
get to be pretty large (10..20 peering points)... So a centralized RR 
design explodes routing information by a factor that is certainly 
unworkable in the long run. Both N (number of external routes) and M 
(number of peering sessions w/ ASn) are expected to grow with time and 
this NxM equation does not look pretty.

The information one actually desires is to have on a per region basis 
the best exit point for a given "reachability" point. This is what you 
get by default by doing path selection on an NLRI using metrics as tie 
breaker. The logical conclusion, imho, would be that for large scale 
deployments a SP needs to have RRs per region that perform this local 
selection decision so that PEs are not bothered w/ it.
That is why it is undesirable to rewrite RDs... doing so breaks the 
ability to perform path selection on what is essentially the same 
information.

All this stuff is not anything new... all one needs to do is copy the 
design used for Internet route reflection. A pair of RRs per 
"region"/"pop" which pick the locally best exit points and reduce the 
ammount of routing information torwards the PEs. All the mechanisms are 
in place to achieve this...

However efforts to get centralized RRs to see and reflect all possible 
paths (without path selection) may be counterproductive. I'd be very 
concerned if the WG where to give its stamp of approval to such attempts.

It would also be contrary to the current direction the WG has taken... 
the recently approved rt-constrain mechanism is a step towards making 
decentralized RRs a more useful tool in l3vpn network design.

regards,
   Pedro.