Re: [Idr] draft-uttaro-idr-bgp-persistence-00

[Robert Raszuk <[e-mail]>]

Jim,

> [Jim U>] One ex would be customers who create multiple VPNs over
> different SPs.. A customer may want to take advantage of the
> knowledge that a control plane failure has occurred and migrate the
> traffic to the backup. This could be done at a path granularity by
> use of the DO_NOT_PERSIST CV. . We as SPs want to provide our
> customers with the tools needed to manage their VPNs and not
> prescribe a one size fits all solution.

I would recommend not to generalize "We as SPs" requirements as above.

Some SPs may prefer to build their control plane in a robust and multi 
vendor way for any application they offer to customers in order to 
prevent from any control plane failures to impact the services.

Other SPs may actually focus on delivering the actual services even 
during a transient control plane failures they may encounter.

I do not think that DO_NOT_PERSIST community is the best way to indicate 
that peering network is multihomed and that it would prefer the normal 
BGP withdraw as opposed to receiving STALE routes from their service 
provider during said service provider encountering a control plane failure.

It is clearly a very new requirement and justification for this proposal 
to develop a tool in order to communicate to your customers about your 
network's control plane failures even though data plane and services 
could continue to be active.

With this in mind what is the mechanism build into this tool for your 
customers to indicate interest is receiving such information ?

Best regards,
R.