Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

From: John Kaippallimalil <[email-masked]>
Date: Wed, 14 Oct 2015 16:19:54 +0000

Hi,

We have posted a new version of the Prefix Cost draft (please see submission below).

The comments addressed include that from the last meeting, as well as discussions on the reflector regarding how this cost can be provided to the host:

1. What is the motivation – what costs are being optimized
   [added entire chapter on Motivation]

2. Does this require additional signaling?
   [No additional signaling incurred in this mechanism - sub option of RA]

3. Does this impact L2 events?
   [Not responding to link layer /L2 events]

4. Is this addressing e2e aspects of flow, etc?
   [No e2e proposed; that is for MPTCP and others.]

5. What is host/application behavior when prefix cost changes?
   The updates provide some details on what can/should be done in the host. I think that detailed mechanisms should be

   addressed in a companion/other draft related to APIs, etc. But, it would be interesting to hear other views.

Would appreciate comments and suggestions.

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

A new version of I-D, draft-mccann-dmm-prefixcost-02.txt

has been successfully submitted by John Kaippallimalil and posted to the IETF repository.

Name:       draft-mccann-dmm-prefixcost

Revision:   02

Title:            Communicating Prefix Cost to Mobile Nodes

Document date:    2015-10-13

Group:            Individual Submission

Pages:            9

URL:            https://www.ietf.org/internet-drafts/draft-mccann-dmm-prefixcost-02.txt

Status:         https://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcost/

Htmlized:       https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02

Diff:           https://www.ietf.org/rfcdiff?url2=draft-mccann-dmm-prefixcost-02

Abstract:

   In a network implementing Distributed Mobility Management, it has

   been agreed that Mobile Nodes (MNs) should exhibit agility in their

   use of IP addresses.  For example, an MN might use an old address for

   ongoing socket connections but use a new, locally assigned address

   for new socket connections.  Determining when to assign a new

   address, and when to release old addresses, is currently an open

   problem.  Making an optimal decision about address assignment and

   release must involve a tradeoff in the amount of signaling used to

   allocate the new addresses, the amount of utility that applications

   are deriving from the use of a previously assigned address, and the

   cost of maintaining an address that was assigned at a previous point

   of attachment.  As the MN moves farther and farther from the initial

   point where an address was assigned, more and more resources are used

   to redirect packets destined for that IP address to its current

   location.  The MN currently does not know the amount of resources

   used as this depends on mobility path and internal routing topology

   of the network(s) which are known only to the network operator.  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.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 14 Oct 2015 17:37:31 +0000

John:

How would the AR know the cost of a prefix ? Assuming the AR is taking the role of a access gateway and the projected prefix is from a remote gateway, how would it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some arbitrary cost metric; those capabilities in the form of attributes allow the MN to pick up a right prefix. So, I'm not sure how the AR computes this cost and how the end points make use of this value.

Sri

From: dmm <[email-masked]<mailto:[email-masked]>> on behalf of John Kaippallimalil <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 14, 2015 at 9:19 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Hi,

1. What is the motivation - what costs are being optimized
   [added entire chapter on Motivation]

John

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Revision:   02

Pages:            9

Abstract:

The IETF Secretariat

---

From: John Kaippallimalil <[email-masked]>
Date: Wed, 14 Oct 2015 18:50:55 +0000

Hi Sri,
This is a good point -

As we note in the draft wrt policy - different service providers may configure the how the cost is interpreted by the host (see chapter 4 - Host Considerations). These could  be the policy/configuration/other considerations in 3GPP for a mobile architecture, and perhaps a different set of assumptions/needs in a cable or BBF network.
The host and network mechanisms are in some way related: for example, host is dynamically configured with S14 or OMA-DM, and the network should use the same rules to determine what prefix cost information is sent by the AR in Router Advertisements.

I do agree that the draft does not explicitly say about how the network side is handled (i.e., similar to the chapter on host considerations). We can add a section like "Network Considerations" and state how host/network work to deliver consistent prefix cost (but also that the values are out of scope) - would that address your concern?

John

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Wednesday, October 14, 2015 12:38 PM
To: John Kaippallimalil; [email-masked]
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

John:

Sri

Hi,

John

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Revision:   02

Pages:            9

Abstract:

The IETF Secretariat

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 14 Oct 2015 19:10:03 +0000

Hi John,

Thanks for your response. Certainly, operators can define their own definitions for the cost metric, but it will still break the end point interoperability. If the industry approach is BYOD, how would you make different devices from roaming partners interpret this cost metric that they receive from the attached common access network ? AR needs provisioning interface to the end point and it needs policy interface to the respective home networks. Assuming those interface exists, still how would a AR ever provide a cost metric for two different prefixes from two remote gateways. Its the same backhaul and the conditions/traffic patters are always changing ?

If we rather acknowledge that metric definition is difficult to specify, instead we focus on capability indications.  We spent few years in IETF discussing this topic of prefix coloring and may the approach is coloring is what we should look at.

Regards
Sri

From: John Kaippallimalil <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 14, 2015 at 11:50 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Hi Sri,
This is a good point –

As we note in the draft wrt policy – different service providers may configure the how the cost is interpreted by the host (see chapter 4 – Host Considerations). These could  be the policy/configuration/other considerations in 3GPP for a mobile architecture, and perhaps a different set of assumptions/needs in a cable or BBF network.
The host and network mechanisms are in some way related: for example, host is dynamically configured with S14 or OMA-DM, and the network should use the same rules to determine what prefix cost information is sent by the AR in Router Advertisements.

