Re: updated draft-gs-l3vpn-scaling & agenda request

Hi Daniel,

> [DC] I think this is getting too much into implementation-specific
> issues. What you write above is related to routing information
> structure, but this does not necessarily mandate implementation
> architecture.

Very true. I was only bringing examples of most widely known/used
implementations.

> For example I am familiar with multi-instance OSPF
> implementations that run a single process/thread for all instances,
> while internally adding instance information to the LSDB.

Correct. But one needs to keep in mind that multi-instance IGP proposals
for all practical purposes are limited to small amount (4,8,16) while
L3VPNs clearly goes over 1000s.

> [DC] Thanks for the clarification. I suggest you add it to the draft.

I think Wes will :) I am not co-author of this document.

> You didn't answer the  following question though: " Also, what do you
> mean by "exacerbate geographic distance"? I don't understand the meaning
> of this expression nor the problem it describes."

The way I read this is that it says that using same RD will on one hand
allow to limit number of paths for a given VPN however among other
issues it exposes inaccurate BGP best path selection problem. In those
cases VPNv4/v6 route reflector will be selecting best path in his IGP
location in the network (or with completely disabled metric to next hop
comaprison) what will result for some (most) PEs to get suboptimal path
from such RR.

The problem is well known and some time back I have proposed general
solution to this issue. It is described in:
draft-ietf-idr-bgp-optimal-route-reflection-01 and it is applicable to
both IPv4/IPv6 as well as same RD L3VPNs.

Best regards,
R.