Re: [alto] unified-props, cellular addresses and path-vector - registry

"Y. Richard Yang" <yry@cs.yale.edu> Fri, 02 March 2018 23:44 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 21FF01242EA for <alto@ietfa.amsl.com>; Fri, 2 Mar 2018 15:44:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 tRSSRUQir2iE for <alto@ietfa.amsl.com>; Fri, 2 Mar 2018 15:44:23 -0800 (PST)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 91E001200C1 for <alto@ietf.org>; Fri, 2 Mar 2018 15:44:22 -0800 (PST)
Received: by mail-lf0-x232.google.com with SMTP id t204so15543921lff.9 for <alto@ietf.org>; Fri, 02 Mar 2018 15:44:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=YXXZeZhrQKEFDz+BB2XBExmYpprj3UY98YvS91pGnvQ=; b=AlD8n6i4HvcwvseXdhl3UgRAv8p/E6OXEfhldLPLxaXThFaVGGpWk30OeLWVUcprrF pijyGLyrBThy7KVCYiG/Xe41AZzSESjNHEPMOokGDaXEU8Au/fvihtxdt7cocj0nj8kj CRurWJg7aWvBbTiSAOvT6DxhRcgTPdZIJUu2EvQrqmzyQ6m8NCo+rjjT2g9OnLnGtbY9 eqezEORr2ogHWnXwwFtA3hDuOtorvx+n1t28p0wEsFxoMVroJzIBKf51dHe8dLz2+boV nyXF6hmyQ6qrdVhpZL7eM9FIqD9gWhl25oJ95meS0i8mL1ygcHaEuGZSQKChdWCttX5h JYkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=YXXZeZhrQKEFDz+BB2XBExmYpprj3UY98YvS91pGnvQ=; b=qgfvJi2a2qWoXPuB+zm76gfnZPWozodjPCxn5pMNR+ovcKYaaMokYg9TMsUfTvI+pm ay74jc6ShwCJCUMmzIjl0ycgDj33UxIiFeOVJzTaMeUYhvngg6Ygqo1iNbHdGlNAtvZw 1pNRvA9AYzSTPBAFKDFj9Vh+bwID6w7y75aTP5ahGpMvdfZdAJqRYIQ+kVjNZ8aweWTD ZZZpcKbFYvR8fbI7PsyGoLIqj/1JYPWMdjfvL3xLK5zwfOqejSPyvjr8mvUC9IlhaX+O VB4/E6/uhsORTTO6yG5j476I6OOk3UUQTxAjafDLrmV7BdzlYeCKuiau1hvHijvjYfgl lqZg==
X-Gm-Message-State: AElRT7GkJxbvENR3DI5Lk7aMQqa+TOxO/cRe3h9/RpatQxnbJO5BN5PI Hwsl9diZ+Q3Ul2oJFzSuzpSKLCtlStXNn8uWoiAI+g==
X-Google-Smtp-Source: AG47ELsYNgq4dDmCvWW47Tq74pnXU6k2luLXGyq61CFyGHP9pzRfSEzby14I3qWqW4nXz6qCEPWQo50MoR9cdBs25W4=
X-Received: by 10.25.89.12 with SMTP id n12mr5348142lfb.10.1520034260801; Fri, 02 Mar 2018 15:44:20 -0800 (PST)
MIME-Version: 1.0
Sender: yang.r.yang@gmail.com
Received: by 10.46.50.26 with HTTP; Fri, 2 Mar 2018 15:44:20 -0800 (PST)
In-Reply-To: <CAAbpuypBz14UbPVnEAHsBE-t=U8tzMjmWH=WRpJtcYhmu42pwA@mail.gmail.com>
References: <HE1PR0702MB3738A4DBCC0A7B0FC1F4945695C00@HE1PR0702MB3738.eurprd07.prod.outlook.com> <CAAbpuypBz14UbPVnEAHsBE-t=U8tzMjmWH=WRpJtcYhmu42pwA@mail.gmail.com>
From: "Y. Richard Yang" <yry@cs.yale.edu>
Date: Fri, 2 Mar 2018 18:44:20 -0500
X-Google-Sender-Auth: Qa6JM6RLnB0clnq48zS6s_1H1LM
Message-ID: <CANUuoLoUWsgU7YJs7npi+t8Jh_h-ZBRLcBSNa8yWe6vEt-XS1w@mail.gmail.com>
To: Jensen Zhang <jingxuan.n.zhang@gmail.com>
Cc: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <sabine.randriamasy@nokia-bell-labs.com>, "alto@ietf.org" <alto@ietf.org>
Content-Type: multipart/alternative; boundary="001a11412e182961a20566768e5a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/ctZhN5zZaNBcGgGVqNxfpC18r_4>
Subject: Re: [alto] unified-props, cellular addresses and path-vector - registry
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 02 Mar 2018 23:44:26 -0000

