Subject: Re: I-D ACTION:draft-arifumi-multi6-sas-policy-dist-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Nov 2004 13:29:26 +0100

> 3.1 Multihome Site with Global-Closed Mixed Connectivity
> 
>                   ==============
>                   |  Internet  |
>                   ==============
>                        |
>          2001:db8::/32 |         3ffe:1800::/32
>                   +----+-+   +-+----+
>                   | ISP1 |   | ISP2 | (Closed Network)
>                   +----+-+   +-+----+
>                        |       |
>        2001:db8:a::/48 |       | 3ffe:1800:a::/48
>          (DHCP-PD')   ++-------++   (DHCP-PD')
>                       | Gateway |
>                       +----+----+
>                            |  2001:db8:a:1::/64
>                            |  3ffe:1800:a:1::/64
>                            |        (RA'/DHCP')
>                  ------+---+----------
>                        |
>                      +-+----+ 2001:db8:a:1:[EUI64]
>                      | Host | 3ffe:1800:a:1:[EUI64]
>                      +------+

I'm afraid I don't see why this case is of interest to multi6.
It is a case where the user site is connected to one ISP and
to one WGP (walled garden provider). This is not site multihoming
in the sense of multi6. As far as I can see, a longest match is
sufficient to tell the host which source prefix to use.

> 3.2 Host with Multiple Home Addresses and Connectivity to Two Global
>    Networks

This is the case of interest to multi6.

...
>      Note that the end nodes are notified of an address-selection policy
>      that includes prefix ::/0 by both ISPs, hence a specific source
>      address for ::/0 can't be determined in the Label-Rule judgment
>      phase described in RFC3484. So, these entries for prefix ::/0 won't
>      actually be stored in the policy table, and this policy table won't
>      have any effect on source-address selection for packets that match
>      ::/0. The source address in these cases will be determined by
>      following rules listed in RFC3484, such as longest match with the
>      destination address.

Exactly. And it is this case - when two ISPs both offer connectivity to
::/0 - that multi6 has to solve. That seems to be the case you don't
help with.

>      Unlike the previous example (3.1.1(iv)), normal destination-
>      address-based routing doesn't specify a particular next-hop.
> 
>              Dst                        Next-Hop
>              2001:db8::/32              ISP1
>              ::/0                       ISP1
>              3ffe:1800::/32             ISP2
>              ::/0                       ISP2

i.e., it doesn't help me choose the appropriate exit router
and source prefix to use for a given destination in ::/0.

That would only be possible if the table contained separate entries
for every prefix that each ISP can route to - that amounts to the
whole BGP table for each ISP - with a metric. Which certainly doesn't
scale.

     Brian

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 8 Nov 2004 18:16:34 +0900

Hi Brian,
thank you for comments.

> sufficient to tell the host which source prefix to use.

Actually longest match isn't sufficient.
If a packet is destined for a closed network,
an appropriate source address is chosen
automatically by longest match.
On the other hand, a packet is destined for
somewhere in the Internet, it is not always
true. For example, when a packet is destined for
3ffe:1801::1 in the Internet, the source address
will be the one delegated by ISP2(WGP). In the
end, the reply packet for it never returns because
of the wall.

Anyway, I agree that this case may not be the scope
of multi6.

> ::/0 - that multi6 has to solve. That seems to be the case you don't

Though I didn't include them in this version of my I-D,
we are thinking of some other solutions. For those hosts
that can support ECMP(equal cost multi-path) or some
other special mechanisms for multihoming, it would
be helpful to notify all the default routes and all the
SAS Policies for default routes as I mentioned in I-D.

For normal hosts, however, it would be better not to
notify multiple routes for the same destination network.
So, it should be configurable on routers not to announce
multiple routes but to choose one. The configuration will
be like prioritizing ISPs.

It may be useful to define a new DHCP option for Solicit
message that explicitly requests for multiple routes for
the same destination network.

--
Arifumi Matsumoto
     Ubiquitous Computing Project
     NTT Information Sharing Platform Laboratories
     E-mail: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Nov 2004 22:36:19 +0100

> end, the reply packet for it never returns because

Yes, correct. It needs to be a bit more complex than
longest match - it's exact match on the /32 for ISP2
and you *will* need a priority policy to achieve that.

Walled Gardens are bad things anyway, so I wonder if
we should solve this?
> SAS Policies for default routes as I mentioned in I-D.

Well, I think the multi6 conclusion is that we need active
reachability checking anyway. The most that SAS policy can
do is decide the order in which reachability is checked.

Therefore, I still think that SAS policy is a secondary
component for multi6.

    Brian