Subject: New Version Notification for draft-sarikaya-6man-next-hop-ra-02.txt

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 3 Jun 2014 11:30:11 -0500

Hi Dan, Brian, Ray, all,

I revised the draft and the revision can be found below.
Please let me know if there are any issues.

Regards,

Behcet

A new version of I-D, draft-sarikaya-6man-next-hop-ra-02.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Name:           draft-sarikaya-6man-next-hop-ra
Revision:       02
Title:          IPv6 RA Options for Next Hop Routes
Document date:  2014-06-03
Group:          Individual Submission
Pages:          13
URL:
http://www.ietf.org/internet-drafts/draft-sarikaya-6man-next-hop-ra-02.txt
Status:
https://datatracker.ietf.org/doc/draft-sarikaya-6man-next-hop-ra/
Htmlized:       http://tools.ietf.org/html/draft-sarikaya-6man-next-hop-ra-02
Diff:
http://www.ietf.org/rfcdiff?url2=draft-sarikaya-6man-next-hop-ra-02

Abstract:
   This document proposes new Router Advertisement options for
   configuring next hop routes on the mobile or fixed nodes.  Using
   these options, an operator can easily configure nodes with multiple
   interfaces (or otherwise multi-homed) to enable them to select the
   routes to a destination.  Each option is defined together with
   definitions of host and router behaviors.  This document also
   proposes the router advertisement extensions for source address
   dependent routing.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 9 Jun 2014 13:19:20 +0900

> Please let me know if there are any issues.

I have several concerns with this draft and do not support its adoption.

First: as defined, the next hop option completely removes the fate-sharing
properties of IPv6 route configuration. With this option, a router can now
specify a non-working next-hop, resulting in broken connectivity for the
hosts. I don't think we should do this. If the desire is to send traffic to
a router on a different interface, then that router should be sending an
RFC 4191 announcement itself.

The stated reason for this is:

   we assume that next hop routers are not able to provide this
   information.  One solution would be to develop an inter-router
   protocol [...] However, such a solution has been singled out due to
   the complexities involved.

However, that is a flawed argument. Consider the case where router A on
link A specifies router B on link B as the router for a specified prefix.
Now router B goes down. Router A has no way of knowing this because it's a
different link. The host now has broken connectivity. In order for the host
not to have broken connectivity, there would have to be an "inter-router
protocol" so router A could know about router B going away, and withdraw
the announcement. So this option, which is proposed precisely to avoid an
inter-router protocol ends up needing an inter-router protocol in order to
work properly.

It's worth noting that we have this problem in IPv4 today - because DHCPv4
does not share fate with routers, many networks are forced to run
redundancy protocols between routers (e.g., VRRP). We should not need to do
this in IPv6.

Second: this breaks the convention that routers are identified by
link-local addresses: because the address options do not contain a scope,
there is no way to use a link-local address in the next hop option, as it
would be meaningless. Thus it must be assumed that the IP address in the
next hop option must have global scope. But using global-scope addresses
removes the ability we have today to do seamless renumbering of IPv6
addresses using multiple prefixes.

Third: the multiple-interface model is much more crude than that currently
being proposed in the MIF working group. This draft should look at that
architecture, particularly with regard to explicit provisioning domains and
trust levels.

Regards,
Lorenzo

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Jun 2014 11:04:15 +1200

Hi Lorenzo,

On 09/06/2014 16:19, Lorenzo Colitti wrote:
> properties of IPv6 route configuration. 

I think that's an intrinsic problem with trying to make SADR work.
Only an intelligence that has some sort of overview can get this
right, i.e. assemble a complete and consistent set of SADR rules
that will always select the correct first hop to get a packet
into a part of the IGP system that will forward it towards the
correct site egress.

I remain to be convinced that this can actually be done by
distributed intelligence; but in any case, I think we are bound
to lose fate-sharing, regardless of whether the SADR rules
come via RAs, DHCPv6, or some other mechanism.

So I'd put it another way: until we have a general model for
how the SADR rules will be computed and distributed, defining
specifics of RA or DHCPv6 messages is maybe premature.

<snip>

> ... So this option, which is proposed precisely to avoid an

But where's the existence proof that we can avoid it?

> addresses using multiple prefixes.

I suppose we could argue that each router on a link could be aware of
all other routers on the same link, and therefore could know the
appropriate link-local address. Or we could argue that each router
should only send Next Hop RAs that pertain to itself. But again, that
points to the fact that we need a general model before we finalise specifics.