I do agree that the draft does not explicitly say about how the network side is handled (i.e., similar to the chapter on host considerations). We can add a section like “Network Considerations” and state how host/network work to deliver consistent prefix cost (but also that the values are out of scope) – would that address your concern?

John

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Wednesday, October 14, 2015 12:38 PM
To: John Kaippallimalil; [email-masked]<mailto:[email-masked]>
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

John:

How would the AR know the cost of a prefix ? Assuming the AR is taking the role of a access gateway and the projected prefix is from a remote gateway, how would it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some arbitrary cost metric; those capabilities in the form of attributes allow the MN to pick up a right prefix. So, I’m not sure how the AR computes this cost and how the end points make use of this value.

Sri

Hi,

John

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Revision:   02

Pages:            9

Abstract:

The IETF Secretariat

---

From: John Kaippallimalil <[email-masked]>
Date: Wed, 14 Oct 2015 20:07:14 +0000

Hi Sri,
Thanks for the feedback about what worked (and didn't) in prefix coloring .
We could explore about "capabilities" in more detail  - if we can do so - that could help other stds bodies understand this better also.
Would like to discuss this in more detail...

Some notes inline below.

John

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Wednesday, October 14, 2015 2:10 PM
To: John Kaippallimalil; [email-masked]
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Hi John,

With respect to end point interoperability - there needs to be an association between the network/radio link provider (PLMN), the configuration of policies of that provider, and the request for addresses in that network. If the radio network, backhaul and core network (IP address) are through different providers, there will be agreements among them on consistent handling of various policies and resources - this should be one of them.

With regard to changing conditions and traffic patterns -  so far this draft has focused on prefix cost as a result of additional resources used due to sub-optimal paths/routes as a result of MN mobility.
I see the issue you are pointing here: that this mechanism has broader applicability than just the change in prefix cost due to mobility. It could very well be that the MN does not move, but yet the cost of supporting the IP prefix can change due to traffic patterns/other network policies.
This needs more thinking to see if it can be generalized ...

If we rather acknowledge that metric definition is difficult to specify, instead we focus on capability indications.  We spent few years in IETF discussing this topic of prefix coloring and may the approach is coloring is what we should look at.
Just making sure I understand this: the comment is not about prefix coloring vs prefix cost (I think they are complementary), but rather that we should learn from the issues that prefix coloring draft faced.
If so: - I'd like to learn from this and avoid repeating/wasting time.
Lets discuss what these general capabilities are (also related to the previous points ...)..

Regards
Sri

Hi Sri,
This is a good point -

John

John:

Sri

Hi,

John

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Revision:   02

Pages:            9

Abstract:

The IETF Secretariat

---

From: Peter McCann <[email-masked]>
Date: Thu, 22 Oct 2015 20:43:49 +0000

Prefix coloring in its current form is not going to work.

If I tell the MN that an address is "Fixed" and will always be on-link I am making a promise that cannot be kept.  The MN can always move to an unaffiliated network that is unable to tunnel/route the packets to the current point of attachment.

Instead of making promises about the future availability of a prefix, the best we can do is inform the MN about the current cost in terms of topological distance from the original point of assignment.  The AR/network can use whatever algorithm it likes to calculate this, as long as it increases with topological distance from the original point of attachment.  Some simple function of the bitwise distance between the assigned address being redirected and a new link-native prefix might suffice.  The MN can use whatever algorithm it likes to release/acquire addresses, as long as the cheaper ones are more preferred over the more expensive.  I don't see any need to be more specific than that.  There won't be any interoperability issues.

-Pete

From: dmm [mailto:[email-masked]] On Behalf Of John Kaippallimalil
Sent: Wednesday, October 14, 2015 4:07 PM
To: Sri Gundavelli (sgundave); [email-masked]
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Hi Sri,

Some notes inline below.

John

Hi John,

Regards
Sri

Hi Sri,
This is a good point -

John

John:

Sri

Hi,

John

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Revision:   02

Pages:            9

Abstract:

The IETF Secretariat

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 22 Oct 2015 21:37:46 +0000

Pete,

There are no simple way to compute that prefix cost. If we say that it is just a topological distance, that’s not simple to measure either. An overlay tunnel across an IP cloud will be viewed as a single hop with a topological distance of 1, but there is an IP cloud  in between. We can certainly say, it can be any algorithm that presents two remote gateways/prefixes in some order with some derived cost metric, but coming out with that algorithm is the core issue here. When an access router views two sets of measurements for two distance gateways, each with different jitter, latency and packet loss characteristics, how would the AR make the call ? Would that be based on latency, or will that be based on packet loss ? Why jitter and why not loss ? When there is no one definitive way to compute that, exposing the same to the end point is incorrect as that has an implication on the application that uses that prefix.

Regarding the property meta-data that goes with a prefix, it can certainly change.  There is no assumption that property set does not change. A router R1 hosting a remote prefix may present a different property set, than a router R2 hosting the same prefix. Updating the same will inform the end-point about the change in network characteristics. What goes into the meta-data is a set of properties with no ambiguity associated with it. But, here this prefix cost is about path characterization and that is not based on one factor, but its a list of factors that cannot be normalized and presented as a single value.

Sri

From: Peter McCann <[email-masked]<mailto:[email-masked]>>
Date: Thursday, October 22, 2015 at 1:43 PM
To: John Kaippallimalil <[email-masked]<mailto:[email-masked]>>, Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

If I tell the MN that an address is “Fixed” and will always be on-link I am making a promise that cannot be kept.  The MN can always move to an unaffiliated network that is unable to tunnel/route the packets to the current point of attachment.

Instead of making promises about the future availability of a prefix, the best we can do is inform the MN about the current cost in terms of topological distance from the original point of assignment.  The AR/network can use whatever algorithm it likes to calculate this, as long as it increases with topological distance from the original point of attachment.  Some simple function of the bitwise distance between the assigned address being redirected and a new link-native prefix might suffice.  The MN can use whatever algorithm it likes to release/acquire addresses, as long as the cheaper ones are more preferred over the more expensive.  I don’t see any need to be more specific than that.  There won’t be any interoperability issues.

-Pete

From: dmm [mailto:[email-masked]] On Behalf Of John Kaippallimalil
Sent: Wednesday, October 14, 2015 4:07 PM
To: Sri Gundavelli (sgundave); [email-masked]<mailto:[email-masked]>
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Hi Sri,
Thanks for the feedback about what worked (and didn’t) in prefix coloring .
We could explore about “capabilities” in more detail  - if we can do so - that could help other stds bodies understand this better also.
Would like to discuss this in more detail…

Some notes inline below.

John

Hi John,

With respect to end point interoperability – there needs to be an association between the network/radio link provider (PLMN), the configuration of policies of that provider, and the request for addresses in that network. If the radio network, backhaul and core network (IP address) are through different providers, there will be agreements among them on consistent handling of various policies and resources – this should be one of them.

With regard to changing conditions and traffic patterns –  so far this draft has focused on prefix cost as a result of additional resources used due to sub-optimal paths/routes as a result of MN mobility.
I see the issue you are pointing here: that this mechanism has broader applicability than just the change in prefix cost due to mobility. It could very well be that the MN does not move, but yet the cost of supporting the IP prefix can change due to traffic patterns/other network policies.
This needs more thinking to see if it can be generalized …

If we rather acknowledge that metric definition is difficult to specify, instead we focus on capability indications.  We spent few years in IETF discussing this topic of prefix coloring and may the approach is coloring is what we should look at.
Just making sure I understand this: the comment is not about prefix coloring vs prefix cost (I think they are complementary), but rather that we should learn from the issues that prefix coloring draft faced.
If so: – I’d like to learn from this and avoid repeating/wasting time.
Lets discuss what these general capabilities are (also related to the previous points …)..

Regards
Sri

Hi Sri,
This is a good point –

John

John:

Sri

Hi,

John

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Revision:   02

Pages:            9

Abstract:

The IETF Secretariat

---

From: Peter McCann <[email-masked]>
Date: Thu, 22 Oct 2015 22:03:16 +0000

So "Fixed" does not mean fixed?  What does it mean, exactly?

Prefix cost is not about conveying latency or jitter to the MN.  The MN can measure those things end-to-end with transport protocols.  It is intended as a measure of the amount of state being maintained in the network on behalf of this prefix and the amount of transport resources being expended to tunnel/route the packets to the current point of attachment.  A prefix allocated originally by a different provider should have a high cost.  A prefix allocated from another region in the same provider would have a medium cost.  A prefix locally allocated by the current AR would have a minimal cost.  It reflects the internal topology of the current access provider and the relationship of the current AR to the point where packets would be routed if the address were fully aggregated.  We don't have to, and we shouldn't, standardize any algorithm for computing this value because every service provider will have its own topology and regional boundaries.

There is no standardized algorithm for setting weights or local preferences in BGP, and yet the protocol functions by preferring routes with lower values over higher ones.

-Pete

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 5:38 PM
To: Peter McCann; John Kaippallimalil; [email-masked]
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Pete,

There are no simple way to compute that prefix cost. If we say that it is just a topological distance, that's not simple to measure either. An overlay tunnel across an IP cloud will be viewed as a single hop with a topological distance of 1, but there is an IP cloud  in between. We can certainly say, it can be any algorithm that presents two remote gateways/prefixes in some order with some derived cost metric, but coming out with that algorithm is the core issue here. When an access router views two sets of measurements for two distance gateways, each with different jitter, latency and packet loss characteristics, how would the AR make the call ? Would that be based on latency, or will that be based on packet loss ? Why jitter and why not loss ? When there is no one definitive way to compute that, exposing the same to the end point is incorrect as that has an implication on the application that uses that prefix.

Sri

-Pete

Hi Sri,

Some notes inline below.

John

Hi John,

Regards
Sri

Hi Sri,
This is a good point -

John

John:

Sri

Hi,

John

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Revision:   02

Pages:            9

Abstract:

The IETF Secretariat

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 22 Oct 2015 22:55:19 +0000

>  It is intended as a measure of the amount of state being maintained in the network on behalf of this prefix and the amount of transport resources being expended to tunnel/route the packets to the current point of attachment.

This is exactly the point. We cannot represent that “state” and “resources” associated with the prefix in a single parameter called “prefix-cost”. At the end of the day, the goal is to enable the end-point to make meaningful use of it. If we say, this value is so local to the operator,  how does my stack on the host make use of it ? I’m launching two applications and there are two prefixes P1 with P-C=5, P2/P-C=6, should both my apps use P1 because it has a better cost, but my host not know what that cost means as we never published that algorithm. What is the point ? Why not suppress all prefixes and give a single prefix that is deemed to meet the app requirement, from the AR point of view ?

If we say that, we don’t specify the algorithm, keep the scope to operator’s end points and domain, then there is truly no need for interop.  I think what you guys are looking for is this extension,  https://tools.ietf.org/id/draft-gundavelli-6man-ipv6-nd-vendor-spec-options-00.txt .

Regarding the “fixed” comment, I see where the disconnect is and its my mistake. I meant to say, there are “n” number of properties that goes with a prefix; each of those prefixes have well defined meaning. As the prefix moves in the network from R1 to R2, properties do change. Property bit A can be ON at R1, but may be OFF on R2. Your example of “Tunneled” is OFF at home link, but ON on a visitor link.

Sri

From: Peter McCann <[email-masked]<mailto:[email-masked]>>
Date: Thursday, October 22, 2015 at 3:03 PM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, John Kaippallimalil <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

So “Fixed” does not mean fixed?  What does it mean, exactly?

Prefix cost is not about conveying latency or jitter to the MN.  The MN can measure those things end-to-end with transport protocols.  It is intended as a measure of the amount of state being maintained in the network on behalf of this prefix and the amount of transport resources being expended to tunnel/route the packets to the current point of attachment.  A prefix allocated originally by a different provider should have a high cost.  A prefix allocated from another region in the same provider would have a medium cost.  A prefix locally allocated by the current AR would have a minimal cost.  It reflects the internal topology of the current access provider and the relationship of the current AR to the point where packets would be routed if the address were fully aggregated.  We don’t have to, and we shouldn’t, standardize any algorithm for computing this value because every service provider will have its own topology and regional boundaries.

-Pete

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 5:38 PM
To: Peter McCann; John Kaippallimalil; [email-masked]<mailto:[email-masked]>
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Pete,

Sri

-Pete

Hi Sri,

Some notes inline below.

John

Hi John,

Regards
Sri

Hi Sri,
This is a good point –

John

John:

Sri

Hi,

John

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Revision:   02

Pages:            9

Abstract:

The IETF Secretariat

---

From: Peter McCann <[email-masked]>
Date: Fri, 23 Oct 2015 00:00:49 +0000

Ok, now I think we are getting somewhere.  I was assuming you were part of the consensus that has seemed to form around "fixed", "sustained", and "nomadic" as the only 3 colors.  I hope we agree that those three values don't really mean anything when sent from the network to the host.  They might make sense in some kind of internal operating system API, but that's a separate question.

Now I think we are just debating the size and scope of the color pallette.  In your example, you have a bit that represents "tunneling in effect".  However, there are long tunnels and there are short tunnels.  A tunnel from the previous base station to the current base station, which are connected by a single Ethernet cable, is no big deal.  However, a tunnel to a foreign network where the prefix was originally assigned may be using up substantial resources and may be costing the visited operator real money due to interconnection fees.  I would like to be able to distinguish between these two cases.  In general, the MN just wants to know "how much pain am I causing the network operator by holding on to this prefix?"  The MN doesn't need to know or care about what kind of mechanism (tunneling, routing, or carrier pigeon) is being used to direct packets destined for the IP address to his current point of attachment.  He can just make use of a simple scalar value that represents the degree of the operator's desire to move him to a more local, less costly prefix.  Simple administratively configured scalar values are used like this all the time in routing protocols to choose among disjoint routes and they seem to work well.

If you can give me enough colors to describe all these shades of grey I will be happy. ;)

