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

[jouni korhonen <[e-mail]>]

Pete,


On Nov 26, 2012, at 10:57 AM, Peter McCann wrote:

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

Should not is OKish. Cannot guarantee that though.

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

Yep.

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

RFC5213 is prepared to handle 1) independent whether the event is
sent or not, ref the DNA text and link-local address MO.


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

I am. This is not an academic exercise.

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

If the LMA stays the same, the link does not flap. One might receive
an event that the access point (or equivalent) changed. This again
depends on the client side implementation.

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

I repeat what I said earlier. If the LMA changes the L2 session goes down,
prefixes may change etc. It is a bit more than just link up/down because
it also involves setting up a new PMIP session & L2 session. (on L2
technologies I am concerned with).

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

No.. or lets say my wording was imprecise. Whether this feature is enabled
depends on the MAG configuration. If MAG allows the LMA to generate the
link-local, then LMA does it and MAG uses that address. In that case the
LMA decides when to use which 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.

Sure. Never claimed it to be different. But as said, I cannot control the
client side implementation. That is the point.

- Jouni


> 
> -Pete