If this was the only issue for seamless renumbering, I'd be a
happy man.

> architecture, particularly with regard to explicit provisioning domains and

I agree, although how PVDs will be reduced to code is still a bit
of a mystery to me. Once again: what's the general model for SADR?

(For those in a mood for more brain punishment, see
http://tools.ietf.org/html/draft-shyam-site-multi . There are
many issues with that draft, but it also raises some
interesting points.)

   Brian

---

From: Ray Hunter <[email-masked]>
Date: Tue, 10 Jun 2014 19:57:37 +0200

> Brian E Carpenter <mailto:[email-masked]>
> 10 June 2014 01:04
> Hi Lorenzo,
>
>> On Wed, Jun 4, 2014 at 1:30 AM, Behcet Sarikaya<[email-masked]>
>> wrote:
>>

> ------------------------------------------------------------------------
FWIW I suspect that we are heading towards a scenario where such 
multi-homed end systems are forced to take part in one or more routing 
protocols, and in a manner similar to an EIGRP stub router or a BGP 
multi-homed AS i.e. the multi-homed hosts establish neighbors with 
multiple upstream routers (possibly from multiple ASes), they speak the 
native routing protocol(s), they learn routes in the same way as 
fully-fledged routers (fate sharing), but they do not/ cannot acts as 
transit devices that forward traffic not destined to or sourced from 
themselves (loop and policy violation prevention).

IMHO attempting to shoehorn this function into ICMP/ RA is not going to 
cut it.

-- 
Regards,
RayH

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 10 Jun 2014 15:17:40 -0500

On Tue, Jun 10, 2014 at 12:57 PM, Ray Hunter <[email-masked]> wrote:
> FWIW I suspect that we are heading towards a scenario where such multi-homed
> end systems are forced to take part in one or more routing protocols, and in
> a manner similar to an EIGRP stub router or a BGP multi-homed AS i.e. the
> multi-homed hosts establish neighbors with multiple upstream routers
> (possibly from multiple ASes), they speak the native routing protocol(s),
> they learn routes in the same way as fully-fledged routers (fate sharing),
> but they do not/ cannot acts as transit devices that forward traffic not
> destined to or sourced from themselves (loop and policy violation
> prevention).
>

> IMHO attempting to shoehorn this function into ICMP/ RA is not going to cut
> it.
>

In the near field communication (NFC) scenario the multi-homed host is
routing packets for IP sensors that are embedded in the host. Also the
host may be routing packets from one interface to the other.
Sorry I don't understand your concern.

Regards,

Behcet

---

From: Ole Troan <[email-masked]>
Date: Tue, 10 Jun 2014 22:45:25 +0200

Brian,

> into a part of the IGP system that will forward it towards the

if we're talking about SADR as in http://tools.ietf.org/html/draft-troan-homenet-sadr-01,
then the context of SADR is within multi prefix multi-homing. i.e. multi-homing with a single interface. the network does SADR, the hosts can optimize by following rule 5.5. of 6724. and it assumes a strong host model (1122).

while for a host directly connected to the egress routers, there does not need to be any exchange of information between those. for a general topology the expectation is that a routing protocol is used and all routers in the network must follow the same forwarding paradigm.

could you expand on what you think is missing, and what you mean by "only an intelligence..."?

and back to this draft, I don't quite understand what problem the draft sets out to solve.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Jun 2014 15:05:58 +1200

> then the context of SADR is within multi prefix multi-homing. i.e. multi-homing with a single interface. the network does SADR, the hosts can optimize by following rule 5.5. of 6724. and it assumes…

That isn't the general case, and probably MIF isn't the general
case either, and both scenarios can arise in enterprise networks
too. I'm not saying that one solutions fits all cases, but I'm
thinking that we need an overview document that describes all cases.

> while for a host directly connected to the egress routers, there does not need to be any exchange of information between those. for a general topology the expectation is that a routing protocol is…

But there may still be multiple routers per link, and/or
multiple interfaces per host, so hosts have to pick an address
pair, an outbound interface and a next hop.

> could you expand on what you think is missing, and what you mean by "only an intelligence..."?

That overview document is missing, and I suspect it will turn
out that in the general case, hosts will need information that
they could only get by participating in the routing protocol
(which is distributed intelligence).

> and back to this draft, I don't quite understand what problem the draft sets out to solve.

Actually I've come to agree with you, which is why I think we
need that overview.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 11 Jun 2014 12:26:40 +0900

> into a part of the IGP system that will forward it towards the

I don't see why. In order to make host-based SADR work, you need the host
to know:

