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

[Alexandru Petrescu <[e-mail]>]

Le 05/11/2012 11:12, Romain KUNTZ a écrit :
> 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.

I agree that is a good engineering approach.

We started in July writing a draft in that space
draft-petrescu-its-scenarios-reqs-01.txt.

I am interested in all discussion in ITS towards refining scenarios,
goals and requirements drafts.  There is also an email list [e-mail].

Alex

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