Re: [netext] Chair review of I-D: draft-ietf-netext-pd-pmip (05)

[Peter McCann <[e-mail]>]

Hi, Jouni,

jouni korhonen wrote:
>> 
>> I guess if you sent a DHCP Renew every time you detected a link flap
>> (handover to new MAG) that would do the trick.  It seems somewhat
>> expensive, though.
> 
> It is what RFC3315 says.. client sends a confirm request.

Right, I am just pointing out that the link may flap even when the
same LMA is reachable.  Seems like overhead.  You seem to be requiring
that the link doesn't flap when the PMIP session continues after a MAG
to MAG handover under the same LMA.

>> It's perfectly conceivable to have an L2 handover to a new MAG in a
>> new PMIP domain.  I don't see why the L2 should be modified to know
>> about the topology of which MAGs can reach which LMAs.
> 
> Are we still talking about the concern where the LMA changes as a
> result of a handover or something else?

I was still talking about change of LMA.  I still don't see why the L2
would behave differently depending on whether the new MAG can reach the
old LMA.

>> Why would the L2 know about the MAG-to-LMA topology?
> 
> The LMA-LMA hanover, as per current RFC5213, would be visible as a
> link flap or L2 session termination whatever. At least on those L2
> technologies that I am aware of.

In my view, a MAG to MAG handover under the same LMA is equally likely
to lead to a link flap.  Which really does no harm, it only leads to
extra DHCP or RS/RA reconfirmation traffic in this case.

>> Ok, but if all the MAGs are using the same link-local address, NUD
>> would come back saying the router is still reachable, right?  Would
>> the MN/MR invalidate or try to reconfirm the old information in this
>> circumstance?
> 
> The context for my assertion was stated earlier:
> 
> "..To be sure the MR sees the change of link, each PMIP session could
> have their unique MAG link-local.." NUD would fail.

Yes, that might help, but it seems to run counter to the recommendation
in RFC 6543.  Also, I am not so sure that it will be possible to define
clean boundaries a priori where different link local addresses would
be assigned.  There may be some overlap in the LMA coverage areas (although
I agree this may not be likely.  More likely would be distinct administrative
domains with no relationship or coordination between them, which makes
coordinating assignment of MAG link-local addresses difficult).

>> ICMP would only be sent if traffic is being generated.  I am more
>> worried about a state where the MN thinks its prefix is still good,
>> but packets aren't being delivered and it could be an indeterminate
>> amount of time before the situation is recognized/corrected.
> 
> How does this differ from what we see out in live today? Actually, if
> the delegated prefix is not valid anymore but no host communicate
> outside world there is no need to renumber immediately. Only until the
> outside world is concerned again. There was a similar discussion e.g.
> in homenet.

You may be running a server on the MN which is waiting for inbound
connections.  The peer correspondent nodes would send traffic to the
old prefix, and there would be no indication to the MN that the old
prefix isn't valid anymore.

-Pete

> 
> - Jouni
> 
> 
>> 
>> -Pete
>> 
>>> - Jouni
>>> 
>>> 
>>>> 
>>>> -Pete
>>>> 
>>>>> 
>>>>> - Jouni
>>>>> 
>>>>>> Besides, as we have noted, the RAs have nothing to do with the
>>>>>> delegated prefix so it seems wrong to use them to control the
>>>>>> validity of the delegated prefix.
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> -Pete
>>>>>> 
>>>>>>> 
>>>>>>> - JOuni
>>>>>>> 
>>>>>>>> 
>>>>>>>> -Pete
>>>>>>>> 
>>>>>>>> 
>>>>>>>> jouni korhonen wrote:
>>>>>>>>> 
>>>>>>>>> Pete,
>>>>>>>>> 
>>>>>>>>> On Nov 20, 2012, at 6:50 PM, Peter McCann wrote:
>>>>>>>>> 
>>>>>>>>>> Basavaraj Patil wrote:
>>>>>>>>>>> 
>>>>>>>>>>> 5. How does the MAG know that it needs to allow forwarding of
>>>>>>>>>>> packets via the PMIP6 tunnel for packets with SRC address that
>>>>>>>>>>> are derived from the delegated prefixes? Its not clear if
>>>>>>>>>>> there is added functionality needed at the MAG to
> accomplish this.
>>>>>>>>>> 
>>>>>>>>>> I think there are potentially some deeper issues here.
>>>>>>>>>> 
>>>>>>>>>> The MN sees the original MAG as its "delegating router". When
>>>>>>>>>> the MN changes to a new MAG, there is no good way to tell that
>>>>>>>>>> the delegated prefixes are still routable to the link.  The
>>>>> delegating
>>>>>>>>> 
>>>>>>>>> This is what the I-D is about.. That's we got the new signaling
>>>>>>>>> in place and the handover case described in Section 3.4.3.
>>>>>>>>> 
>>>>>>>>>> router has become unreachable.  The new router may send an
>>>>>>>>>> RA that advertises the original link prefix, and so the MN
>>>>>>>>>> can tell that its SLAAC unicast addresses are still valid on
>>>>>>>>>> the
> link.
>>>>> However,
>>>>>>>>> 
>>>>>>>>> When the MR (i.e. in RFC5213 terminology the MN) does a
>>>>>>>>> handover, the prefix used between the MR-MAG stays the same as
>>>>>>>>> usually provided by PMIP6. Section 3.4.3 the describes what the
>>>>>>>>> MAG has to do in order to know the existing delegated prefixes
>>>>>>>>> and set the forwarding state.
>>>>>>>>> 
>>>>>>>>>> RFC 3633 says that the delegated prefix is NOT advertised on
>>>>>>>>>> the link between the delegating router and the requesting
> router.
>>>>>>>>> 
>>>>>>>>> And they are not. The delegated prefixes are used on the
>>>>>>>>> downstream interfaces of the MR, not on the MR-MAG link. If the
>>>>>>>>> prefix used on the MR-MAG link is part of the delegated prefix,
>>>>>>>>> then the MR has to use RFC6603.
>>>>>>>>> 
>>>>>>>>>> Therefore, there is no way for the MR to determine whether
>>>>>>>>>> it can still use the delegated prefixes, other than perhaps
>>>>>>>>>> re-running DHCPv6-PD on the new link.
>>>>>>>>> 
>>>>>>>>> From MR point of view nothing changed. So what is the issue?
>>>>>>>>> 
>>>>>>>>> - Jouni
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> -Pete
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> netext mailing list
>>>>>>>>>> [e-mail]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/netext
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> 
>> 
> 
> _______________________________________________
> netext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext