Re: [alto] Zaheduzzaman Sarker's Discuss on draft-ietf-alto-new-transport-17: (with DISCUSS and COMMENT)

[Kai GAO]

Hi Zaheduzzaman,

We are sorry for the late reply -- the mail was blocked by the spam
detector. Please see our responses inline.

Best,
Kai

On Thu, Oct 26, 2023 at 6:56 PM Zaheduzzaman Sarker via Datatracker <
nore...@ietf.org> wrote:

> Zaheduzzaman Sarker has entered the following ballot position for
> draft-ietf-alto-new-transport-17: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/
>
>
>
> --
> DISCUSS:
> --
>
> Thanks for working on this specification.
>
> I have following points which I want to discuss further -
>
> - I understand this new transport is supposed to take advantages of HTTP/2
> and
> HTTP/3 features and have backward compatibility with HTTP/1.x (x=1,
> likely). My
> take is, if I want to server ALTO server over HTTP2/ or HTTP/3 I would use
> this
> new transport. Now if I also want to also support HTTP1.x for whatever
> reasons
> then I have issue, should this new transport is sufficient to support all
> the
> HTTP versions up to HTTP/3? if yes, then why this does specification not
> update
> or even obsolete rfc8895? if the answer is NO, does that mean I need to
> implement both this specification and rfc8895 for HTTP1.1? This relation
> is not
> explicitly defined in this current draft, which it should.
>
> [KAI] Thanks for the comment. Yes, the new transport is sufficient to
support all HTTP
versions up to HTTP/3. The relationship between new transport and RFC8895
is also
raised by the IoT telechat review by Wesley Eddy. Our understanding is that
new
transport is not a replacement of ALTO/SSE, and these two extensions can be
combined
(see the introduction of -18 for more complete discussions).

- I am not convinced that incremental update actually reduces storage at
> ALTO
> server, how is that so? I don't think there is an strict requirement that
> all
> the ALTO clients need to be updated to the recent version to be functional
> (as
> described in this specification), that means unless the serve is sure that
> all
> the clients are updated to certain version it has to keep the update
> versions.
> As storage reduction is a motivation for the transport requirement this
> motivation need to be well described to derive the requirement.
>

[KAI] The "reduced storage" is compared to the case where the server stores
the contents
of each version. It is a motivation to use incremental updates (which
applies to RFC 8895
as well) and we consider incremental updates as one motivation for the new
transport.
Does this make sense?


> - I didn't find any explanation of how the "Concurrent, non-blocking update
> transmission" requirement is meet by the new transport. is this solved by
> the
> use of HTTP/3 with uses QUIC and does not have HOL blocking within a
> connection? Or is this addressed by multiple concurrent HTTP connection to
> the
> ALTO server? This need to be understood better and we should define what
> actually "Concurrent, non-blocking update transmission" means in this
> context
> of fetching updates.
>
>
[KAI] The requirement basically requires that incremental updates can be
transmitted
at the same time (concurrent) and the transmission of one update will not
be blocked
by the transmission of another update. This can be realized by 1) multiple
HTTP
connections, or 2) HTTP/3 using multiple streams. This is compared with RFC
8895
where SSE multiplexes the updates in a single sequence. You make a good
point that
we should clarify how this can be done with new transport. We will add a
paragraph to
Sec 2.1 and upload a revision soon.


> - The encoding or data type of "updates graph (ug)" and "version" is not
> defined. The example uses numeric numbers which is easy to understand with
> incremental values. However, unless and otherwise this data type is defined
> then it is up to the implementers to select that and which will lead to
> interoperability issues. or may be I am missing something here, that is
> why I
> need to discuss the intention here.
>
>
[KAI] The data type of the version tag (the one held by the client) is a
string (JSONString)
but the "version" used to compute the URLs is a sequence number
(JSONNumber), both
specified in Sec 6.2.


> -  Here we are composing URIs from the ug , that tells me without proper
> encoding on ug defined there might be some internationalization issues (see
> rfc6365). Has there been any thoughts or discussions on this encoding and
> potential issues?
>

Re: [alto] SECDIR Last Call review of draft-ietf-alto-new-transport-15

[Kai GAO]

Hi Donald,

Sorry for the late reply as the mail is not properly forwarded to my
primary email. Please see our responses inline and feel free to let us know
if there are further comments.

Best,
Kai

On Thu, Oct 12, 2023 at 10:38 AM Donald Eastlake  wrote:

> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  Document editors and WG chairs should treat these comments just
> like any other last call comments. Sorry this review is a bit late.
>
> The summary of this review is Ready with Issues.
>
> (I did an early review of the -07 version of this draft at which time
> I found only nits all of which were fixed.)
>
> *Security*
>
> While I'm not all that into ALTO, it seems to me that this draft is all
> about messages and message exchanges between ALTO entities where the
> security (authentication, encryption, ...) has been specified in previous
> standards track documents such as RFC 7285; however, in Section 9.3,
> it says the spoofed URIs can be avoided by "encrypting the requests"
> where I think it should say "authenticating" the requests. There are a
> few additional security considerations which seem to be covered by the
> Security Considerations section of this draft.
>

[KAI] You are right. In the meantime, after discussing with the AD and the
HTTPDIR reviewer, we eventually dropped the design of explicitly deleting a
TIPS view. So, it seems that spoofed URI is no longer a concern.


>
> *Other possible issues*
>
> - In the update from -14 to -15, huge numbers of all caps RFC 2119 key
> words have been lowercased. In many instances, this does not look
> right to me. (There are many other cases but one example is that in
> Section 8.4, all words in all upper case were lowercased.)
>
>
[KAI] We went over the keywords and hopefully they are in the right case
now. Some of the operational consideration sections are repetitive to
sections in RFC 8895 and are removed in -17, including Sec 8.4 in -15.


> - Although there is correct text elsewhere, the last paragraph of
> Section 6.4, page 24, seems to say you delete a TIPS view if
> heartbeats time out on one connection for that view. But shouldn't it
> be all connections going away as there might be multiple?
>
>
[KAI] Yes indeed. However, the heartbeat mechanism is no longer needed as
the server now has full control of TIPS views' lifecycles. But similarly,
the server is


> - I am a bit surprised there is nothing about jittering the heartbeat
> messages to be sure they can't get synchronized between muldtiple
> clients. Something like the time between them should be varied by an
> amount randomly selected in the range +0% to -40%.
>
>
[KAI] Previously the idea was to use multiple heartbeat messages to detect
the liveness of clients. Even for 2 messages, the variation is 100%, which
should be good enough. Of course, as we no longer have the heartbeat
mechanism now, this probably will not be an issue anymore.


> - Section 2.1, Page 6: I think there is something not quite right with
> the sentence "Prefetching updates can reduce the time to send the
> request, making it possible to achieve sub-RTT transmission of ALTO
> incremental updates." It seems muddled. Transmission speed /
> transmission time isn't affected by prefetching although, of course,
> the time to satisfy a request can be vastly reduced. Maybe
> "Prefetching updates can reduce the time to satisfy a request, makit
> it possible to achieve rapid, sub-RTT ALTO incremental updates."
>
>
[KAI] Thanks for the proposal. Will use the suggested text.


>
> *Nits*
>
> - Section 3.1, page 10, "(tag" -> "(a tag"
>

[KAI]  Nice catch. Updated as suggested.


>
> - Section 6.2, page 22, "time unit is second" -> "time unit is a second"
>

[KAI] The sentence is no longer there as heartbeat is removed in the new
version.


>
> Hope these comments are helpful.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e...@gmail.com
>
> ___
> 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

Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-09.txt

[Kai GAO]

Hi Sabine and all,

Probably I did not make myself clear. When I said the two sections are
similar to Sec 2 and Sec 5 in RFC 7285, I was mostly talking about the
structure instead of the contents.

I think a brief summary of what Sec 2 of UP draft looks like the follows:

> *ALTO information resources* contain relationships between different
*entities* and *entity properties* and constrain the *domain of valid
entities*.
> To aggregate and distribute such information to ALTO clients, we define a
new ALTO resource called Property Map.
> For efficiency, clarity and other practical concerns, we define 
> *resource-specific
entity domain*, *aggregated entity domain*, and *resource-specific entity
property*.

So we have two groups of concepts: those that motivate Property Map (i.e.,
WHY), and those that realize Property Map (HOW). The WHY concepts exist
once we identify the problem and do not depend on the solution (which
answers your second question), while the HOW concepts only exist because we
solve the problem in a particular way.

In RFC 7285, these two parts are put into two different sections. For
example, Network Map is aimed to provide the aggregation of endpoints,
using PID and endpoint address groups. Endpoint is in Sec 2, while PID and
Endpoint Address (Group) are in Sec 5 after the Network Map is introduced.

I feel we can use the same structure so we don't mix objectives and
solutions.

Best,
Kai


On Thu, Oct 10, 2019 at 9:07 PM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay)  wrote:

