Wendy Roome | 29 Jul 19:47 2015

Re: High level comments on draft-roome-alto-unified-props-00

Richard,

Thanks for the comments.

1. I do not see how we could define a universal hierarchy; I think the
entity hierarchy and inheritance must be defined in the context of each
specific entity domain. Section 2.3 allows for hierarchies, but requires
the domain to define the rules:

   Addresses may be hierarchical, and properties may be inherited based
   on that hierarchy. Again, the rules defining any hierarchy or
   inheritance must be defined when the domain is registered.

If you can suggest a general way to define hierarchy & inheritance for
arbitrary domains, please let me know.

2. I would say the default is no consistency across domains. If there is
any inter-relationship or inheritance between entities from different
domains, the domain rules must define it.

Because PIDs are defined by CIDRs, some readers might think the two
domains are related. So in 3.2.4 I explicitly said they are not.

	- Wendy Roome

>
>Date: Tue, 21 Jul 2015 16:29:09 +0800
>From: "Y. Richard Yang" <yry <at> cs.yale.edu>
>
>Wendy, all,
(Continue reading)

Wendy Roome | 29 Jul 18:49 2015

On-line interop-93 test client

I now have a web-based client for the interop tests defined in
https://datatracker.ietf.org/doc/draft-roome-alto-interop-ietf93/ :

       http://www.wdroome.com/alto/interop-93-client.php

Enter the public URI of your server, select the tests you want, and click
TEST SERVER. Be patient; it runs all tests before reporting the results.
It reports the results as a plain text file, to make it easier to save.

The output first lists the regular tests that passed, one per line. Next
come the failed tests: a one line summary followed by the specific errors.
Then it gives the results of the error tests. After that comes a summary
of all the resources in the IRD, including how many times each was used.
Finally, if any tests failed, it gives the request sent, response
expected, and the actual response received. Note that the latter is a
re-formatted version of the raw bytes the server returned.

It is not the most sophisticated web site ever written, but it seems to
work.

      - Wendy Roome

Jan Seedorf | 28 Jul 21:42 2015
Picon

Minutes from the ALTO Session at IETF-93

Dear all,

 

below are the minutes from the ALTO Session at IETF-93 last week. Thanks again to Lyle for taking notes!

 

Please let us (the chairs) have any comments/edits/corrections you might have.

 

-          Jan

 

 

******

ALTO WG Meeting Notes

 

1520-1530 - Administrivia Chairs 10'

 

Interop Event

- Skype and remote / local team

- 2 client / server combo & 1 solo client & 1 solo server

- No protocol bugs but found a couple of minor implementation bugs

- First interop since approval of RFC 7285

- Proposal from Richard Yang to do this remotely at any time and we could host at any IETF meetings

- Snapshot of test was shown

 

Milestone Dates

- behind charter miletsone dates

- chairs to recalibrate after IETF Prague

- we have very matured proposals for the chartered items so Chairs feel comfortable about progress

 

draf-alto-deployments status update given

chairs to prepare

 

Server Side Notifications (sse)

- adopted as wg item since last IETF

- solves multiple wg charter items

- an update from Wendy has been made

- How to move on is the question?

- 2-3 slides for status is available and may be presented at the end of this meeting

- authors feel it is very mature

- no comments were made on this when asked

 

multi-cost draft

- IPR has been declared on this document

- if one have comments they are urged to comment on mailing list

- as long as the wg knows what they are looking at the IETF does not take a position on it but they do take issue with any lack of awareness of IPR

 

alternative server discovery

- one item is presented to day and we have no alternatives so we may need to move on today

 

Endpoint properties (2 proposals)

- both items to be discussed

- this is a charter item

 

Agenda Bashing? None

 

1530-1540 - Inter-ALTO communication problem P. Wydrych 10'

statement

draft-dulinski-alto-inter-problem-statement-02

 

- discussed changes – rewritten from scratch due to the age of the document

- 11 use cases reduced to 3

- general architecture was presented

- UC 1 – Remote View of Topology

- can calculate cost of sending data

- cannot calculate cost of receiving data (w/o inter-ALTO)

- UC 2 – Detailed Information on Remote Topology

- UC 3 – Partitioned Networks

- Security Issues

- Next Steps

- WG adoption?

WG chair – we will not adopt a document to adopt an item not in the chair

if wg is interested then we will proceed with document but not accept it

- Individual Comment – The problem should be solved but we need to think about the process

- Splitting this document up was done on advice of others

- A couple have

- Vijay – one way to move ahead is AD sponsored draft

- Some interest expressed by Sebastian and a others

Conclusion - We move along with agenda an discuss how to proceed on the mailing list

 

1540-1550 - Path extensions for the ALTO P. Wydrych 10'

protocol

draft-wydrych-alto-paths-00

 

- No way to ask for cost of specific path in ALTO

- Multiple Use Cases presented

- introduces ppid (path pid)

- network map and cost map was presented

- endpoint cost service shown

- Path Computation Service shown

- Question -

- W. Roome – question on the cost map representation

- L. Bertz – expressed usefulness for operators

- Individual comment – expressed other considerations that need to be made in the document

- interest in the wg and details need to be worked out – we dein

1550-1600 - Multiple ALTO information sources S. Kiesel 10'

and partitioned knowledge

draft-kiesel-alto-xdom-disc

 

where are we

- defined dhcp to recommend an alto server URI

- 7285

- we will not standardize the backend (database)

problem statement

- we have multiple sources

- an alto client does not always care about optimizing for itself (an on behalf of request)

- if an ALTO server knows everything would it tell us

> we need to address this problem

Options presented for info replication & request forwarding

Use algorithm based on DNS to resolve IP address to a URI

Ask – to be adopted

Technical Questions – None

2-3 have read latest version of the draft

