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

[Robert Raszuk <[e-mail]>]

Hi Bruno,

 > Nope. In your above case, I would expect the failure to be concealed
 > within the SP AS:
 >
 > PE1 has X via PE1/S (stale) and X via PE2/A (active) - it understands
 > STALE so selects in his forwarding table path via PE2.
 >
 > --> The customer does not see the "STALE" information.

Nope - it sure does.

As I have obviously foreseen you are going to say so I specifically 
pointed out that there is no symmetry on the PEs due to the specific RT 
configuration. See below quote:

"Prefix X is advertised by remote hub in the given VPN such that PE1 vrf
towards CE1 only has X via PE3 and PE2's vrf towards CE2 only has X via
PE4."

> You bring the issue of the incremental deployment of a feature which
> change the (BGP) routing decision. That's a valid point (not necessarily
> specific to the persistence draft).

I think any draft modifying routing decision should discuss such issues.

> One answer is careful deployment of such features.

I am afraid this is very difficult to achieve across EBGP boundaries. If 
you would just limit STALE to IBGP I would perhaps have a bit lighter 
objection :)

> However I the persistence draft could probably be improved to handles
> incremental deployment. This could be addressed in the next revision.
> A first tentative could be:
> - over an iBGP session, the router detecting the BGP session failure,
> flag the routes with a low (e.g. 0) LOCAL_PREF plus the STALE community.
> Within the AS, the STALE community does not influence routing decision
> but inform possible downstream BGP routers of the cause of the low
> local_pref. In particular that the LOCAL_PREF should probably not be
> further changed (some AS handles load balancing by rewriting the Local
> Pref on the ingress PE)
> - inform downstream AS of the STALE condition. First eBGP router could
> translate this community into a low local_pref. With the iBGP mesh, cf
> above.

Translating STALE to Local Pref over EBGP and not using STALE for local 
decision makes the proposal much less dangerous indeed.

Is any action associated with STALE going to be disabled by default in 
all BGP implementations ? If yes I would see it acceptable - provided 
the above changes are introduced.

However if any implementation is going to enable auto translation of 
STALE to local pref = 0 across EBGP boundary, or make best path decision 
based on STALE presence -  we have the same problem as soon as any two 
routers are not upgraded in the same time to the same vendor's code 
version.

--

Regardless how novel and appealing is the idea of telling your customer 
that you can possibly forward, but your control plane is undergoing 
recovery - I still think that churn introduced by this sort of 
signalling on a per path basis is a pretty bad idea. If anything I would 
rather see this in the BGP Operational Message not in the actual routing 
UPDATE messages.

Cheers,
R.