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

From: Peter McCann <[email-masked]>
Date: Mon, 26 Nov 2012 15:54:07 +0000

Hi, Jouni,

jouni korhonen wrote:
> 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.

Right.  I think that many links will flap on every handover, whether
LMA changes or not.

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

Ok, good.

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

Ok, I see that text now.

Should we document (2) somewhere?

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

I don't see how you can make a blanket statement like this for all
link layers that might be used for PMIP.  In particular, it seems
to require a knowledge, at the L2, of whether the current MAG can
see the same LMA.  This knowledge needs to be propagated across the
link to the client, and used to determine whether the link down/up
event propagates through the IP stack.  Perhaps your particular 
implementation experience involved carrying such a signal but I
cannot imagine that it holds true for every L2, especially if they
were not designed with PMIP in mind.

> One might receive
> an event that the access point (or equivalent) changed. This again
> depends on the client side implementation.

And in many implementations I can imagine this event treated as a link
flap.
 
>> 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).

You seem to be implying that the L2 technology has a notion of a PMIP
session.  The layered protocol model would seem to discourage this,
and I can imagine that many link layers are designed without PMIP
in mind.

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

It would still require coordination between the old LMA and the new
LMA, precisely in those situations where no such coordination is possible
(the PMIP domains are distinct and unconnected).

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

But you seem to be making assumptions about the L2 implementation 
and that, in particular, it knows when a PMIP session is disconnected.

I am sorry to be making a big deal about these issues.  I am raising
them because I think it will be important to get these details right
when it comes to the DMM solution.  There, I think we will have some
set of prefixes assigned to the MN at any given time, and some arbitrary
subset will need to be deprecated and/or torn down proactively upon 
each handover (change of MAG if a PMIP-style solution is used to 
re-route the packets).  However, we can discuss more details on the
DMM list if you prefer (and this may get us a bit into DMM solution
space.  But, I am trying to think ahead).

-Pete

---

From: jouni korhonen <[email-masked]>
Date: Tue, 27 Nov 2012 11:00:16 +0200

Pete,

On Nov 26, 2012, at 5:54 PM, Peter McCann wrote:

[budget cut scale removal of text]

> were not designed with PMIP in mind.

I am just reflecting the nature of existing point-to-point L2 
technologies. They tend to be session oriented, ref PPP and 3GPP
stuff. Even when a WLAN type of technology is twisted to resemble
point-to-point (and with authentication) you can make it session
aware.. with limitations. And if the whole user session is between
UE and the LMA, then any leg losing the session usually torn down
the whole pipe including your L2.

I am curious to learn what point-to-point L2 technologies you have
in mind? Something already on the field or on the drawing board?

[smaller cost cut scale removal of text]

> and I can imagine that many link layers are designed without PMIP

I do not have a PMIP aware L2 in mind. See above. Just a point-to-point L2
that has a notion of session itself i.e. one has to explicitly set it up and
it can be disconnected at will by either end.

[snip]

> (the PMIP domains are distinct and unconnected).

It is just a matter of will. OUIs are invented and EUI-64 is big hefty
number. Collision would be less probable than me winning in lottery.
However, this would probably be a task to some other SDO to arrange
than IETF.

[oh-snap]

> and that, in particular, it knows when a PMIP session is disconnected.

See my earlier notes on L2 sessions.

> when it comes to the DMM solution.  There, I think we will have some

Figured that ;) 

> space.  But, I am trying to think ahead).

Yep, I am familiar with this specific problem space. See e.g.
http://tools.ietf.org/html/draft-korhonen-dmm-local-prefix-00
for one solution approach. This, however, assumes the MN always
has at least on LMA that remains the same as long as the MN is
within the PMIP domain. But that was enough DMM for my needs ;)

Thinking ahead is more than welcome!

- Jouni

---

From: Peter McCann <[email-masked]>
Date: Tue, 27 Nov 2012 16:14:02 +0000

Hi, Jouni,

jouni korhonen wrote:
>>>> 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.
>>> 

My point is that L2 is torn down/rebuilt even when the LMA is 
reachable and the PMIP session stays up.

> in mind? Something already on the field or on the drawing board?

Take PPP as an example.  The PPP session would be between the 
MN and the MAG.  There would clearly need to be a new LCP/IPCP
exchange between the MN and a new MAG, even if the new MAG could
get back to the same LMA.  In this case PPP experiences link down/
up but the PMIP session is preserved.

This is distinct from the 3GPP link layer where the p2p session
is between MN and PGW.  The PGW is the first hop router.

PMIP has the MAG as the first hop router.  When you disconnect
from one first hop router and connect to another first hop
router, the link flaps unless you have taken special measures
to hide this event from the IP stack.

>>> because it also involves setting up a new PMIP session & L2 session.
>>> (on L2 technologies I am concerned with).
>> 
> I do not have a PMIP aware L2 in mind. See above. Just a point-to-point
> L2 that has a notion of session itself i.e. one has to explicitly set it
> up and it can be disconnected at will by either end.

But in PMIP the L2 is terminated between MN and MAG.  Change of MAG means
tearing down one L2 session and establishing a new one.  Hence it seems
more natural to me to experience a link flap than to go to the extra
effort to hide this from the IP stack in some special cases (which 
involve the network topology behind the MAG, something that is usually
not visible to L2).

> [snip]
> 
>>>>> 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.
>>> 
>>> 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.
>> 
>> LMA, precisely in those situations where no such coordination is
>> possible (the PMIP domains are distinct and unconnected).
> 

Sure, I agree this is possible.  But, it seems even more natural to
me to allow every MAG to have its own link-local address that is
globally unique.  I guess I am calling into question the assumption
that all MAGs in a PMIP domain have the same link-local address.
Perhaps that was a PMIP design mistake.  If the IP stack is going
to see a link flap anyway, we might as well deal with a proper change
of first-hop router (although that router might still advertise the
same prefix.  It is as if one router became unreachable but another
router pops up to take its place.  MNs should be able to handle this).

>> set of prefixes assigned to the MN at any given time, and some
>> arbitrary subset will need to be deprecated and/or torn down
>> proactively upon each handover (change of MAG if a PMIP-style solution
>> is used to re-route the packets).  However, we can discuss more details
>> on the DMM list if you prefer (and this may get us a bit into DMM
>> solution space.  But, I am trying to think ahead).
> 
> http://tools.ietf.org/html/draft-korhonen-dmm-local-prefix-00 for one
> solution approach. This, however, assumes the MN always has at least on
> LMA that remains the same as long as the MN is within the PMIP domain.
> But that was enough DMM for my needs ;)

Ok, just read your draft.  It raises the right issues, I think.  However,
I wonder if we could make it more general by decoupling the MN-visible
events like RAs and DHCP interaction and link flaps from the PMIP
protocol used to re-route packets and transfer context.
There are many ways to re-route packets and many ways to get the
context about the old prefixes from one AR to another AR.

Also, we should deal with cases where the old LMA is not reachable
and the DHCP server changes.

> Thinking ahead is more than welcome!

Good to hear.  Feel free to snip the netext mailing list from the
CC line when you think it's appropriate.

-Pete