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:dmm-boun...@ietf.org] De la part de Sri Gundavelli >(sgundave) >Envoyé : jeudi 16 octobre 2014 10:58 >À : Alper Yegin; dmm@ietf.org >Objet : Re: [DMM] Forwarding Path & Signaling Management discussion > >Alper, > >Inline Š > > >On 10/16/14 1:32 AM, "Alper Yegin" <alper.ye...@yegin.org> 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 >>dmm@ietf.org >>https://www.ietf.org/mailman/listinfo/dmm > >_______________________________________________ >dmm mailing list >dmm@ietf.org >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 dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
