Re: [alto] Progress on the path vector draft and call for comments

"Y. Richard Yang" <yry@cs.yale.edu> Thu, 20 June 2019 19:27 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 B612912013A for <alto@ietfa.amsl.com>; Thu, 20 Jun 2019 12:27:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 NMVRBooJgy3m for <alto@ietfa.amsl.com>; Thu, 20 Jun 2019 12:27:54 -0700 (PDT)
Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.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 A6CE71200D8 for <alto@ietf.org>; Thu, 20 Jun 2019 12:27:54 -0700 (PDT)
Received: by mail-vs1-f46.google.com with SMTP id l125so2262584vsl.13 for <alto@ietf.org>; Thu, 20 Jun 2019 12:27:54 -0700 (PDT)
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=ZJIk2MZgvaLDnj1va8NdzGNTSPwUB5iD7tbqRw9W6X8=; b=p0ZcPQdbhx7cKj8H+dtwFFcqqS1rgszWFVfHB/ipzAi9UBU+dWAAb5nhMoA9BLRdjY TPsLGWMSOyNZASf/F4SgTXeX2BeOReh4pOO4tNlWqzGw1LSOgwWYzaW38Z3H7nlq4Lq4 MsHhwU0pCy8RXgaUHDws0Fr7sx9LJsHDIZ2ozoucp3DETNyi2TJgngn8XHP/Z7b4n0kW aB1fk4ww6Y06QORIMgoxYFS57xd+dlFGYoL6ben0zGPE5c9gPTH1OpUgwia8qG2C3WLP 1WVzw30WKwsvhHEOqAOWCP8xXBbVq2n3Vl3FnVpb76sNW0eT1fuL2r0Oss8Rsff1dhSb Dijg==
X-Gm-Message-State: APjAAAXsaVw6MAyy3p90ZEKfSt6vqDtZ6bo6VIdvVTZgNkZloW9I75f3 W65aFLByBEmfMerLFR96za9KgbcpWESd3k8pvbY=
X-Google-Smtp-Source: APXvYqy5eP87KRRd+0bc+Z5ls6BO7wyI+PyD6RtqKP4aT0X7B7PK2CUKPKr8zoVJc16RsFqDay7/5jB6pYkCHnIPUvc=
X-Received: by 2002:a67:8d8a:: with SMTP id p132mr8365856vsd.103.1561058873543; Thu, 20 Jun 2019 12:27:53 -0700 (PDT)
MIME-Version: 1.0
References: <CAOELiNPmCWoaVqcmQAL_L-08gcUp5j8trPKNez8Nipq2mUk17Q@mail.gmail.com>
In-Reply-To: <CAOELiNPmCWoaVqcmQAL_L-08gcUp5j8trPKNez8Nipq2mUk17Q@mail.gmail.com>
From: "Y. Richard Yang" <yry@cs.yale.edu>
Date: Thu, 20 Jun 2019 15:27:42 -0400
Message-ID: <CANUuoLr3b1rwN1QHyH5cZREQgXZ_i0dAM5tT4jpXb01j7qk+Gw@mail.gmail.com>
To: Kai GAO <godrickk@gmail.com>
Cc: IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a19191058bc6578d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/7TZT40FJ0Ns97mgZ91-0BRhFcEs>
Subject: Re: [alto] Progress on the path vector draft and call for comments
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: Thu, 20 Jun 2019 19:27:56 -0000

On Wed, Jun 19, 2019 at 8:19 AM Kai GAO <godrickk@gmail.com> wrote:

> Hi ALTO working group,
>
> 2. A mechanism to query properties of abstract network elements
>
> Since we move the property of an abstract network element out of the cost
> type, a new mechanism is required so that 1) a server can announce what
> properties can be contained in the response, and 2) a client can specify
> its desired properties.
>
> Unfortunately, this is one point where we don't have consensus. One simple
> solution is to add a new capability (e.g., "ane-properties") to the IRD
> entry, and a client should also specify the intended properties in the
> "ane-properties" field.
>
> A second option is to reuse the designs of unified property map.
> Precisely, a path vector service should announce at least one entity domain
> "ane" and associated properties, as defined in the unified property map
> draft.
>

Agree. There are a few design options which we need to agree on. A line of
reasoning is the following:
- An abstract network element is fundamentally a dynamic entity and hence
does not exist without the context of an abstraction query: (1) the
properties (e.g., available bandwidth) based on which it is created, and
(2) the properties, in addition to the creation properties, to return. So
this is a discussion on (2), right?

Richard