-Pete

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 6:55 PM
To: Peter McCann; John Kaippallimalil; [email-masked]
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

>  It is intended as a measure of the amount of state being maintained in the network on behalf of this prefix and the amount of transport resources being expended to tunnel/route the packets to the…

This is exactly the point. We cannot represent that "state" and "resources" associated with the prefix in a single parameter called "prefix-cost". At the end of the day, the goal is to enable the end-point to make meaningful use of it. If we say, this value is so local to the operator,  how does my stack on the host make use of it ? I'm launching two applications and there are two prefixes P1 with P-C=5, P2/P-C=6, should both my apps use P1 because it has a better cost, but my host not know what that cost means as we never published that algorithm. What is the point ? Why not suppress all prefixes and give a single prefix that is deemed to meet the app requirement, from the AR point of view ?

If we say that, we don't specify the algorithm, keep the scope to operator's end points and domain, then there is truly no need for interop.  I think what you guys are looking for is this extension,  https://tools.ietf.org/id/draft-gundavelli-6man-ipv6-nd-vendor-spec-options-00.txt .

Regarding the "fixed" comment, I see where the disconnect is and its my mistake. I meant to say, there are "n" number of properties that goes with a prefix; each of those prefixes have well defined meaning. As the prefix moves in the network from R1 to R2, properties do change. Property bit A can be ON at R1, but may be OFF on R2. Your example of "Tunneled" is OFF at home link, but ON on a visitor link.

