Hi Rich, On Feb 1, 2012, at 9:04 AM, Richard Alimi wrote: > I guess I'm a bit late to the party, so I can keep this simple and say > how the draft was currently intended: > (1) The choice of the term "endpoint" (those thingy's that are > contained in PIDs) was not an accident :) > (2) As such, each entry of the Cost Map is the *end-to-end* cost from > the source to the destination (I think this is what Ben meant by > "mesh"). That is, the ALTO Server has already added up the costs on > the physical links along the path for you.
do you intend that a cost map is supposed to be a full mesh of leaf nodes (as per analogy to SPF algorithm) ? IOW: you're not expected to transit across PIDs ? > (3) If there is an entry missing from the Cost Map, it means the ALTO > Server doesn't know the cost from that source to destination (or isn't > willing to tell you). I guess you could generate a path, but the point > about whether a packet can actually traverse that path is a good one > -- ALTO doesn't make any claims on routing capabilities offered by > endpoints. > > Given that particular meaning, you could imagine doing overlay routing > on that (e.g., in a P2P swarm). In that sense, each endpoint is a node > on a graph, and you could imagine doing shortest path on that. > However, that's quite different than doing shortest path on the actual > network topology. This was the reason for my comments a few times (I > guess not on the list, it was probably at the mic during a WG session) > that if we were to ever expose raw network topology via ALTO, then we > need to explicitly denote that it would be a different interpretation > of the Cost Map than we have today (an adjacency matrix seems like a > reasonable model here). I believe we have two orthogonal elements: 1. Information that can be leveraged by traditional SPF/Dijktra algorithm so to compute a topology using same algorithm/paradigms than the ones used in the network. This can be a cost map, I don't mind, as long as the semantic of the information is compatible with what we want to do with it. In this respect, Ben asked a valid question. 2. The ability, for an ALTO server, to deliver a partial or aggregated or virtual topology that would NOT represent the reality of the network infrastructure but rather the topology that the application needs in order to optimize its business. Implementors have worked quite a bit on the latter. > Along those lines, I'm a little bit hesitant of the proposal to add a > "transit" attribute to a PID, since that seems to conflate the two > possible interpretations of the cost map (end-to-end costs vs. > adjacency matrix). If we wanted to convey the actual graph, how about > have an attribute for the entire cost map that indicates explicitly > that it is to be interpreted as an adjacency matrix (and obviously, > ordinal costs would not make sense there). FYI: routing protocols do have such node attribute. In ISIS we call it "overload-bit" and allows an operator to define a router as a non-transit device. Having the same capability in ALTO doesn't look unreasonable to me. I'd go a bit further and I believe having PID Capabilities TLV would probably help. s. > Given this discussion and the confusion it caused, we'll have to go > back and ensure this is explicitly stated in the draft. > > Thoughts? > Rich > > On Mon, Jan 30, 2012 at 9:03 AM, Ben Niven-Jenkins > <[email protected]> wrote: >> Colleagues, >> >> In the current specification of ALTO, are costs always End to End? >> >> What I mean by that is when looking at ALTO cost maps is it possible to >> safely assume that of there is a cost between PIDX & PID Y and a cost >> between PIDY & PIDZ then the cost between PIDX & PIDZ can be calculated as >> cost(PIDX,PIDY)+cost(PIDY,PIDZ)? [If this assumption does hold, it is >> obviously not applicable to ordinal cost types]. >> >> I suspect the answer is no, but I wanted to check what the definitive answer >> is. >> >> >> For example if a cost map contains: >> >> "map" : { >> "PID1": { "PID2": 1 }, >> "PID2": { "PID1": 1, "PID3": 2 }, >> "PID3": { "PID2": 2 } >> >> Can one assume that the cost between PID1 & PID3 is 3 (PID1->PID2 + >> PID2->PID3)? >> >> How about if the cost map contains: >> >> "map" : { >> "PID1": { "PID2": 1, "PID3": 3 }, >> "PID2": { "PID1": 1, "PID3": 2 }, >> "PID3": { "PID2": 2, "PID1": 3 } >> >> Can one assume PID2 is on a path between PID1 & PID3? >> >> Thanks >> Ben >> >> _______________________________________________ >> alto mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/alto > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
