comments on draft-ietf-ppvpn-generic-reqts

[Alex Zinin <zinin@psg.com>]

4.10

  Should be more explicit about the difference in data-plane and
  control-plane resources of the network.

  As with data-plane resource sharing, should talk about SLAs for
  control-plane for the cases where the SP's control plane is used to
  distribute customer's routes, i.e., how does addition of another 100
  VPN sites to a PE not mean slower convergence of those 10 connected
  to it before. I.e., it doesn't seem to be enough to talk about
  failures... isn't control-plane service degradation not a concern?
  What about affects on the Internet routing from this perspective
  (i.e., routing instabilities in a VPN with thousands of sites
  affecting the Internet because of lousy job with resources
  separation in the PEs that also run INET BGP)?

  These considerations should also be reflected in the Security
  Considerations section--DoS attacks on PE control plane CPU are
  possible.

5.1.3:

>    The following example applies to the number of tunnels necessary in
>    various devices in the network. In a PE-based VPN, edge-to-edge
>    tunnels (PE-to-PE)  need to be established, while in a CE-based VPN,
>    end-to-end tunnels between  pairs of CEs are necessary. Therefore,in
>    general, PE-based VPNs scale better than CE-based VPNs, although the
>    scalability of CE-based VPNs may be improved by tunnel aggregation
>    between PEs.

This example presupposes MPLS as the tunneling technology. If the
network does not have to maintain state for tunnels (as it doesn't for
TCP connections, for instance), one could argue that the CE-based
solution actually scales better, since a given CE needs to terminate
only a limited set of tunnels within the VPN it belongs to, while in
the PE-based case, each PE serves a high number of VPNs, and hence
potentially several orders of magnitude more tunnels.

>    A scalable PE-based solution should quantify the amount of state that
>    a PE and P device must support. This should be stated in terms of the
>    total  number of VPNs and site interfaces supported by the service
>    provider.

The second sentence seemed a bit strange. Wasn't a O()-style function
of those meant instead?

>    A CE-based solution should quantify the state and scaling limits.
>    This should be stated in terms of the number of tunnels supported,
>    how these tunnels are provisioned and maintained (e.g., key
>    exchange), how routing occurs across these tunnels, and what the
>    impact of changes in the network topology do to the convergence
>    performance of such a solution.

Why is this for CE-based solutions only? I'd say same questions are
valid for PE-based scenarios too.

5.2.1.

>    A customer should be able to make dynamic requests for changes to
>    traffic parameters. A customer should be able to receive real-time
>    response from the SP network in response to these requests.  One
>    example of such as service is a "Dynamic Bandwidth management"
>    capability, that enables real-time response to customer requests for
>    changes of allocated bandwidth allocated to their VPN(s).

DoS discussion in Security Considerations on this?

6.2.

>    The plug and play feature of a VPN solution with minimum
>    configuration requirements is an important consideration. The VPN
>    solutions should have mechanisms for protection against customer
>    interface and/or routing instabilities so that they do not impact
>    other customers' services.

"...or interfere with the Internet routing"

-- 
Alex