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

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

Hi Sri,

I had to read through this document several times since it is a very
different operational world from the "traditional" enterprise networks
I am familiar with. But, figures 3 and 6 I think show useful points of
comparison with AERO. In figure 3, for example:

  - eNodeB is the place where AERO Client would go, i.e., with AERO
    operating in "proxy" mode. Otherwise, if tunneling were allowed
    all the way to the UE then the UE would be the AERO Client
  - EPC-E is analogous to AERO Server
  - RTR is analogous to AERO Relay

In both vEPC and AERO, there can be many EPC-Es (i.e., AERO Servers)
and these can be lightweight VMs in hypervisors. We already have
several AERO Servers deployed in hypervisors within Boeing.

vEPC specifies an anycast discovery service for discovering EPC-Es,
and this same approach has already been adopted by earlier solutions
such as 6to4 [RFC3068] and 6rd [RFC5969]. AERO could easily adopt an
anycast discovery approach as well, but would be used for discovery
purposes only - after discovering the closest Server via anycast,
the Client would switch to using a unicast address of the Server so
that neighbor cache state could be established. Note that this
neighbor cache state is used instead of an explicit tunnel, since
the AERO tunnel is NBMA.

With the approach in the current version of the AERO spec, however,
the AERO Client is presented with the unicast addresses of potentially
many nearby AERO Servers. The Client can then associate with one or
more Servers simultaneously and can change between Servers if necessary,
e.g., to get better performance. So, the Client chooses the best
Server(s) to use instead of leaving it up to the vagaries of the
routing system. 

As for vEPC's RTRs, AERO can have potentially many Relays. As for
vEPC, the AERO Servers and Relays also engage in an interior BGP
routing instance to track mobile node prefixes. With AERO, however,
the BGP peerings are unidirectional from Servers to Relays. So,
the Servers only need to know about their current set of associated
Clients, while the Relays get full topology information. This is a
very simple system - all Servers establish a TCP connection with
each Relay and then simply announce and withdraw routes over the
TCP connections. Conversely, the Relays never tell the Servers
anything. Unlike vEPC, however, Servers and Relays exchange packets
via tunneling - they do not use a non-tunneled routing domain,
although I suppose they could. But, one aspect of tunneling is that
it does not matter which IP protocol version is used in the IP core
network - it could be IPv4 or IPv6.

There are data flow paths for AERO that seem different from vEPC.
For example:

  1) Client A <-> Server <-> Client B (when both Clients associate
     with the same Server
  2) Client A <-> Server A <-> Relay <-> Server B <-> Client B
     (when the Clients associate with different Servers and before
     route optimization)
  3) Client A <-> Server A <-> Server B <-> Client B (when Server
     to-Server route optimization is applied)
  4) Client A -> Server B -> Client B, and
     Client B -> Server A -> Client A when Client-to-Server route
     optimization is applied
  5) Client A <-> Client B when Client-to-Client route optimization
     is applied

With vEPC I am not sure whether options 4 or 5 are available (but
maybe option 5 is not desired because it doesn't go through a
policy enforcement point?).

Other than that, I think the way AERO manages mobile node network
prefixes is probably quite different from vEPC. AERO always uses
DHCPv6 PD to delegate at least a /64 to each mobile node, and
can also delegate shorter prefixes. The mobile node gets the
same service no matter which Server it associates with, so if
it gets prefix P from Server A it will also get prefix P from
Server B.

That is about all I was able to glean from my first read, but
certainly willing to consider further.

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
> >
> >
> >
> >