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 <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Date: Friday, October 23, 2015 at 6:33 AM To: Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, John Kaippallimalil <john.kaippallima...@huawei.com<mailto:john.kaippallima...@huawei.com>>, "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>> 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. 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:sgund...@cisco.com] Sent: Friday, October 23, 2015 12:59 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org<mailto:dmm@ietf.org> 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 From: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Date: Thursday, October 22, 2015 at 5:00 PM To: Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, John Kaippallimalil <john.kaippallima...@huawei.com<mailto:john.kaippallima...@huawei.com>>, "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>> 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. If you can give me enough colors to describe all these shades of grey I will be happy. ;) -Pete From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, October 22, 2015 6:55 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org<mailto:dmm@ietf.org> 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 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 <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Date: Thursday, October 22, 2015 at 3:03 PM To: Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, John Kaippallimalil <john.kaippallima...@huawei.com<mailto:john.kaippallima...@huawei.com>>, "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>> 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. 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:sgund...@cisco.com] Sent: Thursday, October 22, 2015 5:38 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org<mailto:dmm@ietf.org> 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. 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 <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Date: Thursday, October 22, 2015 at 1:43 PM To: John Kaippallimalil <john.kaippallima...@huawei.com<mailto:john.kaippallima...@huawei.com>>, Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>> Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt 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:dmm-boun...@ietf.org] On Behalf Of John Kaippallimalil Sent: Wednesday, October 14, 2015 4:07 PM To: Sri Gundavelli (sgundave); dmm@ietf.org<mailto:dmm@ietf.org> 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 From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Wednesday, October 14, 2015 2:10 PM To: John Kaippallimalil; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt 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 ? 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 From: John Kaippallimalil <john.kaippallima...@huawei.com<mailto:john.kaippallima...@huawei.com>> Date: Wednesday, October 14, 2015 at 11:50 AM To: Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>> 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:sgund...@cisco.com] Sent: Wednesday, October 14, 2015 12:38 PM To: John Kaippallimalil; dmm@ietf.org<mailto:dmm@ietf.org> 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 From: dmm <dmm-boun...@ietf.org<mailto:dmm-boun...@ietf.org>> on behalf of John Kaippallimalil <john.kaippallima...@huawei.com<mailto:john.kaippallima...@huawei.com>> Date: Wednesday, October 14, 2015 at 9:19 AM To: "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>> Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt 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: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> [mailto:internet-dra...@ietf.org] 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
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
