[alto] alto - Requested session has been scheduled for IETF 101

["IETF Secretariat"]

Dear Vijay Gurbani,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

alto Session 1 (2:30:00)
Monday, Afternoon Session II 1550-1720
Room Name: Palace C size: 50
-



Request Information:


-
Working Group Name: Application-Layer Traffic Optimization
Area Name: Transport Area
Session Requester: Vijay Gurbani

Number of Sessions: 1
Length of Session(s):  2.5 Hours
Number of Attendees: 25
Conflicts to Avoid: 
 First Priority: cdni sipcore i2rs nvo3 pce rtgwg tcpm tsvwg
 Second Priority: lmap dtn



People who must be present:
  Vijay K. Gurbani
  Jan Seedorf
  Mirja Kuehlewind

Resources Requested:

Special Requests:
  
-

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

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

[Randriamasy, Sabine (Nokia - FR/Paris-Saclay)]

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.

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.

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.”

Would this help addressing the issue?

Thanks,
Sabine



From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Jensen Zhang
Sent: Tuesday, February 27, 2018 10:11 AM
To: Kai Gao 
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 
> 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 
> 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 
> 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 

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

[Jensen Zhang]

Hi Kai,

Thanks for your comment. See inline.

On Tue, Feb 27, 2018 at 4:38 PM Kai Gao 
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 
> 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 
>> 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 

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

[Jensen Zhang]

Sabine,

Just add some additional comments to Dawn's proposal. In my opinion, I
think we need to make the unified-props draft minimal so that we can push
it to WGLC asap. So except for those entity domains which has been defined
in the existing RFCs (i.e. 'ipv4', 'ipv6', 'pid'), we should not introduce
more entity domains into this draft. Base on this principle, we also
suggest moving "ane" domain out of the current unified-prop draft.

And after the unified-prop draft is pushed to WGLC and published as RFC, we
can be comfortable with registering a bunch of practical entity domains and
properties (e.g. cellular addresses, cdni capabilities, ane, etc.) by
starting a new draft.

But before that, there is a major issue we need to fix. Just like what I
posted in the previous email, we need to figure out the consistency issue
between ALTO Address Type Registry and ALTO Entity Domain Registry. Whether
we add cellular addresses as a new entity domain or not, this issue has to
be fixed. Do you agree on this?

btw. Sabine, would you like to be a co-author of the unified-props draft?

Best,
Jensen

On Tue, Feb 27, 2018 at 4:25 PM Dawn Chan  wrote:

> Hi Sabine,
>
> Actually I do find the proposal of the entity domain “ecgi”, but I do not
> see the detailed definition in
> https://tools.ietf.org/html/draft-randriamasy-alto-cellular-adresses-01.
> Actually, since the concept of unified property is clean enough. And I
> still remember that Shawn proposed to add a new domain country code for
> CDNI. So the suggestion is to remove the whole  "Section 3.4 ANE Domain" in
> the unified property map, so that it will be defined in the path vector
> draft itself. This way, other entity domains can be registered in their own
> related document?
>
> Dawn
>
> On 27 Feb 2018, at 12: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?
>
> Sabine
>
> *From:* yang.r.y...@gmail.com [mailto:yang.r.y...@gmail.com
> ] *On Behalf Of *Y. Richard Yang
> *Sent:* Friday, February 23, 2018 8:11 PM
> *To:* Dawn Chan 
> *Cc:* Gurbani, Vijay (Nokia - US/Naperville) ;
> Wendy Roome ; Randriamasy, Sabine (Nokia -
> FR/Paris-Saclay) ; alto@ietf.org
> *Subject:* Re: unified-props, cellular addresses and path-vector
>
> It looks that the suggestion by Dawn is reasonable.
>
> I am taking a look again at the possibility of integrating cellular into
> UP quickly. An alternative is that we get it done shortly, in the next
> couple days.
>
> If this is the approach, Sabine is a great person to work together. Make
> sense, Sabine?
>
> Richard
>
>
> On Fri, Feb 23, 2018 at 1:31 AM, Dawn Chan 
> wrote:
>
> Hi all,
>
> Draft Unified Property is quite stable at the moment, and the major
> problem left is whether the cellular address needs to be appended.
> Actually, since the Unified Property maintains an entity domain registry to
> achieve extensibility so that we suggest the new entity domain cellular
> address to be registered in the
> https://www.ietf.org/id/draft-randriamasy-alto-cellular-adresses-01.txt 
> itself.
> This way, the draft Unified Property can proceed first.
>
> Besides, path-vector and unified property depend on each other so they
> should move as a bundle.
>
> Do you think this is a feasible solution?
>
>
> On 23 Feb 2018, at 3:16 AM, Vijay K. Gurbani 
> wrote:
>
> All: In preparation for moving the unified property draft [0] ahead, the
> minutes of the December 2017 Virtual Interim Meeting [1] indicate that
> the chairs seek answers to the following questions from the WG:
>
> (1) Are cellular addresses an important abstraction that the working
> group will like to introduce in ALTO?  Currently, cellular address
> format is specified in a companion draft [2].
>
> (2) If yes, is the unified-props-new draft the correct place to add the
> cellular representation?
>
> Please note that the unified property draft [0] gates path-vector [3],
> as there is a dependency of path-vector on unified-props.  Thus, the
> plan is to move these two drafts ahead as a bundle.
>
> Which means that we need to reach a conclusion on the questions posed
> above so unified-props and path-vector can move ahead.
>
> Please express an substantive opinion on the above questions in the
> mailing list.
>
> [0] 

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

[Kai Gao]

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?


Any comment?


On Tue, Feb 27, 2018 at 3:10 PM Jensen Zhang 
> 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
> 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.gurb...@nokia.com

Network Data Science, 

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

[Kai Gao]

Hi Vijay and all,

I think what Jensen elaborates here is that any address type has a 
corresponding entity domain. As unified property map is basically an 
extension to the endpoint property map, it also extends the domain of 
address types to entity domains.


Unfortunately, there are cases where we still need to distinguish 
between address type (for example, in endpoint cost map) and entity 
domain, so two registries seem inevitiable.


Regards,

Kai


On 02/27/2018 03:10 PM, Jensen Zhang 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 
> 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.gurb...@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