On 3/17/14 7:20 PM, "Jouni Korhonen" <jouni.nos...@gmail.com> wrote:
>Folks, > >Triggered by the question from Behcet, we should come up with the >milestones. Few proposals: > >o The deployment models and scenarios I-D is obvious. >o Anchor selection I-D is obvious. Could we also bundle > the re-anchoring solution into this one or should it be > a different I-D? IMO, these are two different topics and can be kept as separate work items. Anchor selection is tied to access network, request path, policy, handovers and load on the target elements. The entity using the gateway selection can be a end point, a network node or a policy system. The bulk of the work is around laying out the considerations for gateway selection and specifying the logic. The selection to most part is about the assigning a gateway during initial session establishment. Session Re-anchoring is about moving a session state between gateways, after the session got established. It has impact on the forwarding plane and is more about a routing problem. But, you may argue this is also touching the aspect of gateway (re)-selection at a failure point. In this sense there is some relation there, but it depends on how the re-anchoring solution is specified. IMO, its better to track them as separate work items. >o Mobility state exposing I-D. This would communication > between the end host and the network. Maybe also covering > the missing parts within the end host.. Are we OK with one > I-D or how people want to see this? Single ID is fine. Regards Sri _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
