Sri, >> - 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
I'd say let's not deal with it in DMM WG. Or at the least, let's not tackle it in the first phase of DMM work. Otherwise we are making our life an order of magnitude harder from very beginning. Alper On Oct 16, 2014, at 11:58 AM, Sri Gundavelli (sgundave) wrote: > 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-inter >> 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
