RE: draft-mccann-dmm-prefixcost

[John Kaippallimalil <[e-mail]>]

Hi Mudrik,
RFC 7429 https://datatracker.ietf.org/doc/rfc7429/?include_text=1 provides a description of how distributed mobility management works currently (and the gaps). Chapter 4 outlines the current practices.

ND runs as it does in other environments.  In a simple PMIP case, the router in old link detects (NUD) or is told by other signaling (tunnel establishment) in new link that the host is now attached at new link. In this case, there is no tunnel between router-host. The tunnel is in between MAG and LMA (in this case new router is MAG, old router is LMA - anchor node). Other scenarios are outlined in RFC 7429.

Some further responses (responding to inline qns as well):
Based on your descriptions below, I understood you are proposing a different ND mechanism for the MN1 at the new point of attachment. Please see my comments/questions inlined.
>> Its not a different ND. The proposal is for a PIO prefix cost suboption (as per draft: IPv6 Prefix Properties", draft-korhonen-dmm-prefix-properties-04  -- ref [7]). When used here, it would show a low cost in its old link, and a higher cost if the MN is much further away at the new link - e.g., a long backhaul/tunnel between the new MAG/LMA.
Its not a new protocol/or 2 NDs - just a simple extension to ND/PIO, which is understood by routers/hosts capable of processing this extension. 
RE(inline qn): lifetime - MN uses the ND/NUD mechanisms to extend lifetime at the router to which it is attached.

Can the prefix cost be used by MN1 on L1 to select between two reachable paths? How will that impact SASA on multi-homed hosts? To me this prefix cost should somehow be part of SASA.
>> I assume that SASA is referring to source address selection - RFC 6724? If so, I agree. It would not interfere with the selection rules in section 5 - rather, the cost would be one further criterion. We need to define this better in the draft, and will do so. 
Multi-homed hosts are even more interesting as this represents useful choices to the MN. Asking mif wg to review this draft as well.

The router in old attachment point has context that allows it to indicate that the address is being used. In the DAD procedures, old attachment router will respond with duplicate address in the DAD procedures.
[Dusan] So, MN1 at the new point of attachment will not receive DAD NS and respond with NA saying it is already using the address?
>> Correct. 

BR,
JOhn



-----Original Message-----
From: Mudric, Dusan (Dusan) [mailto:[e-mail]] 
Sent: Monday, March 21, 2016 8:29 AM
To: John Kaippallimalil; [e-mail]
Subject: RE: draft-mccann-dmm-prefixcost

Hi John,

Thanks for providing more insights. Based on your description there is another protocol on top of ND that detects MN1 at the new point of attachment in router R2 environment and creates a tunnel to the old router R1. That protocol extends ND from the old local link L1 to the MN1 end point at the new location L2. The end point itself needs to run a tunnel and treat equally ND2 messages from the local link at the new point of attachment and the ND1 messages from the old link.

Is it how the protocol should work? Which RFC(s) define(s) this behavior?

Based on your descriptions below, I understood you are proposing a different ND mechanism for the MN1 at the new point of attachment. Please see my comments/questions inlined.

Can the prefix cost be used by MN1 on L1 to select between two reachable paths? How will that impact SASA on multi-homed hosts? To me this prefix cost should somehow be part of SASA.

Regards,
Dusan Mudric.

-----Original Message-----
From: John Kaippallimalil [mailto:[e-mail]]
Sent: Friday, March 18, 2016 2:17 PM
To: Mudric, Dusan (Dusan); [e-mail]
Subject: RE: draft-mccann-dmm-prefixcost

Hi Dusan,
here are some answers:
Q1: How will MN1 know about the address prefix deletion at the new point of attachment?
When MN1 does not want to use old IP address, it does not respond in the NUD sequence. As a result, the router at the new point of attachment will remove tunnels between original point of attachment to new - PMIP tunnels for example. It will also stop advertising the IP address to MN1 [Dusan] Is this going to be a different ND mechanism? Currently ND uses unsolicited RAs with preferred life time of zero to remove the prefix.

Q2: How will MN1 refresh the prefix in use?
NUD/ICMPv6 to keep the prefix alive. Which in turn can be used to keep the tunnel.
[Dusan] Is this going to be a different ND mechanism? Currently ND uses unsolicited RAs to keep the prefix alive. From the comment Q3 below, there is another mechanism that will allow the old attachment router to somehow pass RA to the new attachment router to refresh the prefix valid life time. Are you saying there are two protocols to extend the prefix valid life time?

Q3: What will MN1 do after the prefix valid life time expires?
The negotiation to extend prefix lifetime would be between new attachment router - old attachment router (e.g., PMIP tunnel). After valid life time expiry - the draft does not change this behavior, same as in other cases - the network would not be able to guarantee a route/forwarding.
The assumption here is that MN1 has choices before the valid life time expiry.

Q4: How will another MN2, at the old point of attachment, detect its address is duplicate (used the MN1)?
The router in old attachment point has context that allows it to indicate that the address is being used. In the DAD procedures, old attachment router will respond with duplicate address in the DAD procedures.
[Dusan] So, MN1 at the new point of attachment will not receive DAD NS and respond with NA saying it is already using the address?

- John




-----Original Message-----
From: Mudric, Dusan (Dusan) [mailto:[e-mail]]
Sent: Friday, March 18, 2016 11:33 AM
To: John Kaippallimalil; [e-mail]
Subject: RE: draft-mccann-dmm-prefixcost

Hi John,

What are the answers to questions Q1 to Q4, if he MN decides to keep the old address?

Thanks,
Dusan.

-----Original Message-----
From: John Kaippallimalil [mailto:[e-mail]]
Sent: Friday, March 18, 2016 12:20 PM
To: Mudric, Dusan (Dusan); [e-mail]
Subject: RE: draft-mccann-dmm-prefixcost

Hi Dusan,
Yes - MNs would keep the address after moving to a new point of attachment. But would then have a choice of keeping the old address (e.g, tunneled) or one advertised locally for example. 

However, it is not obvious to the MN that in fact it has moved (unless it polls at every L2 move). The proposal here would provide an indication in terms of prefix cost.

John


-----Original Message-----
From: ipv6 [mailto:[e-mail]] On Behalf Of Mudric, Dusan (Dusan)
Sent: Friday, March 18, 2016 10:01 AM
To: [e-mail]
Subject: RE: draft-mccann-dmm-prefixcost

Hi John, 

If I understood the draft correctly, MN would keep the address after moving to a new point of attachment.

> Abstract:
>...This document provides a mechanism to communicate to the MN the cost 
>of
 >   maintaining a given prefix at the MN's current point of attachment so
>   that the MN can make better decisions about when to release old
>   addresses and assign new ones.
>
>BR,
>John

Q1: How will MN1 know about the address prefix deletion at the new point of attachment?
Q2: How will MN1 refresh the prefix in use?
Q3: What will MN1 do after the prefix valid life time expires?
Q4: How will another MN2, at the old point of attachment, detect its address is duplicate (used the MN1)?

Regards,
Dusan Mudric.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=BQIFAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=pRlATyTvTCnFLJj3Kz9YxsWVRiJIs5SdZZxq3RFvnCs&s=D0sRq6gHzD8EurUDzW7PxtrPtbZaeyEZD7oievaDlwU&e=
--------------------------------------------------------------------