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

From: "Martin Halstead" <[email-masked]>
Date: Wed, 26 Apr 2006 15:06:45 +0100

Pedro

> In option 'b', RT and
> RD values are not advertised per ASBR VRF, rather they are advertised
> from PE to PE - a major difference. 

>I'm sorry but why does that matter ?

MH: No need to be sorry ;-) this matters for the following reasons
(amongst others):

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.

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

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.

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. This will occur where
RD and customer address space overlap across ASes. Although the
probability of this scenario is small, the consequences could be severe
and difficult to isolate. RFC4364 states that RD values should be made
unique by using public ASNs. Trouble is that not all SPs actually do
that.

Regards

Martin

---

From: Pedro Roque Marques <[email-masked]>
Date: Wed, 26 Apr 2006 10:51:56 -0700

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

> 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

Just not available with centralized RRs.

> supported by option 'b' for the same reasons as described for load

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