From nobody Mon Mar 13 09:56:41 2023 Return-Path: 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 ; 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 ; 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 ; 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 In-Reply-To: Date: Mon, 13 Mar 2023 12:56:33 -0400 Cc: "idr@ietf. org" Content-Transfer-Encoding: quoted-printable Message-Id: <7766AAAE-FC16-4824-8D58-1566EAC8E0A0@puck.nether.net> References: To: Ben Cox X-Mailer: Apple Mail (2.3696.120.41.1.2) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2023 16:56:40 -0000 > On Mar 13, 2023, at 9:27 AM, Ben Cox = wrote: >=20 > Hi IDR/Authors of draft-retana-idr-bgp-quic-01 (who are CC'd) >=20 > 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) >=20 > I'm curious about two things: >=20 > One, are you intending for this to be used as an inter-AS solution or > is this more of an internal AS deployment? >=20 > 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=E2=80=99t as unusual as one might think. > I believe that using QUIC for this mechanism is a pretty sizeable > thing to integrate, so I=E2=80=99m 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. >=20 >=20 > Cheers > Ben >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr