Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links

"Y. Richard Yang" <yry@cs.yale.edu> Tue, 27 June 2023 13:00 UTC

Return-Path: <yang.r.yang@gmail.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DD1C13AE50 for <alto@ietfa.amsl.com>; Tue, 27 Jun 2023 06:00:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.552
X-Spam-Level:
X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.096, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 sLcclqdnAaST for <alto@ietfa.amsl.com>; Tue, 27 Jun 2023 06:00:00 -0700 (PDT)
Received: from mail-ua1-f54.google.com (mail-ua1-f54.google.com [209.85.222.54]) (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 EB759C1575A3 for <alto@ietf.org>; Tue, 27 Jun 2023 06:00:00 -0700 (PDT)
Received: by mail-ua1-f54.google.com with SMTP id a1e0cc1a2514c-786e637f06dso1390463241.2 for <alto@ietf.org>; Tue, 27 Jun 2023 06:00:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687870800; x=1690462800; 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=UkrxFPSaCm46oklv8FxA1rMnXltop97DdbFJmE5nZVM=; b=U+JdQKfK5f0pEjUGSSLFZtPsSmqf1xr5Og5nJoxIcu+gq8qu6TZfoIZWvUpZE+vI1F ave5sXXmTYLM88/XiB9rt25fFXqbtcBmDeMQOj36TeRM4EbT252/oAZ9Xp06++a3A8MB DMO1HDmWTQmxGRrN4Tw11Le8zWPTtRXM4hvRt3r0y2crJGZq1NAeYhYLDO28Oou8kb2A 8gtpTuXcPB/L146I8Y1QQU75y967IxJGMRV/AfZLrp8uGipTarSimdTf0I/UoxF/40yR 4oLH19XBMGSeTwGuvOPhBg+sMPsSsB/V/M+Z4cI095wjVEubEnxcsFrbO4cvIEFDuIcd r45A==
X-Gm-Message-State: AC+VfDygD7g2FVHIZuR+bass2UfVMCHvSFcbudpXqrVfr6oXqjd4jSlz IBwoqloAf+It/iQJpjauoGez/hhhO4GXAm4IXcM=
X-Google-Smtp-Source: ACHHUZ7p+RrE2zyL7qGwto3Doub2bJQsq/CNbvopay6uHAuQ/Q3xaxHTmyh33saPukqk2bCYyglUkO2aBNBSXlmRWZc=
X-Received: by 2002:a05:6102:a2c:b0:443:6457:112 with SMTP id 12-20020a0561020a2c00b0044364570112mr2829503vsb.2.1687870799769; Tue, 27 Jun 2023 05:59:59 -0700 (PDT)
MIME-Version: 1.0
References: <CANUuoLrfh6L4ZWZVDOc-8SX7vOykhnsZb0vWu9uJ1v_BjRZqqA@mail.gmail.com> <DB9PR06MB79157443BECF6E6DD49F66B19E26A@DB9PR06MB7915.eurprd06.prod.outlook.com> <CANUuoLqhDit16McPNU4QgadFHz-hH4ianwMS2qUSEpbYwwdW3g@mail.gmail.com>
In-Reply-To: <CANUuoLqhDit16McPNU4QgadFHz-hH4ianwMS2qUSEpbYwwdW3g@mail.gmail.com>
From: "Y. Richard Yang" <yry@cs.yale.edu>
Date: Tue, 27 Jun 2023 08:59:48 -0400
Message-ID: <CANUuoLoavX+-i_idxdAYWHvW5W-Mb5viWgL78OrS7REE3aWYCQ@mail.gmail.com>
To: LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>
Cc: IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007273c105ff1c0b18"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/w40oW1N3pXrMRZtMzOLXbg0c-qU>
Subject: Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Jun 2023 13:00:01 -0000

On Tue, Jun 27, 2023 at 8:33 AM Y. Richard Yang <yry@cs.yale.edu> wrote:

> Hi Luis,
>
> Thank you so much for starting this thread on Topic B. I feel that this is
> a crucial topic for the WG to investigate. Please see below.
>
> On Mon, Jun 26, 2023 at 5:18 PM LUIS MIGUEL CONTRERAS MURILLO <
> luismiguel.contrerasmurillo@telefonica.com> wrote:
>
>> Hi all,
>>
>> Related to Topic B on maintenance of ALTO, as a way of summary of what
>> has been discussed during the last weeks, we could have two major
>> sub-topics:
>>
>> 1/ extension of ALTO to consider operational simplicity. Here fits the
>> proposal of introducing BGP communities in ALTO. The rationale is that
>> operators use BGP communities quite often as mechanism for applying
>> policies and determining certain behaviors on the IP addresses grouped in
>> the form of communities. This seems quite useful as well at the time of
>> exposing associated information (metrics, topology, etc) as enabled by
>> ALTO. An initial draft can be found here:
>> https://github.com/luismcontreras/alto-bgp-communities
>>
>> The plan is to generate version -01 for IETF 117.
>>
>

> I like this subtopic! I have adopted a view that ALTO should be divided
> into 2 layers: a concept/abstraction layer and a transport layer built on
> top of the concept layer. I feel that there is great work validating the
> concept layer, for example, the concepts of distance, ranking, say in the
> flow director, padis work. For transport later, the WG can be flexible and
> provide multiple transport mechanisms. BGP communities are an excellent,
> well defined framework to serve as a transport (of both existing alto
> concepts/abstractions) and also existing networking abstractions). Good
> direction.
>

To be specific, I think it will be a worthwhile effort to look into
BGP-ALTO; that is, how to use BGP to encode, transport and update ALTO
basic information. It can be considered a BGP vertical slice, with BGP-LS
as the lower lower layer. Make sense? I will add some more details to the
doc.

Talk to many of you soon.

Richard

>
>>
>