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

From: Basavaraj Patil <[email-masked]>
Date: Tue, 20 Nov 2012 10:40:21 -0600

I-D: Prefix Delegation for Proxy Mobile IPv6
<draft-ietf-netext-pd-pmip-05>

Issues:
-------
1. I-D states: "However, Proxy Mobile IPv6 does not support assigning
a prefix to a router and  managing its IP mobility."

PMIP6 specifically mentions that the network based mobility solution
is for a host (as defined in RFC3775). It would be useful to mention
that this I-D is extending network based mobility support to routers
as well.

2. "This document specifies an extension to
   Proxy Mobile IPv6 protocol for supporting network mobility using
   DHCPv6-based Prefix Delegation."

Should it explicitly state that the extension to PMIP6 protocol is for
enabling network mobility for routers?

3. "The mobility elements in the network allow the
   IP host to obtain an IPv4 address and/or a set of IPv6 addresses
   ..."

MAG/LMA assign the host an IPv6 prefix.

4. Would be useful to mention how binding revocation is handled in the
case of delegated prefixes to the MR.

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.

Editorial
---------

s/Proxy Mobile IPv6 enables IP mobility for a host without requiring
   its participation in any mobility signaling, being the network
   responsible for managing IP mobility on behalf of the host./Proxy
   Mobile IPv6 enables IP mobility for a host without requiring
   its participation in any mobility signaling. Mobility agents within
   the network are responsible for managing IP mobility on behalf of
   the host.

s/However, this network-based mobility management support is specific
   to an IP host and currently there is no such network-based mobility
   management support for a mobile router with a cluster of IP hosts
   behind it./However Proxy Mobile IPv6 support is specifically
   intended for a host. Mobile routers can also benefit from the
   network based mobility solution provided by Proxy Mobile IPv6. This
   document extends Proxy Mobile IPv6 support to Mobile routers as
   well.

s/for its inside networks/for the networks subtending off the MR.

s/just as how that is supported for Home Network prefixes/in a similar
manner that the protocol supports hosts which are assigned home
network prefixes.

s/The mobile router forwards outgoing packets from its
   mobile network/The mobile router forwards outgoing or uplink
   packets from the networks that are subtending off it

s/ and the MAG
   delivers the incoming packets to the mobile network/and the MAG
   delivers the downlink packets to the MR.

s/to be able to intercept the related DHCPv6 message sourced from the
mobile router /in order to intercept the related DHCPv6 message
transmitted by the MR.

s/If the network mobility service needs to be offered to the mobile
   router/If the network mobility service is authorized for the mobile
   router

s/This requires the MAG to send a regular
        PBU to the LMA to register the location of the mobile router and
        set-up the bi-directional tunnel./This requires the MAG to
        send a regular PBU (with flag R set) to the LMA to register the
         mobile router and set-up the bi-directional tunnel.

-Raj

---

From: Peter McCann <[email-masked]>
Date: Tue, 20 Nov 2012 16:50:45 +0000

> 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
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,
RFC 3633 says that the delegated prefix is NOT advertised on the
link between the delegating router and the requesting router.
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.

-Pete

---

From: jouni korhonen <[email-masked]>
Date: Tue, 20 Nov 2012 21:56:18 +0200

Raj,

> that this I-D is extending network based mobility support to routers

Ok. I would write this as:

   responsible for managing IP mobility on behalf of the host.  However,
   Proxy Mobile IPv6 does not support assigning a prefix to a router and
   managing IP mobility for it and the networks it serves. This document

> enabling network mobility for routers?

Maybe.. see above.

> MAG/LMA assign the host an IPv6 prefix.

Could you elaborate a bit more?

> case of delegated prefixes to the MR.

Good point. That needs to be clarified.

> functionality needed at the MAG to accomplish this.

Section 3.4.2 states it..? I don't quite get what is missing here..

>          mobile router and set-up the bi-directional tunnel.

Cumulative ACK for the rest.

- Jouni

> 
> 
> 
> -Raj
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: jouni korhonen <[email-masked]>
Date: Tue, 20 Nov 2012 22:07:49 +0200

Pete,

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

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

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

> DHCPv6-PD on the new link.

From MR point of view nothing changed. So what is the issue?

- Jouni

---

