Subject: Re: [alto] Problem with "longest prefix" rule for mapping endpoints to PIDs

From: "Y. Richard Yang" <[email-masked]>
Date: Sat, 2 Nov 2013 21:54:04 -0400

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).

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-masked]>
wrote:

>  [RP] And endpoint is an application, not an IP.  So, an endpoint can be
> in many PIDs.
>
>  More inline..
>
>   From: Wendy Roome <[email-masked]>
> Date: Monday, October 28, 2013 7:57 AM
> To: Cisco Employee <[email-masked]>, "Y. Yang" <[email-masked]>
> Cc: Sebastian Kiesel <[email-masked]>, IETF ALTO <[email-masked]>
> 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-masked]>
> Date: Mon, October 28, 2013 10:37
> To: Wendy Roome <[email-masked]>, "Y. Richard Yang" <
> [email-masked]>
> Cc: Sebastian Kiesel <[email-masked]>, IETF ALTO <[email-masked]>
> 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
> multi-homed network, I.e., a network where the gateway is connected to
> multiple networks.
>
>  Yes, and endpoint  can move from one PID to another if the Gateway is
> down since a host interface can be withdraw and the endpoint will move.
>
>  Thanks,
>
>  Reinaldo
>
>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Sun, 3 Nov 2013 11:08:46 -0500

Let me add a bit to the multihoming case that motivated the multi-PID
values discussion.

> prefer to forget it for now). Hence, we still have the semantics of unique
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

-- 
-- 
 =====================================
| Y. Richard Yang <[email-masked]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================