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

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

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

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

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