1. It should not use source prefix X to talk to nexthop Y.
2. It should prefer source prefix X to talk to destination prefix P.
3. It should prefer source prefix X to talk to nexthop Y.

I don't see how any of these require giving up fate sharing. I do see how
these constraints will cause things to break if you don't have fate sharing.

Note that host-based SADR is not the case in homenet, BTW; homenet takes
care of SADR in the network.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Jun 2014 16:16:11 +1200

> these constraints will cause things to break if you don't have fate sharing.

But what if the X', Y', P' rules come from another source, that
doesn't share fate with the source of the X, Y, P rules?

> care of SADR in the network.

Not, I think, if some hosts are MIFfed directly onto wireless
ISPs. That will happen, even if the homenet architecture doesn't
expect it.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 11 Jun 2014 13:29:38 +0900

> doesn't share fate with the source of the X, Y, P rules?

Please provide an example.

---

From: Ray Hunter <[email-masked]>
Date: Wed, 11 Jun 2014 09:00:40 +0200

> Behcet Sarikaya <mailto:[email-masked]>
> 10 June 2014 22:17
> On Tue, Jun 10, 2014 at 12:57 PM, Ray Hunter<[email-masked]>  wrote:
>>> Brian E Carpenter<mailto:[email-masked]>
>>> 10 June 2014 01:04
>>>
>>> Hi Lorenzo,
>>>
> routing packets for IP sensors that are embedded in the host.
Hmmm. Do you assume that device partnered with the NFC interface speaks 
native IPv6? Or is this actually an ALG?
> Also the
If a device is forwarding IPv6 packets that are not sourced or destined 
to it's own interface address, then it's acting as a router.

Quoting RFC2460

    router      - a node that forwards IPv6 packets not explicitly 
addressed to itself.  [See Note below].

Note: it is possible, though unusual, for a device with multiple
    interfaces to be configured to forward non-self-destined packets
    arriving from some set (fewer than all) of its interfaces, and to
    discard non-self-destined packets arriving from its other interfaces.
    Such a device must obey the protocol requirements for routers when
    receiving packets from, and interacting with neighbors over, the
    former (forwarding) interfaces.  It must obey the protocol
    requirements for hosts when receiving packets from, and interacting
    with neighbors over, the latter (non-forwarding) interfaces.

Why would the device which is acting as a router listen to RA (when 
making any decision on forwarding packets)?

Yes, I am aware of the (IMVHO poor) decision to use RA to communicate a 
default route to the WAN interface of 6204/7084 routers.

That concept is not going to fly IMHO once you have more than one "WAN" 
interface.

Unless you want to copy the stacking model of IPv4 where one router acts 
as a DHCPv4 server and the following as a DHCPv4 client + NAT.

What do you do when the NFC device you are paired to is also 
multi-interface? [NFC phone pairs with another NFC equipped phone]

-- 
Regards,
RayH

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 11 Jun 2014 11:31:58 -0500

Hi Ray,

On Wed, Jun 11, 2014 at 2:00 AM, Ray Hunter <[email-masked]> wrote:
>>>>> redundancy protocols between routers (e.g., VRRP). We should not need
>>>>> to
>>>>> do
>>>>> this in IPv6.
>>>>
>>> multi-homed
>>> cut
> If a device is forwarding IPv6 packets that are not sourced or destined to
> it's own interface address, then it's acting as a router.
>
> Quoting RFC2460
>
>    router      - a node that forwards IPv6 packets not explicitly addressed
> to itself.  [See Note below].
>
> Why would the device which is acting as a router listen to RA (when making
> any decision on forwarding packets)?
>

In the draft, I am not saying anything from myself, I just quoted RFC
7157, so if you disagree then maybe 7157 needs to be changed.

> Unless you want to copy the stacking model of IPv4 where one router acts as
> a DHCPv4 server and the following as a DHCPv4 client + NAT.
>

IPv4 is out of scope in my draft.
As per Brian's suggestion I am working on a DHCPv6 document. In
connection with that solution an IPv4 version of the options can be of
defined.

> multi-interface? [NFC phone pairs with another NFC equipped phone]

Maybe link layer solutions can be used but in any case, I believe such
issues are in scope of groups like 6lo WG.

 Regards,
Behcet

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 Jun 2014 14:20:41 -0400

> ISPs. That will happen, even if the homenet architecture doesn't

Can you explain this situation in more detail?
Are you talking 3G/wifi in a smartphone, or something different?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jun 2014 14:07:47 +1200