> Hi Jensen, Kai
>
>
>
> Thanks Kai for your suggestions, please see my comments inline
>
> Best regards,
>
> Sabine
>
>
>
>
>
> *From:* alto  *On Behalf Of *Kai GAO
> *Sent:* Thursday, October 10, 2019 5:42 AM
> *To:* Jensen Zhang 
> *Cc:* IETF ALTO 
> *Subject:* Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-09.txt
>
>
>
> Sounds good. :)
>
>
>
> On Thu, Oct 10, 2019 at 10:59 AM Jensen Zhang 
> wrote:
>
> Hi Kai,
>
>
>
> Great! This structure looks better to clarify those concepts. I would like
> to support it. If nobody has another proposal against it, let's add this
> change in the next revision.
>
>
>
> I can send a new draft to you by this weekend so that you can take another
> pass before we upload the next revision.
>
>
>
> Thanks,
>
> Jensen
>
>
>
>
>
> On Wed, Oct 9, 2019 at 10:46 PM Kai GAO  wrote:
>
> Hi Jensen and all,
>
>
>
> Actually, I would suggest the following structure:
>
>
>
> - Basic Concepts
>
>   - Information Resource
>
> *[[SR]] it is indeed good to start with the Information Resource that this
> draft introduces, which is the Property Map. Maybe provide a
> “human-readable” definition and explain how it extends properties from
> endpoints to entities and allows resource-specific entities and properties
> for purposes of locality and others. And say this will be detailed in
> further sections. Maybe also add a subsection with examples?  *
>
>   - Entity
>
>   - Entity Property
>
>   - Entity Domain
>
> - Property Map  <  Explain how property map works and the motivations
> for exporting and aggregating entity domains
>
>   - Resource-Specific Entity Domain
>
>   - Aggregated Entity Domain
>
>   - Resource-Specify Entity Property
>
>
>
> The two top-level sections (basic concepts and property map) are similar
> to Sec 2 (Terminology) and Sec 5 (Network Map) in RFC 7285.
>
>
>
> In the basic concepts section, we are describing what already exists even
> without the property map service.
>
> *[[SR]] Not sure I understand. RFC7285 supports Endpoint property maps,
> not Entity property maps. So what is it that already exists?   *
>
>
>
> In the property map section, we are "inventing" concepts that serve
> certain practical purposes (e.g., provide indications of what
> entities/properties can be queried, aggregate entities/properties).
>
>
>
> Having said that, it is OK with me that we keep the current structure or
> only make some small changes if it requires too much work.
>
>
>
> Best,
>
> Kai
>
>
>
>
>
>
>
> On Thu, Oct 10, 2019 at 12:11 AM Jensen Zhang 
> wrote:
>
> Hi Kai,
>
>
>
> I reviewed the document again. I think you are proposing the following
> restructure, right?
>
>
>
> Entity -> Information Resource -> Entity Property (Resource-Specific
> Entity Property) -> Property Map -> Entity Domain (Resource-Specific Entity
> Domain, Aggregated Entity Domain)
>
>
>
> Intuitively it looks good. But when you look into the motivation of
> Resource-Specific Entity Property, you will find it is weak here. Because
&g

Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-09.txt

[Kai GAO]

Sounds good. :)

On Thu, Oct 10, 2019 at 10:59 AM Jensen Zhang 
wrote:

> Hi Kai,
>
> Great! This structure looks better to clarify those concepts. I would like
> to support it. If nobody has another proposal against it, let's add this
> change in the next revision.
>
> I can send a new draft to you by this weekend so that you can take another
> pass before we upload the next revision.
>
> Thanks,
> Jensen
>
>
> On Wed, Oct 9, 2019 at 10:46 PM Kai GAO  wrote:
>
>> Hi Jensen and all,
>>
>> Actually, I would suggest the following structure:
>>
>> - Basic Concepts
>>   - Information Resource
>>   - Entity
>>   - Entity Property
>>   - Entity Domain
>> - Property Map  <  Explain how property map works and the motivations
>> for exporting and aggregating entity domains
>>   - Resource-Specific Entity Domain
>>   - Aggregated Entity Domain
>>   - Resource-Specify Entity Property
>>
>> The two top-level sections (basic concepts and property map) are similar
>> to Sec 2 (Terminology) and Sec 5 (Network Map) in RFC 7285.
>>
>> In the basic concepts section, we are describing what already exists even
>> without the property map service.
>>
>> In the property map section, we are "inventing" concepts that serve
>> certain practical purposes (e.g., provide indications of what
>> entities/properties can be queried, aggregate entities/properties).
>>
>> Having said that, it is OK with me that we keep the current structure or
>> only make some small changes if it requires too much work.
>>
>> Best,
>> Kai
>>
>>
>>
>> On Thu, Oct 10, 2019 at 12:11 AM Jensen Zhang 
>> wrote:
>>
>>> Hi Kai,
>>>
>>> I reviewed the document again. I think you are proposing the following
>>> restructure, right?
>>>
>>> Entity -> Information Resource -> Entity Property (Resource-Specific
>>> Entity Property) -> Property Map -> Entity Domain (Resource-Specific Entity
>>> Domain, Aggregated Entity Domain)
>>>
>>> Intuitively it looks good. But when you look into the motivation of
>>> Resource-Specific Entity Property, you will find it is weak here. Because
>>> only when you use the Aggregated Entity Domain representation in a Property
>>> Map, you will need this concept. Otherwise, it is useless. That is why I
>>> put it behind those two concepts. But maybe your intuition is right. The "
>>> Resource-Specific Entity Property" should be out of "Entity Domain". How
>>> about we move 2.5.4 to 2.6? How do you think?
>>>
>>> Best,
>>> Jensen
>>>
>>>
>>> On Wed, Oct 9, 2019 at 9:02 AM Kai GAO  wrote:
>>>
>>>> Hi Jensen and all,
>>>>
>>>> I'm looking at the -10 version and find it quite odd to have 2.5.4
>>>> Resource-specific Entity Property as a subsection of 2.4 Entity Domain..
>>>>
>>>> My suggestion is to move 2.5.4 to 2.2 instead. Another potential
>>>> improvement is to move 2.4 Information Resource before 2.2.
>>>>
>>>> Best,
>>>> Kai
>>>>
>>>>
>>>>
>>>> On Fri, Sep 27, 2019 at 5:28 AM Jensen Zhang <
>>>> jingxuan.n.zh...@gmail.com> wrote:
>>>>
>>>>> Hi Danny,
>>>>>
>>>>> Thanks for your review and comments. Sabine and I are working on the
>>>>> next revision. We will address all the issues in the next revision.
>>>>>
>>>>> And for your additional comment, actually, the "ip-pid-property-map"
>>>>> resource in IRD is an example of Aggregated Entity Domain. Sec 9.7 should
>>>>> illustrate it. But you are right, the current example in Sec 9.7 does not
>>>>> show the benefit of Aggregated Entity Domain. I will also revise this
>>>>> example in the next revision.
>>>>>
>>>>> Looking forward to your further comments.
>>>>>
>>>>> Thanks,
>>>>> Jensen
>>>>>
>>>>>
>>>>> On Wed, Sep 25, 2019 at 9:50 AM Danny Alex Lachos Perez <
>>>>> dlachos...@gmail.com> wrote:
>>>>>
>>>>>> Hi Sabine,
>>>>>>
>>>>>> I have a quick additional comment:
>>>>>>
>>>>>> I believe that an example (sec. 9) of Aggregated Entity Domain is
>>>>>> missing.
>>

Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-09.txt

[Kai GAO]

Hi Jensen and all,

Actually, I would suggest the following structure:

- Basic Concepts
  - Information Resource
  - Entity
  - Entity Property
  - Entity Domain
- Property Map  <  Explain how property map works and the motivations
for exporting and aggregating entity domains
  - Resource-Specific Entity Domain
  - Aggregated Entity Domain
  - Resource-Specify Entity Property

The two top-level sections (basic concepts and property map) are similar to
Sec 2 (Terminology) and Sec 5 (Network Map) in RFC 7285.

In the basic concepts section, we are describing what already exists even
without the property map service.

In the property map section, we are "inventing" concepts that serve certain
practical purposes (e.g., provide indications of what entities/properties
can be queried, aggregate entities/properties).

Having said that, it is OK with me that we keep the current structure or
only make some small changes if it requires too much work.

Best,
Kai



On Thu, Oct 10, 2019 at 12:11 AM Jensen Zhang 
wrote:

