Re: [Idr] Part 3 of CAR/CT Adoption call (7/14/2022 to 7/27/2022) - Operational Differences

Jeffrey Haas <jhaas@pfrc.org> Sun, 24 July 2022 23:10 UTC

Return-Path: <jhaas@pfrc.org>
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 6AED9C072EA6 for <idr@ietfa.amsl.com>; Sun, 24 Jul 2022 16:10:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 qoKoGiBvAQZB for <idr@ietfa.amsl.com>; Sun, 24 Jul 2022 16:10:47 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3425FC0D2F7D for <idr@ietf.org>; Sun, 24 Jul 2022 16:10:47 -0700 (PDT)
Received: from smtpclient.apple (mobile-166-170-33-81.mycingular.net [166.170.33.81]) by slice.pfrc.org (Postfix) with ESMTPSA id DBE361E345; Sun, 24 Jul 2022 19:10:45 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-CD3B9510-895A-428D-83D1-F2DBA3010A11"
Content-Transfer-Encoding: 7bit
From: Jeffrey Haas <jhaas@pfrc.org>
Mime-Version: 1.0 (1.0)
Date: Sun, 24 Jul 2022 19:07:15 -0400
Message-Id: <20BFB298-BAD4-4CDE-A05A-40CD3A4FDBA7@pfrc.org>
References: <CAOj+MMGXTob8v90Lcor3ddKeQ81CLa43NtnnkR38ZYTjMFwwtg@mail.gmail.com>
Cc: Ketan Talaulikar <ketant.ietf@gmail.com>, Kaliraj Vairavakkalai <kaliraj@juniper.net>, Sue Hares <shares@ndzh.com>, idr@ietf.org
In-Reply-To: <CAOj+MMGXTob8v90Lcor3ddKeQ81CLa43NtnnkR38ZYTjMFwwtg@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: iPhone Mail (19F77)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/FnyvjhQpbWEzeVWDg4-cQTVHQF4>
Subject: Re: [Idr] Part 3 of CAR/CT Adoption call (7/14/2022 to 7/27/2022) - Operational Differences
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: Sun, 24 Jul 2022 23:10:48 -0000

Robert, 

A partial comment from my mobile device. 

Withdraw encoding will pack much denser. On a total withdraw you likely could pack 200 or more prefixes per update. 

Implicit withdraw via replacement is clearly same speed as initial advertisement. 

The stability dynamics and impact of service route re-resolution are largely the same as BGP labeled unicast. Thus, beware churning your transport routes. 



Jeff

> On Jul 24, 2022, at 12:28 PM, Robert Raszuk <robert@raszuk.net> wrote:
> 
> 
> Hi Jeff, 
> 
> Sure 300k times 5 colors makes it 1.5M ... 
> 
> So I have a few different questions here. 
> 
> Assume in CAR/CT enabled domain one color has transport problems ... say low latency is becoming not so low due to interface queuing is transiently congesting for whatever reason between P1 and P2 nodes (not even running any BGP). 
> 
> Q1 - How (by what exact protocol) and how fast such issue with forwarding a given color via this domain will be visible at the CAR/CT layer ? 
> 
> Q2 - Assume Q1 is done - do we now need to withdraw 300K routes based on one color brownout ? 
> 
> Q3 - According to your math such CAR/CT reaction will take 30 sec. What if transport problem is transient and occurs for say 5-10 sec every 40 sec ? 
> 
> Q4 - Is there in any document an analysis on dynamics of CAR/CT signalling needed to make this at all practical in real deployments vs ppts ? 
> 
> We keep burning energy on encoding, but apologies if I missed it but I am not seeing the full picture here.
> 
> Why not advertise just 5 colors between those domains in 5 NLRIs and define a new attribute to carry all the interdomain color mappings in it ? 
> 
> 5 being an example from the section 6.3.2 ... but realistically we could perhaps vastly simplify this if we define day one set of well-known colors instead of each domain inventing their own definition :) 
> 
> Maybe I am just too practical here - but your math inspired those questions :)
> 
> Many thx,
> R.
> 
> 
>> On Sun, Jul 24, 2022 at 4:47 PM Jeffrey Haas <jhaas@pfrc.org> wrote:
>> On Sun, Jul 24, 2022 at 10:44:49AM +0530, Ketan Talaulikar wrote:
>> > The scalability requirements are captured here:
>> > https://datatracker.ietf.org/doc/html/draft-hr-spring-intentaware-routing-using-color-00#section-6.3.2
>> > 
>> > This is the merged document that, I believe, captures the consensus that
>> > both the CAR and CT solutions aim to address.
>> 
>> Thanks, Ketan.
>> 
>> Roughly 1.5 million routes.
>> 
>> Presuming an example 10k update per second handling, roughly 2.5 minutes of
>> convergence time without packing optimizations.
>> 
>> -- Jeff