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

Arifumi Matsumoto wrote:
> Hi Brian,
> thank you for comments.
> 
> On 2004/11/05, at 21:29, Brian E Carpenter wrote:
> 
>>> 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.
> 
> 
> 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.

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?
> 
> Anyway, I agree that this case may not be the scope
> of multi6.
> 
>>
>>> 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.
> 
> 
> 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.

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

> 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 protected]
>