From: Peter McCann <[email-masked]>
Date: Tue, 20 Nov 2012 20:18:19 +0000

Hi, Jouni,

What if the new MAG cannot connect back to the old LMA?  How does the
MR find out that its delegated prefix is no longer routable?

-Pete

jouni korhonen wrote:
>> advertises the original link prefix, and so the MN can tell that its
>> SLAAC unicast addresses are still valid on the link.  However,
>

---

From: jouni korhonen <[email-masked]>
Date: Tue, 20 Nov 2012 22:38:14 +0200

Pete,

> MR find out that its delegated prefix is no longer routable?

In that case your PMIP session goes down.. and the MR sees it as a change
of the link. In that case MR does what any DHCP client is supposed to do
i.e. verify whether its prefixes are still valid on the new link using a
confirm/reply exchange.

- JOuni

---

From: Peter McCann <[email-masked]>
Date: Tue, 20 Nov 2012 21:02:31 +0000

Hi, Jouni,

jouni korhonen wrote:
>> What if the new MAG cannot connect back to the old LMA?  How does
>> the MR find out that its delegated prefix is no longer routable?
> 
> In that case your PMIP session goes down.. and the MR sees it as a
> change of the link. In that case MR does what any DHCP client is
> supposed to do i.e. verify whether its prefixes are still valid on the
> new link using a confirm/reply exchange.

How exactly does the MR detect that the PMIP session has gone down?
The MR sees a MAG with the same globally reserved link-layer and
link-local address.  Is it looking for a Router Advertisement with
a new link prefix?  RFC 4861 specifies that subsequent Router 
Advertisements do not invalidate previously received information.

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

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

---

From: jouni korhonen <[email-masked]>
Date: Tue, 20 Nov 2012 23:39:07 +0200

Pete,

> Advertisements do not invalidate previously received information.

If the PMIP session goes down and the LMA changes then the HNP
also changes. For the MR that is an indication that something
happened on the link -> confirm. If that is not a good enough
indication I would assume the MR gets link up/down even since the
end of PMIP session would also mean the MAG kicks the MR out of
the L2 session.

If the link is some wireless technology e.g. a cellular link, then 
a PMIP session change would equal more drastic stuff on the MAG
facing interface/link. The MR would definitely know the link
changed or something happened to it -> confirm.

To be sure the MR sees the change of link, each PMIP session could
have their unique MAG link-local (possible by specs but a hack in a
way, thus not elaborated in this I-D).

Even RFC3315 is rather vague how the client figures out the link
changed. It is just assumed it somehow gets some indication something
happened.

- Jouni

---

From: Peter McCann <[email-masked]>
Date: Tue, 20 Nov 2012 21:46:31 +0000

Hi, Jouni,

jouni korhonen wrote:
>>> supposed to do i.e. verify whether its prefixes are still valid on
>>> the new link using a confirm/reply exchange.
>> 
>> link-local address.  Is it looking for a Router Advertisement with a
>> new link prefix?  RFC 4861 specifies that subsequent Router
> If the PMIP session goes down and the LMA changes then the HNP also
> changes. For the MR that is an indication that something happened on
> the link -> confirm. 

The only way to communicate the new HNP is with an RA, correct?

> If that is not a good enough indication I would
> assume the MR gets link up/down even since the end of PMIP session
> would also mean the MAG kicks the MR out of the L2 session.

I don't see why this handover should be any different at L2 from
the handovers within a single PMIP domain.  I think the MN would
get link down/up (or not) in both cases, and would not be able to
distinguish the end of the session on this basis.

> If the link is some wireless technology e.g. a cellular link, then a
> PMIP session change would equal more drastic stuff on the MAG facing
> interface/link. The MR would definitely know the link changed or
> something happened to it -> confirm.

It is an inter-MAG handover like any other.  Indistinguishable at
L2.

> way, thus not elaborated in this I-D).

Even so the receipt of a new RA from a new link-local address would
not invalidate the old information received from the old MAG.  This
is not a trigger that deprecates the old prefix.  An MN conforming
to 4861 would not necessarily take any action upon receiving the new
RA.

> changed. It is just assumed it somehow gets some indication something

I don't think we can assume that inter-MAG handoffs involving a change
of LMA are at all distinguishable at the link layer from inter-MAG
handoffs that do not involve a change of LMA.

-Pete

>> delegated prefix so it seems wrong to use them to control the validity
>> of the delegated prefix.
> 
> 
> 
>> 
>> -Pete
>> 
>>> 
>>> - JOuni
>>> 
>>>> 
>>>> -Pete
>>>> 
>>>> 
>>>> jouni korhonen wrote:
>>>>> 
>>>>> Pete,
>>>>> 
>>>>> 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.
>>>>> 
>>>>> 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.
>>>>> 
>>>>>> 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: jouni korhonen <[email-masked]>
Date: Wed, 21 Nov 2012 00:59:25 +0200

Pete,

> The only way to communicate the new HNP is with an RA, correct?

No. Also DHCP applies. If your assumption about MN/MR not being able to
figure out when to confirm its address/prefix, then whole RFC5213 DHCP-based
address assignment would be broken.

> distinguish the end of the session on this basis.

You were talking about the change of LMA.. which would per current specs
mean end of PMIP session. Now if PMIP session ends the MN/MR won't  be
let hanging around in L2 either, right? So the MN/MR would definitely
know that it got kicked away. Think e.g. about cellular case. The lost
of session means the link is plain gone. 

> It is an inter-MAG handover like any other.  Indistinguishable at

It is way different than an inter-MAG handover. See above.

> to 4861 would not necessarily take any action upon receiving the new

DNA.

> handoffs that do not involve a change of LMA.

I disagree. You would know it at your L2. And even if you wouldn't have
such L2, your MAG or latest LMA should send you a destination unreachable
ICMP telling the packets (having src out of delegated prefix) won't get
delivered. If not.. then the deployment is broken and we cannot fix that
part with a spec.

- Jouni

---

From: Peter McCann <[email-masked]>
Date: Wed, 21 Nov 2012 04:55:43 +0000

Hi, Jouni,

jouni korhonen wrote:
>>>>>> What if the new MAG cannot connect back to the old LMA?  How
>>>>>> does the MR find out that its delegated prefix is no longer routable?
>>>>> 
>>>>> In that case your PMIP session goes down.. and the MR sees it as
>>>>> a change of the link. In that case MR does what any DHCP client
>>>>> is supposed to do i.e. verify whether its prefixes are still
>>>>> valid on the new link using a confirm/reply exchange.
>>>> 
>>> changes. For the MR that is an indication that something happened
>>> on the link -> confirm.
>> 
> No. Also DHCP applies. If your assumption about MN/MR not being able
> to figure out when to confirm its address/prefix, then whole RFC5213
> DHCP- based address assignment would be broken.

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.

>>> If that is not a good enough indication I would assume the MR gets
>>> link up/down even since the end of PMIP session would also mean the
>>> MAG kicks the MR out of the L2 session.
>> 
>> I don't see why this handover should be any different at L2 from the
>> handovers within a single PMIP domain.  I think the MN would get
>> link down/up (or not) in both cases, and would not be able to
> You were talking about the change of LMA.. which would per current
> specs mean end of PMIP session. Now if PMIP session ends the MN/MR
> won't  be let hanging around in L2 either, right? So the MN/MR would
> definitely know that it got kicked away. Think e.g. about cellular
> case. The lost of session means the link is plain gone.

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.

>> It is an inter-MAG handover like any other.  Indistinguishable at L2.
> 

Why would the L2 know about the MAG-to-LMA topology?
 
>> Even so the receipt of a new RA from a new link-local address would not
>> invalidate the old information received from the old MAG.  This is not
>> a trigger that deprecates the old prefix.  An MN conforming to 4861
>> would not necessarily take any action upon receiving the new RA.
> 
> DNA.

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?

> I disagree. You would know it at your L2. And even if you wouldn't
> have such L2, your MAG or latest LMA should send you a destination
> unreachable ICMP telling the packets (having src out of delegated
> prefix) won't get delivered. If not.. then the deployment is broken
> and we cannot fix that part with a spec.

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.

-Pete

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

---

From: jouni korhonen <[email-masked]>
Date: Wed, 21 Nov 2012 14:03:02 +0200

Pete,

> (handover to new MAG) that would do the trick.  It seems somewhat

It is what RFC3315 says.. client sends a confirm request.

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

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

> the MN/MR invalidate or try to reconfirm the old information in this

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.

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

- Jouni

---

From: Peter McCann <[email-masked]>
Date: Wed, 21 Nov 2012 16:34:36 +0000

Hi, Jouni,

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

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

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

> 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

>>>>>>>>>>> are derived from the delegated prefixes? Its not clear if
>>>>>>>>>>> there is added functionality needed at the MAG to
> accomplish this.
>>>>>>>>>> 
>>>>>>>>>> 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.
>>>>>>>>> 
>>>>>>>>>> Therefore, there is no way for the MR to determine whether
>>>>>>>>>> it can still use the delegated prefixes, other than perhaps

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 21 Nov 2012 11:09:52 -0600

Inline:

>    managing IP mobility for it and the networks it serves. This document

Raj> Okay.

> > enabling network mobility for routers?

Raj> No harm in emphasizing it.

> Could you elaborate a bit more?

Raj> The I-D is saying that the LMA assigns the MN a set of IPv6 addresses.
What I meant is that the LMA assigns IPv6 prefixes to the MN.

> Section 3.4.2 states it..? I don't quite get what is missing here..

Raj> Right. I missed that.
The text in 3.4.2 :
"

   o  On receiving packets from a mobile router connected to one access
      link, the mobile access gateway MUST ensure that there is an
      established binding for the mobile router and the local mobility
      anchor for the source delegated mobile network prefix before
      tunneling the packet to the MR's local mobility anchor.

"

is fine. So the MAG ensures that the packet can be forwarded by checking
the extended BULE at the MAG?

-Raj

-- 
Basavaraj Patil

---

From: jouni korhonen <[email-masked]>
Date: Thu, 22 Nov 2012 10:54:59 +0200

Pete,

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

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

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

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

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

> 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

---

From: [email-masked]
Date: Thu, 22 Nov 2012 17:27:44 +0800

Hello Raj,

Confirmation on issue 3 and 5, please see below.

> Raj> The I-D is saying that the LMA assigns the MN a set of IPv6 
> addresses. What I meant is that the LMA assigns IPv6 prefixes to the MN.
[Joy] Yes, you are right. More precise to say IPv6 prefix.

> is fine. So the MAG ensures that the packet can be forwarded by 
> checking the extended BULE at the MAG?
[Joy] Correct.

Best Regards
Joy

> On Tue, Nov 20, 2012 at 1:56 PM, jouni korhonen <[email-masked]
> > wrote:
> 
> Raj,
> 

> Raj> The I-D is saying that the LMA assigns the MN a set of IPv6 
> addresses. What I meant is that the LMA assigns IPv6 prefixes to the MN.
>  
> 
> 

> is fine. So the MAG ensures that the packet can be forwarded by 
> checking the extended BULE at the MAG?
> 
> -Raj
> 
> - Jouni
> 
> 
> >
> >
> >
> > -Raj
> >

---

From: Peter McCann <[email-masked]>
Date: Mon, 26 Nov 2012 08:57:56 +0000

Hi, Jouni,

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

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

>> 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.
> 
> no control how the DHCPv6-PD client gets implemented in the MR or
> whether the network driver delivers proper events to upper layers.
> 
> 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?

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

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

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

> 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

---

From: jouni korhonen <[email-masked]>
Date: Mon, 26 Nov 2012 14:48:39 +0200

Pete,

> link SHOULD NOT be propagated to the IP stack (the link flap should

Should not is OKish. Cannot guarantee that though.

> propagated up the IP stack.

Yep.

> Have either of these two requirements been codified in 5213 or 

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

> I am not.  The existing GPRS model is that the GGSN or PGW is the first

I am. This is not an academic exercise.

> flap on a MAG to MAG handover, even when the same LMA is reachable from

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.

> of LMA should always result in a link down/up event that is visible to

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

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

> 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

---

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

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.
>>>>> 
>>>> 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.
>> 
>> link SHOULD NOT be propagated to the IP stack (the link flap should not
>> be visible to IP).
> 

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

>> propagated up the IP stack.

Ok, good.

> sent or not, ref the DNA text and link-local address MO.

Ok, I see that text now.

Should we document (2) somewhere?

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

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

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