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

[jouni korhonen <[e-mail]>]

Pete,

I hope we start getting closer to convergence.. this thread is getting longish..

On Nov 21, 2012, at 6:34 PM, Peter McCann wrote:

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

I would say it it does not flap. The MR (at will) will still see it as a
change of access point or something equivalent at the L2. If that event
then gets delivered to the IP level somehow is out of my control. I have
no control how the DHCPv6-PD client gets implemented in the MR or whether
the network driver delivers proper events to upper layers.

This is getting to the original reason why we wrote the draft. Depending
on how the MR figures out "whether the link changed" it may or may not
bother sending the Confirm Request. And if it does not, then the MAG does
not know about the delegated prefixes -> forwarding fails. On the network
side I cannot really trust the MR DHCPv6-PD client to do the right thing
all the time. 

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

LMA-LMA handover based on the existing specs means the end of PMIP session,
which on the point-to-point link technologies I am aware of also results
in the termination of the L2 session. We have not defined how renumbering
would work in this case. In certain L2 technologies renumbering is not
even supported (ref 3GPP).

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

I know and again back to the context of my assertion:

"..(possible by specs but a hack in a way, thus not elaborated in this I-D)."

And that "specs" dates to original RC5213 which would allow us this. Even
when using RFC6543 I can turn it off by configuration.

> clean boundaries a priori where different link local addresses would
> be assigned.  There may be some overlap in the LMA coverage areas (although

Assuming RFC6543 is not used and we do assign different link-locals, then it
is up to the LMA decide when to use which link-local. Two examples: each LMA
has its own or each PMIP session gets its own "unique" link-local. Both cases
have possibility of address collisions but are quite unlikely. I do not really
care about coverage areas rather the case when something happened on the emulated
home link and for that case the two examples would be sufficient. Note that I
am not prompting such "solution".

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

As said we cannot heal all networking issues by specifications if people
do not implement them properly. If your delegated prefix is gone from the
network point of view and your MR sits there doing nothing while it should
based on e.g. RFC3315, tough luck.

- Jouni

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