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

[jouni korhonen <[e-mail]>]

Pete,

On Nov 21, 2012, at 6:55 AM, 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.

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

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

Are we still talking about the concern where the LMA changes as a result
of a handover or something else?

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

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.

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

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.

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

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


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