Since only a few folks have read the latest version the question of adoption to the mailing list

Common Pietr – We need some sort of discovery service and had some discussion regarding a search engine

Wendy – notes that a registry may be useful and reverse DNS may be flaky

WG adoption cannot be taken now (due to low readership)

Jan asked Sebastian to start discussion of adoption on the mailing list

 

1600-1610 - Extended endpoint properties for H. Song 10'

ALTO

draft-deng-alto-p2p-ext-06

 

- Status

-stable

-recent issues address in 06

-targets charter wg item

- Fast Changing Data – Per Dallas, we should not use ALTO for realtime congestion control and it should be focused on data where it changes on long periods of time (more than minutes)

- Vijay via Sebastian – we talked about a way to discuss privacy concerns in Dallas (discussion taken offline)

- Authors of both documents agree the two (this and Wendy's) are orthogonal

 

1610-1620 - Unified and extensible approach to W. Roome 10'

ALTO properties

draft-roome-alto-unified-props-00

 

- some properties are service specific and some are not, e.g. CIDRs

- Endpoint inheritence is realisitc

- ALTO EP service is POST only

- Make the Property Definition independent of the domain

- Each map may have a set of network properties

- 2 new property map services to replace existing EP service

- Updates 7285

- Drop Wendy's previous proposl

 

- Authors agree documents do not complete because

Wendy's is a replacement of EP Service in 7285

Previous proposal defines new properties

 

Jan -

Notes the other proposal is in the chartered

The charter is not precise as to whether this draft is out of the charter scope

 

Sebastian – not a question of XOR drafts and that both drafts are useful and should be merged

Proposes p2p draft be adopted

We agree we don't want to merge them (per people in the room)

Pietr – notes that he likes both drafts

- first draft has very specific properties

- second has nice features

- Sabin – both drafts are important

- second draft reduces data to converge between the

H – uses existing ep service in his I-d draft-deng-alto-p2p-ext

Vijay – thinks more discussion is necessary

L Bertz – thinks second draft meets the reduction of over the wire reduction objective in the chartered

Conclusion – more discussion is required and the documents can be progressed

 

1620-1630 - ALTO map calculation from network H. Seidel 10'

data

(No internet-draft)

 

- Continuous update of alto network information is required

- Multiple sources of the information exists

- Compile internal network map (displayed on slide)

- Executed large map construction (800 routers) with exclusion and other filters to generate network and cost maps

- Comment – Pietr – good to see presentation where an ALTO server is processing full BGP data and receiving updates periodically

- Jan note hows that this is useful for

- Main idea of presentation is to provide information as opposed to creating a draft

 

1630-1640 - Multi-cost ALTO S. Randriamasy 10'

draft-ietf-alto-multi-cost

 

(Reduced to 5 minutes)

- Main driver is backwards compatibility with legacy clients

- Testable Cost Types discussed – can test a value on a metric w/o the need to return it

- Next Steps – this is a wg document and mature document but we need comments from the team on the mailing list

 

1640-1650 - ALTO cost calendar S. Randriamasy 10'

draft-randriamasy-alto-cost-calendar-04

 

- Overview of changes

- Main updates the service applies to all metrics and it is now backwards compatible

- Request WG adopton

- no time for discussion

- need feedback from WG on mailing list to adopt it?

- is this the right level?

- encourage others to read the draft

1650-1700 - Routing State Abstraction Service W. Roome / Y.Lee 10'

draft-gao-alto-routing-state-abstraction-00

 

- Wendy presenting on behalf of Richard

- Client requests the level of abstraction it wants to see from the ALTO server

- Client uses OpenFlow like list to describe what they want

- Are we interested in this approach?

- only 1 person has read it – Jan asked for folks to read it

 

1700-1710 - Large Data Transfer Coordinator H. Song 10'

ddraft-wang-alto-large-data-framework-00

 

- Due to time we deferred comments to the mailing list

1710-1720 - Spill over/Conclusion/Wrap-up Chairs/WG 10'

 

- General comment of encouraging WG to read each others' documents. Authors are encouraged to read each other's work.

 

******

 

 

============================================================

Prof. Dr. Jan Seedorf

Senior Researcher

NEC Europe Ltd., NEC Laboratories Europe, Network Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel.     +49 (0)6221 4342-221

Fax:     +49 (0)6221 4342-155

e-mail:  jan.seedorf <at> neclab.eu

============================================================

NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB, Registered in England 2832014

 

<div>
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Dear all,<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">below are the minutes from the ALTO Session at IETF-93 last week. Thanks again to Lyle for taking notes!<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">Please let us (the chairs) have any comments/edits/corrections you might have.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoListParagraph">
<span lang="EN-US"><span>-<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><span lang="EN-US">Jan<p></p></span></p>
<p class="MsoListParagraph"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">******<p></p></span></p>
<p><span lang="EN-US">ALTO WG Meeting Notes<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">1520-1530 - Administrivia Chairs 10'<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">Interop Event<p></p></span></p>
<p><span lang="EN-US">- Skype and remote / local team<p></p></span></p>
<p><span lang="EN-US">- 2 client / server combo &amp; 1 solo client &amp; 1 solo server<p></p></span></p>
<p><span lang="EN-US">- No protocol bugs but found a couple of minor implementation bugs<p></p></span></p>
<p><span lang="EN-US">- First interop since approval of RFC 7285<p></p></span></p>
<p><span lang="EN-US">- Proposal from Richard Yang to do this remotely at any time and we could host at any IETF meetings<p></p></span></p>
<p><span lang="EN-US">- Snapshot of test was shown<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">Milestone Dates<p></p></span></p>
<p><span lang="EN-US">- behind charter miletsone dates<p></p></span></p>
<p><span lang="EN-US">- chairs to recalibrate after IETF Prague<p></p></span></p>
<p><span lang="EN-US">- we have very matured proposals for the chartered items so Chairs feel comfortable about progress<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">draf-alto-deployments status update given<p></p></span></p>
<p><span lang="EN-US">chairs to prepare
<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">Server Side Notifications (sse)
<p></p></span></p>
<p><span lang="EN-US">- adopted as wg item since last IETF<p></p></span></p>
<p><span lang="EN-US">- solves multiple wg charter items<p></p></span></p>
<p><span lang="EN-US">- an update from Wendy has been made<p></p></span></p>
<p><span lang="EN-US">- How to move on is the question?<p></p></span></p>
<p><span lang="EN-US">- 2-3 slides for status is available and may be presented at the end of this meeting<p></p></span></p>
<p><span lang="EN-US">- authors feel it is very mature<p></p></span></p>
<p><span lang="EN-US">- no comments were made on this when asked<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">multi-cost draft<p></p></span></p>
<p><span lang="EN-US">- IPR has been declared on this document<p></p></span></p>
<p><span lang="EN-US">- if one have comments they are urged to comment on mailing list<p></p></span></p>
<p><span lang="EN-US">- as long as the wg knows what they are looking at the IETF does not take a position on it but they do take issue with any lack of awareness of IPR<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">alternative server discovery<p></p></span></p>
<p><span lang="EN-US">- one item is presented to day and we have no alternatives so we may need to move on today<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">Endpoint properties (2 proposals)<p></p></span></p>
<p><span lang="EN-US">- both items to be discussed<p></p></span></p>
<p><span lang="EN-US">- this is a charter item<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">Agenda Bashing? None<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">1530-1540 - Inter-ALTO communication problem P. Wydrych 10'<p></p></span></p>
<p><span lang="EN-US">statement<p></p></span></p>
<p><span lang="EN-US">draft-dulinski-alto-inter-problem-statement-02<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">- discussed changes &ndash; rewritten from scratch due to the age of the document<p></p></span></p>
<p><span lang="EN-US">- 11 use cases reduced to 3<p></p></span></p>
<p><span lang="EN-US">- general architecture was presented<p></p></span></p>
<p><span lang="EN-US">- UC 1 &ndash; Remote View of Topology<p></p></span></p>
<p><span lang="EN-US">- can calculate cost of sending data<p></p></span></p>
<p><span lang="EN-US">- cannot calculate cost of receiving data (w/o inter-ALTO)<p></p></span></p>
<p><span lang="EN-US">- UC 2 &ndash; Detailed Information on Remote Topology<p></p></span></p>
<p><span lang="EN-US">- UC 3 &ndash; Partitioned Networks<p></p></span></p>
<p><span lang="EN-US">- Security Issues<p></p></span></p>
<p><span lang="EN-US">- Next Steps<p></p></span></p>
<p><span lang="EN-US">- WG adoption?<p></p></span></p>
<p><span lang="EN-US">WG chair &ndash; we will not adopt a document to adopt an item not in the chair<p></p></span></p>
<p><span lang="EN-US">if wg is interested then we will proceed with document but not accept it<p></p></span></p>
<p><span lang="EN-US">- Individual Comment &ndash; The problem should be solved but we need to think about the process<p></p></span></p>
<p><span lang="EN-US">- Splitting this document up was done on advice of others<p></p></span></p>
<p><span lang="EN-US">- A couple have<p></p></span></p>
<p><span lang="EN-US">- Vijay &ndash; one way to move ahead is AD sponsored draft<p></p></span></p>
<p><span lang="EN-US">- Some interest expressed by Sebastian and a others<p></p></span></p>
<p><span lang="EN-US">Conclusion - We move along with agenda an discuss how to proceed on the mailing list<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">1540-1550 - Path extensions for the ALTO P. Wydrych 10'<p></p></span></p>
<p><span lang="EN-US">protocol<p></p></span></p>
<p><span lang="EN-US">draft-wydrych-alto-paths-00<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">- No way to ask for cost of specific path in ALTO<p></p></span></p>
<p><span lang="EN-US">- Multiple Use Cases presented<p></p></span></p>
<p><span lang="EN-US">- introduces ppid (path pid)<p></p></span></p>
<p><span lang="EN-US">- network map and cost map was presented<p></p></span></p>
<p><span lang="EN-US">- endpoint cost service shown<p></p></span></p>
<p><span lang="EN-US">- Path Computation Service shown<p></p></span></p>
<p><span lang="EN-US">- Question -
<p></p></span></p>
<p><span lang="EN-US">- W. Roome &ndash; question on the cost map representation<p></p></span></p>
<p><span lang="EN-US">- L. Bertz &ndash; expressed usefulness for operators<p></p></span></p>
<p><span lang="EN-US">- Individual comment &ndash; expressed other considerations that need to be made in the document<p></p></span></p>
<p><span lang="EN-US">- interest in the wg and details need to be worked out &ndash; we dein<p></p></span></p>
<p><span lang="EN-US">1550-1600 - Multiple ALTO information sources S. Kiesel 10'<p></p></span></p>
<p><span lang="EN-US">and partitioned knowledge<p></p></span></p>
<p><span lang="EN-US">draft-kiesel-alto-xdom-disc
<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">where are we<p></p></span></p>
<p><span lang="EN-US">- defined dhcp to recommend an alto server URI<p></p></span></p>
<p><span lang="EN-US">- 7285<p></p></span></p>
<p><span lang="EN-US">- we will not standardize the backend (database)<p></p></span></p>
<p><span lang="EN-US">problem statement<p></p></span></p>
<p><span lang="EN-US">- we have multiple sources<p></p></span></p>
<p><span lang="EN-US">- an alto client does not always care about optimizing for itself (an on behalf of request)<p></p></span></p>
<p><span lang="EN-US">- if an ALTO server knows everything would it tell us<p></p></span></p>
<p><span lang="EN-US">&gt; we need to address this problem<p></p></span></p>
<p><span lang="EN-US">Options presented for info replication &amp; request forwarding<p></p></span></p>
<p><span lang="EN-US">Use algorithm based on DNS to resolve IP address to a URI<p></p></span></p>
<p><span lang="EN-US">Ask &ndash; to be adopted<p></p></span></p>
<p><span lang="EN-US">Technical Questions &ndash; None<p></p></span></p>
<p><span lang="EN-US">2-3 have read latest version of the draft<p></p></span></p>
<p><span lang="EN-US">Since only a few folks have read the latest version the question of adoption to the mailing list<p></p></span></p>
<p><span lang="EN-US">Common Pietr &ndash; We need some sort of discovery service and had some discussion regarding a search engine<p></p></span></p>
<p><span lang="EN-US">Wendy &ndash; notes that a registry may be useful and reverse DNS may be flaky<p></p></span></p>
<p><span lang="EN-US">WG adoption cannot be taken now (due to low readership)<p></p></span></p>
<p><span lang="EN-US">Jan asked Sebastian to start discussion of adoption on the mailing list<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">1600-1610 - Extended endpoint properties for H. Song 10'<p></p></span></p>
<p><span lang="EN-US">ALTO<p></p></span></p>
<p><span lang="EN-US">draft-deng-alto-p2p-ext-06<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">- Status<p></p></span></p>
<p><span lang="EN-US">-stable<p></p></span></p>
<p><span lang="EN-US">-recent issues address in 06<p></p></span></p>
<p><span lang="EN-US">-targets charter wg item<p></p></span></p>
<p><span lang="EN-US">- Fast Changing Data &ndash; Per Dallas, we should not use ALTO for realtime congestion control and it should be focused on data where it changes on long periods of time (more than minutes)<p></p></span></p>
<p><span lang="EN-US">- Vijay via Sebastian &ndash; we talked about a way to discuss privacy concerns in Dallas (discussion taken offline)<p></p></span></p>
<p><span lang="EN-US">- Authors of both documents agree the two (this and Wendy's) are orthogonal<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">1610-1620 - Unified and extensible approach to W. Roome 10'<p></p></span></p>
<p><span lang="EN-US">ALTO properties<p></p></span></p>
<p><span lang="EN-US">draft-roome-alto-unified-props-00<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">- some properties are service specific and some are not, e.g. CIDRs<p></p></span></p>
<p><span lang="EN-US">- Endpoint inheritence is realisitc<p></p></span></p>
<p><span lang="EN-US">- ALTO EP service is POST only<p></p></span></p>
<p><span lang="EN-US">- Make the Property Definition independent of the domain<p></p></span></p>
<p><span lang="EN-US">- Each map may have a set of network properties<p></p></span></p>
<p><span lang="EN-US">- 2 new property map services to replace existing EP service<p></p></span></p>
<p><span lang="EN-US">- Updates 7285<p></p></span></p>
<p><span lang="EN-US">- Drop Wendy's previous proposl<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">- Authors agree documents do not complete because<p></p></span></p>
<p><span lang="EN-US">Wendy's is a replacement of EP Service in 7285<p></p></span></p>
<p><span lang="EN-US">Previous proposal defines new properties<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">Jan - <p></p></span></p>
<p><span lang="EN-US">Notes the other proposal is in the chartered<p></p></span></p>
<p><span lang="EN-US">The charter is not precise as to whether this draft is out of the charter scope<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">Sebastian &ndash; not a question of XOR drafts and that both drafts are useful and should be merged<p></p></span></p>
<p><span lang="EN-US">Proposes p2p draft be adopted<p></p></span></p>
<p><span lang="EN-US">We agree we don't want to merge them (per people in the room)<p></p></span></p>
<p><span lang="EN-US">Pietr &ndash; notes that he likes both drafts
<p></p></span></p>
<p><span lang="EN-US">- first draft has very specific properties<p></p></span></p>
<p><span lang="EN-US">- second has nice features<p></p></span></p>
<p><span lang="EN-US">- Sabin &ndash; both drafts are important<p></p></span></p>
<p><span lang="EN-US">- second draft reduces data to converge between the<p></p></span></p>
<p><span lang="EN-US">H &ndash; uses existing ep service in his I-d draft-deng-alto-p2p-ext<p></p></span></p>
<p><span lang="EN-US">Vijay &ndash; thinks more discussion is necessary<p></p></span></p>
<p><span lang="EN-US">L Bertz &ndash; thinks second draft meets the reduction of over the wire reduction objective in the chartered<p></p></span></p>
<p><span lang="EN-US">Conclusion &ndash; more discussion is required and the documents can be progressed<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">1620-1630 - ALTO map calculation from network H. Seidel 10'<p></p></span></p>
<p><span lang="EN-US">data<p></p></span></p>
<p><span lang="EN-US">(No internet-draft)<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">- Continuous update of alto network information is required<p></p></span></p>
<p><span lang="EN-US">- Multiple sources of the information exists<p></p></span></p>
<p><span lang="EN-US">- Compile internal network map (displayed on slide)<p></p></span></p>
<p><span lang="EN-US">- Executed large map construction (800 routers) with exclusion and other filters to generate network and cost maps<p></p></span></p>
<p><span lang="EN-US">- Comment &ndash; Pietr &ndash; good to see presentation where an ALTO server is processing full BGP data and receiving updates periodically<p></p></span></p>
<p><span lang="EN-US">- Jan note hows that this is useful for<p></p></span></p>
<p><span lang="EN-US">- Main idea of presentation is to provide information as opposed to creating a draft<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">1630-1640 - Multi-cost ALTO S. Randriamasy 10'<p></p></span></p>
<p><span lang="EN-US">draft-ietf-alto-multi-cost<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">(Reduced to 5 minutes)<p></p></span></p>
<p><span lang="EN-US">- Main driver is backwards compatibility with legacy clients<p></p></span></p>
<p><span lang="EN-US">- Testable Cost Types discussed &ndash; can test a value on a metric w/o the need to return it<p></p></span></p>
<p><span lang="EN-US">- Next Steps &ndash; this is a wg document and mature document but we need comments from the team on the mailing list<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">1640-1650 - ALTO cost calendar S. Randriamasy 10'<p></p></span></p>
<p><span lang="EN-US">draft-randriamasy-alto-cost-calendar-04<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">- Overview of changes<p></p></span></p>
<p><span lang="EN-US">- Main updates the service applies to all metrics and it is now backwards compatible<p></p></span></p>
<p><span lang="EN-US">- Request WG adopton<p></p></span></p>
<p><span lang="EN-US">- no time for discussion<p></p></span></p>
<p><span lang="EN-US">- need feedback from WG on mailing list to adopt it?<p></p></span></p>
<p><span lang="EN-US">- is this the right level?<p></p></span></p>
<p><span lang="EN-US">- encourage others to read the draft<p></p></span></p>
<p><span lang="EN-US">1650-1700 - Routing State Abstraction Service W. Roome / Y.Lee 10'<p></p></span></p>
<p><span lang="EN-US">draft-gao-alto-routing-state-abstraction-00
<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">- Wendy presenting on behalf of Richard<p></p></span></p>
<p><span lang="EN-US">- Client requests the level of abstraction it wants to see from the ALTO server<p></p></span></p>
<p><span lang="EN-US">- Client uses OpenFlow like list to describe what they want<p></p></span></p>
<p><span lang="EN-US">- Are we interested in this approach?<p></p></span></p>
<p><span lang="EN-US">- only 1 person has read it &ndash; Jan asked for folks to read it<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">1700-1710 - Large Data Transfer Coordinator H. Song 10'<p></p></span></p>
<p><span lang="EN-US">ddraft-wang-alto-large-data-framework-00<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">- Due to time we deferred comments to the mailing list
<p></p></span></p>
<p><span lang="EN-US">1710-1720 - Spill over/Conclusion/Wrap-up Chairs/WG 10'<p></p></span></p>
<p><span lang="EN-US"><p>&nbsp;</p></span></p>
<p><span lang="EN-US">- General comment of encouraging WG to read each others' documents.
</span>Authors are encouraged to read each other's work.<p></p></p>
<p><p>&nbsp;</p></p>
<p class="MsoNormal"><span lang="EN-US">******<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">============================================================<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Prof. Dr. Jan Seedorf<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Senior Researcher<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">NEC Europe Ltd., NEC Laboratories Europe, Network Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel.&nbsp;&nbsp;&nbsp;&nbsp; +49 (0)6221 4342-221<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Fax:&nbsp;&nbsp;&nbsp;&nbsp; +49 (0)6221 4342-155<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">e-mail:&nbsp; </span><a href="mailto:jan.seedorf <at> neclab.eu"><span lang="EN-US">jan.seedorf <at> neclab.eu</span></a><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">============================================================<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End&nbsp; Road, London, HA4 6QE, GB, Registered in England 2832014<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
</div>
</div>
Wendy Roome | 28 Jul 15:33 2015

Parameterized ALTO cost-types

Recently, draft-wydrych-alto-paths-00 &
draft-gao-alto-routing-state-abstraction-00 have proposed extending ALTO
with path-based costs. I'm going to outline a considerably simpler way to
accomplish the same goal. I would like all of you -- and especially the
authors of those drafts! -- to let me know what those extensions provide
that this doesn't.

The Problem:
The ALTO cost model assumes costs depend only on the source & destination
addresses. But modern networks route on other attributes (protocol,
dest-port, diffserv, etc) as well as destination address. The result is
that the cost for downloading a file may depend on the protocol: rtp,
tcp/port80, tcp/other-port, etc.

What's worse, those protocol-dependent costs might not "track." That is,
if you stream a video via rtp, ServerA might be faster than ServerB, but
if you download it via http, ServerB might be faster.

The current ALTO cost model cannot convey those distinctions.

Observation #1:
While paths may be the cause of the cost differences, ALTO clients -- end
user applications -- do not care about the paths their packets take. ALTO
clients just care about the end-to-end costs.

Feel free to describe a use-case that contradicts this claim!

I realize that multi-flow clients need to know about paths, to determine
how much the routes to several different endpoints overlap. But those are
not the clients I am talking about here.

Observation #2:
Clients who are concerned about protocol-dependent costs are only
interested a small number of different protocol/port/etc combinations.
That is, an ALTO client might be interested in the costs for downloading
via rtp vs http. But that is all; the client does not care about the costs
for other protocols & ports.

Again, feel free to point out a use-case that contradicts that claim.

My Proposal:
Instead of introducing a path abstraction, suppose we extend the cost-type
with parameters that describe the packet type, such as protocol, src-port,
dst-port & diffserv. Then a client request for a Filtered Cost Map might
look like this:

   {
      "cost-type" : {
         "cost-metric" : "routingcost",
         "cost-mode" : "numerical",
         "src-port" : 80,
         ³protocol" : 6
      },
      "pids" : {
         "srcs" : [ "PID1", "PID2", "PID3" ],
         "dsts" : [ "PID1" ]
      }
   }

   
The ALTO server returns the numerical routing costs from the srcs to the
dsts, for packets with the indicated port & protocol. If there is no
special route for that packet flavor, the ALTO server simply returns the
general routingcost for the src & dst.

If a client wants costs for a small number of different protocols, the
client can use the multi-cost extension, draft-ietf-alto-multi-cost-00.

My Question:
What do the proposed path-based cost extensions provide that this does not?

	- Wendy Roome

Jan Seedorf | 23 Jul 16:20 2015
Picon

Please read the documents from other WG participants

Dear all,

 

I think we are seeing good progress with all chartered items, which is great, and I am convinced there is good energy in the WG to finish all the milestones.

 

What is sometimes missing---as I mentioned in the ALTO session this week here at IETF-93---is people (other than the authors) reading the drafts and providing feedback to the mailing list. E.g., in order to adopt a draft as WG item, I would like to see comments from other people on the mailing list saying they have read the draft and what they think of it. One good example is how Richard did it for multi-cost (see

https://mailarchive.ietf.org/arch/msg/alto/RUjTEP9-iIKd2txEANZCDDOMHkg) in order to move it forward towards WGLC.  Obviously, if you read a draft and think it is very good and you have fewer or nor comments that is also fine, but please say so on the mailing list. Also, if you have a draft of your own that you want to progress and receive feedback on, why not start by reading other people’s drafts and help them make progress; I am sure people will then also return the favour and read your draft and improve it.

 

As chairs, our role is to make sure that drafts being adopted as WG item have the backing of the majority of the WG (rough consensus) and drafts entering WGLC are ready for publication, so that we do not embarrass ourselves in front of the IESG.

 

-          Jan (with chair hat on)

 

============================================================

Prof. Dr. Jan Seedorf

Senior Researcher

NEC Europe Ltd., NEC Laboratories Europe, Network Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel.     +49 (0)6221 4342-221

Fax:     +49 (0)6221 4342-155

e-mail:  jan.seedorf <at> neclab.eu

============================================================

NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB, Registered in England 2832014

 

<div>
<div class="WordSection1">
<p class="MsoNormal">Dear all,<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal"><span lang="EN-US">I think we are seeing good progress with all chartered items, which is great, and I am convinced there is good energy in the WG to finish all the milestones.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">What is sometimes missing---as I mentioned in the ALTO session this week here at IETF-93---is people (other than the authors) reading the drafts and providing feedback to the mailing list. E.g., in order to adopt a draft
 as WG item, I would like to see comments from other people on the mailing list saying they have read the draft and what they think of it. One good example is how Richard did it for multi-cost (see
<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><a href="https://mailarchive.ietf.org/arch/msg/alto/RUjTEP9-iIKd2txEANZCDDOMHkg">https://mailarchive.ietf.org/arch/msg/alto/RUjTEP9-iIKd2txEANZCDDOMHkg</a>) in order to move it forward towards WGLC. &nbsp;Obviously, if you
 read a draft and think it is very good and you have fewer or nor comments that is also fine, but please say so on the mailing list. Also, if you have a draft of your own that you want to progress and receive feedback on, why not start by reading other people&rsquo;s
 drafts and help them make progress; I am sure people will then also return the favour and read your draft and improve it.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">As chairs, our role is to make sure that drafts being adopted as WG item have the backing of the majority of the WG (rough consensus) and drafts entering WGLC are ready for publication, so that we do not embarrass ourselves
 in front of the IESG.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoListParagraph">
<span lang="EN-US"><span>-<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><span lang="EN-US">Jan (with chair hat on)<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">============================================================<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Prof. Dr. Jan Seedorf<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Senior Researcher<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">NEC Europe Ltd., NEC Laboratories Europe, Network Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel.&nbsp;&nbsp;&nbsp;&nbsp; +49 (0)6221 4342-221<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Fax:&nbsp;&nbsp;&nbsp;&nbsp; +49 (0)6221 4342-155<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">e-mail:&nbsp; </span><a href="mailto:jan.seedorf <at> neclab.eu"><span lang="EN-US">jan.seedorf <at> neclab.eu</span></a><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">============================================================<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End&nbsp; Road, London, HA4 6QE, GB, Registered in England 2832014<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
</div>
</div>
Meetecho Team | 22 Jul 18:41 2015

Meetecho recordings of ALTO WG session

Dear all,

the full recording (synchronized video, audio, slides and jabber room) of the 
ALTO WG session at IETF 93 is available at the following URL:
http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#ALTO

In case of problems with the playout, just drop an e-mail to ietf-support <at> meetecho.com.

For the chair(s): please feel free to put the link to the recording in the minutes,
if you think this might be useful.

Cheers,
the Meetecho Team

Dear all,

the full recording (synchronized video, audio, slides and jabber room) of the 
ALTO WG session at IETF 93 is available at the following URL:
http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#ALTO

In case of problems with the playout, just drop an e-mail to ietf-support <at> meetecho.com.

For the chair(s): please feel free to put the link to the recording in the minutes,
if you think this might be useful.

Cheers,
the Meetecho Team

Y. Richard Yang | 21 Jul 10:29 2015
Picon

High level comments on draft-roome-alto-unified-props-00

Wendy, all,

I just read draft draft-roome-alto-unified-props-00 and liked it a lot. It is very well written, as Wendy always does, and I recommend that many of you read this design.

Personally, I see this design as a good candidate as a WG item. Before making up my mind, I see benefits in discussing two high level design decisions:
1. Hierarchy of general domains. In the current design, this issue already appears in the ipv4 and ipv6 domains. The approach that the draft adopts is longest prefix matching (LPM); see Section 3.1.3.. This can be considered as smallest containing set, if we see each CIDR as a set, and such sets form a directed acyclic graph. Q: Does it make sense for the document to go as far as defining this general principle, instead of the specific LPM?

2. Consistency of the same property across domains. Section 3.2.4 gives one example of such a case. Q: Is this a specific decision for two specific domains, or the general principle is no across domain consistency?

Cheers,
Richard
-
<div><div dir="ltr">Wendy, all,
<div><br></div>
<div>I just read draft&nbsp;<span>draft-roome-alto-unified-props-00 and liked it a lot. It is very well written, as Wendy always does, and I recommend that many of you read this design.</span>
</div>
<div><span><br></span></div>
<div><span>Personally, I see this design as a good candidate as a WG item. Before making up my mind, I see benefits in discussing two high level design decisions:</span></div>
<div><span>
1. Hierarchy of general domains. In the current design, this issue already appears in the ipv4 and ipv6 domains. The approach that the draft adopts is longest prefix matching (LPM); see Section 3.1.3.. This can be considered as smallest containing set, if we see each CIDR as a set, and such sets form a directed acyclic graph. 
Q: Does it make sense for the document to go as far as defining this general principle, instead of the specific LPM?</span></div>
<div><span><br></span></div>
<div><span>2. Consistency of the same property across domains.  Section 3.2.4 gives one example of such a case. 
Q: Is this a specific decision for two specific domains, or the general principle is no across domain consistency?</span></div>
<div><span><br></span></div>
<div><span>Cheers,</span></div>
<div><span>Richard</span></div>
<div><span>- </span></div>
</div></div>
Vijay K. Gurbani | 20 Jul 16:39 2015

Reminder: Slides for Prague IETF

Folks: I have updated the slides I have received and these are
available on the meetings material.

If you have sent slides to Jan only, please resend them to me.
Jan has his hands full with the interop and other sessions, so I
can offload some work from him by uploading the slides.

Please send me the slides in PDF.

Thanks,

- vijay
--

-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg <at> {bell-labs.com,acm.org} / vijay.gurbani <at> alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

Gao Kai | 20 Jul 14:51 2015
Picon

Comments on draft-deng-alto-p2p-ext

Hi all,

I found all these new endpoint properties very useful and I can't help notice many are specialized for mobile and data center scenarios.  However I still have doubts on some issues and here are some comments:

1. I understand that the "precision" field is introduced to indicate the type of the content.  However, in 5 cases out of 8 the field is left empty, in other 2 the only difference is between an exact value and the ranking.  In the last case, "geolocation", the "precision" field can be chosen from four different values, but according to my understanding, an endpoint can have a geolocation for each one of them.  What if the ALTO server wants to provide all kinds of them?  Since they all share the property name "geolocation", it can lead to conflicts when the data are encapsulated in a JSON object.

So instead of using "precision", I think it is better to provide 4 different geolocation properties.  The same idea can apply to "network_access" and "provisioned_bandwidth": use "-rank" suffix in the name to indicate the value is a ranking.

At the same time, introducing "geolocation-type"/"network-access-type"/"provisioned-bandwidth-type" to indicate what "precision"s are supported looks like a good idea to me.

2. The names are using underscores instead of hyphens.  However I think it is better to keep it compatible with RFC 7285 in which property names use hyphens to concatenate words.

3. Why not use strings to represent the bandwidth?  Such as "1 Gbps".  It's more compact.  I'd also like to know if there are some other considerations why the metric and value are separated.

==================

Regards,
Kai
<div>
    Hi all,<br><br>
          I found all these new endpoint properties very useful and I
          can't help notice many are specialized for mobile and data
          center scenarios.&nbsp; However I still have doubts on
                some issues and here

          are some comments:<br><br>
          1. I understand that the "precision" field is introduced to
          indicate the type of the
          content.&nbsp; However, in 5 cases
          out of 8 the field is left empty, in other 2 the only
          difference is between an exact value and the ranking.&nbsp; In the
          last case, "geolocation", the "precision" field can be chosen
          from four different values, but according to my understanding,
          an endpoint can have a geolocation for each one of them.&nbsp; What
          if the ALTO server wants to provide all kinds of them?&nbsp; Since
          they all share the property name "geolocation", it can lead to
          conflicts when the data are encapsulated in a JSON object.<br><br>
          So instead of using "precision", I think it is better to
          provide 4 different geolocation properties.&nbsp; The same idea can
          apply to "network_access" and "provisioned_bandwidth": use
          "-rank" suffix in the name to indicate the value is a ranking.<br><br>
          At the same time, introducing
          "geolocation-type"/"network-access-type"/"provisioned-bandwidth-type"
          to indicate what "precision"s are supported looks like a good
          idea to me.<br><br>
          2. The names are using underscores instead of hyphens.&nbsp;
          However I think it is better to keep it compatible with RFC
          7285 in which property names use hyphens to concatenate words.<br><br>
          3. Why not use strings to represent the bandwidth?&nbsp; Such as "1
          Gbps".&nbsp; It's more compact.&nbsp; I'd also like to know if there are
          some other considerations why the metric and value are
          separated.<br><br>==================<br><br>Regards,<br>Kai<br>
  </div>
Y. Richard Yang | 20 Jul 11:10 2015
Picon

Please read if participate in ALTO interop (Re: Room Info ALTO interop tonight)

Thanks for setting the room for interop up, Jan!


Since a few of us will participate remotely, also to make it easier to share links, we will use Skype as a tool. Please kindly add me to your Skype contact, if you plan to participate, with a sever/client, or not. My Skype ID is yang.richard.yang

Looking forward to a productive event this Prague evening!

Richard 

On Monday, July 20, 2015, Jan Seedorf <Jan.Seedorf <at> neclab.eu> wrote:

For all implementers participating in the ALTO interop tonight, here is the room info:

 

Meeting Name: ALTO Interop Testing

Assigned Room: Florenc

Assigned Date: 07/20/2015

Assigned Start Time: 20:00:00

Assigned End Time: 23:00:00

 

Looking forward to an interesting and hopefully successful event!

 

-          Jan

 

============================================================

Prof. Dr. Jan Seedorf

Senior Researcher

NEC Europe Ltd., NEC Laboratories Europe, Network Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel.     +49 (0)6221 4342-221

Fax:     +49 (0)6221 4342-155

e-mail:  jan.seedorf <at> neclab.eu

============================================================

NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB, Registered in England 2832014

 



--
Richard
<div>
<p>Thanks for setting the room for interop&nbsp;up, Jan!</p>
<div><br></div>
<div>Since a few of us will participate remotely, also to make it easier to share&nbsp;links, we will use Skype as a tool. Please kindly add me to your Skype contact, if you plan to participate, with a sever/client, or not. My Skype ID is yang.richard.yang</div>
<div><br></div>
<div>Looking forward to a productive event this Prague&nbsp;evening!</div>
<div><br></div>
<div>Richard&nbsp;<br><br>On Monday, July 20, 2015, Jan Seedorf &lt;<a href="mailto:Jan.Seedorf <at> neclab.eu">Jan.Seedorf <at> neclab.eu</a>&gt; wrote:<br><blockquote class="gmail_quote">

<div lang="DE" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span lang="EN-US">For all implementers participating in the ALTO interop tonight, here is the room info:</span></p>
<p class="MsoNormal"><span lang="EN-US">&nbsp;</span></p>
<p><span lang="EN-US">Meeting Name: ALTO Interop Testing</span></p>
<p><span lang="EN-US">Assigned Room: Florenc</span></p>
<p><span lang="EN-US">Assigned Date: 07/20/2015</span></p>
<p><span lang="EN-US">Assigned Start Time: 20:00:00</span></p>
<p>Assigned End Time: 23:00:00</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal"><span lang="EN-US">Looking forward to an interesting and hopefully successful event!</span></p>
<p class="MsoNormal"><span lang="EN-US">&nbsp;</span></p>
<p>
<span lang="EN-US"><span>-<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><span lang="EN-US">Jan</span></p>
<p class="MsoNormal"><span lang="EN-US">&nbsp;</span></p>
<p class="MsoNormal"><span lang="EN-US">============================================================</span></p>
<p class="MsoNormal"><span lang="EN-US">Prof. Dr. Jan Seedorf</span></p>
<p class="MsoNormal"><span lang="EN-US">Senior Researcher</span></p>
<p class="MsoNormal"><span lang="EN-US">NEC Europe Ltd., NEC Laboratories Europe, Network Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel.&nbsp;&nbsp;&nbsp;&nbsp; +49 (0)6221 4342-221</span></p>
<p class="MsoNormal"><span lang="EN-US">Fax:&nbsp;&nbsp;&nbsp;&nbsp; +49 (0)6221 4342-155</span></p>
<p class="MsoNormal"><span lang="EN-US">e-mail:&nbsp; </span><a href="javascript:_e(%7B%7D,'cvml','jan.seedorf <at> neclab.eu');" target="_blank"><span lang="EN-US">jan.seedorf <at> neclab.eu</span></a><span lang="EN-US"></span></p>
<p class="MsoNormal"><span lang="EN-US">============================================================</span></p>
<p class="MsoNormal"><span lang="EN-US">NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End&nbsp; Road, London, HA4 6QE, GB, Registered in England 2832014</span></p>
<p class="MsoNormal"><span lang="EN-US">&nbsp;</span></p>
</div>
</div>

</blockquote>
</div>
<br><br>-- <br>Richard<br>
</div>
Jan Seedorf | 20 Jul 09:48 2015
Picon

Room Info ALTO interim tonight

For all implementers participating in the ALTO interop tonight, here is the room info:

 

Meeting Name: ALTO Interop Testing

Assigned Room: Florenc

Assigned Date: 07/20/2015

Assigned Start Time: 20:00:00

Assigned End Time: 23:00:00

 

Looking forward to an interesting and hopefully successful event!

 

-          Jan

 

============================================================

Prof. Dr. Jan Seedorf

Senior Researcher

NEC Europe Ltd., NEC Laboratories Europe, Network Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel.     +49 (0)6221 4342-221

Fax:     +49 (0)6221 4342-155

e-mail:  jan.seedorf <at> neclab.eu

============================================================

NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB, Registered in England 2832014

 

<div>
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">For all implementers participating in the ALTO interop tonight, here is the room info:<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoPlainText"><span lang="EN-US">Meeting Name: ALTO Interop Testing<p></p></span></p>
<p class="MsoPlainText"><span lang="EN-US">Assigned Room: Florenc<p></p></span></p>
<p class="MsoPlainText"><span lang="EN-US">Assigned Date: 07/20/2015<p></p></span></p>
<p class="MsoPlainText"><span lang="EN-US">Assigned Start Time: 20:00:00<p></p></span></p>
<p class="MsoPlainText">Assigned End Time: 23:00:00<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal"><span lang="EN-US">Looking forward to an interesting and hopefully successful event!<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoListParagraph">
<span lang="EN-US"><span>-<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><span lang="EN-US">Jan<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">============================================================<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Prof. Dr. Jan Seedorf<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Senior Researcher<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">NEC Europe Ltd., NEC Laboratories Europe, Network Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel.&nbsp;&nbsp;&nbsp;&nbsp; +49 (0)6221 4342-221<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Fax:&nbsp;&nbsp;&nbsp;&nbsp; +49 (0)6221 4342-155<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">e-mail:&nbsp; </span><a href="mailto:jan.seedorf <at> neclab.eu"><span lang="EN-US">jan.seedorf <at> neclab.eu</span></a><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">============================================================<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End&nbsp; Road, London, HA4 6QE, GB, Registered in England 2832014<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
</div>
</div>

Gmane