Hi Jensen,

Thanks for the comments. Please see below.

On Thu, Mar 1, 2018 at 3:12 AM, Jensen Zhang <jingxuan.n.zhang@gmail.com>
wrote:

> Hi Sabine, all
>
> Let me post some considerations on this topic. Please see my comments
> inline.
>
> On Wed, Feb 28, 2018 at 6:17 AM Randriamasy, Sabine (Nokia -
> FR/Paris-Saclay) <sabine.randriamasy@nokia-bell-labs.com> wrote:
>
>> Hi Jensen, Kai, Vijay, all
>>
>>
>>
>> Thanks all for this discussion on registries, which needs a separate
>> thread so I added “registry” to the initial thread.
>>
>> The ALTO Entity Domain Registry of the Unified Properties (UP) draft is
>> to be seen as an extension of the ALTO Address Type Registry specified in
>> RFC 7285. Indeed ipv4 and ipv6 map to both ALTO Address Type and ALTO
>> Domain Type where the latter set covers the first one.
>>
>>
>>
> Yes. I think the goal of the ALTO Entity Domain Registry is to be an
> extension of the ALTO Address Type Registry. But the relationship between
> these two registries need to be clarified in the documents.
>

This is a good discussion. I can see two views regarding the extension word:
1. ALTO Entity Domain Registry is a superset of ALTO Address Type Registry;
2. ALTO Entity Domain Registry and ALTO Address Type Registry are two
distinct sets, and we only want the intersection to be specified
consistently.

My understanding/view is one, and we should make it clear.


>
>
>> Definitely, Jensen’s explanations (items 1) and 2) ) in his e-mail of Feb
>> 27, 2018 at 3:10 PM should be used in sections 2.7 or 9.2 of the UP draft
>> to clarify the relation between both.
>>
>>
>>
> Yes, agree. I will edit it.
>

OK. Let's edit it.


>
>
>> For section 9.2  of the UP draft, I agree with Jensen’s views and
>> understand Kai’s concerns. We may consider adding a sentence generalized
>> from Sections 3.1.1.2 and 3.1.2.2 to have something like :
>>
>> "When a new address type is registered in the ALTO Address Type Registry
>> of [RFC7285], the same identifier MUST be also registered in the ALTO
>> Entity Domain Registry. And the Entity Address Encoding for this entity
>> domain identifier MUST cover both Address Encoding and Prefix Encoding of
>> the same identifier registered in the ALTO Address Type Registry [RFC7285]."
>>
>> “For the purpose of defining properties, an individual Entity address and
>> the corresponding full-length prefix are considered aliases for the same
>> entity.”
>>
>>
>>
> Yes, such a sentence is helpful.
>
>
>> Would this help addressing the issue?
>>
>>
> Yes, enforce address type registered as entity domain can help to
> guarantee consistency. But I think it is not enough.
>
> Considering a prior document registers a new entity domain called 'AAA'
> first, the 'AAA' can be a valid entity domain but not a valid address type
> at this moment. Then, another later document registers a new address type
> also called 'AAA'. If the encoding of the address type 'AAA' is not
> consistent with the encoding of the entity domain 'AAA', there will be some
> issue.
>
> So I propose we add a new column in the ALTO Entity Domain Registry table,
> maybe called 'Valid for ALTO Addresses', to indicate which entity domain
> can also be used as an address type and which cannot. Those entity domains
> marked as 'Valid for ALTO Addresses' don't have to be registered in ALTO
> Address Type Registry again. In this way, we can make 'ALTO Entity Domain
> Registry' a superset of 'ALTO Address Type Registry'. But of course, other
> columns of the ALTO Entity Domain Registry should be adjusted to
> distinguish individual address encoding from the prefix/block address
> encoding.
>
> Any thougthts?
>
>
This seems to be a good idea---I always like syntax enforced consistency.