> Are you talking 3G/wifi in a smartphone, or something different?

That would be one option, or a tablet of course. Another would
be whatever is standing in the corner where the TV is today - it
might turn out to have its own external connection, at least
for a vendor's call-home facility, over whatever replaces
the CATV cable. I just think that we must assume that the model
of one CE device as the only external point of connection
is not a future-proof assumption.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 12 Jun 2014 11:14:39 +0900

> ISPs. That will happen, even if the homenet architecture doesn't

All the more reason to ensure that each network the host is plugged into
provides a self-sufficient, internally-consistent, and complete view of the
network connectivity it provides, without attempting to draw conclusions or
provide information about any other networks the host might be plugged into.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jun 2014 14:18:25 +1200

> Please provide an example.

The simplest is perhaps the neighbour's WiFi network drifting
across the garden fence, so you get both your own wired
and your neigbour's wireless prefix info. You could tell me
"don't do that" but people will do it, quite unintentionally.

We could of course agree to sacrifice fate-sharing in such a
case. An MPTCP or shim6 like approach that will use whatever
address pairs happen to work will take the sting out of the
failure cases.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jun 2014 14:21:44 +1200

> provide information about any other networks the host might be plugged into.

Agreed. I don't see the draft in question intending to violate
that model.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 12 Jun 2014 11:23:28 +0900

> "don't do that" but people will do it, quite unintentionally.

Can you clarify this further? Is your host simultaneously connected to both
wifi networks? Or are the two homenets merged together?

> address pairs happen to work will take the sting out of the

It's true that "always try every possible combination all the time" does
usually result in something that works (or, at least, is working when you
check it, though it may fail later). But typically we try to build
solutions that are more efficient than that.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 12 Jun 2014 11:27:57 +0900

> Agreed. I don't see the draft in question intending to violate

But it does, because the "next hop address" option is not restricted to be
on the same link as the router that sends it. Therefore, this option can be
used by a router on network A to tell a host to use a next-hop on network
B, even though that router might know nothing at all about whether the host
is even connected to network B.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jun 2014 14:48:59 +1200

> wifi networks? Or are the two homenets merged together?

I've never seen an interface that was capable of joining two
Wi-Fi networks simultaneously, although I suppose you could always
plug in a second interface. But I was actually thinking of one wired
and one Wi-Fi.

And yes, I can also imagine a situation where routers in two
neighbouring homenets decided to establish adjacency due to
some accident with Wi-Fi configuration. Among several billion
pairs of neighbouring homenets, this is bound to happen at
some frequency, I think.

> solutions that are more efficient than that.

If we can, certainly. But perverse cases will arise sometimes,
and we'd prefer that they didn't generate help desk calls.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jun 2014 14:52:27 +1200

> is even connected to network B.

Ah, I see the disconnect here. Yes, I was certainly assuming that
the entity sending the Next Hop options has full topological
knowledge.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 12 Jun 2014 12:04:52 +0900

>  the entity sending the Next Hop options has full topological

I assert that assuming the existence of an entity that has full topoloical
knowledge (especially in a home network) is a fallacy that should
henceforth be known as the "god box fallacy".

---

From: Ralph Droms <[email-masked]>
Date: Thu, 12 Jun 2014 06:46:47 -0400

> On Jun 11, 2014, at 11:04 PM, Lorenzo Colitti <[email-masked]> wrote:
> 
>> On Thu, Jun 12, 2014 at 11:52 AM, Brian E Carpenter <[email-masked]> wrote:
> I assert that assuming the existence of an entity that has full topoloical knowledge (especially in a home network) is a fallacy that should henceforth be known as the "god box fallacy".
> 

I thought that idea was known as "SDN"...

- Ralph

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 12 Jun 2014 19:52:22 +0900

> I thought that idea was known as "SDN"...

Wake me up from cryogenic sleep when the first SDN home network is deployed
:-)

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Jun 2014 15:02:54 +0200

Le 12/06/2014 04:48, Brian E Carpenter a écrit :
>>>>>> I don't see how any of these require giving up fate
>>>>>> sharing. I do see
>>> how
>>>>>> these constraints will cause things to break if you don't
>>>>>> have fate
>>>>> sharing.
>>>>>
>>>>> But what if the X', Y', P' rules come from another source,
>>>>> that doesn't share fate with the source of the X, Y, P
>>>>> rules?
>>>>>
>>> across the garden fence, so you get both your own wired and your
>>> neigbour's wireless prefix info. You could tell me "don't do
>>> that" but people will do it, quite unintentionally.
>>>
>>
>> Can you clarify this further? Is your host simultaneously connected
>> to both wifi networks? Or are the two homenets merged together?
>
> I've never seen an interface that was capable of joining two Wi-Fi
> networks simultaneously,

