Hello authors of path vector and RSADE extensions and all, Both drafts address several emerging use cases, in particular, the multi-path 1st hop, where each hop corresponds to a different choice of access technology.
I'd like to resume the discussion started in IETF96-Berlin upon Richard's presentation, see https://www.ietf.org/proceedings/96/slides/slides-96-alto-6.pdf - issue 2 slide 12: multiple (S,D) pairs (with S and D = sets) in a query is more than useful. Is there a way to allow this as well for "regular" ECS and F/CM ? Can we apply this to both "flows/endpoints" and "PID-paths" ? - issue 2 design choices: a smooth transition would be using native cost maps with multiple input several (S,D) pairs. - Cost metric and mode for "ane-aware paths": Slide 17 illustrates for a (S,D) pair: metric = "ane", mode = "path-vector" = array of N >= 1 "ane" Other modes could be: - mode = "path-graph", (multiple path-vectors - for RSADE or multi-choice paths) - mode = "path-e2e" (single switch N=0 base ALTO mode usually not used), - conveying ane costs and properties (slides 15, 16, 17) on multi-hop maps: In any case, ane property/cost services need to be specified and indicated in the IRD so that the client understands what "ne24" points to. So I suggest the anep-map to be systemetically referenced in the dependent-vtags. As for nep-map values: - inline: information is self-contained and saves round trips but response may be heavy - reference: ALTO Client gets anep map separately if needed. How about letting a Server decide what option to propose? A Server may even directly integrate the cost values in a multi-cost response, provided it has specified a anep-map and references it in its response. If for instance a client requests metric "BW" in "path-vector" mode, the protocol may request that it also requests metric "ane" in this mode (same for "path-graph" mode). Does this make sense ? Thanks, Sabine >>-----Original Message----- >>From: alto [mailto:[email protected]] On Behalf Of Vijay K. Gurbani >>Sent: mercredi 31 août 2016 23:08 >>To: Y. Richard Yang <[email protected]> >>Cc: [email protected]; draft-gao-alto-routing-state- >>[email protected]; IETF ALTO <[email protected]> >>Subject: Re: [alto] Graph representation format deliverable as WG item >> >>On 08/31/2016 03:54 PM, Y. Richard Yang wrote: >>> Hi Vijay, all, >>> >>> Thanks a lot for the reminder. This is a keep-alive that the authors >>> are doing the work and will post an outline to clarify to the WG on >>> the path soon. >> >>Richard: Awesome! Thanks. >> >>- vijay >>-- >>Vijay K. Gurbani, Bell Laboratories, Nokia Networks >>1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) >>Email: [email protected] / [email protected] >>Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq >> >>_______________________________________________ >>alto mailing list >>[email protected] >>https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