Sri

-Pete

Pete,

Sri

-Pete

Hi Sri,

Some notes inline below.

John

Hi John,

Regards
Sri

Hi Sri,
This is a good point -

John

John:

Sri

Hi,

John

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Revision:   02

Pages:            9

Abstract:

The IETF Secretariat

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 23 Oct 2015 04:59:18 +0000

I’ve not payed attention to that discussion on the fixed/sustaining/nomadic address types. But, I don’t see much relation to this specific extension around “prefix-cost” and the drafts dealing with colorometry. I thought the starting point here was about delivering a prefix-cost which is about characterizing of a path cost as some number or some representation of topological distance; its not dealing with properties or capabilities and at least the draft does not talk about that. Staying in that context, per my earlier question, its unclear how the end point will ever pick an address that has lower prefix-cost value, when there is another prefix with a better prefix-cost value. The prefix-cost has only one implied meaning, bigger the better. The same can be achieved by sending a single prefix was my point.

Now, regarding the specific shade of grey that you are looking  in my color palette :), I don’t see an issue there. As long as you can give a property name for each of your fifty shades of grey and have a printed card for each of those colors, the AR will decorate the ND container with the right set of cards and ship it out on the wire. These properties have well defined meaning that can be used by applications for matching the app requirement with the address capabilities. We can certainly argue that we can define infinite # number of properties (with the long/short tunnel example) and we are back in square one, but thats a name space management issue and we will not allow such color definitions. This is different from the prefix-cost issue, where the algorithm is unknown and the value has no universal meaning and my point there its not helping the end point in address selection.

