Re: draft-kaiser-nd-pd-00.txt

[Romain KUNTZ <[e-mail]>]

On Nov 3, 2012, at 19:29 , Alexandru Petrescu <[e-mail]> wrote:
> Le 03/11/2012 19:05, Romain KUNTZ a écrit :
>> Hello Alex,
>> 
>> On Nov 3, 2012, at 17:53 , Alexandru Petrescu
>> <[e-mail]> wrote:
>>> Le 02/11/2012 20:59, Michael Richardson a écrit :
>>>> 
>>>> Alexandru Petrescu <[e-mail]> wrote: AP> Well
>>>> yes, the prefix allocated to a vehicle when using NEMO is AP>
>>>> actually DHCPv6 Prefix Delegation RFC6276.  In that RFC the AP>
>>>> presence of HA is mandatory.
>>>> 
>>>> AP> But some times HA may not be available, e.g. in remote areas
>>>> or AP> uncovered areas.  There, one would still want vehicles to
>>>> AP> inter-communicate.
>>>> 
>>>> Yes, so if there is no uplink, then there is no addresses, so
>>>> really, it's not an address allocation problem, it's a routing
>>>> problem.
>>> 
>>> In a sense yes.
>>> 
>>> But let me try to present this better.
>>> 
>>> I think you agree that, in general, one wouldn't forbid two nearby
>>> vehicles to communicate to each other, even though infrastructure
>>> may not be available in that area.  If you differ on this aspect
>>> (like assuming pervasive WMAN everywhere) then please let me know.
>>> 
>>> When there is no uplink (no WMAN) the negative aspect is that
>>> vehicles can not use MIP-NEMO nor NEMO-DHCP-PD to dynamically
>>> obtain prefixes. The positive aspect is that they can self form
>>> whatever but unique addresses they want, or assign whatever but
>>> routed addresses among them, without fear of disturbing
>>> infrastructure routing, and happily without tunnels either.
>> 
>> Sorry to jump into the discussion. In the case there is no uplink
>> connectivity, I would tend to say that vehicles would use the prefix
>> that had been assigned to them previously (when infrastructure was
>> available and they had connectivity to run NEMO/DHCPv6-PD). Or do
>> you consider that the LV would never have the capability to connect
>> to the infrastructure?
> 
> HEllo Romain and thank you for discussion.
> 
> LV may connect to e.g. house network some times, yes, because it has a
> WiFi egress interface.  At that point it may acquire a prefix using
> MIP-NEMO-DHCP-PD.  But would it stay valid after a long disconnection
> period?  I guess this allocation will behave just like an address
> allocated by DHCP - expire after some time.  If yes, then the MR-LV
> would be prohibited from advertising the prefix inside the vehicle.

This is a valid question and I think this depends on how the MSP (mobility service provider) is configured and how it provides the service (e.g. whether it allocates short-term or long-term prefixes). Disconnection periods can happen in ITS so we should certainly consider such cases and amend existing specifications for the ITS case if needed. I think that  scenarios, goals and requirements for ITS should be agreed before proceeding to the solution space.

Romain

> (I am not sure this prohibition of advertising an expired prefix is
> specified or coded, I just suppose it as natural).
> 
> Alex
> 
>> 
>> Thank you, Romain
>> 
>>> Whether vehicles self-form addresses and inform each other about
>>> them, or otherwise use a central vehicle to allocate addresses to
>>> each other, is indeed debatable.
>>> 
>>> I think both paths should be pursued.  (I mean I have a draft for
>>> each, and there's a competitor draft for one of them, and I plan
>>> to write another one about self-forming ULAs from VIN and there's
>>> competitor activity on this VIN-ULA.)
>>> 
>>>> 
>>>> AP> Direct communication between vehicles in the absence from AP>
>>>> infrastructure is what is being experimented in some settings,
>>>> AP> although I agree they may not be reflected in ISO works.  I
>>>> can AP> speak of the EU project I work on with these V2V and
>>>> V2V2I AP> use-cases.
>>>> 
>>>>>> For the scenario involving the roadside and the vehicle, the
>>>>>> prefix can be exchanged as proposed by Lee
>>>>>> (draft-jhlee-mext-mnpp). The solution from Lee is being
>>>>>> integrated in the ISO TC204 standards related to ISO 21210.
>>>> 
>>>> AP> I am happy to learn that draft-jhlee-mext-mnpp work is AP>
>>>> integrated in ISO TC204 work.
>>>> 
>>>> Can you tell us how/if we can view this TC204 work?
>>> 
>>> Yes, I wonder about this as well.  I think Thierry or Jong-Hyouk
>>> are in best position to briefly describe this.
>>> 
>>>> Also, I can not find draft-jhlee-mext-mnpp. Is there a typo?
>>> 
>>> I think it is http://tools.ietf.org/html/draft-jhlee-mext-mnpp-00
>>> (it may look expired but there is intention on continuing it, I
>>> believe) Is this pointer working for you?
>>> 
>>> Alex
>>> 
>>>> 
>>>> 
>>>> 
>>>> --------------------------------------------------------------------
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
> IETF IPv6 working group mailing list [e-mail] Administrative
>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>> 
>>> 
>>> 
>>> 
>>>> 
>>>> 
>>>> 
>>>> 
> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list [e-mail] Administrative
>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
>