> Hi Kai,
>
> I reviewed the document again. I think you are proposing the following
> restructure, right?
>
> Entity -> Information Resource -> Entity Property (Resource-Specific
> Entity Property) -> Property Map -> Entity Domain (Resource-Specific Entity
> Domain, Aggregated Entity Domain)
>
> Intuitively it looks good. But when you look into the motivation of
> Resource-Specific Entity Property, you will find it is weak here. Because
> only when you use the Aggregated Entity Domain representation in a Property
> Map, you will need this concept. Otherwise, it is useless. That is why I
> put it behind those two concepts. But maybe your intuition is right. The "
> Resource-Specific Entity Property" should be out of "Entity Domain". How
> about we move 2.5.4 to 2.6? How do you think?
>
> Best,
> Jensen
>
>
> On Wed, Oct 9, 2019 at 9:02 AM Kai GAO  wrote:
>
>> Hi Jensen and all,
>>
>> I'm looking at the -10 version and find it quite odd to have 2.5.4
>> Resource-specific Entity Property as a subsection of 2.4 Entity Domain.
>>
>> My suggestion is to move 2.5.4 to 2.2 instead. Another potential
>> improvement is to move 2.4 Information Resource before 2.2.
>>
>> Best,
>> Kai
>>
>>
>>
>> On Fri, Sep 27, 2019 at 5:28 AM Jensen Zhang 
>> wrote:
>>
>>> Hi Danny,
>>>
>>> Thanks for your review and comments. Sabine and I are working on the
>>> next revision. We will address all the issues in the next revision.
>>>
>>> And for your additional comment, actually, the "ip-pid-property-map"
>>> resource in IRD is an example of Aggregated Entity Domain. Sec 9.7 should
>>> illustrate it. But you are right, the current example in Sec 9.7 does not
>>> show the benefit of Aggregated Entity Domain. I will also revise this
>>> example in the next revision.
>>>
>>> Looking forward to your further comments.
>>>
>>> Thanks,
>>> Jensen
>>>
>>>
>>> On Wed, Sep 25, 2019 at 9:50 AM Danny Alex Lachos Perez <
>>> dlachos...@gmail.com> wrote:
>>>
>>>> Hi Sabine,
>>>>
>>>> I have a quick additional comment:
>>>>
>>>> I believe that an example (sec. 9) of Aggregated Entity Domain is
>>>> missing.
>>>> Perhaps you could re-use (or extend) the IRD example [0] and try to add
>>>> a couple of sentences to indicate equivalent entity property mappings (see
>>>> slide 17, 18 in [1]).
>>>>
>>>> Best regards,
>>>>
>>>> Danny Lachos
>>>> [0]
>>>> https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-09#page-28
>>>> [1]
>>>> https://datatracker.ietf.org/meeting/105/materials/slides-105-alto-unified-properties-for-the-alto-protocol-02.pdf
>>>>
>>>> On Tue, Sep 24, 2019 at 10:42 AM Randriamasy, Sabine (Nokia -
>>>> FR/Paris-Saclay)  wrote:
>>>>
>>>>> Hi Danny,
>>>>>
>>>>>
>>>>>
>>>>> Many thanks for your review. I saw your last comment is in Section 9.7.
>>>>>
>>>>> Should we consider that until section 9.7 your review is complete or
>>>>> will you have more questions?
>>>>>
>>>>> We look forward to your other comments,
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Sabine
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>&g

Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-09.txt

[Kai GAO]

Hi Jensen and all,

I'm looking at the -10 version and find it quite odd to have 2.5.4
Resource-specific Entity Property as a subsection of 2.4 Entity Domain.

My suggestion is to move 2.5.4 to 2.2 instead. Another potential
improvement is to move 2.4 Information Resource before 2.2.

Best,
Kai



On Fri, Sep 27, 2019 at 5:28 AM Jensen Zhang 
wrote:

> Hi Danny,
>
> Thanks for your review and comments. Sabine and I are working on the next
> revision. We will address all the issues in the next revision.
>
> And for your additional comment, actually, the "ip-pid-property-map"
> resource in IRD is an example of Aggregated Entity Domain. Sec 9.7 should
> illustrate it. But you are right, the current example in Sec 9.7 does not
> show the benefit of Aggregated Entity Domain. I will also revise this
> example in the next revision.
>
> Looking forward to your further comments.
>
> Thanks,
> Jensen
>
>
> On Wed, Sep 25, 2019 at 9:50 AM Danny Alex Lachos Perez <
> dlachos...@gmail.com> wrote:
>
>> Hi Sabine,
>>
>> I have a quick additional comment:
>>
>> I believe that an example (sec. 9) of Aggregated Entity Domain is missing.
>> Perhaps you could re-use (or extend) the IRD example [0] and try to add a
>> couple of sentences to indicate equivalent entity property mappings (see
>> slide 17, 18 in [1]).
>>
>> Best regards,
>>
>> Danny Lachos
>> [0]
>> https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-09#page-28
>> [1]
>> https://datatracker.ietf.org/meeting/105/materials/slides-105-alto-unified-properties-for-the-alto-protocol-02.pdf
>>
>> On Tue, Sep 24, 2019 at 10:42 AM Randriamasy, Sabine (Nokia -
>> FR/Paris-Saclay)  wrote:
>>
>>> Hi Danny,
>>>
>>>
>>>
>>> Many thanks for your review. I saw your last comment is in Section 9.7.
>>>
>>> Should we consider that until section 9.7 your review is complete or
>>> will you have more questions?
>>>
>>> We look forward to your other comments,
>>>
>>> Best regards,
>>>
>>> Sabine
>>>
>>>
>>>
>>>
>>>
>>> *From:* alto  *On Behalf Of *Danny Alex Lachos
>>> Perez
>>> *Sent:* Tuesday, September 17, 2019 8:28 PM
>>> *To:* IETF ALTO 
>>> *Cc:* i-d-annou...@ietf.org
>>> *Subject:* Re: [alto] I-D Action:
>>> draft-ietf-alto-unified-props-new-09...txt
>>>
>>>
>>>
>>> Dear authors,
>>>
>>>
>>>
>>> I started to read the “*Unified Properties for the ALTO Protocol*” draft
>>> (-09).
>>>
>>>
>>>
>>> Please, see my first comments in the attached file (search for
>>> '[DANNY]').
>>>
>>> Many of them are suggestions about clarity and format issues .
>>>
>>>
>>>
>>> I will continue the review and send additional comments in a short time..
>>>
>>>
>>> Best regards,
>>>
>>>
>>>
>>> Danny Lachos
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Sep 4, 2019 at 10:41 AM  wrote:
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Application-Layer Traffic Optimization
>>> WG of the IETF.
>>>
>>> Title   : Unified Properties for the ALTO Protocol
>>> Authors : Wendy Roome
>>>   Sabine Randriamasy
>>>   Y. Richard Yang
>>>   Jingxuan Jensen Zhang
>>>   Kai Gao
>>> Filename: draft-ietf-alto-unified-props-new-09.txt
>>> Pages   : 43
>>> Date: 2019-09-04
>>>
>>> Abstract:
>>>This document extends the Application-Layer Traffic Optimization
>>>(ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint
>>>properties" to generic types of entities, and by presenting those
>>>properties as maps, similar to the network and cost maps in
>>>[RFC7285].
>>>
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>>>
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-09
>>>
>&

Re: [alto] ALTO meeting info for Sep. 18, 2019

[Kai GAO]

Hi all,

I'm very sorry but I had some trouble with the zoom Linux/Android clients
tonight. My apologies.

Best,
Kai


On Tue, Sep 17, 2019 at 11:27 PM Jensen Zhang 
wrote:

> Dear ALTOers,
>
> Just a friendly reminder that we will continue our weekly meeting this
> Wednesday (*Sep-18*) at *9:30 am US ET*.
>
> Current Agenda*:
>
>- Go over the initial ALTO interop script
>- Discuss about integration between ALTO and SENSE
>
> *If people have other agenda items, please feel free to post.
>
> Bridge: https://yale.zoom.us/my/yryang
>
> Best regards,
> Jensen
>
> --
> You received this message because you are subscribed to the Google Groups
> "alto-weekly-meeting" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to alto-weekly-meeting+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/alto-weekly-meeting/CAAbpuyrc%2BdFBFuUFH8xUR0-AL5zfW9HAENw5sPGjd%3DwzfEDbOg%40mail.gmail.com
> 
> .
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Meeting materials (self) upload reminder

[Kai GAO]

Thanks, Vijay! Everything works smoothly.

Best,
Kai

On Mon, Jul 22, 2019 at 9:26 PM Vijay Gurbani 
wrote:

> You need to be logged into datatracker.  If you do not have a login
> account, please create one.  Then you should be able to see the button.
>
> On Mon, Jul 22, 2019 at 8:24 AM Kai GAO  wrote:
>
>> Hi Vijay,
>>
>> Is there a browser requirement to upload the slides? I'm using Firefox on
>> Linux but cannot see the upload button.
>>
>> Best,
>> Kai
>>
>>
>> On Mon, Jul 22, 2019 at 9:17 PM Vijay Gurbani 
>> wrote:
>>
>>> Folks: Welcome to Montreal IETF.
>>>
>>> As you prepare your slides, please make sure to PDF them.  Also, given
>>> that we constantly tweak our slides until the last minute, perhaps a
>>> version number somewhere on the title slide will help.
>>>
>>> And finally, as I reported before, IETF now allows you to upload your
>>> slides yourself.  Please see [1] for more information.  Let's see if we can
>>> use this new feature.  Thus far, I don't think Jan and I have received any
>>> emails to approve slide uploads.
>>>
>>> [1]
>>> https://mailarchive.ietf.org/arch/msg/alto/63BlH6fmChuCLLQx_Pnl8vzoyTk
>>>
>>> Have fun in Montreal.
>>>
>>> Cheers,
>>>
>>> - vijay
>>> ___
>>> 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

Re: [alto] Meeting materials (self) upload reminder

[Kai GAO]

Hi Vijay,

Is there a browser requirement to upload the slides? I'm using Firefox on
Linux but cannot see the upload button.

Best,
Kai


On Mon, Jul 22, 2019 at 9:17 PM Vijay Gurbani 
wrote:

> Folks: Welcome to Montreal IETF.
>
> As you prepare your slides, please make sure to PDF them.  Also, given
> that we constantly tweak our slides until the last minute, perhaps a
> version number somewhere on the title slide will help.
>
> And finally, as I reported before, IETF now allows you to upload your
> slides yourself.  Please see [1] for more information.  Let's see if we can
> use this new feature.  Thus far, I don't think Jan and I have received any
> emails to approve slide uploads.
>
> [1] https://mailarchive.ietf.org/arch/msg/alto/63BlH6fmChuCLLQx_Pnl8vzoyTk
>
> Have fun in Montreal.
>
> Cheers,
>
> - vijay
> ___
> 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

Re: [alto] Second WGLC of draft-ietf-alto-cost-calendar (version -12)

[Kai GAO]

Hi Sabine and all,

I reviewed the diff between -11 and -12. The changes generally look good
but I spotted some minor issues:

- Title of Section 3.1: resources -> resource or resource's.
- In the first sentence of the last paragraph in section 2.4, the term
"cost Calendar" should be capitalized.
- In Section 4.1 and Section 5, some contents are using "ALTO client"
instead of "ALTO Client".

Best,
Kai


On Sat, Jul 20, 2019 at 11:51 AM Jensen Zhang 
wrote:

> Hi all,
>
> I reviewed the whole diff of the cost calendar draft between version -11
> and version -12. The modification looks good to me. I only have one small
> suggestion:
>
> In the new section 2.1 "Terminology":
>
> o  Calendar, Cost Calendar: When used with a capital "C", these terms
>
>refer to an ALTO Cost Calendar.
>
>
> 'with a capital "C"' may be confusing here. Because the first letters of both 
> "Cost" and "Calendar" are 'C'.  People may think "Cost calendar" is also a 
> term. Maybe "with capitalized words" is better?
>
>
> Thanks,
> Jensen
>
>
> On Fri, Jul 5, 2019 at 3:10 PM Vijay Gurbani 
> wrote:
>
>> One major correction:
>>
>> s/The current WGLC will be open until Jul-12-2019/The current WGLC will
>> be open until Jul-21-2019/
>>
>> The current WGLC will proceed until Jul-21-2019.
>>
>> Thanks.
>>
>> On Fri, Jul 5, 2019 at 1:53 PM Vijay Gurbani > > wrote:
>>
>>> All: The chairs will like to start a second WGLC for
>>> draft-ietf-alto-cost-calendar-12 [0].
>>>
>>> During the first WGLC, a couple of discusses were raised as documented
>>> in [1].  More specifically,
>>>
>>> 1/ Ben indicated a couple of edge cases that need to be resolved.
>>> 2/ Alvaro noted that there is IPR tied to the precursor of this draft,
>>> as detailed in [2].  The chairs will like to ensure that the WG is aware of
>>> the IPR declaration inherited by draft-ietf-alto-cost-calendar, and duly
>>> considers it during the second WGLC.
>>>
>>> Version -12 of the document (the one being WGLC'd) addresses the IESG
>>> discusses and comments, as well as a review by one of the chairs (Vijay).
>>>
>>> The current WGLC will be open until Jul-12-2019 (the start of the IETF
>>> week).  Please post your comments on this draft to the WG mailing list,
>>> even if the comment is simply to say that you support (or not) moving this
>>> work ahead.
>>>
>>> The chairs  will summarize the status of the draft at the end of WGLC
>>> period.
>>>
>>> [0] https://tools.ietf.org/html/draft-ietf-alto-cost-calendar-12
>>> [1]
>>> https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/ballot/
>>> [2]
>>> https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-alto-cost-calendar
>>>
>>> Thank you.
>>>
>>> - vijay
>>>
>> ___
>> 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

[alto] Link to the Path Vector Presentation on July 3rd

[Kai GAO]

Hello ALTO WG,

Please find the attached link [1] to the path vector presentation in the
last meeting. Your comments and feedback are always welcomed!

Best,
Kai

[1]
https://docs.google.com/presentation/d/16Jb9DERQXiFSKuMzssnB8E8Y0Z_w0ttN2QFrBCAw-mk/edit?usp=sharing
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

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

[Kai GAO]

On Fri, Jun 21, 2019 at 3:27 AM Y. Richard Yang  wrote:

>
> On Wed, Jun 19, 2019 at 8:19 AM Kai GAO  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?
>

Not exactly. Right now the path vector draft is mixing (1) and (2), at
least for ane properties. But yes, additional properties may also be
appended, such as endpoint properties mentioned by Sabine. I will include
that in the discussion.


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

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

[Kai GAO]

Hi ALTO working group,

After some internal discussions, we are reaching some agreements on the
path vector draft. Below are some key design points and your comments and
feedback are highly welcomed.

1. A new cost type for path vector

We feel more comfortable with the cost type used in -v05, where the mode is
"array" and the metric is "ane".

It conveys the idea that the results are JSON arrays and the values should
be interpreted as identifiers of abstract network elements.

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.

3. Encoding two messages

Each path vector response consists of an (endpoint) cost map and a unified
property map. Eventually, we decide to use the multipart/related media type
and specify whether it contains a cost map or an endpoint cost map in the
"type" parameter in the IRD.

This serves two purposes: 1) it guarantees the returned path vector and the
properties are consistent, and 2) it only takes one communication cycle and
the server doesn't have to keep the state.

We are going to present more details about the current design in the draft
discussion meeting next week (June 26) and hopefully finalize the design
before IETF 105 submission deadline (July 8). You are more than welcome to
join the discussion!

Many thanks!

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

Re: [alto] ALTO meeting info for May. 15, 2019

[Kai GAO]

Hi everyone,

Please find below the links to the presentation and the two papers
mentioned in the meeting.

