Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt

I wanted to take an opportunity to discuss the rationale for this draft.

We have seen an explosion in the growth of our VPN services both
domestically and globally. Many customers span multiple IGP and BGP
domains with sites in both the AP, EMEA, etc... There are multiple BGP
domains with the number of edge devices supporting RFC 2547 numbered in
the thousands. 

As a SP we have seen these customers demanding more and more
sophisticated routing services/solutions. These range from providing
routing granularity at a regional/global/PE level, providing SP value
added content and VPN Stitching.

As we have thousands of customers and millions of routes there is a
tremendous opportunity to stitch VPNs. These opportunities services
include stitching SP value added services into customer VPNs, providing
middleman services to stitch routing between multiple VPNs ( GM , Ford,
etc... ) and TOD services within the context of a single VPN or between
VPNs. The biggest challenge is how to operationalize these services in a
way that is simple, efficient and easily modified. 

The current state of the art is to either modify import/export lists on
each VRF A and VRF B on each PE to leak routes. Of course on a PE with
VRF A and VRF B we need to apply different configuration to leak routes
locally. The major disadvantages to this approach are:

a) Operational Complexity

For a simple gross extranet multiple PEs need to be touched with
configuration applied to each VPNs routing context to create a complete
stitch. Assume two multi-national multi-national corporations that span
US, EMEA and AP with VPN instantiated on 300-400 PEs that want to share
routing state. Our systems need to re-configure all of these PEs to
modify the import/export lists. Of course we have a multiple vendors
where each vendor has different platforms with different code bases.
This makes for a laborious set of requirements on our software
development staff. 

If we want to create a more complex extranet these same issues are
magnified. Each additional VPN stitched requires additional
configuration on the n-1 VPNs currently participating in the extranet as
each VPNs routing context now needs to import the additional RT
representing the newly stitched VPN. 
b) Dynamic/Temporal Stitching

One variation of VPN stitching is where customers want to stitch for
some period of time. The example that immediately comes to mind is
"Follow the SUN" although this is by no means the only one. In this case
customers may want to stitch VPNs together for some period of time that
is configurable and agreed to by all parties. This would require that a
SP would need to reconfigure PEs quite often assuming the current state
of the art. This creates a lot of configuration churn that can lead to
customer routing instability as VRF are re-built with the new RTs.

c) Route Granularity

In the above two examples the simple modification of the import/export
list would create a situation where all of the routes within in each VPN
would be leaked to the other. This is not only undesirable but
unacceptable. Customers do not want to simply create a merged VPN where
all of the routing information is made available to the other VPN. They
want to selectively leak a set of prefixes between them. This is the
same for two or more customer VPNs as well as SP value added stitching.
This level of granularity would require an entirely different set of
software tools which identify prefixes on a per VPN/PE level and then
apply the appropriate RT information. 

Why is this draft so powerful? With this draft the SP can simply manage
routing information from  central location. In order to create a VPN
stitch, the SP simply applies RTs to facilitate the stitch and reflects
to all PEs. In order to deliver these services from a central location (
RR, etc... ) we need to be able to reflect a route back to the PE that
originated it. This is due to the fact the the two VPNs being stitched
may reside on the same PE. Assuming a central distribution paradigm we
need to have this Accept-Own capability. Without it we will need to
either capacity manage the PEs so that two VPNs that will be stitched
now or in the future are not on the same PE. We can never now apriori so
that means we would need to migrate entire VPN routing contexts with
associated multiple interfaces from one PE to another which would create
customer outages. This is simply not acceptable.

Thanks,
    Jim Uttaro