Sri

From: Peter McCann <[email-masked]<mailto:[email-masked]>>
Date: Thursday, October 22, 2015 at 5:00 PM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, John Kaippallimalil <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Ok, now I think we are getting somewhere.  I was assuming you were part of the consensus that has seemed to form around “fixed”, “sustained”, and “nomadic” as the only 3 colors.  I hope we agree that those three values don’t really mean anything when sent from the network to the host.  They might make sense in some kind of internal operating system API, but that’s a separate question.

Now I think we are just debating the size and scope of the color pallette.  In your example, you have a bit that represents “tunneling in effect”.  However, there are long tunnels and there are short tunnels.  A tunnel from the previous base station to the current base station, which are connected by a single Ethernet cable, is no big deal.  However, a tunnel to a foreign network where the prefix was originally assigned may be using up substantial resources and may be costing the visited operator real money due to interconnection fees.  I would like to be able to distinguish between these two cases.  In general, the MN just wants to know “how much pain am I causing the network operator by holding on to this prefix?”  The MN doesn’t need to know or care about what kind of mechanism (tunneling, routing, or carrier pigeon) is being used to direct packets destined for the IP address to his current point of attachment.  He can just make use of a simple scalar value that represents the degree of the operator’s desire to move him to a more local, less costly prefix.  Simple administratively configured scalar values are used like this all the time in routing protocols to choose among disjoint routes and they seem to work well.

-Pete

Sri

-Pete

Pete,

Sri

-Pete

Hi Sri,

Some notes inline below.

John

Hi John,

Regards
Sri

Hi Sri,
This is a good point –

John

John:

Sri

Hi,

John

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Revision:   02

Pages:            9

Abstract:

The IETF Secretariat

---

From: Peter McCann <[email-masked]>
Date: Fri, 23 Oct 2015 13:33:48 +0000

We can't send just a single prefix (lowest cost), taking away the higher-cost prefixes, because the network doesn't know how many outstanding references (open sockets) there are for the high-cost prefix, and it doesn't know the damage it would cause by breaking those ongoing sessions.  The MN needs to explicitly release a prefix when it is no longer using it.

Why would you tell me that I am not allowed to distinguish between a long tunnel and a short tunnel?  They impose dramatically different costs on the network operator, and  we will need to inform the MN about this so it can move its applications off of the high-cost prefix and on to the lower cost prefixes.

I also don't see the reason to expose the network mobility management scheme to the MN.  Why does the MN care that it's a tunnel being used, and not a set of routing table entries?

-Pete

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Friday, October 23, 2015 12:59 AM
To: Peter McCann; John Kaippallimalil; [email-masked]
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

I've not payed attention to that discussion on the fixed/sustaining/nomadic address types. But, I don't see much relation to this specific extension around "prefix-cost" and the drafts dealing with colorometry. I thought the starting point here was about delivering a prefix-cost which is about characterizing of a path cost as some number or some representation of topological distance; its not dealing with properties or capabilities and at least the draft does not talk about that. Staying in that context, per my earlier question, its unclear how the end point will ever pick an address that has lower prefix-cost value, when there is another prefix with a better prefix-cost value. The prefix-cost has only one implied meaning, bigger the better. The same can be achieved by sending a single prefix was my point.

Now, regarding the specific shade of grey that you are looking  in my color palette :), I don't see an issue there. As long as you can give a property name for each of your fifty shades of grey and have a printed card for each of those colors, the AR will decorate the ND container with the right set of cards and ship it out on the wire. These properties have well defined meaning that can be used by applications for matching the app requirement with the address capabilities. We can certainly argue that we can define infinite # number of properties (with the long/short tunnel example) and we are back in square one, but thats a name space management issue and we will not allow such color definitions. This is different from the prefix-cost issue, where the algorithm is unknown and the value has no universal meaning and my point there its not helping the end point in address selection.

Sri

-Pete

Sri

-Pete

Pete,

Sri

-Pete

Hi Sri,

Some notes inline below.

John

Hi John,

Regards
Sri

Hi Sri,
This is a good point -

John

John:

Sri

Hi,

John

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Revision:   02

Pages:            9

Abstract:

The IETF Secretariat

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 23 Oct 2015 15:22:17 +0000

Ok. But, if you send multiple prefixes with different Prefix-Cost values, how will that be used is still the question ?  As you said, Prefix-Cost is local to that operator, we don’t publish the algorithm, its just a number, and and the MN only knows a bigger value means its most preferred. If I’ve two apps, why will I not ever use a best cost prefix ? Does this not all finally converge to “most-preferred” vs “not-preferred” tags and with Prefix-Cost value playing no role in the address selection ?

I understand the point around selecting a gateway which has “shorter tunnel”, but I’m afraid prefix-cost alone is not sufficient. This is about path characterization and it cannot be represented as a single parameter. If we want Apps to make meaningful use of it, there needs to be many additional parameters and more than that I do not believe ND is the right container for presenting such data. May be this should be part of routing protocols ? This is like bringing BGP attributes to Neighbor Discovery, IMO.

