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

Jensen Zhang <jingxuan.n.zhang@gmail.com> Tue, 27 February 2018 09:11 UTC

Return-Path: <jingxuan.n.zhang@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 2E90C1241FC for <alto@ietfa.amsl.com>; Tue, 27 Feb 2018 01:11:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 JP_RwYoB3kvU for <alto@ietfa.amsl.com>; Tue, 27 Feb 2018 01:11:22 -0800 (PST)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 70B141201F2 for <alto@ietf.org>; Tue, 27 Feb 2018 01:11:22 -0800 (PST)
Received: by mail-yw0-x22d.google.com with SMTP id b70so6069572ywh.5 for <alto@ietf.org>; Tue, 27 Feb 2018 01:11:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O0kXIPGMVJgy/tx4sQ6VHw6XI8o7DRf0LMAb+x6lSSE=; b=cjE8q0TFlqfiz5dcEc8aYMQSRl97S61LSEJ7FN4cbjC+Cj6FZifhO6JZGWFkDYAbyb HFPF+tR9S2I5VurHSLA/G87OY31pcs8K47HerwDwA3GvbP+Y00qC7X/tKRjTPW9nJcIh s3CzwoN+MY4Ou+keroUTrG9lIA6Cgh9P6deRYHoacup7kBaxF+dWK+/XEmR8ItsmLdXZ vfA1t5ks4+olYJ/NpHPtVXoKS7HLBHpYe8tzAEgc3LDdLkYMNAfX50wBPx8YSnh1cm63 xNZCtuN/4HbSpP5/2+IoNnSPCKBUjjbEenxhyjS8D5y4TS+QDlg9QP8d8JErHt52Ke+8 rzYg==
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=O0kXIPGMVJgy/tx4sQ6VHw6XI8o7DRf0LMAb+x6lSSE=; b=jPR7ie/YeLPjBbVk+ELY4k3Cb62kjRThh+9QVlc+K5TV/vTxj9x6O/74OFN0XgU1C7 CmeO9CFmbrByJHYGfMKXjeQkdtRBX2LlO1F1mLUblhOGbgIA4s7DwVyn6Vixan0PJuTE gvq+1mwN4oVMe6gj2BBzekLjqHFfeUx6pmXwTlOvDrl9p9GCnPxXa7uGA+yC9Xwny/mK lYWVnJNFCuLW++8Cmc6KQOmA037hxo4cITXCXZvLvnrB0V9+9yD8RrlkoVrxnl3Ulqom D/ig8kelhTjc5GuD0Fhx9w0V/HKQbrfuL1Ts7focjEESBGF9eQQv695OCd38PwhWtKSN JXaw==
X-Gm-Message-State: APf1xPDv+Q7X0r8saD7O97xzILYPOescUaHcGv9OMD/v+4l1DqSiK+QQ 7ZUHK9EfNuWCjPu6RMywJzQQaAI1Qs63i4kdCEA=
X-Google-Smtp-Source: AG47ELvX4FxXHKWUUYqy/6YlE2vo3/kjRZYMArIn6A0dhsQwUCwnRlTj8XD+ktNWfHfViBHhSPMas2PtTh7wzhzIgJg=
X-Received: by 10.13.253.131 with SMTP id n125mr8612762ywf.129.1519722681658; Tue, 27 Feb 2018 01:11:21 -0800 (PST)
MIME-Version: 1.0
References: <5e6a98ff-3c8d-f1b8-2deb-21788cdfef09@nokia.com> <BLUPR02MB1202578B8645F956E30B7066B5CC0@BLUPR02MB1202.namprd02.prod.outlook.com> <CANUuoLrAR=b9b36extXU6Hc6VSv1ExsD7Yze09b8WUnfSnbJCg@mail.gmail.com> <HE1PR0702MB3738F145B3656EEC8E59957795C10@HE1PR0702MB3738.eurprd07.prod.outlook.com> <ce583dd3-f378-e465-bd20-14b295a43366@nokia.com> <CAAbpuypzb6=42zYq9r16Zi69r62d0CpPyrFUmWT+oQg7=MqBuA@mail.gmail.com> <CAAbpuyo=f9-WfN257Q5CU5SEzqZzBgSK1YMsUTxYNg=U4k_e7g@mail.gmail.com> <d1881c03-9642-ccb5-3e27-e8ccda42e1f2@mails.tsinghua.edu.cn>
In-Reply-To: <d1881c03-9642-ccb5-3e27-e8ccda42e1f2@mails.tsinghua.edu.cn>
From: Jensen Zhang <jingxuan.n.zhang@gmail.com>
Date: Tue, 27 Feb 2018 09:11:11 +0000
Message-ID: <CAAbpuyoFzmh35Dmc_vGTK86rX9O0aF1uOUK-Od0BEVhLKURGWQ@mail.gmail.com>
To: Kai Gao <gaok12@mails.tsinghua.edu.cn>
Cc: "Vijay K. Gurbani" <vijay.gurbani@nokia.com>, "alto@ietf.org" <alto@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c06919a98f42b05662e0233"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/3zm0oGMZWhbkQ_CS1PPaZG9HlDU>
Subject: Re: [alto] unified-props, cellular addresses and path-vector
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: Tue, 27 Feb 2018 09:11:25 -0000

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 listalto@ietf.orghttps://www.ietf.org/mailman/listinfo/alto
>
>
>