Re: [v6ops] Announcing draft-petrescu-relay-route-pd-problem-00

["Leaf Yeh" <[e-mail]>]

Ole - should we ask Markus to kick
http://tools.ietf.org/html/draft-stenberg-pd-route-maintenance-00 back into
life?
Alex - With respect to the need of combining that other solution, not being
independent, I think Leaf could explain that.  Right?


I read draft-petrescu here targets the routing issue on the relay, which
sounds a network component not included in the Fig.1 titled 'Possible prefix
delegation deployment cases' in the draft-stenberg.

I guess the draft-stenberg might intend to suggest some so-called
'approaches' for the Requesting Routers (RR) or Delegating Routers (DR), or
even Backend provisioning system against some (frankly speaking, vague)
issues, but not for the relay agent of DHCPv6.

I also have not read out the solid protocol enhancement for DHCPv6 from
draft-stenberg yet.


Best Regards,
Leaf



-----Original Message-----
From: Alexandru Petrescu [mailto:[e-mail]] 
Sent: Sunday, November 03, 2013 12:43 AM
To: Ole Troan
Cc: Leaf Yeh; [e-mail]
Subject: Re: [v6ops] Announcing draft-petrescu-relay-route-pd-problem-00

Ole,

Thank you for the comment.  Yes, I think such text with that analogy could
help clarify.

I will be happy to include you as co-author if you provided text.

Yes, why not ask Markus to kick that other draft back into life?

With respect to the need of combining that other solution, not being
independent, I think Leaf could explain that.  Right?

Alex

Le 01/11/2013 16:33, Ole Troan a écrit :
> Alexandru,
>
> with regards to your solutions; 5.3.
> draft-ietf-dhc-dhcpv6-prefix-pool-opt-03 for prefix pool of PD isn't 
> standalone, that has to be combined with solution in 5.1 or 5.2.
>
> I think you could add some text where you draw an analogy to having a 
> statically configured aggregate route, with configuring a prefix
> (/64) for address assignment. routing is set up very similarly. that 
> could go in section 3.1. "Allocating a prefix is an operation 
> different..."
>
> should we ask Markus to kick
> http://tools.ietf.org/html/draft-stenberg-pd-route-maintenance-00
> back into life?
>
> cheers, Ole
>
> On 22 Oct 2013, at 13:35 , Alexandru Petrescu 
> <[e-mail]> wrote:
>
>> Hello participants to v6ops WG,
>>
>> We have just submitted draft-petrescu-relay-route-pd-problem-00
>> http://tools.ietf.org/html/draft-petrescu-relay-route-pd-problem-00
>>
>>
"Route Problem at Relay during DHCPv6 Prefix Delegation"
>> M. Boucadair (France Telecom) L. Yeh (Freelancer Technologies) A.
>> Petrescu (CEA).
>>
>> It presents a problem of routing at Relay during Prefix Delegation of 
>> DHCPv6; also lists some solutions I-Ds.  The problem may be relevant 
>> in the DHC WG, at the Broadband Forum and maybe at 3GPP.
>>
>> Please comment on this draft.
>>
>> Thanks,
>>
>> Alex
>>
>> Le 08/10/2013 10:55, Alexandru Petrescu a écrit :
>>> Le 08/10/2013 10:49, Vízdal Aleš a écrit :
>>>>>> The GGSN/PGW is UEs next-hop as the traffic is tunnelled in GTP 
>>>>>> through all the intermediate nodes.
>>>>>
>>>>> Ah, right, there is a GTP tunnel above all the intermediary IP 
>>>>> nodes.
>>>>>
>>>>> However, even when a tunnel is dynamically set up, a routing table 
>>>>> entry is added in the Relay's routing table (or other similar 
>>>>> entry).  The parameters of that entry necessarily include, among 
>>>>> others, the prefix which is allocated.
>>>>>
>>>>> No?
>>>>
>>>> The tunnel stays up for the lifetime of the PDP/PDN context.
>>>
>>> Ok.
>>>
>>>> There is no relay in the 3GPP access architecture.
>>>
>>> Ok.
>>>
>>>> If the tunnel drops, the PGW/GGSN will remove the route from their 
>>>> routing table, once a new tunnel is setup the routing table is 
>>>> updated accordingly.
>>>
>>> The route associated with that tunnel should contain a parameter 
>>> containing the Delegated Prefix.  When there is no delegated prefix, 
>>> that route entry should be updated.
>>>
>>> The tunnel could stay up but only for the Smartphone.  Or it could 
>>> stay up for both the Smartphone _and_ the Hosts in the smartphone's 
>>> LAN. These are two different things.
>>>
>>> Alex
>>>
>>>
>>>>
>>>>> Alex
>>>>
>>>> Ales
>>>>
>>>>
>>>
>>>
>>> _______________________________________________ v6ops mailing list 
>>> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>>
>>
>>
>> _______________________________________________ v6ops mailing list 
>> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>