Sri

From: Peter McCann <[email-masked]<mailto:[email-masked]>>
Date: Friday, October 23, 2015 at 6:33 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, John Kaippallimalil <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

We can’t send just a single prefix (lowest cost), taking away the higher-cost prefixes, because the network doesn’t know how many outstanding references (open sockets) there are for the high-cost prefix, and it doesn’t know the damage it would cause by breaking those ongoing sessions.  The MN needs to explicitly release a prefix when it is no longer using it.

I also don’t see the reason to expose the network mobility management scheme to the MN.  Why does the MN care that it’s a tunnel being used, and not a set of routing table entries?

-Pete

Sri

-Pete

Sri

-Pete

Pete,

Sri

-Pete

Hi Sri,

Some notes inline below.

John

Hi John,

Regards
Sri

Hi Sri,
This is a good point –

John

John:

Sri

Hi,

John

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Revision:   02

Pages:            9

Abstract:

The IETF Secretariat

---

From: Peter McCann <[email-masked]>
Date: Mon, 26 Oct 2015 15:18:56 +0000

An MN may not use the lowest-cost prefix because it has an ongoing session with a previously-assigned, but now higher cost, prefix.  We have to leave the address release decision up to the MN because the network does not have a reference count for the addresses.   That only exists inside the MN.

This problem space is very much like a routing protocol.  There are multiple (inbound) routes that the MN is selecting from.  The network needs to provide a hint about which prefix is the most local, direct path to the Internet.  The network has the topology information, but we don't necessarily want to send a map of the operator's network to the MN.  So, I think encapsulating this information in a single cost metric is both necessary and appropriate.

-Pete

