Hi Pierrick, Yes; Typo. Its inter-controller interface.
We have to look at DMM as a mobility domain and the interactions/protocol interfaces are between the entities within that domain. The roaming is more about a business relation and about security agreements. I do not believe we need to model business relations into protocol definitions. That's more about sharing security credential and authorization. Its possible administrative boundaries are at a domain level and the controllers of each domain may have security relation with other controllers. A controller of one domain may not interface with the Data Plane entities managed by another controller, but it may interface with the controller of other domain, so that controller can interface with the Data Plane entities under its control. In this context of this work, its simply a interface between Control-Plane and User-plane entity. The focus of the discussion is more about the semantics of the interface; its about operations, information elements and the expected state changes. Sri On 10/16/14 2:16 AM, "[email protected]" <[email protected]> wrote: >Hi, > >On roaming: > >Sri, I guess you meant "inter-controller interface", right? IMU, roaming >is about coordination between controller belonging to different >administrative (or routing?) domain. > >Sri already clarified this, but I think it is important to insist on the >fact that the wort item shall specified a protocol agnostic CP/DP >interface .Then, this generic interface can be implemented using >different protocols (among them is BGP), but this is out of scope of the >work item. > >BR, >Pierrick > >>-----Message d'origine----- >>De : dmm [mailto:[email protected]] De la part de Sri Gundavelli >>(sgundave) >>Envoyé : jeudi 16 octobre 2014 10:58 >>À : Alper Yegin; [email protected] >>Objet : Re: [DMM] Forwarding Path & Signaling Management discussion >> >>Alper, >> >>Inline Š >> >> >>On 10/16/14 1:32 AM, "Alper Yegin" <[email protected]> wrote: >> >>>Hello folks, >>> >>>Here are few clarification questions and comments on the Forwarding >>>Path & Signaling Management WT discussion material (oh, maybe it's time >>>we start numbering these WTs :-) >>>http://www.ietf.org/proceedings/interim/2014/10/07/dmm/slides/slides-in >>>ter >>>im-2014-dmm-3-1.pdf >>> >>> >>>- Are we not going to support roaming? Or, even w/o roaming, I'd think >>>there'd be inter-domain signaling, e.g., DPA and DPN belonging to two >>>different networks. >> >> >>[Sri] I agree, Roaming should be supported. That's a good point. That is >>a intra- >>controller interface. >> >> >>> >>>- What is the difference between DPA and DPN? We need definitions for >>>these terms. >> >>[Sri] >>Data Plane Anchor >>Data Plane Node >> >>We had some definitions in the IETF slides that we discussed in the last >>meeting >> >> >>> >>>- Slide 8: Is this simply showing how BGP-based solutions can be >>>covered here? Or something else? >> >> >>[Sri] The interface can be realized using multiple approaches, one being >>the >>BGP-based approach, other explicit signaling based interface >> >> >>> >>>- What is the relationship between Slides 6-7-8? >> >> >>[Sri] I though we had some discussion on this in the last IETF. In the >>context of >>Forwarding path, the key point is the interface between a control plane >>entity >>and a data plane entity. >>May be Marco has a better explanation >> >> >> >>> >>>- What is a controller "type"? >> >>[Sri] In deployments there could be controller entities on function >>basis; >>Ex: Mobility Controller, Routing controller ..etc. I agree with you we >>should not >>decompose the controller, but should look at this as one single entity. >> >> >> >>> >>>- Should QoS really be part of this work? I think notŠ >> >>[Sri] There is QoS support in all mobility architecture. QoS is tied to >>subscription and a key function of the mobility gateway. The CP entity >>should >>be able to provide the QoS parameters to the DP entity >> >> >>> >>>- Why would DP be querying CP? >> >>[Sri] Keeping the interface between CP and DP flexible allows us to >>support all >>types of scenarios. Lets take a simple example of a DP node loosing >>state, >>there should be mechanism to make a query to the CP entity. >> >>> >>>- Slide 13: It's not immediately clear why we need these identifiers, >>>and how they are used. Maybe there's a solution behind them, but the >>>reader cannot get the picture. >> >>[Sri] These are described at a high-level; Subject to change. The draft >>should >>have some details on the semantics and structure. >> >> >>> >>>Thanks. >>> >>>Alper >>> >>> >>> >>> >>> >>> >>> >>>_______________________________________________ >>>dmm mailing list >>>[email protected] >>>https://www.ietf.org/mailman/listinfo/dmm >> >>_______________________________________________ >>dmm mailing list >>[email protected] >>https://www.ietf.org/mailman/listinfo/dmm > >__________________________________________________________________________ >_______________________________________________ > >Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc >pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >recu ce message par erreur, veuillez le signaler >a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >electroniques etant susceptibles d'alteration, >Orange decline toute responsabilite si ce message a ete altere, deforme >ou falsifie. Merci. > >This message and its attachments may contain confidential or privileged >information that may be protected by law; >they should not be distributed, used or copied without authorisation. >If you have received this email in error, please notify the sender and >delete this message and its attachments. >As emails may be altered, Orange is not liable for messages that have >been modified, changed or falsified. >Thank you. > _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
