Re: Preparing for DMM future steps and rechartering

Hi, Alex,

When it comes to injecting routes into the routing infrastructure, 
I think we have to use the "proxy" model.  It doesn't make sense for
the MN to be speaking to the access network's routing protocol.  This
means the MAG will need to authenticate the MN and check that the
IP addresses assigned to that MN ID were in fact really assigned to
that MN.  I think it can be done easily with forward/reverse DNS
lookups.

Sri, if we can make the tunnels a fall-back mechanism for use only
when the MN has moved too far to make the routing update scalable,
then yes, we can eliminate the PMIP signaling from the access network.
I think client MIP should be used when we need to fall back - especially
because there is likely to be no relationship between the previous and
new domains, other than the fact that they are both connected to the
Internet.

-Pete


Alexandru Petrescu wrote:
> Sri,
> 
> Sorry if my mail was too direct.  It is not my intention to suggest
> getting rid of anything.
> 
> Frankly speaking I don't know what DMM is, and I still have to review
> the draft-ietf-dmm-best-practices-gap-analysis-02
> 
> Whenever one says one particular protocol I have a problem with each.
> For example, but just an example, I have growing problems articulating
> an explanation of the lack of MIP deployment.
> 
> Deployment, testing and prototype interest are valuable indicators.
> 
> Alex
> 
> Le 11/11/2013 17:08, Sri Gundavelli (sgundave) a écrit :
>> Alex - So, the proposal is to get rid of the MIP signaling plane and
>> piggyback on some routing updates, or over OpenFlow ? So, what is
>> the result, we use a generic non-MIP interfaces and make them look
>> like MIP interfaces ? What is the point ? This is DMM ?
>> 
>> 
>> Regards Sri
>> 
>> 
>> 
>> 
>> On 11/11/13 7:51 AM, "Alexandru Petrescu"
>> <[email protected]> wrote:
>> 
>>> 
>>> I think it may converge.
>>> 
>>> I am not sure whether we have reached a point where we can discuss
>>> without assuming a particular protocol (i.e. neither MIP, nor BGP),
>>> but I think we can discuss route update method vs tunnel-based
>>> method.
>>> 
>>> We can also discuss whether new functionality is needed on the mobile
>>> entity, vs whether the first-hop router does much on its behalf
>>> ('proxy').  Which may bring in a question of whether a Mobile Host or
>>> a Mobile Router is considered.
>>> 
>>> Effects of route updates may be too heavy on a network ('route
>>> churn') or less so; it may depend, among several factors, on the
>>> topology and the addressing architecture of the fixed network.
>>> 
>>> Routing protocols are highly distributed concepts, yet many include
>>> particularly designated entities, which have particular roles (not
>>> all routers are equal) - these could host what we expect to be more
>>> controlling points.
>>> 
>>> Alex
>>> 
>>>> 
>> 
>> 
>> 
>