IETF Logo Mail Archive

Re: [Idr] Questions over draft-retana-idr-bgp-quic-01

Jared Mauch <jared@puck.nether.net> Mon, 13 March 2023 16:56 UTC

Return-Path: <jared@puck.nether.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12221C151534 for <idr@ietfa.amsl.com>; Mon, 13 Mar 2023 09:56:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.296
X-Spam-Level:
X-Spam-Status: No, score=-4.296 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=puck.nether.net
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 sYd9PQwrrr3e for <idr@ietfa.amsl.com>; Mon, 13 Mar 2023 09:56:35 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 CBFDBC1524B4 for <idr@ietf.org>; Mon, 13 Mar 2023 09:56:35 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2602:fe55:64:0:174:420d:1184:f170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 128635401B5; Mon, 13 Mar 2023 12:56:34 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 puck.nether.net 128635401B5
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=puck.nether.net; s=default; t=1678726594; bh=pMzIfue+Ft8c3K4p2qVUU4UIbaOkd+JY4s6vGhOqUFQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=EkPZMD+7Qu5iYNx0Ed2NSBHIWg937yWoAzpF9VhiGFjuPU1Ws8gFrKUDr92h1K1vC glDhD1ool0892M6YF+ahnLOtCEC92E1x91RD1prNWozg2wdZNPXpj8Bcwi6HjWQSAO llLg2ljby0Qq91EjY84H5cIlw2GUfpUo0vWEy/bhm6nk0vgY072bLFk9auq9uwP7lo fQ92xlhQj60DalnxdAQKPQHVZJ3IP1NvTlXFuKZSrlzRO2/VzrRvL3foh8CSQWZDfy Oc83rek6Z3twzeHc4yJ5eu7xA7D3T0gjwNSyJ7esckeDg1xbqtoSopdiswOXkEER5B He2gqHl6yqByw==
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.2\))
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <CAL=9YSUKo4XOuBAXORqt58EmduEB5vPGN=0Zzw5bTaEdoDJfJg@mail.gmail.com>
Date: Mon, 13 Mar 2023 12:56:33 -0400
Cc: "idr@ietf. org" <idr@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7766AAAE-FC16-4824-8D58-1566EAC8E0A0@puck.nether.net>
References: <CAL=9YSUKo4XOuBAXORqt58EmduEB5vPGN=0Zzw5bTaEdoDJfJg@mail.gmail.com>
To: Ben Cox <ben=40benjojo.co.uk@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3696.120.41.1.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/YpUxzOegJTHpPO5JfptjvbM6p3o>
Subject: Re: [Idr] Questions over draft-retana-idr-bgp-quic-01
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Mar 2023 16:56:40 -0000


> On Mar 13, 2023, at 9:27 AM, Ben Cox <ben=40benjojo.co.uk@dmarc.ietf.org> wrote:
> 
> Hi IDR/Authors of draft-retana-idr-bgp-quic-01 (who are CC'd)
> 
> I was wondering on the direct motivations for this draft, you
> mentioned that you wish to use QUIC as a way to better mitigate the
> impact of errors when using multi-protocol sessions (to avoid taking
> down other protocols with one error in one protocol out of many)
> 
> I'm curious about two things:
> 
> One, are you intending for this to be used as an inter-AS solution or
> is this more of an internal AS deployment?
> 
> Second, are you able to provide any examples of these errors taking
> down entire connections that have happened to you in the past?

Not an author, but yes.  If you were to use this internally you MAY be able to coordinate changes, but for external changes (even different lines of business within same company for example) it may not be possible, or there could be an initial misconfiguration that happens.  Is there someone who is familiar with QUIC that is also familiar with long lived TCP sessions and/or routing that has some insights?

> Are
> these MP sessions like v4+v6 address families, or other things?

Yes, to enable a new AFI over the same transport (eg: v4 unicast to v4 unicast + v4 multicast) would require tearing down the MP-BGP session and restart it which can be undesirable operational outcome.

I have my own concerns about the lack of stability within QUIC standards here as well.  We often see TCP sessions up for several years carrying BGP data, and most of the QUIC stuff is extremely short lived, while a 7 year+ TCP (BGP) session isn’t as unusual as one might think.


> I believe that using QUIC for this mechanism is a pretty sizeable
> thing to integrate, so I’m interested in figuring out if there is a
> more lightweight way to doing this


Keeping a stable transport while adding AFI (eg: enable v6 AFI, or VPN AFI) without causing next-hops and routes to be invalidated and flap based on the capability negotiation change which happens in the initial open exchange today does have operational value.

> 
> 
> Cheers
> Ben
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

v2.23.0 | Report a Bug | By Email