On Thu, Dec 1, 2011 at 09:07, Tao Sun <hisun...@gmail.com> wrote:
> You can already do this today with RIOs, and I don't see why there need to
>> be two ways of doing the same thing. Adding a different method to configure
>> the same information is twice the code and more than twice the complexity,
>> since when you have two sources of information with different semantics you
>> need to figure out how to merge them, what happens if they disagree, what
>> to do if one is wrong, what to do if one expires, and so on.
>>
> We can not do this today. As 1 and 2 mentioned, both the deployed gateway
> and the 3GPP specification need to be updated to use RIO.
>
What I meant is that a protocol and IETF perspective, you can do this today
using RIOs. So the protocol is there if 3GPP wants to use it. The
3GPP specs need to be updated regardless of whether we decide to
standardize the proposed DHCPv6 route option or not.
> I agree we need to consider the disagree/confliction among policies. That
> is caused by the multiple interface feature. If you use RA for all the
> interfaces, the rule received may still conflict. Addressing the
> confliction is exactly what MIF WG shall consider IMHO.
>
It is not caused by having multiple interfaces, it is caused by the fact
that there are potentially two sources of information. It can happen even
on only one interface, if the network on that interface supports both RAs
and DHCPv6 route.
> Also, in the mobile case I don't understand how you would use a
>> different gateway anyway. The mobile network is a point-to-point link, so
>> there's no way to distinguish multiple gateways. How would you use this?
>>
>>
> There are two types of scenarios. 1) A host is connected to the mobile
> network and WiFi at the same time, a typical scenario of MIF. 2) A mobile
> host connects to multiple APNs simultaneously, i.e., multiple PDN
> connection is established. The type 2) scenrio is also considered to be
> addressed in the OPIIS (Operator Policies for IP Interface Selection)
> work item in 3GPP.
>
#1 can't be solved using either the DHCPv6 route option or RIOs because in
general the carrier network doesn't know the IPv6 address of the default
gateway on the wifi network.
#2 can be fixed both using DHCPv6 route option and using RIOs.
>
>> ***Broadband network
>>>
>>> 1. WiFi network. Some WiFi hotspots provide local services. The
>>> route configuration on RG is needed to direct some traffic to local network
>>> while other traffic to the Internet.
>>>
>>
>> I don't understand why you need host changes to do this. Since the
>> hotspot router is a router, it can simply forward the packets the right way
>> by itself.
>>
>>
> You may refer to the Section of 3.4 of this draft or Section 5.2 of RFC
> 4191.
>
I don't see how Section 3.4 of this draft ("applicability to routers") is
relevant to this discussion. Section 5.2 of RFC 5191 describes a different
scenario (two routers on the same link) than the one you suggested here
(one router on a given link).
> 2. VPN network. When a user connect to enterprise VPN network,
>>> the routing of VPN traffic need to be configured. Due to the large number
>>> of such VPN network, we cannot assume all the VPN network only use RA.
>>> DHCPv6 provides another choice which may be preferred by the VPN network.
>>>
>>
>> The rationale here seems to be that "if we create a new option, some
>> networks might use it". That's certainly true, but it doesn't provide a
>> compelling reason why we need the option in the first place.
>>
> To us, its a compelling reason due to the network managment/operation,
> per-subscriber service, foresee burden of modification to existing gateway
> and specifications.
>
Who is "us", and what is the use case? I don't see why the ones discussed
so far can't use RIOs.
_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif
