Hi Dino,
> -Original Message-
> From: Dino Farinacci [mailto:farina...@gmail.com]
> Sent: Wednesday, February 07, 2018 4:35 PM
> To: Templin, Fred L
> Cc: Sri Gundavelli (sgundave) ; i...@ietf.org; dmm
>
> Subject: Re: [DMM] [Ila] Fwd: New Version Notification for
> AERO uses IPv6 Neighbor Discovery as its control-plane. Surely that is the
> most mature?
Yes when used in a layer-2 subnet. Uses in a wider scope it has NHRP
properties.
If you remember we had something called LISP-EMACS (thanks John Curran) which
we “ARPed a Map-Request over a layer 3 mul
Hi Dino,
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dino Farinacci
> Sent: Thursday, February 01, 2018 3:38 PM
> To: Sri Gundavelli (sgundave)
> Cc: i...@ietf.org; dmm
> Subject: Re: [DMM] [Ila] Fwd: New Version Notification for
&
Thank you Fred.
There is a reason for mobile architectures shifting towards CP-UP split
architecture (Ref: DMM WG documents + 3GPP CUPS), and the stated goal of
further simplification in the mobile user plane (Reference: 3GPP CT4 Study
item and 3GPP Liaison statement to DMM). Now, it will be goo
Hi, please add AERO to the list:
https://datatracker.ietf.org/doc/draft-templin-aerolink/
AERO does IPv6 ND over tunnels, and supports mobility via dynamic
neighbor cache updates the same as any IPv6 link. Use cases include
(but are not limited to):
- Enterprise mobile devices (cellphones, table
Absolutely! A programmable data plane what FPC interface is offering,
keeps the CUPS objectives.
Sri
On 2/1/18, 5:07 PM, "ila on behalf of Marco Liebsch" wrote:
>I think we should rather relax the dependency between control and data
>plane. If we treat the data plane as nodes which enforce poli
Tom,
Last I remember, we gave one “generic” and an access agnostic protocol in
the form MIPv6/PMIPv6, they never got it and never cared.
But, if you can sell it to 3GPP, this new control-plane that goes into
user-plane, I am with you. :-)
Sri
On 2/1/18, 4:57 PM, "Tom Herbert" wrote:
>O
I think we should rather relax the dependency between control and data plane.
If we treat the data plane as nodes which enforce policies (encap, recap,
re-write, etc), any c plane may suit and enforce suitable policies in the
selected data plane nodes, e.g. by utilizing the DMM group’s FPC mode
On Thu, Feb 1, 2018 at 4:38 PM, Sri Gundavelli (sgundave)
wrote:
>> One thing to add. LISP has a more mature control-plane mapping system.
>>ILA has a recent proposal for its control-plane.
>
> Mobility architectures started with a unified CP/UP approach, then the
> industry thought its a great id
> One thing to add. LISP has a more mature control-plane mapping system.
>ILA has a recent proposal for its control-plane.
Mobility architectures started with a unified CP/UP approach, then the
industry thought its a great idea to move the Control-plane out, and
reduce the state in the User-plane,
One thing to add. LISP has a more mature control-plane mapping system. ILA has
a recent proposal for its control-plane.
Dino
> On Feb 1, 2018, at 3:33 PM, Sri Gundavelli (sgundave)
> wrote:
>
> Thank you Dino.
>
> WG - Same comments for this draft. LISP is another LOC-ID proposal, with
> m
Thank you Dino.
WG - Same comments for this draft. LISP is another LOC-ID proposal, with
many common attributes (if I may say, like two twins) shared with ILA;
some differences in how the Locator (COA) and identifier (HOA) spaces are
defined/used/managed, and with one key difference of tunnelin
> ILA is one of the proposals on the table. This is not an adoption call at
> this time, but asking the WG to review and open up some discussions that
> will help IETF understand the problem/solutions, and pick the right
> solution(s) for this problem statement. If there is interest and if the
> wo
Thank you Tom and Kalyani for your submission.
WG - During the adoption of
draft-matsushima-spring-dmm-srv6-mobile-uplane, we did say that we will
consider alternative approaches for the problem statement around mobile
user-plane optimization, and that we will not limit to SRv6 as the only
option.
14 matches
Mail list logo