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

[Christian Vogt <christian.vogt at nomadiclab.com>]

Tony:

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

Yes, you need support on both sides.  It's similar to TCP congestion
control, which also can be effectively disabled by a misbehaving host,
namely through acknowledgment pacing.

The difference between Six/One and TCP congestion control is that, in
Six/One, a host has no incentives to misbehave.

The requirement for compliance on both sides exists for network-based
solutions as well.  Here, you need compliance by both edge networks.

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

Yes, Six/One enforces a symmetric path for each communication session.
You can have different paths for different sessions, but each of them
will be symmetric.

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

Here I was referring not to the provider fail-over case, but to the case
where the edge network operator decides to switch traffic to a different
operator for traffic engineering reasons.  E.g., the edge network
operator might want to load-balance traffic across its border routers.

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

Not sure if I understand you correctly.  But in any case:  Informing a
remote mapping function about locator alternatives is not enough.  You
also need...

- a provider selection mechanism locally in an edge network that
monitors provider connections and decides when it is time to switch, and

- a mapping update mechanism that tells remote mapping functions /when/
to switch to /which/ alternative locator.

Iljitsch and I have discussed the provider selection mechanisms in a
recent email exchange (see my email "Provider Selection and Mapping
Updates" from today).  And it is the mapping update mechanism where the
delays and packet losses that I was talking about in this email exchange
come into play.

- Christian


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