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

[Peter McCann <[e-mail]>]

Hi, Jouni,

jouni korhonen wrote:
> Pete,
> 
> On Nov 20, 2012, at 11:46 PM, Peter McCann wrote:
> 
>> Hi, Jouni,
>> 
>> jouni korhonen wrote:
>>> 
>>> Pete,
>>> 
>>> On Nov 20, 2012, at 11:02 PM, Peter McCann wrote:
>>> 
>>>> Hi, Jouni,
>>>> 
>>>> jouni korhonen wrote:
>>>>> 
>>>>> Pete,
>>>>> 
>>>>> On Nov 20, 2012, at 10:18 PM, Peter McCann wrote:
>>>>> 
>>>>>> 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?
>>>>> 
>>>>> 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.
>>> 
>>> 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?
> 
> 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
>> 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'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.

>>> 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.
> 
> It is way different than an inter-MAG handover. See above.

Why would the L2 know about the MAG-to-LMA topology?
 
>>> 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 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?

>>> Even RFC3315 is rather vague how the client figures out the link
>>> changed. It is just assumed it somehow gets some indication something
>>> happened.
>> 
>> 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.
> 
> 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

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