Presentation:
https://docs.google.com/presentation/d/1NZO9mutCTU7lzBILCHPDuzw2zJIaCLN2jY0q-oPhtzM/edit?usp=sharing
Propane (SIGCOMM'16): http://doi.acm.org/10.1145/2934872.2934909
Noria (OSDI'18):
https://www.usenix.org/conference/osdi18/presentation/gjengset

Best,
Kai


On Wed, May 15, 2019 at 12:41 AM Danny Alex Lachos Perez <
dlachos...@gmail.com> wrote:

> Hello all,
>
> Just a friendly reminder that we will have our ALTO weekly meeting this
> Wednesday (*May-15*) at *9:30 am US ET*.
>
> Agenda:
>
>- Existing WG items
>
> Bridge: https://yale.zoom.us/j/8423318713
>
> Best regards,
>
> Danny Lachos
>
>
> On Tue, May 7, 2019 at 10:59 AM Danny Alex Lachos Perez <
> dlachos...@gmail.com> wrote:
>
>> Hello all,
>>
>> Just a friendly reminder that we will have our ALTO weekly meeting this
>> Wednesday (May-08) at 9:30 am US ET.
>>
>> Agenda*:
>>
>>- Extensions (5G, and other use cases)
>>- @Farni will talk about SCEF (Service Capability Exposure Function)
>>and ZSM (Zero-touch Service Management)
>>
>> *If people have other agenda items, please feel free to post.
>>
>> Bridge: https://yale.zoom.us/j/8423318713
>>
>> Best regards,
>>
>> Danny Lachos
>>
>>
>> On Tue, Apr 23, 2019 at 12:30 PM Danny Alex Lachos Perez <
>> dlachos...@gmail.com> wrote:
>>
>>> Hello all,
>>>
>>> Just a friendly reminder that we will have our ALTO weekly meeting this
>>> Wednesday (*Apr-24*) at *9:30 am US ET*.
>>>
>>> Agenda*:
>>>
>>>- Extensions (5G, and other use cases)
>>>   - Related work: SDN for End-to-End Networked Science at the
>>>   Exascale (SENSE) 
>>>- Working plan for May (3-5 mins)
>>>   - Tentative plan: Discussions about existing documents and
>>>   extensions in alternate weeks.
>>>- How to proceed regarding the reminder e-mails (3-5 mins)
>>>   - Current plan: Continue using the official wg mailing list
>>>   (alto@ietf)
>>>
>>> *If people have other agenda items, please feel free to post.
>>>
>>> Bridge: https://yale.zoom.us/j/8423318713
>>>
>>> Best regards,
>>>
>>> Danny Lachos
>>>
>>>
>>> On Tue, Apr 16, 2019 at 11:33 AM Y. Richard Yang 
>>> wrote:
>>>
 Dear all,

 This is a reminder that we will focus on the existing documents, in
 particular, the PV document during the meeting tomorrow. Hence, I
 anticipate a smaller group.

 To prepare for the meeting next week, may I suggest that, if you have
 time, please take a look at this SENSE project:
 https://ieeexplore.ieee.org/document/8648795

 It gives a more interactive, vision which we are part and looking at
 carefully.

 Cheers,
 Richard

 On Thu, Mar 28, 2019 at 1:34 PM Y. Richard Yang 
 wrote:

> Dear all,
>
> Thanks a lot to those who attended the IETF ALTO session the day
> before yesterday (Tuesday) either remotely using Meetecho or in person in
> Prague. For those who did not attend, it was a wonderful session, in which
> we discussed both the progress of existing WG documents and 3 potential
> remaining work. The chairs and AD provided clear guidance and suggestions!
>
> During the meeting, we mentioned the *Wednesday* weekly meetings
> started last year in which a team discusses both the existing WG documents
> and potential extensions.
>
> The schedule from this point is planned as the following: we discuss
> existing documents and extensions in alternate weeks, and hence the plan
> for the next 4 weeks is the following:
>
> - Apr. 3: Existing documents; in particular, Unified Properties and FCI
> - Apr. 10: Extensions (5G, and other use cases)
> - Apr. 17: Existing documents, in particular, PV
> - Apr. 24: Extensions (5G, and other use cases)
>
> Danny is our meeting tsar; and Jensen the backup tsar.
>
> It is not required that everyone attends each meeting, but any
> suggestions for topics are highly welcome. The meetings are *open*
> and feel free to join. To avoid spamming the alto@ietf mailing list,
> we will post meeting reminders for the first two meetings to alto@ietf
> and then will stop. *If you want to receive later reminders, please
> let me (Danny or Jensen) know, and we will love to have you.*
>
> The meetings are always at *9:30 US ET* (EU may change Daylight soon
> and we plan to stick to the US schedule for now).
>
> The meetings use *zoom* to allow sharing of slides:
> https://yale.zoom.us/j/8423318713
>
> Cheers,
> Y. Richard Yang
> Professor of Computer Science
>


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

Re: [alto] Adam Roach's No Objection on draft-ietf-alto-cost-calendar-09: (with COMMENT)

[Kai GAO]

Hi Adam,

Thanks for the clarification. Regarding the situation, I wonder if the
following procedure makes sense:

1. Extensions of the ALTO protocol should not explicitly cite a specific
(especially the obsoleted) JSON RFC but "follow the same JSON format as in
the base protocol (RFC 7285)".
2. Charter a draft to clarify the impacts of new JSON (and probably TLS
too) standards on all ALTO-related RFCs.

Or maybe we should have a standard paragraph stating the situation and put
it in every ALTO extension?

What do you think?

Best,
Kai


On Wed, Jan 30, 2019 at 3:30 AM Adam Roach  wrote:

> On 1/29/19 12:52 PM, Kai GAO wrote:
>
> Hi Adam and Benjamin,
>
> It appears to me that the JSON format is not specific to the cost calendar
> but a general problem with all ALTO extensions (or even all protocols
> encoded in JSON).
>
> I wonder if we have some kind of "best practice" in situations like this.
> For example, how do other protocols handle this if they originally cited
> RFC 7159?
>
>
> I can't offhand think of a protocol in a similar situation regarding JSON.
> In other similar cases, the course of action has been somewhat dependent on
> the nature of the changes between an older draft and a draft that obsoletes
> it. In many cases, changes are backwards-compatible, and I think there's an
> implicit assumption that new implementations will automatically make use of
> the newer document.
>
> In other cases where there have been breaking changes, I've seen working
> groups issue new clarification documents to "clean up" the discrepancy. For
> example, when RFC 6665 replaced RFC 3265, the SIPCORE working group created
> RFC 7647 to clarify the impact of those changes on RFC 3515. It wouldn't be
> unreasonable for ALTO to do something similar.
>
>
> Since you guys are more senior in the IETF, do you happen to know any RFC
> in a similar situation? I think that would be extremely helpful so we don't
> have to get into this fight for other on-going ALTO drafts.
>
>
> The decision made by the JSON working group when creating RFC 8259 was
> that the practice of trying to deal with multiple encodings was problematic
> from an interoperability perspective, and that practical interoperability
> is best achieved by always using UTF-8. The RFC itself attempts to capture
> this rationale:
>
>
>Previous specifications of JSON have not required the use of UTF-8
>when transmitting JSON text.  However, the vast majority of JSON-
>based software implementations have chosen to use the UTF-8 encoding,
>to the extent that it is the only encoding that achieves
>interoperability.
>
>
> A decision by the ALTO working group to intentionally use an obsoleted
> version of JSON puts it in the position of reverting consensus established
> by the JSON working group. While this kind of consensus revision is
> possible in the IETF, it needs to be part of the charter of the working
> group that is doing it. Given that ALTO is not chartered to revise JSON
> procedures, this isn't allowable.
>
> If you wanted to normatively cite RFC 8259 and then include non-normative
> text indicating that it is possible that older data might be written in
> UTF-16 or UTF-32, and that implementations might want a configuration
> option that allows reading such formats, I think that would be keeping in
> the spirit of the "part of a closed ecosystem" language in RFC 8259.
>
> /a
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Adam Roach's No Objection on draft-ietf-alto-cost-calendar-09: (with COMMENT)

[Kai GAO]

Hi Adam and Benjamin,

It appears to me that the JSON format is not specific to the cost calendar
but a general problem with all ALTO extensions (or even all protocols
encoded in JSON).

I wonder if we have some kind of "best practice" in situations like this.
For example, how do other protocols handle this if they originally cited
RFC 7159?

Since you guys are more senior in the IETF, do you happen to know any RFC
in a similar situation? I think that would be extremely helpful so we don't
have to get into this fight for other on-going ALTO drafts.

Many thanks!

Best,
Kai


On Wed, Jan 30, 2019 at 1:53 AM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay)  wrote:

> Hi Adam and Benjamin,
>
> Regarding the citation of RFC 8259, in the Introduction, using the JSON
> format as specified in RFC 8259 may actually cause backwards compatibility
> issues with RFC7285 that uses the JSON format specified in RFC7159. Would
> it be OK to cite 7159 in the Introduction and add the paragraph below in
> section 2.2.2 “Compatibility with legacy ALTO Clients" ?
>
> Thanks,
> Sabine
>
> Last, for backwards compatibility with ,
>   this extension encodes its requests and responses using the JSON
>   Data Interchange Format specified in ..
>   The latter has been obsoleted by ,
>   that among others makes UTF-8 mandatory for text encoding to
>   improve interoperability. Therefore, Clients and Servers
> supporting
>   ALTO Calendars SHOULD use UTF-8 for text encoding while still
> being able to
>   successfully read texts in other encodings such as UTF-16 and
> UTF-32.
>
> -Original Message-
> From: Adam Roach 
> Sent: Friday, January 25, 2019 10:25 PM
> To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <
> sabine.randriam...@nokia-bell-labs.com>; The IESG 
> Cc: draft-ietf-alto-cost-calen...@ietf.org; Gurbani, Vijay (Nokia -
> US/Naperville) ; alto-cha...@ietf.org;
> alto@ietf.org
> Subject: Re: Adam Roach's No Objection on
> draft-ietf-alto-cost-calendar-09: (with COMMENT)
>
> On 1/25/19 10:06 AM, Randriamasy, Sabine (Nokia - FR/Paris-Saclay) wrote:
> > [[SR]] The purpose is actually to lighten the reading. Would the
> following addition to paragraph 3 of section 4.1.3 be OK ?
> > "The Server returns Calendars with arrays of 12 numbers. To lighten the
> text, the arrays in the provided example are symbolized by expression
> "[v1,v2, ... v12]" that is otherwise not valid in JSON. The same type of
> symbolization is used in the example Server responses."
>
>
> That seems a reasonable approach. Thanks!
>
> /a
>
> ___
> 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

Re: [alto] Review on draft-ietf-alto-unified-props-new-04

[Kai GAO]

Hi Sabine and Jensen,

The reason why the inconsistency could happen is that there is no
restriction on how ATR is registered.

One way, as Sabine pointed out, is to extend the procedure in RFC 7285.

Appending a "mapping" column can leave RFC 7285 as it is. Meanwhile, new
domains are RECOMMENDED to follow the current procedure, which can help
avoid naming clashes with existing address types.

To conclude, unless the registration to ATR is updated, developers MUST not
assume a domain and an address type are equivalent even if they have the
same name.

Best,
Kai


On Tue, Dec 11, 2018 at 1:09 AM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay)  wrote:

