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

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 protected]<mailto:[email protected]>>
Date: Wednesday, October 14, 2015 at 11:50 AM
To: Sri Gundavelli <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
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 protected]]
Sent: Wednesday, October 14, 2015 12:38 PM
To: John Kaippallimalil; [email protected]<mailto:[email protected]>
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 <[email protected]<mailto:[email protected]>> on behalf of John Kaippallimalil <[email protected]<mailto:[email protected]>>
Date: Wednesday, October 14, 2015 at 9:19 AM
To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
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: [email protected]<mailto:[email protected]> [mailto:[email protected]]
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
[email protected]
https://www.ietf.org/mailman/listinfo/dmm