Re: [DMM] DMM Interim call #2 - agenda forming

["Templin, Fred L" <[e-mail]>]

Hi Sri,

I thumbed through the document, but will do a more careful read
and get back to you. One aspect that the two proposals have in
common is the use of an internal instance of BGP to keep track
of mobile network prefixes while advertising only one or a few
aggregated network prefixes to the outside world. AERO (and its
predecessor IRON) have been doing that for a long time, having
learned the lessons from the Connexion-By-Boeing experience.

Thanks - Fred
[e-mail]

> -----Original Message-----
> From: Sri Gundavelli (sgundave) [mailto:[e-mail]]
> Sent: Wednesday, September 10, 2014 5:14 PM
> To: Sri Gundavelli (sgundave); Templin, Fred L; [e-mail]
> Cc: Dapeng Liu; [e-mail]
> Subject: Re: [DMM] DMM Interim call #2 - agenda forming
> 
> Hi Fred,
> 
> Looking at other solution alternative, there is this proposal from
> Satoru-san.
> 
> http://www.ietf.org/id/draft-matsushima-stateless-uplane-vepc-03.txt
> 
> Will be good to know your views on how you see this approach compare with
> Aero.
> 
> 
> Regards
> Sri
> 
> 
> 
> On 9/10/14 4:25 PM, "Sri Gundavelli (sgundave)" <[e-mail]> wrote:
> 
> >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.
> >
> >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.
> >
> >
> >Regards
> >Sri
> >
> >
> >
> >