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

> 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