Re: Can a BFD session change its source port to facilitate auto recovery

Abhinav Srivastava <absrivas@gmail.com> Thu, 23 March 2023 03:44 UTC

Return-Path: <absrivas@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2F1C14CE46 for <rtg-bfd@ietfa.amsl.com>; Wed, 22 Mar 2023 20:44:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_KTqZ4yMK7C for <rtg-bfd@ietfa.amsl.com>; Wed, 22 Mar 2023 20:44:08 -0700 (PDT)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B7B2C14CF15 for <rtg-bfd@ietf.org>; Wed, 22 Mar 2023 20:44:08 -0700 (PDT)
Received: by mail-ed1-x52b.google.com with SMTP id r11so81228285edd.5 for <rtg-bfd@ietf.org>; Wed, 22 Mar 2023 20:44:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679543046; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=m4L546q/n4Q4JnSBpO3jE4gYqpBrFnoPUR/nuMRf1ys=; b=iFSyprg0B5t3tS/itHwOs3FA8cED30Pzpcmt38XZ0hBRjqe5PVJ9VWJLKeHwzNzmSa jrWZCL5Z2lcLg8W9fzcXaoJPd3f3Neba2byrL0JMWWnsQ/eqfsX1FB60fog8h6shFGuO 3OqWga2rXLIMDNDIaJPsF4SAvKtVu4Z3BeCGVRQDs3GO9Ob59aqb6YGlSZPPtc2JKbKw +etShlb+Jaeg+H4dAVEGg0yljXsfee3U3a+M5137wMNsO/il0E/1pQ0ToPTNAfpoQgiP q3aBSBy+Kq9DQvwGXyFZ7hCKGe8rloZuN5vC87we8raU3P+aSoinuCT1hkUMxw02E4PM 4Egw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679543046; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=m4L546q/n4Q4JnSBpO3jE4gYqpBrFnoPUR/nuMRf1ys=; b=PFBwWa5+j3/sNxwnMBbUSgCmlkJWMeJVMWXWpDKQ3r/6Mgp8IinSppkZqX/1x3iQom kRgQ4qQn7dNkUz+z41NN4K5vGC4f1WmlHN7vwMhZ8tRB80glwHIkMlXWmqzS+kucekfN Rmeaw6xlEnHkFO/3AZF925oFImsKdZ2QDo4gu76Y3LZY+vfbg0IOXlSgKPXOsFwGF+ZN Zt6IcDiIl4kmVyySOp9T6Ua/eT79EQCGQw4eJgN03a3hpZXtet88JW93aY17Pj/pPpe9 52k2rAn/uauTXvqvVmC5efLleQUiOOGBumaNtKeJqh0a5u5blqalOjgYZPrXK4on+RSd 5X1g==
X-Gm-Message-State: AO0yUKVfmLm5Kb6KPCfy52KqlhPYMkZGUncyezOYZIJF2G5nCaxWGBHt AxHcTHjuPzwprQ60uf8WWbr5x11+4EZibfJW0sezAaMV
X-Google-Smtp-Source: AK7set8H3Wlejt9GmPb6efWqBet/iE8QngbXHJ/KgdH8awHkaWakrDkPOcRVxaJ1ebeDGcQXK3pA/Q81RcnwDASMvzs=
X-Received: by 2002:a17:907:788e:b0:932:4577:6705 with SMTP id ku14-20020a170907788e00b0093245776705mr4575968ejc.6.1679543046431; Wed, 22 Mar 2023 20:44:06 -0700 (PDT)
MIME-Version: 1.0
References: <CAL9v8R0Nv6VrdU3gdk8uJ+_K_tehGLXQSor_gBeYq90Tf4WL=Q@mail.gmail.com> <CA+RyBmWQ8upd1SmxwbWiQwyxRmx4ZE07rg18_C7wbX1dtA7J8g@mail.gmail.com>
In-Reply-To: <CA+RyBmWQ8upd1SmxwbWiQwyxRmx4ZE07rg18_C7wbX1dtA7J8g@mail.gmail.com>
From: Abhinav Srivastava <absrivas@gmail.com>
Date: Wed, 22 Mar 2023 20:43:55 -0700
Message-ID: <CAL9v8R2iYMGjxF-A9SuDMcu2EF6h0isquTxjuAtNdqFwv_6etg@mail.gmail.com>
Subject: Re: Can a BFD session change its source port to facilitate auto recovery
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: rtg-bfd@ietf.org
Content-Type: multipart/alternative; boundary="000000000000aae97d05f78916b2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/crZTbL1oAJeQq3nf-J--Ub1gelQ>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Mar 2023 03:44:09 -0000

Multi-hop BFD would be the mechanism that detects the failure on the path
it happens to be using for the session. I wasn't thinking of another
mechanism.  Detection timer expiry would be the trigger for recovery which
could be augmented with few other possible criteria like how long session
hasn't been able to come back up or prolonged flapping.

Thanks
Abhinav

On Wed, 22 Mar, 2023, 3:05 pm Greg Mirsky, <gregimirsky@gmail.com> wrote:

> Hi Abhinav,
> thank you for presenting an interesting scenario for a discussion. I have
> several questions to better understand it:
>
>    - How the network failure that triggers the recovery process is
>    detected?
>    - If the failure detection mechanism is not multi-hop BFD, what is the
>    relationship between the detection intervals of heat mechanism and the
>    multi-hop BFD session?
>
> Regards,
> Greg
>
> On Wed, Mar 22, 2023 at 4:36 PM Abhinav Srivastava <absrivas@gmail.com>
> wrote:
>
>> Hi all,
>>
>>
>>
>> I needed clarification around whether source port can be changed for a
>> BFD session in case of multi hop BFD.   The ability to change BFD source
>> port when BFD session goes down helps BFD session to recover if its stuck
>> on a network path where there is some intermittent but significant packet
>> loss.
>>
>>
>>
>> In such cases, normally without BFD, end to end application traffic would
>> eventually settle down on a good path as applications typically change
>> source port after experiencing disconnection or failures.  But if BFD is
>> being used to monitor some part of a path which is experiencing significant
>> but not 100% packet loss, it will start causing next hop list of associated
>> static route or the associated BGP sessions to start flapping forever, as
>> BFD packets would be stuck to that partial lossy path forever (until BFD
>> session is deleted and recreated by admin action).  This may also hinder
>> the typical application recovery strategy of changing source port on
>> failure.
>>
>>
>>
>> Ability to dynamically change BFD source port can help BFD recover in
>> such cases.  Is this something that is allowed as per RFC?  The RFC5881,
>> section 4 (for single hop) case states that –
>>
>> *“The source port MUST be in the range 49152 through 65535. The same UDP
>> source port number MUST be used for all BFD Control packets associated with
>> a particular session”*
>>
>>
>>
>> Thanks
>>
>> Abhinav
>>
>