On Jan 31, 2012, at 7:29 AM, stefano previdi wrote: > > On Jan 31, 2012, at 4:08 PM, Vijay K. Gurbani wrote: > >> On 01/31/2012 05:14 AM, stefano previdi wrote: >> ben> This might be a case where we'd need a PID property to distinguish >> ben> "transit" PIDs from "End Host" PIDs. >> ben> >> stefano> sounds pretty reasonable to me. >> >> Ben: I suspect that your question had a foundation of some sort >> and was not simply a fishing expedition ;-) >> >> Let me ask you this: is the PID property that you would like to put >> in useful for CDN-usage in ALTO? > > > there are a variety of cases where this would be useful. When > you distribute a link-state topology you know you're talking > about routers and links and semantic is well-known. Same when > you advertise BGP routes or VPNv4 routes or whatever... the > protocol has the semantic you need to consider. > > In ALTO you have the necessary bits to tell if cost is based on > routing or air miles or others but you don't really know what a > PID is (other than a bunch of addresses). > Right, but the costs (and cost types) are associated with cost maps, not network maps. I still think a "transit" PID does not make sense (while thinking that PID attributes are a good thing).
A while back we did model link-state topology in ALTO, and the only sensible way we could figure out was to assign a PID to each router interface and to model a router as a set of PID where costs between the "interface" PIDs were 0. Links were modeled in the the Cost Map, where the link cost mapped directly into the cost between two "interface" PIDs. It did work, but then BGP-LS came along, which was a much cleaner way to convert topology. If we want to convey topology to apps via ALTO, we have to come up with a convention, so that the receiving app can properly interpret it. Stefano, Rich W, Jon and I proposed such convention a couple of IETFs ago, but there was lot of resistance to it at that time. Maybe the time is right for it this time… /Jan _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
