Wendy, all, I agree, PIDs are not the same as routes.
I am wondering whether we should specify client behavior if a server sends a map with the same prefix in two PIDs. Should it ignore the complete map, or just the duplicate prefix(es)? Or can we find a sort-of reasonable algorithm to resolve the ambiguity? Defining a map with certain properties as "illegal" (i.e., saying that the server MUST NOT send it) but completely leaving unspecified how the client should react if the server does it anyway is IMO not a good practise. Sebastian On Mon, Oct 28, 2013 at 09:02:04AM -0400, Wendy Roome wrote: > Here's my take. A PID is a collection of endpoints whose "cost metrics" are > sufficiently similar that we can lump them together as a group. PIDs > partition the endpoint space into equivalence classes. By that definition, > an endpoint can only be in one PID. > > I think the problem is that we're confusing "PIDs" with "routes". A PID is > *not* a route. If there are multiple routes to the endpoints in a PID, the > network picks the best route, and the ALTO server's cost metric should > reflect the cost of that best route. But the route to an endpoint does *not* > determine the endpoint's PID. An endpoint is always in the same PID, > regardless of the route the network uses to get to that endpoint. > > Example: An office has a network with 500 endpoints. The office network has > a hierarchy of internal routers, and (say) two gateway routers that connect > to the rest of the internet via two different ISPs. As I see it, those 500 > endpoints are in one PID, regardless of how many gateway routers connect > them to the outside, and whether or not they're working. The ALTO server may > say that the gateway routers are in the office PID, or they may be in the > ISP's PIDs, or they may each be in their own PID. That's the ALTO server's > call. > > But the PID for an endpoint in that office does *not* depend on the route > used to get to it. It's always in the same PID, regardless of which router > is active. The endpoints do not move from one PID to another if a gateway > router goes down. > > I agree with Richard that saying, "A server must not do 'foo', but if it > does, a client should recover by doing 'bar'" seems wrong. If a server > violates the protocol, that's an error. > > As for situations where an ALTO server might put the same CIDR in two PIDs > because the server is automagically deduces PIDs from network routes, well, > it's the server's responsibility to detect that duplication and resolve it > by picking a PID. It's not the client's job. > > - Wendy > > From: "Y. Richard Yang" <[email protected]> > Date: Fri, October 25, 2013 15:39 > To: "Reinaldo Penno, (repenno)" <[email protected]> > Cc: Sebastian Kiesel <[email protected]>, IETF ALTO <[email protected]>, > Wendy Roome <[email protected]> > Subject: Re: [alto] Problem with "longest prefix" rule for mapping > endpoints to PIDs > > > > On Oct 24, 2013 6:37 PM, "Reinaldo Penno (repenno)" <[email protected]> > wrote: > > > > Right. Routers have forwarding entries that point to N different > > interfaces. Sometimes they have the same weight, sometimes flow load > > balancing or some other tie breaking internal to the router. And ALTO has > > prefixes that are mapped to two different PIDs. Just another day in the > > Internet. > > Mapping to multiple prefixes in fib has well defined semantics, such as load > balancing paths, as you mentioned. It is not clear the use cases for mapping > to multiple PIDs, and our current assignment to resolve the case (e.g., 2d > or 2e) may not provide the intended semantics (e.g., hash on IP to achieve > load balancing). Hence, I am still in the pushing-back mode for > simplicity... > > Richard > > > > On 10/24/13 2:24 PM, "Sebastian Kiesel" <[email protected]> wrote: > > > > >But we should not declare multiple > > >occurences of one prefix as illegal, > > > > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