Right, that is the case with most WiFi interfaces: each can join one
ESSID not more.

As an addition, there exist some slight variations which may make think
of an interface joining several ESSIDs: 802.11p and 802.11ac.

In 802.11p there is no ESSID so an interface may be interpreted
to join all ('*') networks.

In 802.11ac an interface joins two channels: one in the 2.4GHz and the
other in the 5.4GHz range, to offer an aggregated 1Gbps bandwidth.

Depending on implementation, an 802.11ac card may join the 2.4GHz
channel of one ESSID and the 5.4GHz channel of another.

> although I suppose you could always plug in a second interface.

Right, and that is typically the case with 'boxes' deployed in vehicles 
such as automobiles.  They carry at least 2 WiFi interfaces - one for 
the external WiFi hotspot and one to offer hotspot to passengers (the 
vehicle's frame is usually a very strong attenuator in this power ranges).

> But I
> was actually thinking of one wired and one Wi-Fi.
>
> neighbouring homenets decided to establish adjacency due to some
> accident with Wi-Fi configuration. Among several billion pairs of
> neighbouring homenets, this is bound to happen at some frequency, I
> think.

I agree.  And it may happen not only on these boxes WiFi interfaces but 
also on their femto-cell interfaces.

Alex

>> It's true that "always try every possible combination all the time"
>> does usually result in something that works (or, at least, is
>> working when you check it, though it may fail later). But typically
>> we try to build solutions that are more efficient than that.
>
> If we can, certainly. But perverse cases will arise sometimes, and
> we'd prefer that they didn't generate help desk calls.
>
> Brian
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Ray Hunter <[email-masked]>
Date: Thu, 12 Jun 2014 22:09:36 +0200

> Lorenzo Colitti <mailto:[email-masked]>
> 12 June 2014 05:04
>
> I assert that assuming the existence of an entity that has full 
> topoloical knowledge (especially in a home network) is a fallacy that 
> should henceforth be known as the "god box fallacy".
>
Absolutely agree. In these days of "bring your own device" that's 
rapidly becoming equivalent to "bring your own router".

-- 
Regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Jun 2014 16:39:35 +1200

> rapidly becoming equivalent to "bring your own router".

(This takes us right back to today's mailstorm on homenet.)

Link-state and distance-vector routing protocols are both based
on graph theory algorithms that *assume* perfect knowledge of
the topology. That is a bit strange, since initially routers have
almost zero knowledge of the topology, but the reality is that by
the time one of these routing protocols converges, the distributed
algorithm has discovered the topology in order to execute itself.
So Lorenzo's god box is distributed across all the nodes participating
in the routing protocol.

Logically, the whole problem does solve itself if all multi-addressed
hosts also run the routing protocol. I'm beginning to wonder if
that isn't actually a lower cost solution than the alternatives.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Jun 2014 14:01:25 +0900

> So Lorenzo's god box is distributed across all the nodes participating

Right, and that's fine.

I have no issues with an entity that has limited topological knowledge
presenting that limited knowledge to the hosts as authoritative. For
example: a router sending a host a route announcement for a prefix it knows
it can reach, and potentially annotating said route announcement with "you
must use this source prefix to reach this prefix through me" information,
if it has it (e.g., if it got a PD for the source prefix).

I have no issues with an entity that has "full" topological knowledge (for
some value of "full") presenting that knowledge to the hosts as
authoritative. For example: router participating in homenet giving
information on the homenet - if homenet runs a distributed routing
protocol, once the protocol has converged, then all nodes have "full"
knowledge.

I strongly oppose having an entity with limited topological knowledge
telling the hosts things it does not have knowledge about. For example, the
homenet router in the previous paragraph making assertions about the a 4G
network the host might be connected to, or a 4G network making assertions
about a wifi network the host might be connected to.

> that isn't actually a lower cost solution than the alternatives.

It will be a long time before we get there.

What sort of problem are we trying to solve? If it's just a question of
"this route is not likely to work from this source address", the host
doesn't need a routing protocol. It just needs a way to have that hint
communicated to it in a timely manner.

---

From: Ole Troan <[email-masked]>
Date: Fri, 13 Jun 2014 12:00:03 +0200

Brian,

> that isn't actually a lower cost solution than the alternatives.

Topology #1:

CER A    CER B
   |               |
   --------------
           |
        host

Topology #2:

CER A    CER B
   |               |
   --------------
           |
       router
           |
        host

Topology #3:

CER A ----|
                 |----  host ---- CER B
CER B ----|

what do you mean by the "whole problem"?
I assume we are talking about multi-prefix multihoming, in my mind that is where a host has a single interface with multiple addresses (from different /64s). each address is essentially connected to different exit circuits, and it is the responsibility of the host to "multi-home". 

topology #1 and #2 (which can be an arbitrary topology) is MHMP. Topology #1 is solved by rule 5.5 in RFC6724 (prefer the next-hop router that I learnt the source address from). Topology #2 is solved by SADR in the network.

all of them put quite a lot of requirements on the host/application:
 - probing for working SA/DA pairs on connection
 - load sharing across circuits
 - failover to different SA/DA pair on failure
 - take local host policy into consideration, e.g. prefer WIFI over 4G for cost reasons, rather than purely using the link with
   best latency / bandwidth
 - take connected network policy into consideration, e.g. only use source addresses from ISP A, when ISP B fails (cause that's my 
   expensive backup link.)

would any of this be easier if the host had full routing information available? a full BGP feed from each ISP on each interface? I just can't see that, I need sub-second failover, BGP provides sub hour convergence. even participating in SADR doesn't really give the host very much, SADR only helps reaching the right exits in the local network. the routers do that for the host already. and yes in an arbitrary topology routers must use a routing protocol for that.

topology #3 which is what in my reading this draft focuses on. it appears to proposed that a multi-homed host (that is, with multiple interfaces) should trust a message from a router on one interface to install a route to a different router on another interface. that seems like a big departure from how routing generally works. and it makes a big assumption about how the host is connected to the network. it also seems like quite a far fetched use case. I'll connect to a WIFI link, to receive a default route that should point out the 4G interface?

as far as I'm concerned the problem of MHMP is solved, with SADR in the network and rule 5.5 in the host directly connected to do independent CERs. and while the local network can give some indication on failure, the network is largely unaware of the end to end connection, and I don't see any other option than that the host probes. isn't that what essentially shim6 does to? the use of MP-TCP would of course help a lot. what problem do you see as unsolved here?

what is lacking though, is how hosts / applications deal with multi-homing. I run MPMH at home and I have still not found any IP stack / application that handles that well. name based sockets seemed quite promising, anyone continuing work on that?

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Jun 2014 13:31:19 +1200

Ole,

comment at the end...

>> that isn't actually a lower cost solution than the alternatives.

I see the total problem as more complex because there are certainly other
scenarios, and in enterprise networks there's a general lack of
understanding that multiple prefixes should be considered the norm
in IPv6, as well as their interaction with ISP ingress filters
and with multiple border routers. So I stick to my view that we need
an overview document (to which your message would be a major
contribution). Unfortunately as I've already told Behcet off-list,
I just don't have the time to work on that and also I don't think
I have enough knowledge.

> what is lacking though, is how hosts / applications deal with multi-homing. I run MPMH at home and I have still not found any IP stack / application that handles that well. name based sockets seeme…

As far as I know it is dormant. I actually agree with you, if it could
be made to work. For a bit more discussion see my recent rant in CCR:
http://www.sigcomm.org/ccr/papers/2014/April/0000000.0000008

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Jun 2014 13:33:52 +1200

On 13/06/2014 17:01, Lorenzo Colitti wrote:
...
> communicated to it in a timely manner.

If your application runs over TCP, MPTCP resolves this.

   Brian

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 17 Jun 2014 15:10:58 -0500

Hi Ole,

>> that isn't actually a lower cost solution than the alternatives.

What is CER in your topologies? I did not see them used in RFC 7157?

Behcet
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Ole Troan <[email-masked]>
Date: Tue, 17 Jun 2014 22:21:08 +0200

> What is CER in your topologies? I did not see them used in RFC 7157?

Customer Edge Router. See RFC6204, or the homenet-arch document.

cheers,
Ole

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 17 Jun 2014 16:27:25 -0500

Then I don't understand your Topology #2, it is not in homenet-arch?
Where is it, what is it?

Behcet

---

From: Ole Troan <[email-masked]>
Date: Tue, 17 Jun 2014 23:34:18 +0200

> Then I don't understand your Topology #2, it is not in homenet-arch?

what don't you understand?
Two ISPs, two CERs, internal router on shared subnet

cheers,
Ole