Re: [Idr] Comparison between session-reset and treat-as-withdraw

Hi Robert,

Agree that bgp-operational-message could provide detailed diagnostic information which would be quite helpful for diagnosing of treat-as-withdraw events. And some mechanism for automatic route recovery can also be helpful after some important routes are treat-as-withdraw.

Regards,
Jie

> -----Original Message-----
> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert
> Raszuk
> Sent: Monday, September 17, 2012 3:37 PM
> To: Jie Dong
> Cc: John Leslie; Randy Bush; idr wg
> Subject: Re: [Idr] Comparison between session-reset and treat-as-withdraw
> 
> All,
> 
> Treat-as-withdraw was supposed to be used with
> bgp-operational-message. Using is as default before
> bgp-operational-message is available is IMHO a mistake.
> 
> Regards,
> R.
> 
> On Mon, Sep 17, 2012 at 9:29 AM, Jie Dong <jie.dong@huawei.com> wrote:
> > Hi John,
> >
> >>    By which I guess he means that treat-as-withdraw has no automatic
> >> recovery path. And with that, I agree.
> >
> > Yes, that's exactly what I mean.
> >
> >>    We may succeed in "routing around the problem" when we use
> >> treat-as-withdraw; but I think we may lack any way to restore the
> >> original route when the actual issue is resolved.
> >>
> >>    And that, IMHO, deserves some discussion...
> >
> > Agreed, after using treat-as-withdraw on some routes, there will be some
> inconsistency between the sending and receiving BGP speaker for some time,
> and some user traffic may be affected. Thus similar to session reset, maybe the
> receiving speaker could try to recover the particular routes with some back-off
> mechanism before manual intervention.
> >
> >
> > Best regards,
> > Jie
> >
> >> -----Original Message-----
> >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of
> John
> >> Leslie
> >> Sent: Friday, September 14, 2012 11:00 PM
> >> To: Randy Bush
> >> Cc: idr wg
> >> Subject: Re: [Idr] Comparison between session-reset and treat-as-withdraw
> >>
> >> Randy Bush <randy@psg.com> wrote:
> >> > [Enke Chen <enkechen@cisco.com> wrote:]
> >> >
> >> >> In terms of recovery, it has been shown that the session reset and
> >> >> reestablishment usually do not eliminate malformed updates.  Instead
> >> >> the session would often get into the cycle of reset and
> >> >> reestablishment until the culprit route is removed from the routing
> >> >> system by the operator manually.
> >> >
> >> > been there.  have coffee cup and tee shirt.  sadly sessions go bouncy
> >> > bouncy is not uncommon.
> >>
> >>    Yes... major pain, and very little information about the actual issue.
> >>
> >>    But when the actual issue _is_ at the router getting the NOTIFICATION,
> >> we are "routing around the problem".
> >>
> >>    We now are facing cases where the actual issue is elsewhere.
> >>
> >> Jie Dong <jie.dong@huawei.com> wrote:
> >> ]
> >> ] If there is no session re-establishment after the session terminated,
> >> ] we may lose the chance of recovering the session automatically in
> >> ] some error cases.
> >>
> >>    By which I guess he means that treat-as-withdraw has no automatic
> >> recovery path. And with that, I agree.
> >>
> >>    We may succeed in "routing around the problem" when we use
> >> treat-as-withdraw; but I think we may lack any way to restore the
> >> original route when the actual issue is resolved.
> >>
> >>    And that, IMHO, deserves some discussion...
> >>
> >> --
> >> John Leslie <john@jlc.net>
> >> _______________________________________________
> >> Idr mailing list
> >> Idr@ietf.org
> >> https://www.ietf.org/mailman/listinfo/idr
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr