Re: [alto] 109 recharter working Google doc

"Y. Richard Yang" <yry@cs.yale.edu> Tue, 17 November 2020 00:52 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 EE8C23A17A7 for <alto@ietfa.amsl.com>; Mon, 16 Nov 2020 16:52:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.279
X-Spam-Level:
X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.677, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EY4RfrFbjD63 for <alto@ietfa.amsl.com>; Mon, 16 Nov 2020 16:52:52 -0800 (PST)
Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D3103A17A6 for <alto@ietf.org>; Mon, 16 Nov 2020 16:52:52 -0800 (PST)
Received: by mail-lf1-f46.google.com with SMTP id j205so27800858lfj.6 for <alto@ietf.org>; Mon, 16 Nov 2020 16:52:52 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r1kZmn2nOBc7EeWvz1A44RHh45Q5Sgb3hlXftqoZ+cY=; b=Pwl4lCRjIDzQplJ9K8kPaWLCk62k8itmAKAsdUGEPSCfMk6nrJDJHJqa5aCOgYhlVi OESI7jbxysWa1jEdFFwmyaccgwDn2d0/Ckgg8ETt9vSTrvioD8cMhjXI7sxIIDAaFdR5 I6uuXlmJt1zssorCYeVFgZkWupdfx6k5n6J5NteIS1cztmH/JlfIFc7ojXp1NE2aFk4a QmjchpcQFFdXANl2+VmfWTZlow2Bi0SQXl9sV/E6y30HZXqRJQBFiyO7ctoXdR//6LgR ejvzPKiQOZndI15IOiCqYXolWqdgu24Qv/S8hpRopJO6BGoFhTDiINYLtqiqsAGwdwJT 2KbQ==
X-Gm-Message-State: AOAM5332vAz4I2zDAJt7OO3cTjRVs87KxJPM1NCbmzFHznVQAPfxpT4F +sLzmxCvGlNh5WigmN1W2Ihc2lxvJtVrNPlVMMg=
X-Google-Smtp-Source: ABdhPJzY6q51Dy/wvvYdYL5T6J6rkB3WxMrxvEEC6zm1rcWYhfAs9KDBp2XRrtD43hyHEhFvejP6TwQm84skEb4WnFg=
X-Received: by 2002:ac2:5cd4:: with SMTP id f20mr706618lfq.302.1605574370075; Mon, 16 Nov 2020 16:52:50 -0800 (PST)
MIME-Version: 1.0
References: <B8F9A780D330094D99AF023C5877DABAADB7EF5A@dggeml511-mbs.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABAADB7EF5A@dggeml511-mbs.china.huawei.com>
From: "Y. Richard Yang" <yry@cs.yale.edu>
Date: Mon, 16 Nov 2020 19:52:39 -0500
Message-ID: <CANUuoLovgxVBtV7mOM4mjRMpyRmXr33xcqo48Tv+R55LVDjx8Q@mail.gmail.com>
To: Qin Wu <bill.wu@huawei.com>
Cc: "Chunshan Xiong (Tencent)" <chunshxiong@tencent.com>, "Gang Li (China Mobile)" <ligangyf@chinamobile.com>, "Yannis (Yunfei) Zhang" <yanniszhang@tencent.com>, "Walid, Anwar (Nokia - US/Murray Hill)" <anwar.walid@nokia-bell-labs.com>, Sebastian Kiesel <ietf-alto@skiesel.de>, "Randriamasy, Sabine (Nokia - FR)" <sabine.randriamasy@nokia-bell-labs.com>, LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>, Jensen Zhang <jensen@jensen-zhang.site>, Kai Gao <kaigao@scu.edu.cn>, Börje Ohlman <borje.ohlman@ericsson.com>, Vijay Gurbani <vijay.gurbani@gmail.com>, Jan Seedorf <jan.seedorf@hft-stuttgart.de>, Martin Duke <martin.h.duke@gmail.com>, IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fd2b0405b442e96f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/ya0Tx5USy7i1jQn63g4lOQQSGTQ>
X-Mailman-Approved-At: Sun, 29 Nov 2020 17:13:29 -0800
Subject: Re: [alto] 109 recharter working Google doc
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
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, 17 Nov 2020 00:52:55 -0000

+ Moved the discussions to include the mailing list as well, as the
comments and feedback are excellent!

Hi Qin,

Thanks a lot for the comments. Please see inline.

On Mon, Nov 16, 2020 at 7:16 AM Qin Wu <bill.wu@huawei.com> wrote:

