Hi Piotr, Thanks for starting a discussion on this scheme. Please see below.
On Sunday, March 22, 2015, Piotr Wydrych <[email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > Hi All, > > As some of you may remember, few years ago, long time before the protocol > has been standardized, an idea of inter-ALTO communication has been > proposed. As the protocol is now ready and extensions are beeing developed, > I'd like to raise your attention to this communication scheme again :-) > > Since it's not possible to discuss the proposal within 5', I'll raise some > issues on the list. > > 1. The rationale > Some (maybe out-of-date) rationale can be found in > draft-dulinski-alto-inter-problem-statement-01 from July 2011. For me, > the two most important use-cases in which operators significantly may > benefit from map exchange are (a) route assymmetry and (b) remote isp's > preference. > Regarding (a), the core ALTO protocol focuses on comparing traffic > destination endpoints (thanks to, e.g., data from BGP tables). If an ALTO > server is aware of routes towards the AS it belongs to, it may compare > traffic sources between each other. In (b), I assume that information > from remote ASes may make endpoints from the same AS (e.g., assigned to the > same PID due the same AS-PATH) distinguishable. > > Since YMMV, I'd be glad to hear your voice to come out with a set of > really important issues to be solved by inter-ALTO. I don't want to start > an academic discussion and think of a lot of generic and specific use-cases. > > Let me add one more use case, in the setting of inter-alto communications. A setting that we are looking into is that a network is partitioned (sharded), and hence there are multiple servers with each being responsible for a given region. This can be considered a setting of hierarchical alto. Hence, there are can be iterative and/or recursive patterns on answering a query. I feel that this is an important issue, to answer your question. > 2. General requirements > Base on the use-cases, a question may be raised: is there any set of > information that has to be provided every time an ALTO server says it > implements inter-ALTO? Some other requirements that have to be investigated > include authentication, information confidentiality, incremental updatest > etc. Right. The requirements will depend on the use cases. > > 3. Does any IETF RFC/draft address all the reqs? > I do not know of any. Not I know of. > > 4. Extension spec > E.g., should it be contained within one draft or split into problem > statment / reqs / definition? > > My personal preference is that a problem statement, which includes some clear, real possible use cases can be a good starting point. Talk to you at Dallas. Richard > Best regards, > Piotr > -- > Piotr 'GhosT' Wydrych .. xmpp:wydrych//agh.edu.pl .. > https://urldefense.proofpoint.com/v2/url?u=http-3A__wydrych. > net_&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v- > 0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=4LLxlHCMd4UqEyyOvanuw4GrAfAT6f > LGDAyAygWwHeo&s=aRMuAaXLNQ7_EYrl_EG_SN9EpqKEyptvEJEyhS_qdMo&e= > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > > _______________________________________________ > alto mailing list > [email protected] > https://urldefense.proofpoint.com/v2/url?u=https-3A__www. > ietf.org_mailman_listinfo_alto&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r= > 4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m= > 4LLxlHCMd4UqEyyOvanuw4GrAfAT6fLGDAyAygWwHeo&s= > mEoC8TS77l8YfKS4Somakf1ikOrKv40Jbfqp7FrWCA8&e= -- Richard
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
