(I haven't paid close attention to the list, so apologies if I'm raising old
issues.)
1. Was the term "Nomadic" discussed? To me, a nomadic thing moves around, but
in this draft, Nomadic IP addresses do not move around; they are replaced.
"Ephemeral IP Address" might convey the idea more
I support the adoption of draft-seite-dmm-rg-multihoming as. WG document.
The ability for the MAG to register multiple transport end points with the LMA
is a basic protocol semantic. How a system architecture uses this extension is
a deployment consideration.
Sri
Hi Pierrick,
I hope you know how to read.
I said noone so far said SGW should be multihomed, i.e. it should
send some of its traffic to fixed network.
In fact multihomed is wrong here as it is used for the hosts while we
are talking here about SGW or RG which have LAN and WAN side
interfaces.
Hi Jouni,
On Tue, Dec 1, 2015 at 6:41 PM, Jouni Korhonen wrote:
> As an individual contributor I support the adoption of this I-D. MCoA is a
> feature that we still lack..
>
Are you sure?
MCoA is solved in Netext Flow Mobility draft,
Behcet,
12/2/2015, 11:02 AM, Behcet Sarikaya kirjoitti:
Hi Jouni,
On Tue, Dec 1, 2015 at 6:41 PM, Jouni Korhonen wrote:
As an individual contributor I support the adoption of this I-D. MCoA is a
feature that we still lack..
Are you sure?
MCoA is solved in Netext
Hi Behcet,
This extension is for any use-case requiring a MAG to be multihomed. For sure,
multihomed RG can be one of them, but there is no reason to restrict MCoA to
this use-case.
Pierrick
> -Message d'origine-
> DeĀ : dmm [mailto:dmm-boun...@ietf.org] De la part de Behcet Sarikaya
Hi,
I have read draft-gundavelli-dmm-lma-controlled-mag-params and support it.
>From my point of view, this document would allow in-band device management,
>which can facilitate deployment of PMIP based architecture. Moreover, this
>option could be used together with notification messages, and
Hi, all,
I have been following the DMM WG and the MIP/PMIP related extensions.
I personally think the HNP-renumbering support is a necessary extension of the
basic RFC5213.
I support the adoption of this draft to be a WG work.
BR,
+---+