> Hi Kai and Jensen,
>
>
>
> Thanks for pointing this out. Indeed the draft may have a section maybe
> 2.8 explaining how Endpoints are necessarily Entities. And it may recall
> this in section 9 explaining that the EDR is a superset of the ATR.
>
>
>
> If I got Kai’s point:
>
> - “Draft A proposes a new entity domain called "ABCP", which is not an
> address type. By the time of the registration, no address type of the same
> name exists...”
>
> We should add “and the entities in that domain are considered as **not**
> likely to be able to send/receive messages over a network”. Otherwise,
> these entities fall in definition 2.1 of RFC 7285 and are likely to be
> endpoints. In which case the Entity Domain registration MUST follow the
> procedure of section 9.2.1 and also register an new Address type with the
> same identifier.
>
>
>
> Suppose, it’s not the case, i.e. the “ABCP” registered in the EDR did not
> point to any addressable endpoint. When “Draft B proposes a new (ALTO)
> address type called "ABCP", which is registered to ATR.”, it MUST look up
> the EDR to see if the Domain Name ID “ABCP” is already present. If yes,
> there is no chance that “ABCP” will be present in the proposed column
> appended to EDR with the corresponding ALTO address type name “ABCP”,
> otherwise “ABCP” would already be present in the ATR.
>
>
>
> So I think Kai’s suggestion to append a “ATR mapping” column is useful for
> documentation and to prevent the risk pointed out, any registration of an
> address type that did not map to any standard “S” will need to look up the
> EDR. This rule will require to extend the ATR procedure defined in section
> 14.4 of RFC 7285. Some date-based filtering such as look up EDR if last
> update was before the standardization of “S”.
>
>
>
> Any opinion in the WG?
>
>
>
> Thanks,
>
> Sabine
>
>
>
>
>
> *From:* Jensen Zhang 
> *Sent:* Sunday, December 09, 2018 5:21 PM
> *To:* Gao Kai ; Randriamasy, Sabine (Nokia -
> FR/Paris-Saclay) ; Richard Yang <
> y...@cs.yale.edu>
> *Cc:* IETF ALTO 
> *Subject:* Re: [alto] Review on draft-ietf-alto-unified-props-new-04
>
>
>
> About the registry consistency, I agree that the current specification is
> not enough, although the definition of the consistency looks reasonable.
>
>
>
> Adding a column in EDR to alias to the id in ATR makes sense for me. It
> means that the EDR has more proactivity to enforce the consistency. It can
> avoid the new registration in ATR to break the consistency. And it only
> requires a slight change to the current specification. I support this
> design.
>
>
>
> Sabine and Richard, do you have any opinions?
>
>
>
> Best,
>
> Jensen
>
>
>
> On Sun, Dec 9, 2018, 10:45 AM Kai GAO  wrote:
>
> Hi all,
>
>
>
> Another issue is the consistency between Entity Domain Registry (EDR) and
> Address Type Registry (ATR).
>
>
>
> Even with the current proposal, it MAY not be able to guarantee
> consistency. Consider the following case:
>
>
>
> Draft A proposes a new entity domain called "ABCP", which is not an
> address type. By the time of the registration, no address type of the same
> name exists, so the entity domain is only registered to EDR.
>
>
>
> Draft B proposes a new address type called "ABCP", which is registered to
> ATR.
>
>
>
> Thus, it is impossible to "guarantee" consistency if ATR does not verify
> the registered domain names in EDR. In that case, it may be a better idea
> to NOT guarantee implicit consistency at all and make dependencies
> explicit. This can be easily achieved by appending a column to EDR with the
> corresponding address type name, (e.g., "ipv4" for "ipv4" and "ipv6" for
> "ipv6"). Thus, any library which supports UP extension should be able to
> translate an endpoint address to an entity address and vice versa.
>
>
>
> One way to think of it is that the conflicts mainly come from name
> clashes. This "fallback name" gives address type an alias in EDR, which
> resolves name clashes.
>
>
>
> Just my 2 cents.
>
>
>
> Best,
>
> Kai
>
> ___
> 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] Review on draft-ietf-alto-unified-props-new-04

[Kai GAO]

Hi all,

Another issue is the consistency between Entity Domain Registry (EDR) and
Address Type Registry (ATR).

Even with the current proposal, it MAY not be able to guarantee
consistency. Consider the following case:

Draft A proposes a new entity domain called "ABCP", which is not an address
type. By the time of the registration, no address type of the same name
exists, so the entity domain is only registered to EDR.

Draft B proposes a new address type called "ABCP", which is registered to
ATR.

Thus, it is impossible to "guarantee" consistency if ATR does not verify
the registered domain names in EDR. In that case, it may be a better idea
to NOT guarantee implicit consistency at all and make dependencies
explicit. This can be easily achieved by appending a column to EDR with the
corresponding address type name, (e.g., "ipv4" for "ipv4" and "ipv6" for
"ipv6"). Thus, any library which supports UP extension should be able to
translate an endpoint address to an entity address and vice versa.

One way to think of it is that the conflicts mainly come from name clashes.
This "fallback name" gives address type an alias in EDR, which resolves
name clashes.

Just my 2 cents.

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

[alto] Review on draft-ietf-alto-unified-props-new-04

[Kai GAO]

Hi everyone,

Below is a review on the unified property map extension:

1. In Sec 2.1, the first sentence reads "The entity is an extended concept
of the endpoint ...". Here the word "extended" may not be very precise, and
the term "generalization" (which is also used in the abstract) sounds
better. Generalization indicates that an endpoint is essentially an entity
while extension could be misleading and even incorrect. For example, in
certain languages, A extends B indicates that A is also B.

2. In Sec 2.2, an entity domain is defined as "a set of entities". This
seems odd because then one can say a set of two entities
{"ipv4:190.0.2.34", "pid:PID1"} is also a domain, which doesn't make sense.
An entity domain should be a generalization of endpoint address type, which
must define the syntax and semantics of the entity addresses in this
domain. Thus, borrowed from the definition of a domain in math, it could be
"the complete set of all possible values of a given address type". Here the
"given address type" is uniquely represented by the domain name, which
indicates the "semantics" for this domain, while syntax for "all possible
values" is defined by the "domain-specific entity addresses".

I also feel Sec 2 can be slightly rearranged for better clarity. Right now
there are a lot of cross-references between different concepts. I suggest
having a short section introducing the terms and then using a paragraph to
specify their relations, for example,

(domain name, domain-specific address type, hierarchies, relations)
-(1:1)-> domain -(1:n)-> entity address -(1:1)-> entity -(1:m)-> property
<-(1:1)- (property type, property value)

3. I think the draft should make it clear that the uniqueness of an entity
address only applies in the same unified property map. For example,
"pid:PID1" could point to different entities when two UPMs depend on two
different network maps, both have the PID "PID1".

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

[alto] Fwd: New Version Notification for draft-gao-alto-routing-state-abstraction-08.txt

[Kai Gao]

Dear ALTO WG,

The latest version (-08) has improved the clarity of the algorithms with 
simpler symbols and more detailed examples. Reviews and comments are 
welcomed!


Best Regards,

Kai



 Forwarded Message 
Subject: 	New Version Notification for 
draft-gao-alto-routing-state-abstraction-08.txt

Date:   Thu, 01 Mar 2018 21:41:15 -0800
From:   internet-dra...@ietf.org
To: 	Yang Yang <y...@cs.yale.edu>, Chen Gu <gc1993101...@gmail.com>, 
xinwang2...@hotmail.com <xinwang2...@hotmail.com>, Y. Richard Yang 
<y...@cs.yale.edu>, Xin Wang (Tony) <xinwang2...@hotmail.com>, Qiao Xiang 
<qiao.xi...@cs.yale.edu>, Kai Gao <gao...@mails.tsinghua.edu.cn>, 
G.Robert Chen <chenguo...@huawei.com>, G. Robert Chen 
<chenguo...@huawei.com>




A new version of I-D, draft-gao-alto-routing-state-abstraction-08.txt
has been successfully submitted by Kai Gao and posted to the
IETF repository.

Name:   draft-gao-alto-routing-state-abstraction
Revision:   08
Title:  Compressing ALTO Path Vectors
Document date:  2018-03-02
Group:  Individual Submission
Pages:  25
URL:
https://www.ietf.org/internet-drafts/draft-gao-alto-routing-state-abstraction-08.txt
Status: 
https://datatracker.ietf.org/doc/draft-gao-alto-routing-state-abstraction/
Htmlized:   
https://tools.ietf.org/html/draft-gao-alto-routing-state-abstraction-08
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-gao-alto-routing-state-abstraction-08
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-gao-alto-routing-state-abstraction-08

Abstract:
   The path vector extension [I-D.ietf-alto-path-vector] has extended
   the base ALTO protocol [RFC7285] with the ability to represent a more
   detailed view of the network which contains not only end-to-end costs
   but also information about shared bottlenecks.

   However, the view computed by straw man algorithms can contain
   redundant information and result in unnecessary communication
   overhead.  The situation gets even worse when certain ALTO extensions
   are enabled, for example, the incremental update extension
   [I-D.ietf-alto-incr-update-sse] which continuously pushes data
   changes to ALTO clients.  Redundant information can trigger
   unnecessary updates.

   In this document, several algorithms are described which can
   effectively reduce the redundancy in the network view while still
   providing the same information as in the original path vectors.


  



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

