Let me add a bit to the multihoming case that motivated the multi-PID values discussion.
On Saturday, November 2, 2013, Y. Richard Yang wrote: > This is a great discussion! By building on IP addresses in the base > protocol, PIDs can serve as either locators or identifiers, which I think > is at the core of the discussion. > > My intuitive visualization of PIDs is that they represent the ports (PoPs) > of a giant, abstract switch. Without multihoming (connecting to multi > ports) or dynamics (e.g., mobility), it is obvious that each endhost (I > mean an interface, and a host with multiple interfaces are multiple > endhosts) connects to only one port of the switch. > > Next consider multihoming, and assume two homing only for simplicity. It > just means that the same endhost connects to two ports. If it is physical > multihoming, the endhost should use two interface cards each with its own > address (assume each interface should have a unique address) and we have no > problem. But in BGP style multihoming, the same address can be announced on > both ports. One clean definition is that we do not consider control-plane > multihoming and assume that the routing system will pick only a single > active port to reach the address (using src address is trickier, and I > prefer to forget it for now). Hence, we still have the semantics of unique > PID (port). > Assume the principle of maximum information hiding, we can first focus on only the data plane not the control plane. If the multihoming happens only in the control plane (rib) and the routing system picks a single home in the data plane (fib), then each address should belong to one PID, reflecting the data plane flows. Assume that the multihoming does happen in the data plane, and the fib uses multiple concurrent routes. First consider the simple extreme case to get some intuition: the ALTO Server defines only three PIDs (PID1 and PID2) each containing exactly the same prefix, and PID3 for the rest as default. Then the Cost Map should reflect the meaning that the bits from PID3 to the prefix will be split, say 20%, 80%. Consider routing cost. Then it will be consistent to set PID3 -> PID1: 0.2, PID3 -> PID1: 0.8. If PID1 and PID2 are merged into only PID1, we have PID3 -> PID1: 1. One can consider other metrics such as available bw, which is slightly more "speculative", and but still be able to handle them consistently as merged or split. In other words, one can *transform* a multi-PID values setting into a unique-PID value setting in most cases: find the same prefix that appeared in multiple PIDs, define a new PID containing only this prefix, and remove the prefix from other PIDs. In many cases, this should be sufficient. One potential case is that the ALTO server may try to convey extra redundancy: there are multiple, redundant paths to the prefix. This can be handled by the multi-value metrics: for example, define a cost metric that list/enumerates (the number of) disjoint paths. Are there cases the transformation is not enough? Richard This seems to be good as a first base design. One can think of a PID > represent an identifier in some settings. The discussion is for a different > time. > > Richard > On Oct 28, 2013 11:08 AM, "Reinaldo Penno (repenno)" <[email protected]> > wrote: > > [RP] And endpoint is an application, not an IP. So, an endpoint can be > in many PIDs. > > More inline.. > > From: Wendy Roome <[email protected]> > Date: Monday, October 28, 2013 7:57 AM > To: Cisco Employee <[email protected]>, "Y. Yang" <[email protected]> > Cc: Sebastian Kiesel <[email protected]>, IETF ALTO <[email protected]> > Subject: Re: [alto] Problem with "longest prefix" rule for mapping > endpoints to PIDs > > I agree with #1 & #3. But those just move an endpoint between PIDs. > That's fine. At any given time, the endpoint is only in one PID. > > But I disagree with #2. The endpoints in a multi-homed network may have > two different routes, but they are in one PID, not two PIDs. Here's how I > look at it: if I want to send a packet to 10.0.0.1, I just tell the network > to send the packet. I do *not* tell the network the route or which gateway > to use. > > [RP] The interface and source selection address determines to a great > extend the path the packet will take through a network. Both are possible > today and with IPv6 will be much more pervasive. > > > That's the network's job. And the network does its best to hide that > from users. Similarly, an ALTO client just wants the cost from endpoint A > to B. The client doesn't want to guess the best route. That's the ALTO > server's job. > > - Wendy > > > From: "Reinaldo Penno (repenno)" <[email protected]> > Date: Mon, October 28, 2013 10:37 > To: Wendy Roome <[email protected]>, "Y. Richard Yang" < > [email protected]> > Cc: Sebastian Kiesel <[email protected]>, IETF ALTO <[email protected]> > Subject: Re: [alto] Problem with "longest prefix" rule for mapping > endpoints to PIDs > > A few points to consider. > > Yes, an endpoint can move from one PID to another in case of Mobile IP > > Yes, and endpoint can be found in multiple PIDs if it is in a > > -- -- ===================================== | Y. Richard Yang <[email protected]> | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | =====================================
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
