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

[Peter McCann <[e-mail]>]

Hi, Jouni,

jouni korhonen wrote:
> Pete,
> 
> I hope we start getting closer to convergence.. this thread is getting
> longish..

Yes and sorry about the delay responding.  We had the Thanksgiving 
holiday here in the US and I was out of touch.

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

Ok, so can we summarize the recommendation for PMIP deployments:

(1) When handing off between two MAGs under the same LMA, the change of
link SHOULD NOT be propagated to the IP stack (the link flap should
not be visible to IP).

(2) When handing off between two MAGs where the second MAG cannot or
does not connect back to the previous LMA, the change of link MUST be
propagated up the IP stack.

I think that (1) is a SHOULD NOT because violation of this SHOULD NOT
only leads to some extra traffic on the link from re-confirmation.  In
contrast, (2) is a MUST because the absence of a link down/up event
could lead to a hung session where the MN thinks it has a routable
prefix but actually does not.

Have either of these two requirements been codified in 5213 or 
elsewhere?

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

Are you aware of a deployment of PMIP over the 3GPP PDP context link?
I am not.  The existing GPRS model is that the GGSN or PGW is the first
hop router, and traffic is always tunneled directly back to that router.
In contrast, PMIP has the MAG as the first hop router.  This is a 
fundamental difference that IMHO makes it more likely to see a link
flap on a MAG to MAG handover, even when the same LMA is reachable from
both.

I think you agree with me that a change of MAG that results in a change
of LMA should always result in a link down/up event that is visible to
the IP stack.

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

Agreed, it's possible.

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

Did you mean to say "up to the MAG"?  I am not sure I like the idea of
the LMA controlling the MAG's link-local address.

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

If the link down/up event has been hidden from the IP stack, then sitting
there doing nothing is exactly what an RFC3315 compliant implementation
would do.  Hence my use of MUST in (2) above.

-Pete