Re: [alto] Agenda requests for London IETF

[Kai Gao]

Hi Vijay and Jan,


I would like to request a slot on the path vector compression draft.

Time: 10min

Presenter: Kai (Jensen and Dawn may serve as backups)

Draft: 
https://datatracker.ietf.org/doc/draft-gao-alto-routing-state-abstraction/


Thanks very much!


Regards,

Kai


On 03/06/2018 01:09 AM, Vijay K. Gurbani wrote:

Folks: Pursuant to the call for agenda requests on Feb-17 [1], we have
only received a couple of agenda requests.

If you have sent them out, please make sure that you Cc both Jan and me,
and please make sure you get an acknowledgement.

If you have not sent them out, you should do so today as draft agendas
are due on Wednesday (tomorrow).

[1] https://www.ietf.org/mail-archive/web/alto/current/msg03606.html

Cheers,

- 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

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

[alto] Update on I-D draft-gao-alto-routing-state-abstraction

[Kai Gao]

Dear ALTO folks,

We have uploaded a newer version -07 of the Internet draft 
draft-gao-alto-routing-state-abstraction [1]. Your comments and feedback 
are most welcome!


The draft is a supplement to the path vector extension. It proposes 
several algorithms which can either be used to compute the on-demand 
path vectors, or be used as a post-processing step to compress the path 
vector results of an existing implementation.


This revision has mainly focused on the clarity of the algorithms with 
more examples. The draft will be presented at the interim meeting too.


Thanks very much!

Best regards,

Kai

[1] 
https://datatracker.ietf.org/doc/draft-gao-alto-routing-state-abstraction/


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

[alto] Review of draft-ietf-alto-performance-metrics-02

[Kai Gao]

Dear ALTO working group,

Below is a review of draft-ietf-alto-performance-metrics-02. Most of 
them are minor edits and I think section 2 could be better organized. 
Your feedback and comments are highly appreciated.


Thanks!

Regards,

Kai





p3, table 1, last row:
missing a "]"

p3, introduction, last paragraph

"explicitly specified" -> "standard" or "ISP independent"

p4, 2nd para

"If some are subject to ... them to the client"

Could be

"For example, those that are subject to privacy concerns should not be 
provided

to unauthorized ALTO clients."

p4, figure 1

"retrieve and aggregation" -> "retrieval and aggregation"

p4, 3rd para

SHOULD -> MUST since if a metric is not announced to clients in IRD, 
it's strange to say it's "supported".


p4, 4th para

further versions -> maybe "future extensions" is better? Can we add new 
types if this document becomes standard?


as for example, ... metrics. -> such as many metrics related to 
end-to-end path bandwidth.


ALTO may convey ... capacity related measurements. -> I don't quite 
understand this part. Is it saying ALTO should provide some unified 
aggregation mechanism since these metrics cannot be provided by a single 
party?


p4, 5th para

will rapidly give up... -> SHOULD/CAN rapidly give up

sec2

I wonder if we could use "Data sources and computation of ALTO 
performance cost metrics". Many metric specifications point back to this 
section so I think it should also give guidelines or suggestions while 
talking about challenges.


The specifications are generally good but is it possible to split the 
examples a bit? There are many large blank blocks.


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

Re: [alto] Proposed Path Aware Networking Research Group in Prague

[Kai Gao]

Hi Brian and all,

It is definitely closely related and I feel the target of PAN fits 
perfectly with the latest efforts within ALTO WG, in particular the path 
vector extension, which aim to provide fine-grained path information to 
higher-layer orchestrators/applications.


Our group would be very interested in PAN RG and we would try our best 
to attend.


Thanks for the information and wish you all the best!

Regards,

Kai


On 07/13/2017 11:35 PM, Brian Trammell (IETF) wrote:

Greetings, all, and apologies for the cross-posting,

We'll be having a first meeting of the proposed Path Aware Networking
(PAN) RG at IETF 99 in Prague next week, 13:30 Wednesday in Congress
Hall 3. It's been suggested The scope of this RG might be of interest
to your working group, research group, or BoF, so I hope you'll have
a chance to drop by. Olivier Bonaventure will give a review and overview
of research to date in this space, and Adrian Perrig will present a
fully path-aware Internet architecture, as an illustration of what is
possible when path-awareness is promoted to a first-order goal.

 From our proposed charter (https://datatracker.ietf.org/group/panrg/about):

The Internet architecture assumes a division between the end-to-end
functionality of the transport layer and the properties of the path between the
endpoints. The path is assumed to be invisible, homogeneous, singular, with
dynamics solely determined by the connectivity of the endpoints and the Internet
control plane. Endpoints have very little information about the paths over which
their traffic is carried, and no control at all beyond the destination address.

Increased diversity in access networks, and ubiquitous mobile connectivity, have
made this architecture's assumptions about paths less tenable. Multipath
protocols taking advantage of this mobile connectivity begin to show us a way
forward, though: if endpoints cannot control the path, at least they can
determine the properties of the path by choosing among paths available to them.

This research group aims to support research in bringing path awareness to
transport and application layer protocols, and to bring research in this space
to the attention of the Internet engineering and protocol design community.

The scope of work within the RG includes, but is not strictly limited to:

- communication and discovery of information about the properties of a path on
local networks and in internetworks, exploration of trust and risk models
associated with this information, and algorithms for path selection at
endpoints based on this information.

- algorithms for making transport-layer scheduling decisions based on
information about path properties.

- algorithms for reconciling path selection at endpoints with widely deployed
routing protocols and network operations best practices.

The research group's scope overlaps with existing IETF and IRTF efforts, and
will collaborate with groups chartered to work on multipath transport protocols
(MPTCP, QUIC, TSVWG), congestion control in multiply-connected environments
(ICCRG), and alternate routing architectures (e.g. LISP), and is related to
the questions raised in the multiple recent BoF sessions that have addressed
path awareness and multiply-connected networks (e.g. SPUD, PLUS, BANANA).

The PAN(P)RG intends to meet at each IETF meeting until a
determination is made whether or not to charter it. Afterward, the RG intends to
meet at 1-3 IETF meetings per year, and hold one workshop per year, collocated
with a related academic conference.

Thanks, cheers

Brian (as co-chair PAN PRG)


___
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

Re: [alto] Agenda requests

[Kai Gao]

Hi Vijay,

Thanks very much for the reminder. That'll do.

Best regards,

Kai


On 07/11/2017 04:26 AM, Vijay K. Gurbani wrote:

On 07/10/2017 09:34 AM, Gao Kai wrote:

Hi Vijay,

I'm very sorry for the delay. Could I schedule a slot as follows?

Name of presenter: Dawn Chen
Length of presentation: 10-15min
Associated draft: draft-gao-routing-state-abstraction

Gao: I am very sorry, but at this point the agenda is bursting at the
seams and there is absolutely no place for an non-chartered item.

For now, Jan and I will put you in an "overflow" section.  If by some
miracle, we complete ahead of time, you can get a 5' slot; if not, I
am afraid there is nothing much we can do.

Cheers,

- vijay



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

[alto] Reviews on draft-gao-alto-fcs-02

[Kai Gao]

Dear authors of draft-gao-alto-fcs,

I have roughly reviewed the latest FCS draft. Please see the comments below.


Regards,
Kai

Terminology:

sX: section X
ppX: page X
pX: paragraph X
lX: line X

pp3, s1, p1
l2: scenario -> scenarios
l3-4: "... the P2P application ..." -> "... P2P applications ..."

pp3, s1
p2, l2: central -> centralized
p2 & p3: I think these two paragraphs can benefit from some restructuring to
make the motivations for flow-based query more explicit and also easier 
to read.


pp3, s1, p5
l1: consider -> describe
l3: schema -> schemas


pp4, s1, p1
l2: "... 5-tuples of ..." -> Use the explicit form of the 5-tuple: "... 
5-tuple "

l6: "SHOULD support" -> "supports"
l7: "to satisfy" -> "and satisfies"

pp5, s3.1.2, p5
l4: "appeared" -> "appear"

pp6, s3.2
title: "Extend" -> "Extended"
p2, l2: "... to measure the cost" -> "... to specify the request"
p2, l3: "SHOULD" -> "MUST"
p2, l4: "be" -> "have"
p2, l5: "format" -> "formats"
p4, l2: Extra space after "TypedEndpointAddr"

pp6, s3.2.1, p1
l1: "contain" -> "can be"
l4: "specified" -> remove it.
l5: "be conflict" -> "conflict"
l6: "is conflict" -> "conflicts"

pp7, s3.2.3, p1: Use "Protocol" instead of "protocol" to make it 
explicit that

it represents the value contained in the query.

pp8
s3.3.1, p1, l1: Remove "then"
s3.3.2, p6, l4: "appeared" -> "appear"
s3.3.3, p1, l2: "exactly" -> "exactly the same"
s4, title: Example -> Examples

pp14, s4.2.3, p4, l3: "value types" -> "value type"

pp15, s4.2.5.1, p1, l5: ", the servers" -> ". The servers"

pp16, s4.2.5, p3, l3: "TypedHeadreField" -> "TypedHeaderField"


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

Re: [alto] Unified properties salient design points

[Kai Gao]

Hi all,

Shawn has raised an important issue that in a single unified property 
map, suggesting that entities of ALL "domain-types" MUST contain ALL 
types declared in "prop-types".


Regarding D3 in Richard's original post about "addressing" in different 
domains, one possibility is to define a global addressing for all domain 
types. For example, per-resource domain such as PID can have addresses 
like "PID:${network-map-id}.${PID}" while dynamic queries can also have 
addresses like "ane:${query-id}:${ane-id}" or even 
"ane:${pv-service-id}.${query-id}.${ane-id}.


Meanwhile, it seems reasonable that this unified property map should 
include corresponding network maps or cost services in "uses" field of 
its IRD entry.


Universal addressing assumes users can make queries on any property 
type, which may make optimization impossible if user only requires a 
subset of prop types.


Regards,
Kai


On 03/30/2017 11:22 AM, Shawn Lin wrote:

Hi Richard and all,

I have some thoughts about capabilities definition in property map. 
Currently, the capabilities is defined like this:



object {
DomainName domain-types<1..*>;
PropertyName prop-types<1..*>;
} PropertyMapCapabilities


It looks all good for IRD example in 7.3 in [EPM] because “ipv4” and 
“ipv6” are all belong to Internet Address Domain. But I think this 
capabilities definition does not expose the relationship between 
domain types and property types. Different domain types may have 
different set of property types and a same property name in different 
domain type may have different meanings (section 2.5 in [EPM]).



Let us consider the following example, a client receives a IRD 
information from a ALTO server,


“my-property-map”: {
…
“capabilities”: {
“domain-types”: [ “ipv4”, “pid” ],
“prop-types” : [ “country”, “state”,
“property-only-for-domain-type-pid”]
   }
…
}

and this client may construct its filter property map request like 
below since it does not know property “property-only-for-pid” is only 
for domain type pid.


{
“entities”: [ “ipv4:192.0.2.0/26 ”,
“ipv4:192.0.2.0/28 ” ],
“properties”: [ “property-only-for-domain-type-pid”]

}

Responses of this request will be always empty, while this client 
never knows that it construct a meaningless request.


One potential solution is that we can define capabilities as a map, 
domain -> {properties}.


object {
DomainName domain-types<1..*>;
DomainPropertyTypes domain-prop-types<1..*>;
} PropertyMapCapabilities
object {
 [JSONString domain-type];
 PropertyName prop-types<1..*>;
} DomainPropertyTypes;

The IRD information in above example can be modified like this:

“my-property-map”: {
…
“capabilities”: {
“domain-types”: [ “ipv4”, “pid” ],
“prop-types” : [
[“country”, “state”],  // ipv4->{properties}
[“country”, “state”, “pid-specified-property”]]//
pid->{properties}
   }
…
}


With additional information of the relationship between domain types 
and properties types, the client will not send meaningless request any 
more. :)


Bests,
Shawn Lin

[EPM] 
https://datatracker.ietf.org/doc/html/draft-roome-alto-unified-props-new 



On Wed, Mar 29, 2017 at 4:21 AM, Y. Richard Yang > wrote:


Dear all,

As multiple discussions, we feel that the unified properties draft
(), although not a working group draft, can be an important piece
to help finish several remaining working items.

For those who are not tracking the document, the design might
appear to be simple: it is after all just a simple key-value map.
When conducting a real design, many issues, many quite general,
however, appear. Hence the design can benefit from good feedback
from the good talents of this group. The objective of this email
is to make clear the salient points of the current design. We will
go over and discuss them Friday during the WG session.

D1. The goal is to provide properties to entities.

D2. Each entity must have an entity name to be identified. An
entity name is a typed (domained) string, in a format of
:, e.g., "ipv4:192.1.1.1", "pid:myid1",
"ane:myane111". The  provides essentially the type of the
name.

D3. There are essentially three types of domains: global,
per-resource, per-query (dynamic):

D3.1 ipv4 and ipv6 are global, in that they are not dependent on
particular resources;

D3.2 pid depends on a particular network map resource;

D3.3 ane (abstract network element) may depend on a particular
query of an ALTO resource. So far we cannot handle such case well.
There can be multiple design 

Re: [alto] Graph representation format deliverable as WG item

[Kai Gao]

Hi all,

I'd like to share with you some thoughts on the graph representation. 
Please see below.


As stated in RFC 7285 section 5.1:


  The definition of ALTO network maps is based on the observation that,
  in reality, many endpoints are near by to one another in terms of
  network connectivity.  By treating a group of nearby endpoints
  together as a single entity, an ALTO server indicates aggregation of
  these endpoints due to their proximity.  This aggregation can also
  lead to greater scalability without losing critical information when
  conveying other network information (e.g., when defining cost maps).


A major motivation for introducing PID is to allow an ALTO server to 
"aggregate these endpoints due to their proximity". Thus, we should 
consider endpoints which belong to the same PID but are not "near" as a 
result of bad aggregation. In this case, not only a path vector cannot 
be represented in a reasonable way, all routing costs can become less 
useful.


Given that a bad aggregation harms the efficacy of ALTO, I think we 
should have a consensus that it SHOULD be avoided. At least, endpoints 
within the same PID SHOULD be "close" in terms of the cost types 
provided in an associated cost map.


Therefore, I feel the question should be asked in the opposite way: how 
do we aggregate the endpoints so that path vectors between these PIDs 
make sense?


For example, if path vectors represent AS paths, PIDs can be aggregated 
by prefixes with the same AS path. If path vectors represent paths in an 
L2 network, PIDs should probably be aggregated by the attachment point 
or gateways.


I think we can emphasize this as a "guideline" or "best practice" for 
servers providing path vectors, because the aggregation requires domain 
knowledge and may vary in different scenarios.


Regards,
Kai
On 03/07/2017 08:32 AM, Jensen Zhang wrote:

Hi all,

We almost finish the update of path-vector draft. But here is a 
question I feel we need to discuss:


Shall we query the path vector between PIDs?

Because PIDs can be defined for many different reasons. The endpoints 
in the same PID may not be nearby. Even we consider the simplest use 
case, every PID is an AS, there may be still different routings 
between different ASes for loading balancing. So how to return the 
routing information by just using a path vector?


A simple solution is to introduce a new cost-mode (Maybe "path-graph" 
as Sabine proposed). But I believe the cost value of path-graph will 
be complex.


In my opinion, if we want to provide the routing information, i2rs has 
done a good job. So I think the advantage of ALTO is simple. 
Applications can query the necessary routing state information from 
ALTO in a very simple way.


Any comments?

Thanks,
Jensen

On Sun, Mar 5, 2017 at 12:34 PM, Jensen Zhang 
> wrote:


And I want to involve Wendy into this discussion since I remember
we discussed the unified cost schema. About the cost schema for
path-vector, I have three options here:

Option1: (Legacy schema)

---
pids:
  srcs: [PID1, PID2]
  dsts: [PID1, PID2, PID3]

Option2: (Basic flow-based schema)

---
pid-flows:
  - src: PID1
dst: PID1
  - src: PID1
dst: PID2
  - src: PID2
dst: PID3

Option3: (Advanced flow-based schema)

---
flows:
  flow1:
ip_src: 10.10.1.0/24 
tcp_port_src: 54321
ip_dst: 10.10.101.0/24 
tcp_port_dst: 8080
  flow2:
ip_src: 10.10.2.0/24 
tcp_port_src: 54321
ip_dst: 10.10.102.0/24 
tcp_port_dst: 8081

Option1 and Option2 are acceptable for CM/FCM/ECS now because it
will not change the schema of response. But I think Option2 and
Option3 are more useful for path-vector. Do you have some good
suggestions?

Thanks,
Jensen

On Sun, Mar 5, 2017 at 12:14 PM, Jensen Zhang
>
wrote:

Hi Sabine,

Wonderful! Actually, I'm working with Dawn recently and hoping
to update the draft-yang-alto-path-vector. About your
suggestions, I have some comments. See below.

Best,
Jensen

On Sat, Mar 4, 2017 at 1:44 AM, Randriamasy, Sabine (Nokia -
FR) > wrote:

Hi Dawn and Jensen, path-vector authors and all,

Thanks a lot for resuming the discussion on the
“path-vector” mode. I also read your e-mails on the
“Problems of encoding path-vector in multi-cost”
discussions. Before answering, I needed to clarify on the
proposed designs on path-vector.

So below I have some suggestions for the