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
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
Sri,
Your summary is comprehensive as it includes DHCP & IKEv2 too though they
didn't ask specifically.
For IKEv2 I see similar stuff needed for Config Payloads (for most of the
attribute types), but not sure how this would be used in FMC cases (non-3GPP
access).
--
Uma C.
-Original Mess
>
> So, in your mind how many SIR prefixes will be used in a
typical T1 operator domain?
Sri, very good question and I don't think anybody figured this yet for 5G..
> Also, how can we quantify the state that ILA introduces in
different parts
Hello Sri,
This is more about address coloring than the Liaison statement.
The approach of coloring IPv4 and IPv6 addresses/prefixes with
mobility properties.
This is about standardizing IP address address/prefix ³types". Each ³type"
has a certain behavior that the network is expected to provi
Hi Uma,
> [Uma]: SRH in the proposal not only put a sort of mobility solution (encoded
> in the SID) but also use to guide the packet through non shortest path from
> the source as needed and as listed in the SRH.
>
It would be nice to have a concrete example of how this would be used
and how SR u
There were several issues raised. I don't think fragmentation actually came up
as one of them, but that is good point.
[Uma]: Yes.
Intermediate nodes cannot fragment packets in IPv6.
…
- The proposal attempted to carve out an exception to RFC8200 for just SR and
limited use to controlled domai
Uma,
On 2/2/18, 11:07 AM, "Uma Chunduri" wrote:
>Sri,
>
>Your summary is comprehensive as it includes DHCP & IKEv2 too though they
>didn't ask specifically.
[Sri] Right, they did not ask, but those all the pieces in the puzzle.
>
>For IKEv2 I see similar stuff needed for Config Payloads (f
Alex:
> I propose you add the following draft about ND Prefix Delegation
>extensions to Neighbor Discovery:
https://tools.ietf.org/html/draft-kaiser-nd-pd-01 (it is not about
coloring the prefix, but it is about prefix delegation
options in ND)
[Sri] Do not see the relevance for adding a generic
