[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RAM] Re: the separation of ID/RLOC



Christian,

Sorry to take so long to respond.

On Jul 4, 2007, at 3:16 AM, Christian Vogt wrote:

Whether or not long update delays are an issue depends, as you say, on
the change frequency and granularity. However, any assumptions that we
make in this regards should be very careful. Our goal is to give edge
networks more freedom in traffic engineering and provider selection.
And it would be great if we could reach this goal without restrictions
-- such as in terms of change frequency or granularity.

Isn't this issue easily resolved by advertising more than one locator?

if you want to an enable edge network to decide through which provider
ingress packets are received, then the edge network must be able to tell
remote edge networks one specific transit locator to which they should
send packets.


A destination can certainly express a preference, but as always, the holder of the packet gets to decide on the next hop. This may or may not include dropping the packet. This is best effort and there are no guarantees.


If an edge network advertises more than one transit locator, then it is
up to remote edge networks to select one of those. This takes away the
ability for edge networks to select an ingress provider.


Since a destination does not currently have that ability and the ability to be multi-homed today, I don't see that this is truly an issue. Further, I don't see a path to a world where this could ever be the case. In today's world, where only a single prefix is advertised, the destination can use various methods (e.g., path prepend) to try to induce particular path selection, but this is not a guarantee. A transit provider can easily have a policy in place that contradicts the end-user policy, and the transit provider's policy will win.

In a world where a host can express a locator preference, the correspondent can also choose to ignore the destination's preferences. This seems like it shifts control from the transit to the correspondent, but at no time would it ever seem to give the destination true and unilateral control.


Additionally,
you still need a locator selection mechanism for the remote edge network
-- which may involve its own signaling overhead, delay, and packet loss.


I think you're making an assumption that only a single locator would be advertised at a time, and that signaling would be required to transition between locators.

In fact, I was positing having multiple locators advertised simultaneously, with preferences expressed about their utilization. We do this already today with MX records and it seems to work passably well.


With Six/One [1], edge networks can select both their ingress and egress
providers, and they can change them within 1 RTT without signaling.


If I understand it correctly, a host can advertise what addresses are in its bunch, and a network can choose to do a prefix rewrite, which *should* result in the correspondent using the same addresses. However, the enforced symmetry is based on the actions of the correspondent host, which is not guaranteed. Further, when taken into conjunction with source address filtering by the next hop egress network, it implies that the edge network is going to necessarily couple its ingress and egress providers on a per-packet basis.


There is also no packet loss if the old provider is still operational at
the time of the change. And the granularity of provider selection (both
ingress and egress) is on a per-communication-session level.


Unfortunately, the only practical way of determining that an old provider (or, more generally, an old path) is non-operational is to lose packets.

In short, I'm not seeing anything different here: if you advertise multiple locators, you would seem to be doing about the best that can be done in terms of providing alternate path information short of doing an explicit path setup. This would seem to be true of most of the proposals, unsurprisingly.

Tony

_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram