Re: [Idr] Fwd: New Version Notification for draft-spaghetti-idr-bgp-sendholdtimer-05.txt

Job / Enke / Robert / All

As draft-spaghetti-idr-bgp-sendholdtimer is queued for adoption call, I
don’t think we are all in consensus the TCP_USER_TIMEOUT as the best
solution.

As for the NG TCP Model,  if IDR decides to go with the TCP_USER_TIMEOUT
solution, the scope of the NG TCP model is more limited as it would be just
monitoring of the reset.

Has the TCP_USER_TIMEOUT been tested with any implementations including any
open BGP implementations.

If IDR adopts draft-spaghetti-idr-bgp-sendholdtimer, then the NG TCP model
ability to monitor the details of the connection State and zero window
condition is more critical as it could served as the detection method
to trigger
the send hold timer to reset the peer.

I think the answer for the Yang model direction maybe just to wait till
after the adoption call.

Kind Regards

Gyan

On Fri, Aug 5, 2022 at 1:55 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:

>
> Dear IDR
>
> I support adoption and progressing this document.
>
> The BGP stuck state TCP Zero has resulted in black hole traffic over the
> internet and as this issue has been around for over a decade. I think we
> need to all come together and resolve this issue.
>
> As BGP is being used now more predominately with BGP Only MSDC DC
> Architecture RFC 7938,  it is even more important to get our hands around
> this problem.
>
> From Enke’s email the TCP Timeout is as well a possible approach and here
> I don’t think we need to just focus on one approach but rather a holistic
> approach which maybe multi faceted that would give  operators the desired
> internet stability.
>
> During my OPS DIR review of TCP Yang model this past March and then
> recently in June in discussions with TCPM, I brought up that the TCP Yang
> model was missing TCP flags to monitor the state as well as TCP windowing
> parameters to monitor window sizing and as well the BGP TCP 0 window state
> stuck peer issue discussed on IDR.
>
> As a result of the discussions on TCPM we came to an agreement and thanks
> to Sue for chiming in that we agreed to develop an NG TCP Yang model that
> would help address the BGP TCP stuck state and focus on that as well as
> other parameters that maybe helpful for monitoring the state of TCP for BGP
> application.
>
> OPSDIR Review of TCP Yang model
>
>
> https://datatracker.ietf.org/doc/review-ietf-tcpm-yang-tcp-06-opsdir-lc-mishra-2022-03-03/
>
> At IETF 114 I had the opportunity to present the BGP TCP stuck issue and
> justification for a new NG TCP Yang model and had some good feedback from
> TCPM on moving forward with this NG TCP Yang model with the hopes of being
> able to proactively monitor the BGP TCP window state and when the 0 window
> occurs as well as monitoring other
> parameters that will help detect this issue.
>
> IETF 114 Agenda - 7/29 10AM TCPM 2nd to last presentation NG TCPM Yang
> model
>
> https://datatracker.ietf.org/meeting/agenda
>
>
> I think a combination of the detection mechanism which with this new NG
> TCP Yang model we can detect via Netconf / Yang monitoring the TCP 0 Window
> state occurance, and then with this draft we can trigger the send hold
> timer to terminate the BGP session.
>
>
>
> Kind Regards
>
> Gyan
>
> On Sat, Jul 30, 2022 at 1:23 PM Job Snijders <job=
> 40fastly.com@dmarc.ietf.org> wrote:
>
>> Dear IDR,
>>
>> I’d like to bring this draft to the working group for another round of
>> consideration for WG adoption.
>>
>> There now are two implementations which have implemented the concept
>> (OpenBGPd and FRR) in releases shipping to customers.
>>
>> Our hope is that more BGP implementers take an interest to help improve
>> global Internet routing system stability.
>>
>> We welcome interested parties to help co-author the document,
>> specifically in these areas:
>>
>> - is the 4271 surgery correct?
>>
>> - graceful restart considerations?
>>
>> - do chassis/COTS router vendors feel comfortable with the suggested
>> timers, or is more leeway needed?
>>
>> The goal is to bring the fault stale state back from days/weeks to a few
>> minutes (not to race to the bottom and seek sub-minute resolution).
>>
>> We’d like to ask the IDR chairs to consider kicking off the WG adoption
>> process.
>>
>> Kind regards,
>>
>> Job
>>
>> ---------- Forwarded message ---------
>> From: <internet-drafts@ietf.org>
>> Date: Sat, 30 Jul 2022 at 13:06
>> Subject: New Version Notification for
>> draft-spaghetti-idr-bgp-sendholdtimer-05.txt
>> To: Ben Cartwright-Cox <ben@benjojo.co.uk>, Job Snijders <job@fastly.com>
>>
>>
>>
>> A new version of I-D, draft-spaghetti-idr-bgp-sendholdtimer-05.txt
>> has been successfully submitted by Ben Cartwright-Cox and posted to the
>> IETF repository.
>>
>> Name:           draft-spaghetti-idr-bgp-sendholdtimer
>> Revision:       05
>> Title:          Border Gateway Protocol 4 (BGP-4) Send Hold Timer
>> Document date:  2022-07-30
>> Group:          Individual Submission
>> Pages:          7
>> URL:
>> https://www.ietf.org/archive/id/draft-spaghetti-idr-bgp-sendholdtimer-05.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-spaghetti-idr-bgp-sendholdtimer/
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-spaghetti-idr-bgp-sendholdtimer
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-spaghetti-idr-bgp-sendholdtimer-05
>>
>> Abstract:
>>    This document defines the SendHoldTimer session attribute for the
>>    Border Gateway Protocol (BGP) Finite State Machine (FSM).
>>    Implementation of a SendHoldTimer should help overcome situations
>>    where BGP sessions are not terminated after it has become detectable
>>    for the local system that the remote system is not processing BGP
>>    messages.  For robustness, this document specifies that the local
>>    system should close BGP connections and not solely rely on the remote
>>    system for session tear down when BGP timers have expired.  This
>>    document updates RFC4271.
>>
>>
>>
>>
>>
>> The IETF Secretariat
>>
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
>
>
> *M 301 502-1347*
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*