Re: [Idr] Part 2 of CAR/CT Adoption call (7/6 to 7/20) - Adoption of draft-dskc-bess-bgp-car-05.txt and draft-kaliraj-idr-bgp-classful-transport-planes-17.txt

Robert Raszuk <robert@raszuk.net> Sat, 16 July 2022 23:29 UTC

Return-Path: <robert@raszuk.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 58EB7C14CF04 for <idr@ietfa.amsl.com>; Sat, 16 Jul 2022 16:29:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.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 niA9yeN024vi for <idr@ietfa.amsl.com>; Sat, 16 Jul 2022 16:29:06 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 99CCCC14F721 for <idr@ietf.org>; Sat, 16 Jul 2022 16:29:06 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id e28so13605178lfj.4 for <idr@ietf.org>; Sat, 16 Jul 2022 16:29:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rB0Uu/UVHsRc8HBSpM9VQldgyrINrZpsAIgATfI8Ld4=; b=CzC77oDyb/5TiPNx/SmjEeE8EBMSaVADECvzXlSsw5DEt0gm8PQxuA1PGIFIYOvQZS iH7kItEmhcUx9dyOIVA/tmqbEXcd4lrY74ZKtpdglqoVEnT1ptKIzL0tjFomKzbgg8J/ 8Prr06zkdY3Rr49H9ygKzI50z1VtALaes9vd4cwtoq/FX4z+AIA2ae3dOfysyEmMRi71 RKmoUWxe6DhuNl4Xa9835QJ8HPJv1D4XFji9DveiEyLL3vxyDs7TUKzHwRZohoprTyv/ b0Gbw2mHzsVzaIUppK5Fwoswb2z614qh2mU8W/R9XJJkc9IZHGQ3/H2qhZE9PwMwekaI dIBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rB0Uu/UVHsRc8HBSpM9VQldgyrINrZpsAIgATfI8Ld4=; b=JKIIbykBV/9FrDGsL+RhbijPn6WVwHox0+4balzem43OgXbyMQ76+x4vx679cudcwm J7YZ9pjzFUi60fDNDWtBmHxZ+JmyTZL6+3UI2/zNA49YSbu1Li6eXbuoFOqBoeFr4pYJ U7FVpnTuRDUukZCRSDfc61NFUiqq8GLcuQ599Ml9/7wyvYNK5PECWUVL6FvJFRiIJfHi 9cAXaHFYVW8uJHgw72h++ztlz42T5SuRR9bL2Ml+W6XjuSTpPIh6DodNoyrU0GSEez1e U26afa+OPIR+X5LV9Dyg0RHAfXrIVH1frzobDfHRSrFWBGxgvQAEHWh/t0/WvW04ynLN XEOA==
X-Gm-Message-State: AJIora+ePql7j7J8m0sEYjq3QFl/3rnCuU+4zu2zda4AUD8GOGfeQCfm NOOH68lDfyw5obNuEWT/gTGQB9q4tHzjdd2Z1DxveA==
X-Google-Smtp-Source: AGRyM1ulBxpOIFlbBUhatgPxXp5USrzsJ/GUyoPbdb4AisHpqxZPU4lJFZNE/gJUGjUJgw6xn2cSMs829EDQ58aKOh0=
X-Received: by 2002:a05:6512:2204:b0:489:fd91:89ea with SMTP id h4-20020a056512220400b00489fd9189eamr12010594lfu.593.1658014144041; Sat, 16 Jul 2022 16:29:04 -0700 (PDT)
MIME-Version: 1.0
References: <E27754A9-964C-4D4F-B19C-688814E17829@tsinghua.org.cn>
In-Reply-To: <E27754A9-964C-4D4F-B19C-688814E17829@tsinghua.org.cn>
From: Robert Raszuk <robert@raszuk.net>
Date: Sun, 17 Jul 2022 01:28:53 +0200
Message-ID: <CAOj+MMEpWKgqsJkW2dDJjWA8jke8UwSrdT6+2usCAg9CWWYJ5A@mail.gmail.com>
To: Aijun Wang <wangaijun@tsinghua.org.cn>
Cc: idr <idr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000016a67e05e3f480dd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/pFGnuhuvcc4orDHRm6EJALKqG7s>
Subject: Re: [Idr] Part 2 of CAR/CT Adoption call (7/6 to 7/20) - Adoption of draft-dskc-bess-bgp-car-05.txt and draft-kaliraj-idr-bgp-classful-transport-planes-17.txt
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: Sat, 16 Jul 2022 23:29:10 -0000

Aijun,

> CT utilize the existing VPN infrastructure,

That is completely not true.

Both solutions define new NLRIs and use new SAFI.

Let's keep the facts straight.

Thx,
Robert.



On Sun, Jul 17, 2022 at 1:21 AM Aijun Wang <wangaijun@tsinghua.org.cn>
wrote:

> Hi, All:
>
> It seems that we need more additional comparisons based on the same use
> cases and topology that described in
> https://datatracker.ietf.org/doc/draft-hr-spring-intentaware-routing-using-color/ to
> make better judgment on the selection of different approaches.
> As operator, we are glad to select one solution that can interoperable
> with other among the key vendors. I think this can also reduce the
> implementation efforts for the vendors to support both of them.
>
> Regarding to the current two approaches, the followings are my thoughts
> and concerns:
> 1) The key difference for CT and CAR is where to put the color/transport
> class/intention within the BGP encoding.
> CT utilize the existing VPN infrastructure, CAR design one new NLRI
> encoding.
> 2) Then CT can utilize some existing mechanism(RTC) to filter the unwanted
> colored route, but CAR need to invent some new tools to achieve the same
> goal.
> 3) CAR can be easily accepted/incorporated with the SR/SRv6 Policy,
> whereas CT can easily be understood with the wide deployed RD/RT based VPN
> services.
>
> There are also some others technical differences between these two
> approaches, but as operator we have concerns more on the deployment
> scalability, operation complexity and the pressure on the edge, transit and
> border routers.
> For example, if the transport class in CT can be triggered automatically
> based on the received service intent, it can certainly release the operator
> from tedious configuration.
> Let’s continue the comparison on the 3rd part of this adoption call that
> raised by Sue.
>
>
> Aijun Wang
> China Telecom
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>