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

[<[e-mail]>]

Hi Robert,


>From: Robert Raszuk, Sent: Tuesday, October 25, 2011 8:16 AM
>
>Hi Jim,
>
>> [Jim U>] Why do you believe that? BGP can
>> and does fail independently of the underlying LDP session.. I do
>> believe that viability of a data path between two endpoints should be
>> taken into account when validating paths to NHs but that effort is
>> clearly a much bigger effort.. This draft would take advantage of
>> this mechanism but I am not looking to define that in this draft..
>
>In my opinion  there is a need to recognize the difference of possibly
>locally using a stale path (and that is btw exactly what GR spec does
..
>except here it would be GR per prefix with longer timer) versus keep
>advertising paths which may be invalid.

There may be a need to distinguish both. However, I wish you could
explain why you see this need.

BTW GR does both: locally keep a stale path _and_ implicitly keep
advertising a path which may be invalid. 


>> I would suggest to at least add the recommendation statement to the
>> document that during best path selection especially for stale paths
>> a validity of required forwarding paradigm to next hop of stale
>> paths should be verified. [Jim U>] Why would this not be something
>> that needs to be done as a general rule for paths.. I mean the
>> underlying LSP could fail independently of BGP.. If this needs to be
>> done in should be done as a general rule...
>
>Respectfully disagree.
>
>I am sure you very well know how many customers are relaying on using
>BGP keepalives to determine PE-CE link up and PE-CE reachability.
Recall
>how many times SP customers including your own customers were asking to
>reduce holdtime on their ebgp session to 3/9 ... those customers just
do
>not have a better way to determine VPN site reachability.

Regarding the activation of persistence over an eBGP PE-CE session, I
agree both with you and Jim that you would need to evaluate how much the
forwarding will share fate with the BGP session. And if there is a
doubt, you would need to check forwarding status (e.g. BFD if link level
info is not reliable).
Note however, that this is not new. GR has the same issue (e.g. if on
the CE the forwarding share fate with the control plane, you should not
enable BG GR). Note also that even if persistence take the wrong
decision (i.e. advertise the route while the forwarding is down) if the
site is not dual homed, the issue is limited as traffic is dropped in
all cases. And if the site is dual homed, persistence will favor the
backup link. Hence the status of the forwarding is less important that
for GR, which do use the link/BGP session with an uncertain status.

>Of course such reduction of keepalives is a bad idea (even if their
>processing is offloaded or prioritized on main RP) so BFD was invented
>to address this issue. And either BFD if present or EBGP session up
>state was _the_only_ probe to determine if CE over frame relay PVC or
>multiaccess media is live. That is the key difference.
>
>So when you drop session you remove prefixes advertised from the site
>and backup can be activated. Now you are proposing to keep advertising
>them as STALE which really means MAYBE_REACHABLE. I am not sure why
>validation of next hop reachability by BFD or even OBJECT_TRACKING or
>SCRIPT would be at all difficult.
>
>Anyway I think this proposal as pointed out in the other email has much
>bigger deployment issue so I think there is not much point on this
>validation debate at this point before the loop problem is solved due
to
>inconsistent forwarding plane decisions.
>
>Best regards,
>R.
>_______________________________________________
>Idr mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/idr