> Thanks Richard for the update on multi-domain discussion, I have a few
> questions on this deck of slides:
>
> 1.       RFC7971 provides ALTO deployment consideration, one assumption
> it made is
>
> " The ALTO protocol is designed for use cases where the ALTO server and
> client can be located in
>
> different organizations or trust domains. ALTO is inherently
>
>    designed for use in multi-domain environments.  Most importantly,
>
>    ALTO is designed to enable deployments in which the ALTO server and
>
>    the ALTO client are not located within the same administrative
>
>    domain. "
>
> That seems to indicate Multiple administrative domains should be supported? Does the assumption in the RFC7971 still hold?
>
> To my understanding, multiple administrative domains can be supported by Cascaded servers [RFC7971], i.e.,each administration domain
>
> has a ALTO server, ALTO server in another separate domain acting as alto client can query the ALTO server in each domain and aggregate network topology information and exposed to the other ALTO client
>
>
>
> Also ALTO server can get topology data from different data source such as BGP, SNMP, NETCONF,etc in different administrative domain? RFC7752 figure 3 provide one of such use cases. It seems multiple domain proposal require
>
> ALTO server to server synchronization, either forward ALTO client request from one server to another server? Or ALTO server in the middle domain send new request to the server in the next domain? The big challenge is to the amount    of path information and cost data to be returned can be huge.
>
>
>
> Thanks for making clear the text of RFC7961! Multidomain should still be
the basic environment. The current ALTO services, as they are designed, can
work in a multidomain environment, say using cascading servers, in some
settings. There are two things missing: (1) there is no document specifying
the complete multidomain querying process, which we want to fix; and (2)
the current design can have issues in some multidomain settings; for
example, when conducting cascading query, the downstream ALTO server may
have multiple ingress points for the same flow (e.g., ECS specified by
src/dst IPs). The current design assumes that either the downstream can try
to go upstream to identify the ingress or assume that there is only one
ingress (in some cases can be true). I will make some slides to clarify.


> 2.       I see multi-domain proposal as flow based query, I am wondering how multi-domain proposal is related to flow based query (https://datatracker.ietf.org/doc/draft-gao-alto-fcs/)? Is multi-domain proposal focus on IP layer flow query?
>
>
Good point. If we proceed with generic flow-based queries (ECS and cost map
are IP layer only, and hence are just special cases), we can make
multidomain to be generic flow aware. It looks that generic flow is the
direction of many networks.


> 3.       is there any ALTO protocol extension? E.g., network map
> extension, Cost map extension, or property map extension?
>
>
> Not sure I fully understand the question. Some generic extensions (e.g.,
the one by Sabine) will extend cost map and property map. Is this what you
have in mind?

Thanks again!

Richard


> -Qin
>
> *发件人:* Y. Richard Yang [mailto:yry@cs.yale.edu]
> *发送时间:* 2020年11月13日 8:05
> *收件人:* Chunshan Xiong (Tencent) <chunshxiong@tencent.com>; Gang Li (China
> Mobile) <ligangyf@chinamobile.com>; Yannis (Yunfei) Zhang <
> yanniszhang@tencent.com>; Walid, Anwar (Nokia - US/Murray Hill) <
> anwar.walid@nokia-bell-labs.com>; Sebastian Kiesel <ietf-alto@skiesel.de>;
> Randriamasy, Sabine (Nokia - FR) <sabine.randriamasy@nokia-bell-labs.com>;
> LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>;
> Jensen Zhang <jensen@jensen-zhang.site>; Kai Gao <kaigao@scu.edu.cn>;
> Börje Ohlman <borje.ohlman@ericsson.com>
> *抄送:* Qin Wu <bill.wu@huawei.com>; Vijay Gurbani <vijay.gurbani@gmail.com>;
> Jan Seedorf <jan.seedorf@hft-stuttgart.de>; Martin Duke <
> martin.h.duke@gmail.com>
> *主题:* Re: 109 recharter working Google doc
>
>
>
> Dear all,
>
>
>
> I made a deck of slides intended to be used for the multidomain discussion
> meeting next week during IETF109. It is attached to this email.
>
>
>
> Any feedback will be highly appreciated. I will send it to the broad
> mailing list as well.
>
>
>
> Richard
>
>
>
> On Wed, Nov 11, 2020 at 10:16 PM Y. Richard Yang <yry@cs.yale.edu> wrote:
>
> Hi all,
>
>
>
> It is exactly one week from tomorrow when we will have the IETF 109
> meeting on ALTO recharter discussions. I cleaned up the Google doc a bit so
> that we all have the same format:
>
>
> https://docs.google.com/document/d/1qP9jf-CMXvNiEE3YAnApTczAE4QkBW23Q1Eg99uOaEQ/edit?usp=sharing
>
>
>
> Please take a look and please revise. It will be nice if we all finish a
> stable version by Friday so that we have the slides to give each
> other feedback.
>
>
>
> Thanks a lot!!
>
>
>
> Richard
>
>