Hi Sri, Thanks for the balanced reply, and see below for some responses:
> -----Original Message----- > From: Sri Gundavelli (sgundave) [mailto:[email protected]] > Sent: Wednesday, September 10, 2014 4:26 PM > To: Templin, Fred L; [email protected] > Cc: Jouni Korhonen; Dapeng Liu; [email protected] > Subject: Re: [DMM] DMM Interim call #2 - agenda forming > > Fred, > > I'm not suggesting Aero vs MIP debate. IMO, its simply not worth it. Each > of the protocols have certain properties, which helps in some use-cases > and may be inefficient for some other use-cases. But, you can make all of > them work, MIP, GTP, MOBIKE, AERO ... There is no silver bullet in any one > of them, unless some one can prove it. Some architectures are based on > fixed anchors and some such as LISP-based are based on floating anchors. > Solutions based on fixed anchors have properties that suits a SP > deployment; a single point of charging, policy enforcement, LI support, > subscriber control but looses the aspect of optimized routing path. As an > example, "I've the best optimized path for my traffic, but my operator has > no clue where my traffic gets routed out". That works very well for some > cases and does not work for some other deployments. These are all points > of debate and each have to be measures on its own merit. With AERO, as I have already mentioned it does not matter which one of possibly hundreds or thousands of AERO Servers the Client associates with. The Client can also easily change between Servers, e.g., to get better performance, or can even associate with multiple Servers, e.g., for load balancing and to reduce path stretch. AERO also has built-in route optimization where the Client itself requests an optimized route to a potential correspondent Client. But, the network does not need to honor that request, e.g., if it wants to maintain a policy enforcement point, single point of charging, etc. So, the AERO anchors could be either fixed or floating depending on the network's actual policies. > The choice of the protocol is also tied to the legacy and deployed > infrastructure. Many times its about an evolution. I do not know how many > people in this WG have been involved in the AERO protocol development, or > familiar with it, at least I'm not involved in its development. But, I'm > not against AERO or some thing else. If the discussion has to be about a > protocol selection and the approach of multiple options does not work, > then we should just only do that and call for a vote and settle that > matter. I'm suggesting an approach, where we avoid this protocol debate > and allow multiple options. I'm sure, that battle will be bitter and not > worth it. AERO has been a work-in-progress since about the 2002 timeframe. In about 2005, a simplified precursor to AERO was productized and shipped by major network equipment vendors under a different name, but it was really just a stripped down function targeted for hosts in fixed networks. Not really AERO at all, but it did include and validate the NBMA virtual link model AERO is based on. In the later 2000's and into the earlier part of this decade, AERO underwent constructive development in the IRTF RRG - again, under a different name. Then, in 2012 a first edition of AERO was published as RFC6706 through AD sponsorship. Since that time, I have continued development on the second edition as a sole author effort, but with the help of MANY contributors who have been acknowledged in the document. The second edition is now at the point where it would be good to have it brought into a working group home, which might be worth discussing at some point. Thanks - Fred [email protected] > Regards > Sri > > > > > > > > > On 9/10/14 3:47 PM, "Templin, Fred L" <[email protected]> wrote: > > >Hi Behcet and Sri, > > > >> -----Original Message----- > >> From: Behcet Sarikaya [mailto:[email protected]] > >> Sent: Wednesday, September 10, 2014 3:15 PM > >> To: Sri Gundavelli (sgundave) > >> Cc: Templin, Fred L; Jouni Korhonen; Dapeng Liu; [email protected] > >> Subject: Re: [DMM] DMM Interim call #2 - agenda forming > >> > >> Hi Sri, > >> > >> On Wed, Sep 10, 2014 at 5:01 PM, Sri Gundavelli (sgundave) > >> <[email protected]> wrote: > >> > Hi Fred, > >> > > >> > > >> > IMHO, DMM solution need to be tied to one specific protocol. We don't > >>have > >> > to battle this out and come up with one answer. Once we have > >>high-level > >> > view of the solution and the interfaces, its possible to realize those > >> > interfaces using any protocols. You call it MIP, GTP, Aero ..does not > >> > matter. The core specs can identify the interface requirements and the > >> > specific protocol documents can publish extensions to the protocols. > >>We > >> > let the deployments make the call on the protocol choice. > >> > > > > >There are points of comparison between MIP and AERO that IMHO > >should be taken under consideration. MIP has been around for a > >long time, but AERO is not exactly new either. It has its genesis > >from a long list of earlier RFCs including (in chronologic order): > > > >http://www.rfc-editor.org/rfc/rfc2529.txt > >http://www.rfc-editor.org/rfc/rfc4214.txt > >http://www.rfc-editor.org/rfc/rfc5214.txt > >http://www.rfc-editor.org/rfc/rfc5320.txt > >http://www.rfc-editor.org/rfc/rfc5720.txt > >http://www.rfc-editor.org/rfc/rfc6139.txt > >http://www.rfc-editor.org/rfc/rfc6179.txt > >http://www.rfc-editor.org/rfc/rfc6706.txt > > > >I know a lot of people throughout the IETF and other forums have > >put a tremendous amount of energy into MIP-based solutions, but > >to my understanding the archetype for those solutions is still > >based on a host that goes wandering from its home physical link > >and requires the assist of a home agent on that physical link > >to keep track of its current location. > > > >Conversely, the archetype for AERO is a router that remains > >connected to a virtual link configured over its home network no > >matter where the router moves to. That means that it does not > >matter which "agent" on the virtual link the router associates > >with, and that is why AERO has already solved the DMM problem. > > > >> These are your views. > >> Not mine for sure. > > > >I have heard you say this on multiple occasions, Behcet, and I > >am beginning to wonder if you have a better understanding of the > >situation than I do. But, I do believe solution alternatives > >should be discussed rather than just marching forward without > >considering new approaches. > > > >Thanks - Fred > >[email protected] > > > >> Regards, > >> > >> Behcet > >> > > >> > > >> > Regards > >> > Sri > >> > > >> > > >> > > >> > > >> > > >> > On 9/10/14 11:43 AM, "Templin, Fred L" <[email protected]> > >>wrote: > >> > > >> >>Hi Jouni, > >> >> > >> >>I'd like to propose a slightly different charter: > >> >> > >> >> "AERO already solves distributed mobility management and provides a > >> >> a comprehensive mobility solution for any mobile device. AERO > >>should > >> >> therefore be approved as the mobility management solution for DMM. > >> >> Publication of AERO will therefore conclude the working group's > >> >> activity." > >> >> > >> >>Can we have this on the agenda? > >> >> > >> >>Thanks - Fred > >> >>[email protected] > >> >> > >> >>> -----Original Message----- > >> >>> From: dmm [mailto:[email protected]] On Behalf Of Jouni Korhonen > >> >>> Sent: Wednesday, September 10, 2014 11:37 AM > >> >>> To: [email protected] > >> >>> Cc: Dapeng Liu; [email protected] > >> >>> Subject: Re: [DMM] DMM Interim call #2 - agenda forming > >> >>> > >> >>> > >> >>> What do you mean by no agenda? To me it clearly says we use the > >>call #2 > >> >>> for setting up the work split. > >> >>> > >> >>> - Jouni > >> >>> > >> >>> 9/10/2014 9:06 PM, Behcet Sarikaya kirjoitti: > >> >>> > Jouni, why don't we cancel this one (#2) and do the next one (#3) > >>with > >> >>> > an agenda? > >> >>> > I hope Alper can attend :-) > >> >>> > > >> >>> > Regards, > >> >>> > > >> >>> > Behcet > >> >>> > > >> >>> > On Wed, Sep 10, 2014 at 1:02 PM, Jouni Korhonen > >> >>><[email protected]> wrote: > >> >>> >> > >> >>> >> It seems I sent this to a wrong receiver.. that explains why it > >>did > >> >>>not > >> >>> >> appear on the list. > >> >>> >> > >> >>> >> - Jouni > >> >>> >> > >> >>> >> -------- Alkuperäinen viesti / Orig.Msg. -------- > >> >>> >> Aihe: DMM Interim call #2 - agenda forming > >> >>> >> Päiväys: Mon, 08 Sep 2014 23:43:24 +0300 > >> >>> >> Lähettäjä: Jouni Korhonen <[email protected]> > >> >>> >> Vastaanottaja: [email protected] > >> >>> >> CC: [email protected], Dapeng Liu > >><[email protected]> > >> >>> >> > >> >>> >> Folks, > >> >>> >> > >> >>> >> The next interim is close. Assuming there are no overwhelming > >>amount > >> >>>of > >> >>> >> comments to the re-charter text, we are ready to start setting > >>up the > >> >>> >> work split on the solution space! Remember the discussion and the > >> >>> >> minutes from the IETF#90 Friday session. No other agenda items > >>are > >> >>> >> planned for the next interim. > >> >>> >> > >> >>> >> - Jouni & Dapeng > >> >>> >> > >> >>> >> > >> >>> >> _______________________________________________ > >> >>> >> dmm mailing list > >> >>> >> [email protected] > >> >>> >> https://www.ietf.org/mailman/listinfo/dmm > >> >>> > >> >>> _______________________________________________ > >> >>> dmm mailing list > >> >>> [email protected] > >> >>> https://www.ietf.org/mailman/listinfo/dmm > >> >>_______________________________________________ > >> >>dmm mailing list > >> >>[email protected] > >> >>https://www.ietf.org/mailman/listinfo/dmm > >> > _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
