Dear Dirk, thanks a lot for your review and for your comments. Please see inline for my response.
>-----Original Message----- >From: dirk.von-h...@telekom.de [mailto:dirk.von-h...@telekom.de] >Sent: Donnerstag, 31. Oktober 2013 16:59 >To: Marco Liebsch; dmm@ietf.org >Subject: RE: DMM framework > >Dear Marco, all, > >I think the idea of describing mobility management functions in a generic and >modular way can help to allow for fair comparison of different existing >approaches and new extensions towards fulfillment of DMM requirements. As >your draft shows also routing-protocol based approaches as LISP can be >described by this nomenclature. With the new functional entities - and the >defined reference points in between - and the abstraction of the mobility >related >ones it thus should help to analyse general network architectures and >functional >decompositions for both fixed and mobile sessions - in a similar fashion as >SDN/NFV (Software Defined Networks/Network Function Virtualization) concepts >proceed. That was a key idea behind the framework to allow building a DMM solution that allows exposing relevant states to the dataplane, e.g. routers, SDN controllers, etc, and to enable inter-working, aiming at an optimized routing path to the MN's current anchor The specifications of the DMM group could take such framework to specify the hooks between the mobility control plane and e.g. a transport network control plane without interfering with other WGs or SDOs. > >As usually the network analysis will focus on the performance parameters >denoted below. I think therefore the framework activities are valuable work >from an operators point of view which we should intensify - thus perhaps >helping >the resulting protocol proposals to be deployed in reality one day. Yes, support for building a DMM solution that integrates well with an operator's architecture is a valid point. The framework could also be used to identify gaps in available protocols and architectures, not only mobility protocols, but also transport network related components, e.g. BGP, SDN technology, LISP, MPLS, etc. Closing these gaps and interfacing the mobility control plane with the transport network control plane enables suitable solutions for DMM. > >Perhaps one could add in sect. 4.1/4.2 that within MN in Fig. 2 and Fig.3 the >corresponding FEs FE_MU_U and FE_MU_C are not included since for PMIP6 >they reside in MAG ... this surely will become clear from the appendices A1/A2 >later on. True, the mobile host components have not been captured in these two figures as the focus was on the placement of the DMM-specific functions. But you have a point here, we should at least clarify this in the test. Thanks for spotting this. > >If I remember correctly it was agreed that both framework documents (i.e. >compared to http://tools.ietf.org/id/draft-chan-dmm-framework-03.txt) with >their different way of abstraction can complement each other and should >continue, right? Yes, they can be considered complementary. Hope both can be useful and support the specifications of the DMM group by identifying required protocol functions and interfaces for both, mobility protocols and transport network technology. Thanks again for your feedback, marco > >Thanks! > >Best regards >Dirk > >-----Original Message----- >From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of >Marco Liebsch >Sent: Sonntag, 27. Oktober 2013 22:02 >To: dmm@ietf.org >Subject: [DMM] DMM framework > >Folks, > >during my presentation at last IETF about http://www.ietf.org/id/draft-liebsch- >dmm-framework-analysis-02.txt, >around 20 people indicated interest in working on a framework. > >We think this framework, the described functional entities and associated >reference points to enable unicast DMM is mature. The original idea of this >framework was to be mobility protocol-agnostic and identify components of >available transport network technology, including SDN technology, to >complement mobility protocols and enable optimized DMM operation. Such >optimization we see in terms of transport costs, routing path, latency, etc. > >We'd appreciate any comments and contributions to the framework. Please also >refer to the slides from last meeting to recall the status of the work. > >http://www.ietf.org/proceedings/87/slides/slides-87-dmm-11.pdf > >marco > > > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