Thanks!
Richard



> Thanks,
> Jensen
>
>
>>
>> Thanks,
>>
>> Sabine
>>
>>
>>
>>
>>
>>
>>
>> *From:* alto [mailto:alto-bounces@ietf.org] *On Behalf Of *Jensen Zhang
>> *Sent:* Tuesday, February 27, 2018 10:11 AM
>> *To:* Kai Gao <gaok12@mails.tsinghua.edu.cn>
>> *Cc:* alto@ietf.org
>> *Subject:* Re: [alto] unified-props, cellular addresses and path-vector
>>
>>
>>
>> Hi Kai,
>>
>> Thanks for your comment. See inline.
>>
>> On Tue, Feb 27, 2018 at 4:38 PM Kai Gao <gaok12@mails.tsinghua.edu.cn>
>> wrote:
>>
>> Hi Jensen,
>>
>> Please see inline.
>>
>>
>>
>> On 02/27/2018 03:44 PM, Jensen Zhang wrote:
>>
>> Hi all,
>>
>>
>>
>> Continue the discussion above. I suggest modifying the first paragraph of
>> page 26 of draft-ietf-alto-unified-props-new-01
>>
>>
>>
>> "It is RECOMMANDED that a new ALTO entity domain be registered when the
>> corresponding address type is registered based on ALTO Address Type
>> Registry [RFC7285]."
>>
>>
>>
>> as the following:
>>
>>
>>
>> "When a new address type is registered in the ALTO Address Type Registry
>> [RFC7285], the same identifier MUST be also registered in the ALTO Entity
>> Domain Registry. And the Entity Address Encoding of this entity domain
>> identifier MUST include both Address Encoding and Prefix Encoding of the
>> same identifier registered in the ALTO Address Type Registry [RFC7285]."
>>
>> It might be odd to have two encodings for a single entry. Since address
>> encoding is actually a special case of prefix encoding, maybe we can use
>> prefix encoding alone?
>>
>>
>>
>> The words may need to be revised. But we indeed hope to accept both
>> Address Encoding and Prefix Encoding as the valid Entity Address Encoding.
>> Using prefix encoding alone is not consistent with what "ipv4" and "ipv6"
>> domain do in Section 3.1 of draft-alto-unified-props-new-01.
>>
>>
>>
>>
>>
>> Any comment?
>>
>>
>>
>>
>>
>> On Tue, Feb 27, 2018 at 3:10 PM Jensen Zhang <jingxuan.n.zhang@gmail.com>
>> wrote:
>>
>> Hi Vijay,
>>
>> It is a good point to explain the relationship of "ALTO Address Type
>> Registry" and "ALTO Entity Domain Registry".
>>
>>
>>
>> See my comment inline.
>>
>> On Tue, Feb 27, 2018 at 3:21 AM Vijay K. Gurbani <vijay.gurbani@nokia.com>
>> wrote:
>>
>> [As co-chair]
>>
>> Sabine, Richard: If you decide to proceed as you outline below, then
>> please realize that time is of essence.
>>
>> [As individual contributor]
>>
>> I am a bit confused by this discussion though.  Are cellular addresses
>> ALTO address types?  In which case they will have to be registered in
>> the ALTO Address Type Registry as detailed in Section 14.4 of the base
>> ALTO RFC [1].
>>
>> Yes, cellular address are ALTO address types. So of course they should be
>> registered in the "ALTO Address Type Registry" based on RFC7285.
>>
>>
>>
>> Or are cellular address ALTO entities?  In which case they will have to
>> be registered through unified-props registry in Section 9.2 of the
>> unified-props document [2]?
>>
>> And yes, cellular addresses "should" also be ALTO entities. But let's
>> delay the answer to this question and see the following questions first.
>>
>>
>>
>> Why do we have legacy identifiers like 'ipv4' and 'ipv6' being
>> registered in two registries, i.e., in the registries of [1] and [2]?
>>
>> In fact, why do we have a ALTO Entity Domain Registry in [2] at all?
>>
>> Why we introduce a new Registry? Because the key idea is to move the
>> property map service from endpoint scope to the more general scope (which
>> we call "entity domain" in the draft).
>>
>>
>>
>> So,
>>
>> 1) in this general scope, *an entity MAY or MAY NOT be an endpoint*. For
>> example, "pid" is introduced as an entity domain, but it is not an endpoint
>> address type. To allow this, we need this new registry.
>>
>> 2) But to cover the capability of the endpoint property service, *an
>> endpoint MUST be an entity*. As the result, "ipv4" and "ipv6" are
>> registered in both "ALTO Address Type Register" and "ALTO Entity Domain
>> Registry".
>>
>>
>>
>> Now let's go back to the question "are cellular addresses ALTO
>> entities?". Sure, as they are ALTO endpoint addresses, they MUST be ALTO
>> entities. So they MUST be registered in the "ALTO Entity Domain Registry".
>>
>>
>>
>> I am afraid I am missing something ... can you please elaborate?
>>
>>
>>
>> Is it clear now? Do we agree on this? Or Sabine and Richad want to say
>> anything?
>>
>>
>>
>> I think we need to well define the process of the ALTO Entity Domain
>> Registry to guarantee the syntax and semantics of the same indentifier
>> registered in both Registries are consistent. And I think this may be a
>> missing item in the current unified-props draft. If we fix this part, the
>> draft should be ready.
>>
>>
>>
>> Thanks,
>>
>> Jensen
>>
>>
>>
>>
>>
>> [1] https://tools.ietf.org/html/rfc7285#section-14.4
>> [2]
>> https://tools.ietf.org/html/draft-ietf-alto-unified-props-
>> new-01#section-9.2
>>
>> Thanks,
>>
>> On 02/26/2018 10:18 AM, Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
>> wrote:
>> > Hi Richard,
>> >
>> > I agree, the Unified Property draft is definitely a good placeholder for
>> > the cellular addresses. Domain and entities are already defined in
>> > https://tools.ietf.org/html/draft-randriamasy-alto-cellular-adresses-01
>> > . So how about in a next step, we consider pouring the content of the
>> > latter draft in the UP draft and in a further step propose a list of
>> > properties, while looking at other WG to see whether they already
>> > specified any?
>>
>> - vijay
>> --
>> Vijay K. Gurbani / vijay.gurbani@nokia.com
>> Network Data Science, Nokia Networks
>> Calendar: http://goo.gl/x3Ogq
>>
>> _______________________________________________
>> alto mailing list
>> alto@ietf.org
>> https://www.ietf.org/mailman/listinfo/alto
>>
>>
>>
>> _______________________________________________
>>
>> alto mailing list
>>
>> alto@ietf.org
>>
>> https://www.ietf.org/mailman/listinfo/alto
>>
>>
>>
>>
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
>


-- 
-- 
 =====================================
| Y. Richard Yang <yry@cs.yale.edu>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================