From: dmm [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Friday, October 23, 2015 11:22 AM
To: Peter McCann; John Kaippallimalil; [email-masked]
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Ok. But, if you send multiple prefixes with different Prefix-Cost values, how will that be used is still the question ?  As you said, Prefix-Cost is local to that operator, we don't publish the algorithm, its just a number, and and the MN only knows a bigger value means its most preferred. If I've two apps, why will I not ever use a best cost prefix ? Does this not all finally converge to "most-preferred" vs "not-preferred" tags and with Prefix-Cost value playing no role in the address selection ?

I understand the point around selecting a gateway which has "shorter tunnel", but I'm afraid prefix-cost alone is not sufficient. This is about path characterization and it cannot be represented as a single parameter. If we want Apps to make meaningful use of it, there needs to be many additional parameters and more than that I do not believe ND is the right container for presenting such data. May be this should be part of routing protocols ? This is like bringing BGP attributes to Neighbor Discovery, IMO.

Sri

-Pete

Sri

-Pete

Sri

-Pete

Pete,

Sri

-Pete

Hi Sri,

Some notes inline below.

John

Hi John,

Regards
Sri

Hi Sri,
This is a good point -

John

John:

Sri

Hi,

John

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Revision:   02

Pages:            9

Abstract:

The IETF Secretariat

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 26 Oct 2015 22:13:59 +0000

We are attempting to solve the problem in the wrong layers and/or wrong protocols.  Traditionally, such aspects are managed in routing protocols, DNS layers or in vendor specific schemes. Some of the vendors such as Akamai has a entire business built around this for CDN selection.  There are sophisticated measurement techniques.   There are also other query based schemes with DNS. DNS SRV records are specifically introduced for such localized node selection; Directory services based on LDAP/MSFT AD use such schemes.  We can certainly bring that complexity into the access gateway and into ND, and without being prescriptive on  the approach, or how it even remotely helps in address selection on an application basis, but I do not see any one using it. I will not repeat my other comments, but I’m not convinced this even works, or if the choice of the protocol is right.

I suggest we should get this reviewed in 6MAN WG and get some better feedback.

cheers
Sri

From: Peter McCann <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 26, 2015 at 8:18 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, John Kaippallimalil <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

This problem space is very much like a routing protocol.  There are multiple (inbound) routes that the MN is selecting from.  The network needs to provide a hint about which prefix is the most local, direct path to the Internet.  The network has the topology information, but we don’t necessarily want to send a map of the operator’s network to the MN.  So, I think encapsulating this information in a single cost metric is both necessary and appropriate.

-Pete

Sri

-Pete

Sri

-Pete

Sri

-Pete

Pete,

Sri

-Pete

Hi Sri,

Some notes inline below.

John

Hi John,

Regards
Sri

Hi Sri,
This is a good point –

John

John:

Sri

Hi,

John

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Revision:   02

Pages:            9

Abstract:

The IETF Secretariat

---

From: Peter McCann <[email-masked]>
Date: Tue, 27 Oct 2015 01:22:57 +0000

I don't understand why you think it needs to be so complicated.  It seems much simpler than the other prefix coloring approaches I have seen being suggested, and much easier to see how applications would use the information.

I agree it might be wise to consult 6man and also MIF.  Perhaps Brian can suggest how to open the discussion to those other groups.

-Pete

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Monday, October 26, 2015 6:14 PM
To: Peter McCann; John Kaippallimalil; [email-masked]
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

We are attempting to solve the problem in the wrong layers and/or wrong protocols.  Traditionally, such aspects are managed in routing protocols, DNS layers or in vendor specific schemes. Some of the vendors such as Akamai has a entire business built around this for CDN selection.  There are sophisticated measurement techniques.   There are also other query based schemes with DNS. DNS SRV records are specifically introduced for such localized node selection; Directory services based on LDAP/MSFT AD use such schemes.  We can certainly bring that complexity into the access gateway and into ND, and without being prescriptive on  the approach, or how it even remotely helps in address selection on an application basis, but I do not see any one using it. I will not repeat my other comments, but I'm not convinced this even works, or if the choice of the protocol is right.

cheers
Sri

-Pete

Sri

-Pete

Sri

-Pete

Sri

-Pete

Pete,

Sri

-Pete

Hi Sri,

Some notes inline below.

John

Hi John,

Regards
Sri

Hi Sri,
This is a good point -

John

John:

Sri

Hi,

John

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Revision:   02

Pages:            9

Abstract:

The IETF Secretariat

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 28 Oct 2015 16:42:20 +0000

If you look at the network design of any SP’s network archtecture, they ensure the latency between two points in the back-haul network does not exceed “n” msecs. So, there is a local gateway and two remote gateways, the new logic that inserted in the access gateway will give you prefix-cost of 1, 2 and 2. What does the client pick ? Local prefix with prefix-cost 1 or 2 ? It always coverges to local or remote, similar to the current home or roam. If there is any latency differential, that is largely due to radio or the application server, and the prefix cost does not include either of them. Fundamentally, the approach of application selecting a prefix that is based on some thing called prefix-cost, for which there is no published algorithm is not some thing I’m able to follow.

> I agree it might be wise to consult 6man and also MIF.

Ack; I don’t know if MIF guys would have a clue about this, but 6man and Routing guys may give some sensible feedback.

Sri

From: Peter McCann <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 26, 2015 at 6:22 PM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, John Kaippallimalil <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

I don’t understand why you think it needs to be so complicated.  It seems much simpler than the other prefix coloring approaches I have seen being suggested, and much easier to see how applications would use the information.

-Pete

cheers
Sri

-Pete

Sri

-Pete

Sri

-Pete

Sri

-Pete

Pete,

Sri

-Pete

Hi Sri,

Some notes inline below.

John

Hi John,

Regards
Sri

Hi Sri,
This is a good point –

John

John:

Sri

Hi,

John

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Revision:   02

Pages:            9

Abstract:

The IETF Secretariat

---

From: Peter McCann <[email-masked]>
Date: Wed, 28 Oct 2015 17:44:16 +0000

The application should always prefer the lowest cost prefix (the more local one).  What is wrong with that?

The only reason you would use a higher cost prefix is because you had a session already established on that prefix and needed to keep using it.

-Pete

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Wednesday, October 28, 2015 12:42 PM
To: Peter McCann; John Kaippallimalil; [email-masked]
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

If you look at the network design of any SP's network archtecture, they ensure the latency between two points in the back-haul network does not exceed "n" msecs. So, there is a local gateway and two remote gateways, the new logic that inserted in the access gateway will give you prefix-cost of 1, 2 and 2. What does the client pick ? Local prefix with prefix-cost 1 or 2 ? It always coverges to local or remote, similar to the current home or roam. If there is any latency differential, that is largely due to radio or the application server, and the prefix cost does not include either of them. Fundamentally, the approach of application selecting a prefix that is based on some thing called prefix-cost, for which there is no published algorithm is not some thing I'm able to follow.

> I agree it might be wise to consult 6man and also MIF.

Ack; I don't know if MIF guys would have a clue about this, but 6man and Routing guys may give some sensible feedback.

Sri

-Pete

cheers
Sri

-Pete

Sri

-Pete

Sri

-Pete

Sri

-Pete

Pete,

Sri

-Pete

Hi Sri,

Some notes inline below.

John

Hi John,

Regards
Sri

Hi Sri,
This is a good point -

John

John:

Sri

Hi,

John

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Revision:   02

Pages:            9

Abstract:

The IETF Secretariat

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 29 Oct 2015 18:53:56 +0000

Sure. But, if this all boils down to marking a prefix as a local prefix , or a remove prefix (as in this example), then its more a capability indicator and not a cost indicator. Prefix-cost can be viewed as a property as the value in there has no significance any more and it always converge to a binary value.

I also suspect  Jouni might be wondering as why his earlier draft, (draft-korhonen-dmm-local-prefix-01) cannot meet the requirement here, it can tell what is local prefix and what is remote prefix. I’m also thinking why the much more generic prefix property scheme (draft-bhandari-dhc-class-based-prefix, draft-korhonen-dmm-prefix-properties)  does not help here.  At least there, inherently there is an aspect of an application selecting a prefix based on its requirements and not have the network blindly assume the application requirement and select a gateway that it believes is the best for the application.

 Sri

From: Peter McCann <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 28, 2015 at 10:44 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, John Kaippallimalil <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

-Pete

Sri

-Pete

cheers
Sri

-Pete

Sri

-Pete

Sri

-Pete

Sri

-Pete

Pete,

Sri

-Pete

Hi Sri,

Some notes inline below.

John

Hi John,

Regards
Sri

Hi Sri,
This is a good point –

John

John:

Sri

Hi,

John

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Revision:   02

Pages:            9

Abstract:

The IETF Secretariat

---

From: Peter McCann <[email-masked]>
Date: Thu, 29 Oct 2015 18:58:43 +0000

We need more than just a binary value.  Those tunnels can be long, medium, short, or non-existent.

We do in fact embed the prefix cost in korhonen-dmm-prefix-properties (we reference it in the draft).

I don't think DHCP is the right protocol to carry this information.  If you believe, as I think you do, that the prefix property will change upon handover to a new AR then we shouldn't tie the transmission of the information to the DHCP state machine.  We should not force DHCP to run on every handover.

-Pete

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Thursday, October 29, 2015 2:54 PM
To: Peter McCann; John Kaippallimalil; [email-masked]
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

I also suspect  Jouni might be wondering as why his earlier draft, (draft-korhonen-dmm-local-prefix-01) cannot meet the requirement here, it can tell what is local prefix and what is remote prefix. I'm also thinking why the much more generic prefix property scheme (draft-bhandari-dhc-class-based-prefix, draft-korhonen-dmm-prefix-properties)  does not help here.  At least there, inherently there is an aspect of an application selecting a prefix based on its requirements and not have the network blindly assume the application requirement and select a gateway that it believes is the best for the application.

 Sri

-Pete

Sri

-Pete

cheers
Sri

-Pete

Sri

-Pete

Sri

-Pete

Sri

-Pete

Pete,

Sri

-Pete

Hi Sri,

Some notes inline below.

John

Hi John,

Regards
Sri

Hi Sri,
This is a good point -

John

John:

Sri

Hi,

John

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Revision:   02

Pages:            9

Abstract:

The IETF Secretariat

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 29 Oct 2015 19:38:11 +0000

I don’t think this is about a new option, vs an extension to existing option in some draft. I’m trying to understand the practical use for that prefix-cost parameter. The idea that every base station/AP/some access node is constantly doing measurements on the high-speed backhaul links and using that measurement in gateway selection appears to be a very expensive proposition and the real value of that approach is the question here. The difference in the back haul measurements between a access gateway and any gateway will be insignificant as these are high-speed pipes; the difference is always the air interface, or the application server.

We should discuss this in Yokohoma.

Sri

From: Peter McCann <[email-masked]<mailto:[email-masked]>>
Date: Thursday, October 29, 2015 at 11:58 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, John Kaippallimalil <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

I don’t think DHCP is the right protocol to carry this information.  If you believe, as I think you do, that the prefix property will change upon handover to a new AR then we shouldn’t tie the transmission of the information to the DHCP state machine.  We should not force DHCP to run on every handover.

-Pete

 Sri

-Pete

Sri

-Pete

cheers
Sri

-Pete

Sri

-Pete

Sri

-Pete

Sri

-Pete

Pete,

Sri

-Pete

Hi Sri,

Some notes inline below.

John

Hi John,

Regards
Sri

Hi Sri,
This is a good point –

John

John:

Sri

Hi,

John

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Revision:   02

Pages:            9

Abstract:

The IETF Secretariat

---

From: John Kaippallimalil <[email-masked]>
Date: Thu, 29 Oct 2015 20:41:26 +0000

It does not have to be as dynamic or complex. Just the topology of the network and resources used in forwarding introduces enough variable costs.
Also, backhaul network costs being insignificant is probably valid now, but with radio bandwidth increases of 100 -1000 times (some trials plan to exceed even this with cmw, mmw) in dense radio networks , backhaul costs and first hop route is going to be a big problem.
In the draft we've referred to these requirements from NGMN in the Motivation section. At this point, I think we are assuming different architectural (and other) assumptions.

Lets discuss in Yokohama.

BR,
John

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Thursday, October 29, 2015 2:38 PM
To: Peter McCann; John Kaippallimalil; [email-masked]
Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

I don't think this is about a new option, vs an extension to existing option in some draft. I'm trying to understand the practical use for that prefix-cost parameter. The idea that every base station/AP/some access node is constantly doing measurements on the high-speed backhaul links and using that measurement in gateway selection appears to be a very expensive proposition and the real value of that approach is the question here. The difference in the back haul measurements between a access gateway and any gateway will be insignificant as these are high-speed pipes; the difference is always the air interface, or the application server.

Sri

-Pete

 Sri

-Pete

Sri

-Pete

cheers
Sri

-Pete

Sri

-Pete

Sri

-Pete

Sri

-Pete

Pete,

Sri

-Pete

Hi Sri,

Some notes inline below.

John

Hi John,

Regards
Sri

Hi Sri,
This is a good point -

John

John:

Sri

Hi,

John

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Revision:   02

Pages:            9

Abstract:

The IETF Secretariat

---

From: Peter McCann <[email-masked]>
Date: Thu, 29 Oct 2015 20:48:29 +0000

Right it's not about measuring latency (the MN can do that itself at the transport layer).  It is really about the network topology and the business relationships between providers.  If I am borrowing a home address from a remote provider, and they are charging me for it while I deliver it on-link to the current AR of the MN (using tunneling, routing, whatever) I need to somehow reflect that fact to the MN and discourage the use of the prefix for new connections.  However, I am willing to keep it on-link for as long as the MN has old connections that are still using it.  Similar considerations can apply even within the same provider if I have moved too far from the initial point of assignment - there is a cross-regional tunnel in place that is costing me OpEx to maintain.  I would like to gently urge the MN to stop using that prefix, when it is convenient for the MN to do so.

-Pete

From: John Kaippallimalil
Sent: Thursday, October 29, 2015 4:41 PM
To: Sri Gundavelli (sgundave); Peter McCann; [email-masked]
Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

BR,
John

Sri

-Pete

 Sri

-Pete

Sri

-Pete

cheers
Sri

-Pete

Sri

-Pete

Sri

-Pete

Sri

-Pete

Pete,

Sri

-Pete

Hi Sri,

Some notes inline below.

John

Hi John,

Regards
Sri

Hi Sri,
This is a good point -

John

John:

Sri

Hi,

John

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 2:37 PM
To: John Kaippallimalil; Peter McCann; Peter McCann
Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

Revision:   02

Pages:            9

Abstract:

The IETF Secretariat