Subject: Re: [DMM] Preparing for DMM future steps and rechartering

From: Peter McCann <[email-masked]>
Date: Sun, 10 Nov 2013 23:13:44 +0000

Hi, Sri,

I think you will agree that PMIP is a control protocol for setting up
tunnels.  A tunnel implies that we are not using the destination IP
of the inner packet for routing and by definition will lead to a non-optimal
route and a bit of state on some box that can fail and lose that state.

I hope that DMM can consider other approaches such as injecting routes
from the latest L2-attachment point into the access network, which is
a truly Distributed Mobility Management protocol for getting the packets
to the mobile node.  It will lead to more optimal routes and more robust
fault-tolerant operation of the network.

I think we can continue to use the term MAG to apply to that first-hop
router which is hopefully co-located with the L2 termination point (it
may not be so in every technology depending on the extent to which that
technology has evolved to support truly Distributed operation).  Anything
that happens below the MAG (between the MAG and the L2 termination point)
should be out of scope and we should not define any protocol there and we
should discourage any separation between the two.

However, we should not require the MAG to run any form of PMIP because 
tunnels should not be required in the architecture.  We should not require
an LMA, because this would imply a central point of state maintenance and
possibility of failure.

It is fine to consider a split between CP and DP but I thought we had agreed
that any discussion of the protocol to use on such an interface would be
out of scope for this WG.  IMHO we should leave that to the Wireless & Mobile
Working Group of ONF.

Now, the proponents of OpenFlow and other CP/DP splits have argued that it is
better to centralize the algorithms such as routing protocols on a logically
centralized server or servers with a synchronized global view of the network.
I have no problem with that, in which case this centralized controller just 
needs to get notified about the MN's current attachment point, so it can install
the routes (or tunnels, if an operator wishes to use them) into the DP.  But,
the mechanisms for doing so are out of scope for the DMM WG because we are not
working on a CP/DP split.  I think it would be appropriate for the DMM WG (which
exists in the IETF, a standards body that has a long history of developing 
distributed and fault-tolerant routing protocols) to describe a more distributed 
alternative, building on foundational Internet technologies such as I-BGP, in
such a way that will bring down the costs, reduce the latency, and increase the
robustness of wireless access networks.

I actually don't think we need to define any new extensions or IEs for BGP; I
would like to read more about Ryuji's proposed extensions here.  All we need is
for the MAG to learn what IPs have been assigned to the MN, decide which of those
IPs are in the scope of the local AS, and inject routes for those prefixes to
itself.  We could work on alternative mechanisms for discovering this list of
addresses - the fundamental requirement is that we use an authenticated MN ID
(probably an NAI) as an index to lookup the set of IPs in a distributed database.
I've proposed using DNS for this but there are other alternatives.  We also need
a way to make sure the latest UPDATE gets used by all the BGP peers.  I've proposed
putting a timestamp in LOCAL_PREF but there are probably other alternatives.

It would also be nice to have a well-defined fall-back mechanism in case the MN
moves to a different AS or just too far from the original MAG, in which case the
I-BGP approach wouldn't scale.  For these cases, I think a client MIP tunnel to
an HA located in the original AS for each assigned IP address would be ideal.
The HA can behave just like the MAGs in that domain, injecting routes when MNs
establish tunnels to it so as to attract the packets to themselves (this would
be the routing equivalent of the proxy-ARP or proxy-ND mechanism that works on
just a single home link in MIPv4 or MIPv6).  We should work on mechanisms to enable
dynamic assignment of local HAs to MNs and dynamic establishment of security associations
that don't require AAA and associated round-trips to the home network.  Because the HA
is associated with the original MAG that assigned the address, this may involve
some DHCP extensions.  There is already a way to assign the HA IP address but we
will need new extensions to carry the HA credentials to the MN (maybe just an HA DNS
name so the MN can use DANE to retrieve a public key).

I think something like the path I've outlined above would make a good work plan
for the future of DMM.

-Pete

Sri Gundavelli (sgundave) wrote:
> Hi Pete,
> 
> The "D" in DMM to me is "Distributed Data Plane". Your observation on
> my antithetical approach towards "D" is true for control plane. As
> that is not aligned with the current industry direction. When the CP
> is distributed, the cost of the network goes up 10-fold. Running
> policy interfaces to every distributed node is a operational
> nightmare. We bring the CP together for orchestration and enabling
> SDN. We distribute the DP for simplifying the forwarding plane and for
> realizing an optimized routing plane. I assumed you are OK with this.
> 
>> Also, we should not require the MAG to run PMIP.
> 
> 
> I think there is a slight disconnect here. I suspect you want a CP/DP
> based access architecture. But, you want a OpenFlow interface between
> the CP and DP nodes, or may be piggyback the routing protocols along
> the lines of Ryuji's view. My proposal is not about mandating PMIP
> between CP and DP, but rather PMIP stays in the control plane between
> a MAG and LMA, but between MAG-CP and MAG-DP, it can be any interface.
> Between a MAG-CP and a MAG-DP, this could be CAPWAP for WLAN, OpenFlow
> in some other access, some other approach or routing approach. From
> this WG point of view, we can define high-level messaging
> structure/IE's and map them to the respective protocols. This is
> consistent with my approach for CAPWAP Split, or PMIP split approaches.
> Does this work for you ?
> 
> 
> Regards
> Sri
> 
> 
> 
> 
> 
> 
> 
> On 11/10/13 11:27 AM, "Peter McCann" <[email-masked]> wrote:
> 
>> Hi, Sri,
>> 
>> I think the chain of gateways you have listed is exactly the source
>> of the problem we are trying to solve, and are antithetical to the D
>> in DMM.
>> 
>> Perhaps we should stick with the term MAG, since that is what we use in
>> the IETF mobility work, and agree not to talk about what happens
>> between the L2-termination point and the MAG.  In my opinion the MAG
>> should be co-located on the L2-termination point and that is the model
>> I am mentally using.
>> 
>> Also, we should not require the MAG to run PMIP.  There have been 2
>> proposals to inject routes from the attachment point instead of
>> initiating tunnels and I think those should be in-scope.
>> 
>> -Pete

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 11 Nov 2013 15:29:55 +0000

Hi Pete,

I'm not sure, I agree with this, or understand this to be precise. I do
not know know CP (in the form of PMIP, GTP or some other protocol XYZ) can
be completely eliminated. There needs to be some interface between the
access gateway and the mobility anchor. I assumed your's, Marco's and
Ryuji's goal is for eliminating the tunnel, which I don't believe it can
be achieved, but still thought we can discuss this. IMO, its not just
about inserting a RIB route and redistributing it, but even there in DP
there is a state transfer needed  from the CP and the DP. Starting point
appears like a simple route propagation, very soon it will end up with a
bunch of state that gets moved between the two nodes.  But, may be I don't
understand the ideas clearly on eliminating CP and eliminating tunnels.
I'm not going to oppose this, I don't see this converging, IMHO.

Regards
Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 11 Nov 2013 16:51:25 +0100

Le 11/11/2013 16:29, Sri Gundavelli (sgundave) a écrit :
> Hi Pete,
>
> I'm not sure, I agree with this, or understand this to be precise. I
>  do not know know CP (in the form of PMIP, GTP or some other protocol
>  XYZ) can be completely eliminated. There needs to be some interface
>  between the access gateway and the mobility anchor. I assumed
> your's, Marco's and Ryuji's goal is for eliminating the tunnel,
> which I don't believe it can be achieved, but still thought we can
> discuss this. IMO, its not just about inserting a RIB route and
> redistributing it, but even there in DP there is a state transfer
> needed  from the CP and the DP. Starting point appears like a simple
> route propagation, very soon it will end up with a bunch of state
> that gets moved between the two nodes.  But, may be I don't
> understand the ideas clearly on eliminating CP and eliminating
> tunnels. I'm not going to oppose this, I don't see this converging,
> IMHO.

I think it may converge.

I am not sure whether we have reached a point where we can discuss
without assuming a particular protocol (i.e. neither MIP, nor BGP), but
I think we can discuss route update method vs tunnel-based method.

We can also discuss whether new functionality is needed on the mobile
entity, vs whether the first-hop router does much on its behalf
('proxy').  Which may bring in a question of whether a Mobile Host or a
Mobile Router is considered.

Effects of route updates may be too heavy on a network ('route churn')
or less so; it may depend, among several factors, on the topology and
the addressing architecture of the fixed network.

Routing protocols are highly distributed concepts, yet many include
particularly designated entities, which have particular roles (not all
routers are equal) - these could host what we expect to be more
controlling points.

Alex

> Regards Sri
>> I think you will agree that PMIP is a control protocol for setting
>>  up tunnels.  A tunnel implies that we are not using the
>> destination IP of the inner packet for routing and by definition
>> will lead to a non-optimal route and a bit of state on some box
>> that can fail and lose that state.
>>
>> I hope that DMM can consider other approaches such as injecting
>> routes from the latest L2-attachment point into the access network,
>> which is a truly Distributed Mobility Management protocol for
>> getting the packets to the mobile node.  It will lead to more
>> optimal routes and more robust fault-tolerant operation of the
>> network.
>>
>> I think we can continue to use the term MAG to apply to that
>> first-hop router which is hopefully co-located with the L2
>> termination point (it may not be so in every technology depending
>> on the extent to which that technology has evolved to support truly
>> Distributed operation).  Anything that happens below the MAG
>> (between the MAG and the L2 termination point) should be out of
>> scope and we should not define any protocol there and we should
>> discourage any separation between the two.
>>
>> However, we should not require the MAG to run any form of PMIP
>> because tunnels should not be required in the architecture.  We
>> should not require an LMA, because this would imply a central point
>> of state maintenance and possibility of failure.
>>
>> It is fine to consider a split between CP and DP but I thought we
>> had agreed that any discussion of the protocol to use on such an
>> interface would be out of scope for this WG.  IMHO we should leave
>>  that to the Wireless & Mobile Working Group of ONF.
>>
>> Now, the proponents of OpenFlow and other CP/DP splits have argued
>>  that it is better to centralize the algorithms such as routing
>> protocols on a logically centralized server or servers with a
>> synchronized global view of the network. I have no problem with
>> that, in which case this centralized controller just needs to get
>> notified about the MN's current attachment point, so it can
>> install the routes (or tunnels, if an operator wishes to use them)
>> into the DP. But, the mechanisms for doing so are out of scope for
>> the DMM WG because we are not working on a CP/DP split.  I think it
>> would be appropriate for the DMM WG (which exists in the IETF, a
>> standards body that has a long history of developing distributed
>> and fault-tolerant routing protocols) to describe a more
>> distributed alternative, building on foundational Internet
>> technologies such as I-BGP, in such a way that will bring down the
>>  costs, reduce the latency, and increase the robustness of wireless
>>  access networks.
>>
>> I actually don't think we need to define any new extensions or IEs
>>  for BGP; I would like to read more about Ryuji's proposed
>> extensions here.  All we need is for the MAG to learn what IPs have
>> been assigned to the MN, decide which of those IPs are in the scope
>> of the local AS, and inject routes for those prefixes to itself. We
>> could work on alternative mechanisms for discovering this list of
>> addresses - the fundamental requirement is that we use an
>> authenticated MN ID (probably an NAI) as an index to lookup the set
>> of IPs in a distributed database. I've proposed using DNS for this
>> but there are other alternatives.  We also need a way to make sure
>> the latest UPDATE gets used by all the BGP peers. I've proposed
>> It would also be nice to have a well-defined fall-back mechanism in
>> case the MN moves to a different AS or just too far from the
>> original MAG, in which case the I-BGP approach wouldn't scale. For
>> these cases, I think a client MIP tunnel to an HA located in the
>> original AS for each assigned IP address would be ideal. The HA can
>> behave just like the MAGs in that domain, injecting routes when MNs
>> establish tunnels to it so as to attract the packets to themselves
>> (this would be the routing equivalent of the proxy-ARP or proxy-ND
>> mechanism that works on just a single home link in MIPv4 or MIPv6).
>> We should work on mechanisms to enable dynamic assignment of local
>> HAs to MNs and dynamic establishment of security associations that
>> don't require AAA and associated round-trips to the home network.
>> Because the HA is associated with the original MAG that assigned
>> the address, this may involve some DHCP extensions.  There is
>> already a way to assign the HA IP address but we will need new
>> extensions to carry the HA credentials to the MN (maybe just an HA
>> DNS name so the MN can use DANE to retrieve a public key).
>>
>> I think something like the path I've outlined above would make a
>> good work plan for the future of DMM.
>>
>> -Pete
>>
>
> _______________________________________________ dmm mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/dmm
>
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 11 Nov 2013 16:08:05 +0000

Alex - So, the proposal is to get rid of the MIP signaling plane and
piggyback on some routing updates, or over OpenFlow ? So, what is the
result, we use a generic non-MIP interfaces and make them look like MIP
interfaces ? What is the point ? This is DMM ?

Regards
Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 11 Nov 2013 17:41:57 +0100

Sri,

Sorry if my mail was too direct.  It is not my intention to suggest
getting rid of anything.

Frankly speaking I don't know what DMM is, and I still have to review
the draft-ietf-dmm-best-practices-gap-analysis-02

Whenever one says one particular protocol I have a problem with each.
For example, but just an example, I have growing problems articulating
an explanation of the lack of MIP deployment.

Deployment, testing and prototype interest are valuable indicators.

Alex

Le 11/11/2013 17:08, Sri Gundavelli (sgundave) a écrit :
> result, we use a generic non-MIP interfaces and make them look like
> MIP interfaces ? What is the point ? This is DMM ?
>
>
> Regards Sri
>
>
>
>
> On 11/11/13 7:51 AM, "Alexandru Petrescu"
> <[email-masked]> wrote:
>
>>
>> I think it may converge.
>>
>> without assuming a particular protocol (i.e. neither MIP, nor BGP),
>> but I think we can discuss route update method vs tunnel-based
>> method.
>>
>> We can also discuss whether new functionality is needed on the
>> mobile entity, vs whether the first-hop router does much on its
>> behalf ('proxy').  Which may bring in a question of whether a
>> Mobile Host or a Mobile Router is considered.
>>
>> Effects of route updates may be too heavy on a network ('route
>> churn') or less so; it may depend, among several factors, on the
>> topology and the addressing architecture of the fixed network.
>>
>> Routing protocols are highly distributed concepts, yet many
>> include particularly designated entities, which have particular
>> roles (not all routers are equal) - these could host what we expect
>> to be more controlling points.
>>
>> Alex
>>
>>>
>
>
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 11 Nov 2013 14:10:07 -0600

I think we need a draft from Pete on this so we can all understand what is
being proposed.

Regards,

Behcet

On Mon, Nov 11, 2013 at 9:29 AM, Sri Gundavelli (sgundave) <
[email-masked]> wrote:

> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>

---

From: Peter McCann <[email-masked]>
Date: Mon, 11 Nov 2013 21:17:37 +0000

Hi, Sri,

Sri Gundavelli (sgundave) wrote:
> not know know CP (in the form of PMIP, GTP or some other protocol XYZ)
> can be completely eliminated. There needs to be some interface between
> the access gateway and the mobility anchor. 

As I said in jabber during the meeting we need to carefully define these
terms.

Let's try to use the term MAG consistently.  It means the first node that
can see IP packets from the MN.  In my mind this should be co-located with
the L2 termination point.

As for "mobility anchor" I am not sure what is your definition of that term.
If you mean some router in the network that the packets for a given MN's
assigned IP address are delivered, then that entity can change over the 
period of time the address is assigned to a given MN.  IMHO when the address
is assigned, that node should be the MAG to which the MN is attached at the
time of assignment.  You can do this by choosing the pool of addresses that
are normally routed to the MAG.  When the MN moves, the "mobility anchor"
can be changed if the routing tables are updated.

> I assumed your's, Marco's
> and Ryuji's goal is for eliminating the tunnel, which I don't believe it
> can be achieved, but still thought we can discuss this. 

If we can change the "mobility anchor" to always be the current MAG while
the MN is in the same domain (or perhaps the same part of a domain) then
there will not be a need for tunnels during that period of time.  You need
a tunnel when you move outside the domain under which routing protocols are
scalable.  This can be a client-MIP tunnel because there won't be much need
to update it, assuming the new CoA is managed in the same way by whatever
network the MN is on at that time.

> IMO, its not
> just about inserting a RIB route and redistributing it, but even there
> in DP there is a state transfer needed  from the CP and the DP. Starting
> point appears like a simple route propagation, very soon it will end up
> with a bunch of state that gets moved between the two nodes.  

MAG authenticates the MN when it attaches/moves in.  Authentication gives
an MN ID.  MN ID is used to lookup IP addresses currently assigned.  UPDATE
is generated for those IPs to attract packets to the current MAG.  Mission
accomplished.

> But, may
> be I don't understand the ideas clearly on eliminating CP and
> eliminating tunnels. I'm not going to oppose this, I don't see this
> converging, IMHO.

I think you mean the discussion will not converge, when Alex interpreted 
this to mean the routing tables won't converge... anyway, I hope we can
consider routing protocols as one way to accomplish localized mobility
management.

-Pete

>> tunnels.  A tunnel implies that we are not using the destination IP of
>> the inner packet for routing and by definition will lead to a
>> non-optimal route and a bit of state on some box that can fail and lose
>> that state.
>> 
>> from the latest L2-attachment point into the access network, which is a
>> truly Distributed Mobility Management protocol for getting the packets
>> to the mobile node.  It will lead to more optimal routes and more
>> robust fault-tolerant operation of the network.
>> 
>> technology has evolved to support truly Distributed operation).
>> Anything that happens below the MAG (between the MAG and the L2
>> termination point) should be out of scope and we should not define any
>> protocol there and we should discourage any separation between the two.
>> 
>> tunnels should not be required in the architecture.  We should not
>> require an LMA, because this would imply a central point of state
>> maintenance and possibility of failure.
>> 
>> It is fine to consider a split between CP and DP but I thought we had
>> agreed that any discussion of the protocol to use on such an interface
>> would be out of scope for this WG.  IMHO we should leave that to the
>> Wireless & Mobile Working Group of ONF.
>> 
>> Now, the proponents of OpenFlow and other CP/DP splits have argued that
>> it is better to centralize the algorithms such as routing protocols on
>> a logically centralized server or servers with a synchronized global
>> view of the network. I have no problem with that, in which case this
>> centralized controller just needs to get notified about the MN's
>> current attachment point, so it can install the routes (or tunnels, if
>> an operator wishes to use them) into the DP. But, the mechanisms for
>> doing so are out of scope for the DMM WG because we are not working on
>> a CP/DP split.  I think it would be appropriate for the DMM WG (which
>> exists in the IETF, a standards body that has a long history of
>> developing distributed and fault-tolerant routing protocols) to
>> describe a more distributed alternative, building on foundational
>> Internet technologies such as I-BGP, in such a way that will bring down
>> the costs, reduce the latency, and increase the robustness of wireless
>> access networks.
>> 
>> I actually don't think we need to define any new extensions or IEs for
>> BGP; I would like to read more about Ryuji's proposed extensions here. 
>> All we need is for the MAG to learn what IPs have been assigned to the
>> MN, decide which of those IPs are in the scope of the local AS, and
>> inject routes for those prefixes to itself.  We could work on
>> alternative mechanisms for discovering this list of addresses - the
>> fundamental requirement is that we use an authenticated MN ID (probably
>> an NAI) as an index to lookup the set of IPs in a distributed database.
>> I've proposed using DNS for this but there are other alternatives.  We
>> also need a way to make sure the latest UPDATE gets used by all the BGP
>> peers. I've proposed putting a timestamp in LOCAL_PREF but there are
>> probably other alternatives.
>> 
>> case the MN moves to a different AS or just too far from the original
>> MAG, in which case the I-BGP approach wouldn't scale.  For these cases,
>> I think a client MIP tunnel to an HA located in the original AS for
>> each assigned IP address would be ideal. The HA can behave just like
>> the MAGs in that domain, injecting routes when MNs establish tunnels to
>> it so as to attract the packets to themselves (this would be the
>> routing equivalent of the proxy-ARP or proxy-ND mechanism that works on
>> just a single home link in MIPv4 or MIPv6).  We should work on
>> mechanisms to enable dynamic assignment of local HAs to MNs and dynamic
>> establishment of security associations that don't require AAA and
>> associated round-trips to the home network. Because the HA is
>> associated with the original MAG that assigned the address, this may
>> involve some DHCP extensions.  There is already a way to assign the HA
>> IP address but we will need new extensions to carry the HA credentials
>> to the MN (maybe just an HA DNS name so the MN can use DANE to retrieve
>> a public key).
>>

---

From: Peter McCann <[email-masked]>
Date: Mon, 11 Nov 2013 21:22:34 +0000

Hi, Alex,

When it comes to injecting routes into the routing infrastructure, 
I think we have to use the "proxy" model.  It doesn't make sense for
the MN to be speaking to the access network's routing protocol.  This
means the MAG will need to authenticate the MN and check that the
IP addresses assigned to that MN ID were in fact really assigned to
that MN.  I think it can be done easily with forward/reverse DNS
lookups.

Sri, if we can make the tunnels a fall-back mechanism for use only
when the MN has moved too far to make the routing update scalable,
then yes, we can eliminate the PMIP signaling from the access network.
I think client MIP should be used when we need to fall back - especially
because there is likely to be no relationship between the previous and
new domains, other than the fact that they are both connected to the
Internet.

-Pete

Alexandru Petrescu wrote:
>> piggyback on some routing updates, or over OpenFlow ? So, what is
>> the result, we use a generic non-MIP interfaces and make them look
>> like MIP interfaces ? What is the point ? This is DMM ?
>> 
>> 
>> Regards Sri
>> 
>> 
>> 
>> 
>>> ('proxy').  Which may bring in a question of whether a Mobile Host or
>>> a Mobile Router is considered.
>>> 
>>> particularly designated entities, which have particular roles (not
>>> all routers are equal) - these could host what we expect to be more
>>> controlling points.
>>> 
>>> Alex
>>> 
>>>> 
>> 
>> 
>> 
>

---

From: Peter McCann <[email-masked]>
Date: Mon, 11 Nov 2013 21:43:50 +0000

http://tools.ietf.org/html/draft-mccann-dmm-flatarch-00

-Pete

Behcet Sarikaya wrote:
> I think we need a draft from Pete on this so we can all understand
> what is being proposed.
> 
> 
> Regards,
> 
> 
> Behcet
> 
> 
> 
> On Mon, Nov 11, 2013 at 9:29 AM, Sri Gundavelli (sgundave)
> <[email-masked]> wrote:
> 
> 
> 	Hi Pete,
> 
> the 	access gateway and the mobility anchor. I assumed your's, Marco's
> and 	Ryuji's goal is for eliminating the tunnel, which I don't believe
> it can 	be achieved, but still thought we can discuss this. IMO, its not
> in DP 	there is a state transfer needed  from the CP and the DP.
> Starting point 	appears like a simple route propagation, very soon it
> will end up with a 	bunch of state that gets moved between the two
> nodes.  But, may be I don't 	understand the ideas clearly on eliminating
> CP and eliminating tunnels. 	I'm not going to oppose this, I don't see
> this converging, IMHO.
> 
> 
> 
> 
> 	Regards
> 	Sri
> 
> 
> 
> 
> 	>of the inner packet for routing and by definition will lead to a
> 	>non-optimal 	>route and a bit of state on some box that can fail and
> lose that state. 	> 	>I hope that DMM can consider other approaches such
> as injecting routes 	>from the latest L2-attachment point into the
> access network, which is 	>a truly Distributed Mobility Management
> protocol for getting the packets 	>to the mobile node.  It will lead to
> more optimal routes and more robust 	>fault-tolerant operation of the
> network. 	> 	>I think we can continue to use the term MAG to apply to
> that first-hop 	>router which is hopefully co-located with the L2
> termination point (it 	>may not be so in every technology depending on
> the extent to which that 	>technology has evolved to support truly
> Distributed operation). Anything 	>that happens below the MAG (between
> the MAG and the L2 termination point) 	>should be out of scope and we
> should not define any protocol there and we 	>should discourage any
> separation between the two. 	> 	>However, we should not require the MAG
> to run any form of PMIP because 	>tunnels should not be required in the
> architecture.  We should not require 	>an LMA, because this would imply
> a central point of state maintenance and 	>possibility of failure. 	>
> 	>agreed 	>that any discussion of the protocol to use on such an
> interface would be 	>out of scope for this WG.  IMHO we should leave
> that to the Wireless & 	>Mobile 	>Working Group of ONF. 	> 	>Now, the
> proponents of OpenFlow and other CP/DP splits have argued that 	>it is
> 	>better to centralize the algorithms such as routing protocols on a
> 	>logically 	>centralized server or servers with a synchronized global
> view of the 	>network. 	>I have no problem with that, in which case this
> centralized controller 	>just 	>needs to get notified about the MN's
> current attachment point, so it can 	>install 	>the routes (or tunnels,
> if an operator wishes to use them) into the DP. 	>But, 	>the mechanisms
> for doing so are out of scope for the DMM WG because we 	>are not
> 	>working on a CP/DP split.  I think it would be appropriate for the DMM
> WG 	>(which 	>exists in the IETF, a standards body that has a long
> history of 	>developing 	>distributed and fault-tolerant routing
> protocols) to describe a more 	>distributed 	>alternative, building on
> foundational Internet technologies such as 	>I-BGP, in 	>such a way that
> will bring down the costs, reduce the latency, and 	>increase the
> 	>robustness of wireless access networks. 	> 	>I actually don't think we
> need to define any new extensions or IEs for 	>BGP; I 	>would like to
> read more about Ryuji's proposed extensions here. All we 	>need is 	>for
> the MAG to learn what IPs have been assigned to the MN, decide which
> 	>of those 	>IPs are in the scope of the local AS, and inject routes for
> those 	>prefixes to 	>itself.  We could work on alternative mechanisms
> for discovering this 	>list of 	>addresses - the fundamental requirement
> is that we use an authenticated 	>MN ID 	>(probably an NAI) as an index
> to lookup the set of IPs in a distributed 	>database. 	>I've proposed
> using DNS for this but there are other alternatives. We 	>also need 	>a
> way to make sure the latest UPDATE gets used by all the BGP peers.
> 	>I've proposed 	>putting a timestamp in LOCAL_PREF but there are
> probably other 	>alternatives. 	> 	>It would also be nice to have a
> well-defined fall-back mechanism in case 	>the MN 	>moves to a different
> AS or just too far from the original MAG, in which 	>case the 	>I-BGP
> approach wouldn't scale.  For these cases, I think a client MIP 	>tunnel
> to 	>an HA located in the original AS for each assigned IP address would
> be 	>ideal. 	>The HA can behave just like the MAGs in that domain,
> injecting routes 	>when MNs 	>establish tunnels to it so as to attract
> the packets to themselves (this 	>would 	>be the routing equivalent of
> the proxy-ARP or proxy-ND mechanism that 	>works on 	>just a single home
> link in MIPv4 or MIPv6).  We should work on mechanisms 	>to enable
> 	>dynamic assignment of local HAs to MNs and dynamic establishment of
> 	>security associations 	>that don't require AAA and associated
> round-trips to the home network. 	>Because the HA 	>is associated with
> the original MAG that assigned the address, this may 	>involve 	>some
> DHCP extensions.  There is already a way to assign the HA IP address
> 	>but we 	>will need new extensions to carry the HA credentials to the
> MN (maybe 	>just an HA DNS 	>name so the MN can use DANE to retrieve a
> public key). 	> 	>I think something like the path I've outlined above
> would make a good 	>work plan 	>for the future of DMM. 	> 	>-Pete 	>
> 
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 12 Nov 2013 06:13:12 +0000

Hi Pete,

>As for "mobility anchor" I am not sure what is your definition of that
>term. If you mean some router in the network that the packets for a given
>MN's

My definition of a "mobility anchor" is the traditional definition that we
are familiar with. Its the entity that's hosting the subscriber session
and that is HA in CDMA, HA in WiMAX, GGSN/PGW in GSM networks and LMA in
generic PMIP-based architectures. Now, if that entity is in the routing
path is one aspect, or relocation of the subscriber state between two such
nodes is another aspect, but eliminating that function entirely from the
network is interesting :). Probably, if the view that mobile architecture
is all about IP address continuity and hence just a routing problem, then
that may be it. 

The proposals on the table fail to acknowledge the existence of the core
service functions in mobility architecture such as Charging, LI, DPI,
Policy Š and when such constraints are removed, sure, its a host route
that does all the magic. The assumption that there will be a single node
mobility architecture and that node is nothing but either a base station
or a cell-site router is interesting, but it is fine with me.

On a lighter note, In 80's I grew up watching the old StarTrek series and
most of my pre-teen years I lived in Star ship enterprise in Andromeda
Galaxy. That first-hand experience with "Transporter", "Beam Us Up",
"Phasers", "Telepresence" Š today makes me accept any new technology that
gets beamed at me. Anchor-less mobile network is another in that list that
I can accept and live with :) :)

Regards
Sri

---

From: Peter McCann <[email-masked]>
Date: Tue, 12 Nov 2013 21:29:43 +0000

Hi, Sri,

Even if we agree that those services are necessary (and I would point out
once again that most of them are not beneficial to the end-user) I don't
think we should be architecting the network in such a way that we lose the
basic benefits of IP (shortest path routing and fault-tolerance).  We can
implement those services without taking all the packets to a central location;
maybe just the first packet or meta-information about the first packet can
be taken to an SDN controller that can make some decision and pass it down
to the user plane.

I really don't think this is such fantastic science-fiction. ;)

-Pete

Sri Gundavelli (sgundave) wrote:
>> term. If you mean some router in the network that the packets for a
>> given MN's
> 
> 
> My definition of a "mobility anchor" is the traditional definition that
> we are familiar with. Its the entity that's hosting the subscriber
> session and that is HA in CDMA, HA in WiMAX, GGSN/PGW in GSM networks
> and LMA in generic PMIP-based architectures. Now, if that entity is in
> the routing path is one aspect, or relocation of the subscriber state
> between two such nodes is another aspect, but eliminating that function
> entirely from the network is interesting :). Probably, if the view that
> mobile architecture is all about IP address continuity and hence just a
> routing problem, then that may be it.
> 
> On a lighter note, In 80's I grew up watching the old StarTrek series
> and most of my pre-teen years I lived in Star ship enterprise in
> Andromeda Galaxy. That first-hand experience with "Transporter", "Beam
> Us Up", "Phasers", "Telepresence" Š today makes me accept any new
> technology that gets beamed at me. Anchor-less mobile network is another
> in that list that I can accept and live with :) :)
> 
> 
> 
> 
> Regards
> Sri
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>>> between the access gateway and the mobility anchor.
>> 
>> As I said in jabber during the meeting we need to carefully define
>> these terms.
>> 
>> Let's try to use the term MAG consistently.  It means the first node
>> that can see IP packets from the MN.  In my mind this should be
>> co-located with the L2 termination point.
>> 
>> term. If you mean some router in the network that the packets for a
>> given MN's assigned IP address are delivered, then that entity can
>> change over the period of time the address is assigned to a given MN. 
>> IMHO when the address is assigned, that node should be the MAG to which
>> the MN is attached at the time of assignment.  You can do this by
>> choosing the pool of addresses that are normally routed to the MAG. 
>> When the MN moves, the "mobility anchor" can be changed if the routing
>> tables are updated.
>> 
>>> I assumed your's, Marco's and Ryuji's goal is for eliminating the
>>> tunnel, which I don't believe it can be achieved, but still thought we
>>> can discuss this.
>> 
>> If we can change the "mobility anchor" to always be the current MAG
>> while the MN is in the same domain (or perhaps the same part of a
>> domain) then there will not be a need for tunnels during that period of
>> time.  You need a tunnel when you move outside the domain under which
>> routing protocols are scalable.  This can be a client-MIP tunnel
>> because there won't be much need to update it, assuming the new CoA is
>> managed in the same way by whatever network the MN is on at that time.
>> 
>>> IMO, its not just about inserting a RIB route and redistributing it,
>>> but even there in DP there is a state transfer needed  from the CP and
>>> the DP. Starting point appears like a simple route propagation, very
>>> soon it will end up with a bunch of state that gets moved between the
>>> two nodes.
>> 
>> MAG authenticates the MN when it attaches/moves in.  Authentication
>> gives an MN ID.  MN ID is used to lookup IP addresses currently
>> assigned. UPDATE is generated for those IPs to attract packets to the
>> current MAG. Mission accomplished.
>> 
>>> But, may
>> I think you mean the discussion will not converge, when Alex
>> interpreted this to mean the routing tables won't converge... anyway, I
>> hope we can consider routing protocols as one way to accomplish
>> localized mobility management.
>> 
>> -Pete
>> 
>>> 
>>> 
>>> 
>>> 
>>> Regards
>>> Sri
>>> 
>>> 
>>> 
>>>> non-optimal route and a bit of state on some box that can fail and
>>>> lose that state.
>>>> 
>>>> which is a truly Distributed Mobility Management protocol for getting
>>>> the packets to the mobile node.  It will lead to more optimal routes
>>>> and more robust fault-tolerant operation of the network.
>>>> 
>>>> I think we can continue to use the term MAG to apply to that first-
>>>> hop router which is hopefully co-located with the L2 termination
>>>> point (it may not be so in every technology depending on the extent
>>>> to which that technology has evolved to support truly Distributed
>>>> operation). Anything that happens below the MAG (between the MAG and
>>>> the L2 termination point) should be out of scope and we should not
>>>> define any protocol there and we should discourage any separation
>>>> between the two.
>>>> 
>>>> agreed that any discussion of the protocol to use on such an
>>>> synchronized global view of the network. I have no problem with that,
>>>> in which case this centralized controller just needs to get notified
>>>> about the MN's current attachment point, so it can install the routes
>>>> (or tunnels, if an operator wishes to use them) into the DP. But, the
>>>> mechanisms for doing so are out of scope for the DMM WG because we
>>>> are not working on a CP/DP split.  I think it would be appropriate
>>>> for the DMM WG (which exists in the IETF, a standards body that has a
>>>> long history of developing distributed and fault-tolerant routing
>>>> protocols) to describe a more distributed alternative, building on
>>>> foundational Internet technologies such as I-BGP, in such a way that
>>>> will bring down the costs, reduce the latency, and increase the
>>>> for BGP; I would like to read more about Ryuji's proposed extensions
>>>> here. All we need is for the MAG to learn what IPs have been assigned
>>>> to the MN, decide which of those IPs are in the scope of the local
>>>> AS, and inject routes for those prefixes to itself.  We could work on
>>>> fundamental requirement is that we use an authenticated MN ID
>>>> (probably an NAI) as an index to lookup the set of IPs in a
>>>> distributed database. I've proposed using DNS for this but there are
>>>> other alternatives. We also need a way to make sure the latest UPDATE
>>>> gets used by all the BGP peers. I've proposed putting a timestamp in
>>>> LOCAL_PREF but there are probably other alternatives.
>>>> 
>>>> MAG, in which case the I-BGP approach wouldn't scale.  For these
>>>> cases, I think a client MIP tunnel to an HA located in the original
>>>> AS for each assigned IP address would be ideal. The HA can behave
>>>> just like the MAGs in that domain, injecting routes when MNs
>>>> Because the HA is associated with the original MAG that assigned the
>>>> address, this may involve some DHCP extensions.  There is already a
>>>> way to assign the HA IP address but we will need new extensions to
>>>> carry the HA credentials to the MN (maybe just an HA DNS name so the
>>>> MN can use DANE to retrieve a public key).
>>>> 
>>>> I think something like the path I've outlined above would make a good
>>>> work plan for the future of DMM.
>>>> 
>>>> -Pete
>>>>

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 13 Nov 2013 10:10:36 +0000

Hi Sri, all,
let me step in here (with some delay..) to clarify one point you raised.
Please see inline.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Sri
>Gundavelli (sgundave)
>Sent: Montag, 11. November 2013 16:30
>To: Peter McCann
>Cc: [email-masked]
>Subject: Re: [DMM] Preparing for DMM future steps and rechartering
>
>Hi Pete,
>
>I'm not sure, I agree with this, or understand this to be precise. I do not know
>know CP (in the form of PMIP, GTP or some other protocol XYZ) can be
>completely eliminated. There needs to be some interface between the access
>gateway and the mobility anchor. I assumed your's, Marco's and Ryuji's goal is
>for eliminating the tunnel, which I don't believe it can be achieved, but still
>thought we can discuss this.

My intention is not to eliminate a tunnel that exists in any of the tunnel management
protocols (aka MIP6, PMIP6, ..). My picture of DMM primarily distributes topological
anchor point for the MN's IP address(es). Forget about the C-plane for now.
Tunnels apply solely below (well, towards access) such anchor.
If we distribute them to an extreme, they are placed on radio access points and
the tunnel disappears. Then we arrive at Pete's model. If anchor points are somewhere
above, say in the backhaul, the tunnel remains at least between the anchor and some node in
the access (network based mobility mgmnt) or the MN (host based mobility mgmnt).

I think none of the proposals wants to discuss away the tunnels as per MIP/PMIP. But above
anchor level, regular routing applies to plain data packets of the U-Plane.
A key component for DMM, IMO, is how to accomplish that routing towards
the MN's current anchor point, even if the anchored IP address is topologically incorrect.
To accomplish this, my intent is to not introduce tunnels above anchor level.
So, it's not about eliminating tunnels, but it is about not introducing tunnels
where never have been tunnels before :-)

marco

> IMO, its not just about inserting a RIB route and
>redistributing it, but even there in DP there is a state transfer needed  from the
>CP and the DP. Starting point appears like a simple route propagation, very soon
>it will end up with a bunch of state that gets moved between the two nodes.  But,
>may be I don't understand the ideas clearly on eliminating CP and eliminating
>tunnels.
>>view of the network.
>>I have no problem with that, in which case this centralized controller
>>just needs to get notified about the MN's current attachment point, so
>>it can install the routes (or tunnels, if an operator wishes to use
>>them) into the DP.
>>But,
>>the mechanisms for doing so are out of scope for the DMM WG because we
>>are not working on a CP/DP split.  I think it would be appropriate for
>>the DMM WG (which exists in the IETF, a standards body that has a long
>>history of developing distributed and fault-tolerant routing protocols)
>>to describe a more distributed alternative, building on foundational
>>peers.
>>I've proposed
>>each assigned IP address would be ideal.
>>The HA can behave just like the MAGs in that domain, injecting routes
>>when MNs establish tunnels to it so as to attract the packets to
>>themselves (this would be the routing equivalent of the proxy-ARP or
>>proxy-ND mechanism that works on just a single home link in MIPv4 or
>>MIPv6).  We should work on mechanisms to enable dynamic assignment of
>>local HAs to MNs and dynamic establishment of security associations
>>is associated with the original MAG that assigned the address, this may

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 13 Nov 2013 11:51:29 +0100

Hi,

I'm also jumping into the discussion a bit late.

Without going into all the detailed discussions that have taken place
recently, I just want to share my view on the MIP-based vs routing-based
approach.

IMHO, we probably need to further look at both approaches in this group,
but with enough energy level (otherwise we risk to end up with nothing
after several years). I personally have my doubts that a distributed
routing-based approach scales in a moderately large domain (we also saw
many years ago proposals of doing mobility with routing that did not
take off because of convergence, scalability and administrative issues).
I think a MIP-based approach (network or host based) would work, though
it would imply keeping multiple anchors active for a given MN.

We believe this routing-based vs MIP-based comparison is quite
interesting, and we are actually working at UC3M on experimentally
evaluating both, so we can make a more educated statement on pros and
cons of each of them.

My two cents,

Carlos

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 13 Nov 2013 11:23:43 +0000

Carlos, 

just to clarify my view here: I do not see them as different approaches,
but in a way that the routing approach can complement mobility anchor-based
approaches (MIP-like protocols). And such routing support is needed only
in certain deployments, i.e. in case of a runtime change of the MN's anchor
while the new anchor imports the MN's IP address (binding) context to enable IP address
continuity. To enable routing the MN's downlink data to its current anchor
in the transport network above anchor level, e.g. host routes can be used.

We end up in a routing-only approach if these anchors will be distributed to an extreme
and placed e.g. on radio access points and the approach uses something else than
MIP protocols to transfer IP address context between these access points. Then we
have Pete's DMM deployment model. 

Do you agree to that view?

I think there is common understanding that DMM is a lot about deployment.
Any of those deployment models are valid. Whereas the DMM WG cannot work on all
extensions needed to enable all models, we should converge on a reasonable
set of first work items to allow operators to enable DMM in their network.

marco

>From: Carlos Jesús Bernardos Cano [mailto:[email-masked]]
>Sent: Mittwoch, 13. November 2013 11:51
>To: Marco Liebsch
>Cc: Sri Gundavelli (sgundave); Peter McCann; [email-masked]
>Without going into all the detailed discussions that have taken place recently, I
>just want to share my view on the MIP-based vs routing-based approach.
>
>IMHO, we probably need to further look at both approaches in this group, but
>with enough energy level (otherwise we risk to end up with nothing after several
>years). I personally have my doubts that a distributed routing-based approach
>scales in a moderately large domain (we also saw many years ago proposals of
>doing mobility with routing that did not take off because of convergence,
>scalability and administrative issues).
>I think a MIP-based approach (network or host based) would work, though it
>would imply keeping multiple anchors active for a given MN.
>
>We believe this routing-based vs MIP-based comparison is quite interesting, and
>we are actually working at UC3M on experimentally evaluating both, so we can
>make a more educated statement on pros and cons of each of them.
>
>My two cents,
>
>Carlos
>
>> >From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> >Sri Gundavelli (sgundave)
>> >between the access gateway and the mobility anchor. I assumed your's,
>> >Marco's and Ryuji's goal is for eliminating the tunnel, which I don't
>> >believe it can be achieved, but still thought we can discuss this.
>>
>> My intention is not to eliminate a tunnel that exists in any of the
>> tunnel management protocols (aka MIP6, PMIP6, ..). My picture of DMM
>> primarily distributes topological anchor point for the MN's IP address(es).
>Forget about the C-plane for now.
>> If we distribute them to an extreme, they are placed on radio access
>> points and the tunnel disappears. Then we arrive at Pete's model. If
>> anchor points are somewhere above, say in the backhaul, the tunnel
>> remains at least between the anchor and some node in the access (network
>based mobility mgmnt) or the MN (host based mobility mgmnt).
>>
>> I think none of the proposals wants to discuss away the tunnels as per
>> MIP/PMIP. But above anchor level, regular routing applies to plain data
>packets of the U-Plane.
>> A key component for DMM, IMO, is how to accomplish that routing
>> towards the MN's current anchor point, even if the anchored IP address is
>topologically incorrect.
>> So, it's not about eliminating tunnels, but it is about not
>> introducing tunnels where never have been tunnels before :-)
>>
>> marco
>>
>> >but even there in DP there is a state transfer needed  from the CP
>> >and the DP. Starting point appears like a simple route propagation,
>> >very soon it will end up with a bunch of state that gets moved
>> >between the two nodes.  But, may be I don't understand the ideas
>> >clearly on eliminating CP and eliminating tunnels.
>> >>up tunnels.  A tunnel implies that we are not using the destination
>> >>IP of the inner packet for routing and by definition will lead to a
>> >>optimal routes and more robust fault-tolerant operation of the network.
>> >>
>> >>termination point (it may not be so in every technology depending on
>> >>the extent to which that technology has evolved to support truly Distributed
>operation).
>> >>termination point) should be out of scope and we should not define
>> >>any protocol there and we should discourage any separation between the
>two.
>> >>
>> >>synchronized global view of the network.
>> >>I have no problem with that, in which case this centralized
>> >>controller just needs to get notified about the MN's current
>> >>attachment point, so it can install the routes (or tunnels, if an
>> >>operator wishes to use
>> >>them) into the DP.
>> >>But,
>> >>the mechanisms for doing so are out of scope for the DMM WG because
>> >>we are not working on a CP/DP split.  I think it would be
>> >>appropriate for the DMM WG (which exists in the IETF, a standards
>> >>body that has a long history of developing distributed and
>> >>fault-tolerant routing protocols) to describe a more distributed
>> >>alternative, building on foundational Internet technologies such as
>> >>I-BGP, in such a way that will bring down the costs, reduce the
>> >>latency, and increase the robustness of wireless access networks.
>> >>
>> >>for BGP; I would like to read more about Ryuji's proposed extensions here.
>> >>All we need is for the MAG to learn what IPs have been assigned to
>> >>the MN, decide which of those IPs are in the scope of the local AS,
>> >>and inject routes for those prefixes to itself.  We could work on
>> >>I've proposed using DNS for this but there are other alternatives.
>> >>We also need a way to make sure the latest UPDATE gets used by all
>> >>the BGP peers.
>> >>I've proposed
>> >>original AS for each assigned IP address would be ideal.
>> >>The HA can behave just like the MAGs in that domain, injecting
>> >>routes when MNs establish tunnels to it so as to attract the packets
>> >>to themselves (this would be the routing equivalent of the proxy-ARP
>> >>or proxy-ND mechanism that works on just a single home link in MIPv4
>> >>or MIPv6).  We should work on mechanisms to enable dynamic
>> >>assignment of local HAs to MNs and dynamic establishment of security
>> >>associations that don't require AAA and associated round-trips to the home
>network.
>> >>Because the HA
>> >>is associated with the original MAG that assigned the address, this
>> >>may involve some DHCP extensions.  There is already a way to assign
>> >>the HA IP address but we will need new extensions to carry the HA
>> >>credentials to the MN (maybe just an HA DNS name so the MN can use
>> >>DANE to retrieve a public key).
>> >>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 13 Nov 2013 12:47:48 +0100

Hi Marco,

> in the transport network above anchor level, e.g. host routes can be used.

I'm not sure I agree on this. To me this seem to already assume a
certain solution. And I'm biased because I also have some solutions in
mind :D

For example, I think we should not limit only to downlink, unless the
ingress filtering is not considered an issue (if it is not, this also
kind-of assumes a certain type of solution).

> have Pete's DMM deployment model. 

Agree, but a routing approach could also be applied even if the anchors
are not placed on the radio access points. That's why I see routing as
an alternative solution to IP mobility protocols.

> set of first work items to allow operators to enable DMM in their network.

I agree. It would be helpful to get some feedback from operators on
which deployments they have more interest on.

Thanks,

Carlos

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 13 Nov 2013 11:59:29 +0000

Please see inline, Carlos.

>Sent: Mittwoch, 13. November 2013 12:48
>To: Marco Liebsch
>> just to clarify my view here: I do not see them as different
>> approaches, but in a way that the routing approach can complement
>> mobility anchor-based approaches (MIP-like protocols). And such
>> routing support is needed only in certain deployments, i.e. in case of
>> a runtime change of the MN's anchor while the new anchor imports the
>> MN's IP address (binding) context to enable IP address continuity. To
>> enable routing the MN's downlink data to its current anchor in the transport
>network above anchor level, e.g. host routes can be used.
>
>I'm not sure I agree on this. To me this seem to already assume a certain
>solution. And I'm biased because I also have some solutions in mind :D

Not a solution, but a deployment model. The solution would dig into the
protocol bits of a selected protocol e.g. BGP to solve that. That's not what
I am writing about. I write this only to abstract the available solutions to
deployment models and see where the DMM group can do some work to
enable a variety of them.

>
>For example, I think we should not limit only to downlink, unless the ingress
>filtering is not considered an issue (if it is not, this also kind-of assumes a certain
>type of solution).

For sure not. I refrained from describing the complete sequence, as it's not
relevant for this discussion. Just trying to draw some models and see which
gaps DMM can close.

>
>>
>> We end up in a routing-only approach if these anchors will be
>> distributed to an extreme and placed e.g. on radio access points and
>> the approach uses something else than MIP protocols to transfer IP
>> address context between these access points. Then we have Pete's DMM
>deployment model.
>
>Agree, but a routing approach could also be applied even if the anchors are not
>placed on the radio access points. That's why I see routing as an alternative
>solution to IP mobility protocols.

Sure. But I am not sure that it should be the DMM group that builds a new
alternative to IP mobility. What's the gap analysis then about?
Interesting to research about, though.

>> Any of those deployment models are valid. Whereas the DMM WG cannot
>> work on all extensions needed to enable all models, we should converge
>> on a reasonable set of first work items to allow operators to enable DMM in
>their network.
>
>I agree. It would be helpful to get some feedback from operators on which
>deployments they have more interest on.

Good.

Thanks,
marco

>> >IMHO, we probably need to further look at both approaches in this
>> >group, but with enough energy level (otherwise we risk to end up with
>> >nothing after several years). I personally have my doubts that a
>> >distributed routing-based approach scales in a moderately large
>> >domain (we also saw many years ago proposals of doing mobility with
>> >routing that did not take off because of convergence, scalability and
>administrative issues).
>> >I think a MIP-based approach (network or host based) would work,
>> >though it would imply keeping multiple anchors active for a given MN.
>> >
>> >> >From: [email-masked] [mailto:[email-masked]] On Behalf
>> >> >Of Sri Gundavelli (sgundave)
>> >> >I'm not sure, I agree with this, or understand this to be precise.
>> >> >I do not know know CP (in the form of PMIP, GTP or some other
>> >> >protocol
>> >> >XYZ) can be completely eliminated. There needs to be some
>> >> >interface between the access gateway and the mobility anchor. I
>> >> >assumed your's, Marco's and Ryuji's goal is for eliminating the
>> >> >tunnel, which I don't believe it can be achieved, but still thought we can
>discuss this.
>> >>
>> >> tunnel management protocols (aka MIP6, PMIP6, ..). My picture of
>> >> DMM primarily distributes topological anchor point for the MN's IP
>address(es).
>> >> If we distribute them to an extreme, they are placed on radio
>> >> access points and the tunnel disappears. Then we arrive at Pete's
>> >> model. If anchor points are somewhere above, say in the backhaul,
>> >> the tunnel remains at least between the anchor and some node in the
>> >> access (network
>> >> I think none of the proposals wants to discuss away the tunnels as
>> >> per MIP/PMIP. But above anchor level, regular routing applies to
>> >> plain data
>> >packets of the U-Plane.
>> >> > IMO, its not just about inserting a RIB route and redistributing
>> >> >it, but even there in DP there is a state transfer needed  from
>> >> >the CP and the DP. Starting point appears like a simple route
>> >> >propagation, very soon it will end up with a bunch of state that
>> >> >gets moved between the two nodes.  But, may be I don't understand
>> >> >the ideas clearly on eliminating CP and eliminating tunnels.
>> >> >>I think you will agree that PMIP is a control protocol for
>> >> >>setting up tunnels.  A tunnel implies that we are not using the
>> >> >>routes from the latest L2-attachment point into the access
>> >> >>network, which is a truly Distributed Mobility Management
>> >> >>protocol for getting the packets to the mobile node.  It will
>> >> >>lead to more optimal routes and more robust fault-tolerant operation of
>the network.
>> >> >>
>> >> >>on the extent to which that technology has evolved to support
>> >> >>truly Distributed
>> >operation).
>> >> >>termination point) should be out of scope and we should not
>> >> >>between the
>> >> >>should not require an LMA, because this would imply a central
>> >> >>point of state maintenance and possibility of failure.
>> >> >>
>> >> >>interface would be out of scope for this WG.  IMHO we should
>> >> >>leave that to the Wireless & Mobile Working Group of ONF.
>> >> >>
>> >> >>Now, the proponents of OpenFlow and other CP/DP splits have
>> >> >>argued that it is better to centralize the algorithms such as
>> >> >>routing protocols on a logically centralized server or servers
>> >> >>with a synchronized global view of the network.
>> >> >>the mechanisms for doing so are out of scope for the DMM WG
>> >> >>because we are not working on a CP/DP split.  I think it would be
>> >> >>alternative, building on foundational Internet technologies such
>> >> >>as I-BGP, in such a way that will bring down the costs, reduce
>> >> >>the latency, and increase the robustness of wireless access networks.
>> >> >>
>> >> >>I actually don't think we need to define any new extensions or
>> >> >>IEs for BGP; I would like to read more about Ryuji's proposed extensions
>here.
>> >> >>All we need is for the MAG to learn what IPs have been assigned
>> >> >>to the MN, decide which of those IPs are in the scope of the
>> >> >>local AS, and inject routes for those prefixes to itself.  We
>> >> >>authenticated MN ID (probably an NAI) as an index to lookup the
>> >> >>set of IPs in a distributed
>> >database.
>> >> >>We also need a way to make sure the latest UPDATE gets used by
>> >> >>all the BGP peers.
>> >> >>I've proposed
>> >> >>It would also be nice to have a well-defined fall-back mechanism
>> >> >>in case the MN moves to a different AS or just too far from the
>> >> >>original MAG, in which case the I-BGP approach wouldn't scale.
>> >> >>For these cases, I think a client MIP tunnel to an HA located in
>> >> >>the original AS for each assigned IP address would be ideal.
>> >> >>routes when MNs establish tunnels to it so as to attract the
>> >> >>packets to themselves (this would be the routing equivalent of
>> >> >>the proxy-ARP or proxy-ND mechanism that works on just a single
>> >> >>home link in MIPv4 or MIPv6).  We should work on mechanisms to
>> >> >>enable dynamic assignment of local HAs to MNs and dynamic
>> >> >>associated round-trips to the home
>> >network.
>> >> >>Because the HA
>> >> >>is associated with the original MAG that assigned the address,
>> >> >>this may involve some DHCP extensions.  There is already a way to
>> >> >>assign the HA IP address but we will need new extensions to carry
>> >> >>the HA credentials to the MN (maybe just an HA DNS name so the MN
>> >> >>can use DANE to retrieve a public key).
>> >> >>

---

From: Brian Haberman <[email-masked]>
Date: Wed, 13 Nov 2013 10:26:26 -0500

Hi Pete,
     Speaking with no hat on...

> I really don't think this is such fantastic science-fiction. ;)

The degree to which this is science fiction really depends on what scope
you think these host routes will have in the routing system.

* Are you assuming mobility within a single enterprise or Autonomous System?

* Limited mobility within a consortium of networks?

* Is this global mobility for any/all nodes?

Regards,
Brian

---

From: Peter McCann <[email-masked]>
Date: Wed, 13 Nov 2013 15:39:46 +0000

Hi, Brian,

Brian Haberman wrote:
>> Even if we agree that those services are necessary (and I would point 
>> out once again that most of them are not beneficial to the end-user) 
>> I don't think we should be architecting the network in such a way 
>> that we lose the basic benefits of IP (shortest path routing and 
>> fault-tolerance).  We can implement those services without taking all 
>> the packets to a central location; maybe just the first packet or 
>> meta-information about the first packet can be taken to an SDN 
>> controller that can make some decision and pass it down to the user 
>> plane.
>> 
> The degree to which this is science fiction really depends on what 
> scope you think these host routes will have in the routing system.
> 

Yes, at the most this will be one AS.

> * Limited mobility within a consortium of networks?

No.  At the most this will be one AS, possibly less depending on scalability.

> * Is this global mobility for any/all nodes?

No.  I think global mobility should be handled with client MIP because we
should not assume any relationship between previous/next visited networks.

The Boeing experiment (not science fiction, but also not scalable) tried
global mobility with BGP:

Dul, A., "Global IP Network Mobility using Border Gateway Protocol (BGP)," Available at: http://quark.net/docs/Global_IP_Network_Mobility_using_BGP.pdf

This obviously wouldn't work for billions of MNs.  But, with DMM people
are starting to realize that MNs don't need completely stable global addresses
that live forever.  So I think DMM should focus on localized mobility management.

-Pete

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 13 Nov 2013 17:02:33 +0100

Le 13/11/2013 16:39, Peter McCann a écrit :
> Hi, Brian,
>
> Brian Haberman wrote:
>> Hi Pete, Speaking with no hat on... On 11/12/13 4:29 PM, Peter
>> McCann wrote:
>>> Hi, Sri,
>>>
>>> Even if we agree that those services are necessary (and I would
>>> point out once again that most of them are not beneficial to the
>>>  end-user) I don't think we should be architecting the network in
>>>  such a way that we lose the basic benefits of IP (shortest path
>>>  routing and fault-tolerance).  We can implement those services
>>> without taking all the packets to a central location; maybe just
>>>  the first packet or meta-information about the first packet can
>>>  be taken to an SDN controller that can make some decision and
>>> pass it down to the user plane.
>>>

I agree.

In search of a qualifying metric the number of ASes is very good.

If need to go in further detail (sci-fi?) one may also consider metrics
such as the level of aggregation of prefixes in the addressing
architecture, and the IP distance between two Access Routers (not the
geographical distance).

I assume with fully hierarchical addressing, and small IP distance
between ARs may lead to acceptance of route updates on that scale.

(in the Connexion by Boeing test case the IP distance between ARs is
known to be very low although spanning wide geographical areas - no
route churn).

Alex

> No.  I think global mobility should be handled with client MIP
> because we should not assume any relationship between previous/next
> visited networks.
>
> The Boeing experiment (not science fiction, but also not scalable)
> tried global mobility with BGP:
>
> Dul, A., "Global IP Network Mobility using Border Gateway Protocol
> (BGP)," Available at:
> http://quark.net/docs/Global_IP_Network_Mobility_using_BGP.pdf
>
> This obviously wouldn't work for billions of MNs.  But, with DMM
> people are starting to realize that MNs don't need completely stable
>  global addresses that live forever.  So I think DMM should focus on
>> Regards, Brian

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 13 Nov 2013 14:43:39 -0600

As for the next steps, my suggestion is that Jouni posts a draft charter
based on the slide he showed in Vancouver where different pieces of a dmm
solution was listed.

We can have email discussions based on that proposal and hopefully come to
a consensus in a reasonable amount of time.

However, Jouni did not post his slides in the proceedings, I checked all
the presentations and the chair's slides are not there. So maybe the first
step should be that Jouni posts his slides so we can have a look.

Regards,

Behcet

---

From: Brian Haberman <[email-masked]>
Date: Wed, 13 Nov 2013 15:53:28 -0500

Rather than sink into a re-chartering discussion, I would like the WG to
focus on completing the existing work items.  It was suggested that an
interim (or 2) get set up to work on these items.  Please focus on this
rather than re-chartering.

Regards,
Your friendly AD

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 13 Nov 2013 15:01:40 -0600

Hi Brian,

I personally think that Interim(s) would not work for dmm. Only a few
people could go to such meetings. Most of us already have a heavy travel
schedule, squeezing another trip seems not so reasonable.

Regards,

Behcet

---

From: Brian Haberman <[email-masked]>
Date: Wed, 13 Nov 2013 16:04:32 -0500

I never said they had to be face-to-face meetings.  It is completely
acceptable to hold virtual (on-line) meetings.

Regards,
Brian

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 14 Nov 2013 01:02:47 +0100

Hi Marco,

Thanks for the discussion. Please see inline below.

> enable a variety of them.

Well, I'm not sure about that. To me, keeping always a single anchor by
effectively moving the it using a routing approach is a different
solution that using multiple distributed anchors, and keeping old ones
while there active communications ongoing (and using more "optimal" ones
for new communications).

> relevant for this discussion. Just trying to draw some models and see which

OK.

> Interesting to research about, though.

Agree.

Thanks,

Carlos

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 14 Nov 2013 05:22:08 +0000

Hi Marco,

>tunnel management
>points and

Ok. 

Distributing topological anchor points at the access edge can be done
today without any new standards extensions. This is more about deployment
and selection of a gateway at the access edge. But, any time the MN moves
and attaches to a different point in the network, that tunnel and the CP
is expected to be there between the previous home-anchor and the current
access-anchor. But, here, the proposals hide the tunnel (at the initial
attachment point and what can be argued as a home link and which is fine),
but when the MN moves the session is re-anchored to a different gateway
with a churn in the routing infrastructure and with major impact to policy
plane. So, there is no tunnel and there is no CP in this model.

>MIP/PMIP. But above

:) If you can show this working without re-anchoring the session to a
different gateway, then I will agree. You see this from the point of view
of IP routing, but I'm looking for that subscriber session which I'm not
able to find.
 
Tunnels hide the topology and make that reachability work; it gives me a
stable anchor point that my operator can manage my session.

Regards
Sri

---

From: Peter McCann <[email-masked]>
Date: Thu, 14 Nov 2013 13:19:22 +0000

Hi, Marco, Sri,

I think that Marco's analysis works, in the sense that it places both
classes of solutions within a cohesive framework.  I am more doubtful,
however, that the two kinds of solutions would co-exist in the same
access network, as they both seem to implement a kind of local mobility
management.

Yes, Sri, I think this is a "re-anchoring" if we define the anchor as
the point to which IP packets are delivered by the routing infrastructure.
I don't see why you say there is no control plane; I can still have an
SDN-style network with a separate controller making policy decisions.
It is true that there is no single router that handles the user's traffic
for the life of the IP session, but I thought the point of DMM was to get
rid of such scalability and fault bottlenecks.

I am a little confused as to what is your definition of a control plane.
It seems you apply this term to the LMA, but in today's specs the LMA
is a combined CP/DP entity.

-Pete

Sri Gundavelli (sgundave) wrote:
>> primarily distributes topological anchor point for the MN's IP
>> address(es). Forget about the C-plane for now.
>> remains at least between the anchor and some node in the access
>> (network based mobility mgmnt) or the MN (host based mobility mgmnt).
> 
> 
> Ok.
> 
> today without any new standards extensions. This is more about
> deployment and selection of a gateway at the access edge. But, any
> time the MN moves and attaches to a different point in the network,
> that tunnel and the CP is expected to be there between the previous
> home- anchor and the current access-anchor. But, here, the proposals
> hide the tunnel (at the initial attachment point and what can be
> argued as a home link and which is fine), but when the MN moves the
> session is re- anchored to a different gateway with a churn in the
> routing infrastructure and with major impact to policy plane. So,
> there is no tunnel and there is no CP in this model.
> 
> 
>> 
>> packets of the U-Plane. A key component for DMM, IMO, is how to
>> accomplish that routing towards the MN's current anchor point, even if
>> the anchored IP address is topologically incorrect. To accomplish this,
>> my intent is to not introduce tunnels above anchor level. So, it's not
>> about eliminating tunnels, but it is about not introducing tunnels
> different gateway, then I will agree. You see this from the point of
> view of IP routing, but I'm looking for that subscriber session which
> I'm not able to find.
> 
> Tunnels hide the topology and make that reachability work; it gives me
> a stable anchor point that my operator can manage my session.
> 
> 
> Regards
> Sri
> 
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 14 Nov 2013 15:28:34 +0000

Hi Pete,

My definition of CP is between the AG and the MA, what is out there today.
Now, if there is a functional split of CP and DP on any entity, and if
there is a interface between those two in the form of some CP interface,
then I don't have a term for that interface. We can probably agree that
CP/DP split approaches are outside the scope of this discussions.

> I can still have an SDN-style network with a separate controller making
>policy decisions.

Ok. I understand now. Only the DP is moved, but the session CP state is
anchored on a central node ? I call that central node as a mobility
anchor, now if that anchor is in the data path or not is one
consideration. But, functionally, there is still a mobility anchor.

Regards
Sri

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 15 Nov 2013 09:56:42 +0000

Hi Sri,

>From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
>Sent: Donnerstag, 14. November 2013 06:22
>To: Marco Liebsch; Peter McCann
>Cc: [email-masked]
>Subject: Re: Preparing for DMM future steps and rechartering
>
>Hi Marco,
>
>
>>
>Distributing topological anchor points at the access edge can be done today
>without any new standards extensions. This is more about deployment and
>selection of a gateway at the access edge. But, any time the MN moves and
>attaches to a different point in the network, that tunnel and the CP is expected
>to be there between the previous home-anchor and the current access-anchor.
>But, here, the proposals hide the tunnel (at the initial attachment point and what
>can be argued as a home link and which is fine), but when the MN moves the
>session is re-anchored to a different gateway with a churn in the routing
>infrastructure and with major impact to policy plane. So, there is no tunnel and
>there is no CP in this model.

Depends. I assume that the session you describe is a mobility session (binding ID-Locator),
not a data session. If the mobility session remains anchored at the previous attachment point,
there will be a tunnel towards the new attachment point, which may serve
as MAG. Optionally, the new attachment point may provide a new anchor and an additional
mobility session, hence an additional HoA, which depend on the MN to handle multiple
IPs. Other approach would imply moving the MN's mobility session from the previous anchor/point of attachment
to the new one. Then there is at least no tunnel needed to forward packets from the previous
anchor to the new one. But the anchored HoA or HNP at the new anchor is topologically
incorrect. That means the routing plane above anchors can take care about delivering
downlink packets to the MN's current anchor. Agree that that's an impact to the routing policy
plane, but a valid approach to achieve more optimal routes. 

>>So, it's not about eliminating tunnels, but it is about not introducing
>>tunnels where never have been tunnels before :-)
>
>
>:) If you can show this working without re-anchoring the session to a different
>gateway, then I will agree. You see this from the point of view of IP routing, but
>I'm looking for that subscriber session which I'm not able to find.

Without re-anchoring the previous mobility session at the new anchor means
the previous anchor remains involved in the packet delivery. I was talking about
the case where the previous mobility session will be transferred and anchored at the new
mobility anchor. Only that enables short delivery paths, as the anchor points of the
MN's IP address is close to the MN. But in that case the routing plane needs
to support packet delivery for that MN. So, either by introducing tunnels in the
routing plane (e.g. according to LISP), which I'd like to avoid. Or by using per-host routes.
Or by using address translation to a routable address, which delivers the packet
to the mobile's current anchor. 

>
>Tunnels hide the topology and make that reachability work; it gives me a stable
>anchor point that my operator can manage my session.

Sure, anchors as well as tunnels from that anchor to a locator should be kept. After
anchor relocation, the new anchor takes care about tunnel management to
deliver packets to the current MN's location. However, the routing plane above
anchor level may take care about delivering packets to the current anchor, which
is a prerequisite to allow the new anchor doing his job.

Greetings,
marco

---

From: Peter McCann <[email-masked]>
Date: Fri, 15 Nov 2013 20:13:12 +0000

Hi, Sri,

> My definition of CP is between the AG and the MA, what is out there

The "control plane" is an abstract term for a collection of entities,
one of which exists in each AG and MA.

> Now, if there is a functional split of CP and DP on any entity,
> and if there is a interface between those two in the form of some CP
> interface, then I don't have a term for that interface. We can probably
> agree that CP/DP split approaches are outside the scope of this
> discussions.

I would call that a CP-DP interface and I agree it's out of scope of
DMM.

In particular, PMIP is not a CP-DP interface protocol.

>> I can still have an SDN-style network with a separate controller
>> making policy decisions.
> 
> Ok. I understand now. Only the DP is moved, but the session CP state
> is anchored on a central node ? I call that central node as a mobility

There can be (but does not have to be) a centralized control plane
element that has a global view of all the MNs currently attached
and keeps track of which MAG they are currently on.  From the point
of view of DMM, that's just an operational detail of a particular
deployment.  We certainly should not require the data plane traffic
to go through that node, and we should allow for mechanisms other
than tunneling to redirect packets to the new MAG after a mobility
event.  The centralized control plane (if it exists) can be involved
in setting up that redirection state, or a distributed routing 
protocol can take care of it.

-Pete

>> the point to which IP packets are delivered by the routing
>> infrastructure. I don't see why you say there is no control plane; I
>> can still have an SDN-style network with a separate controller making
>> policy decisions. It is true that there is no single router that
>> handles the user's traffic for the life of the IP session, but I
>> thought the point of DMM was to get rid of such scalability and fault
>> bottlenecks.
>> 
>> I am a little confused as to what is your definition of a control
>> plane. It seems you apply this term to the LMA, but in today's specs
>> the LMA is a combined CP/DP entity.
>> 
>> -Pete
>> 
>>>> address(es). Forget about the C-plane for now. Tunnels apply solely
>>>> below (well, towards access) such anchor. If we distribute them to an
>>>> extreme, they are placed on radio access points and the tunnel
>>>> disappears. Then we arrive at Pete's model. If anchor points are
>>>> somewhere above, say in the backhaul, the tunnel remains at least
>>>> between the anchor and some node in the access (network based
>>>> mobility mgmnt) or the MN (host based mobility
> mgmnt).
>>> 
>>> 
>>> Ok.
>>> 
>>>> plain data packets of the U-Plane. A key component for DMM, IMO,
>>>> is how to accomplish that routing towards the MN's current anchor
>>>> point, even if the anchored IP address is topologically incorrect.
>>>> To accomplish this, my intent is to not introduce tunnels above
>>>> anchor level. So, it's not about eliminating tunnels, but it is
>>>> about not introducing tunnels where never have been tunnels before
>>>> :-)
>>> 
>>> 
>>> Tunnels hide the topology and make that reachability work; it gives
>>> me a stable anchor point that my operator can manage my session.
>>> 
>>> 
>>> Regards
>>> Sri
>>>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 18 Nov 2013 01:21:57 +0000

Hi Marco,

>plane, but a valid approach to achieve more optimal routes.

Dated: 01/Aug/2011, reflecting our progress.

http://www.ietf.org/mail-archive/web/mext/current/msg04766.html

IMO, one can realize DMM by the the ways of a.) Adopting improved Gateway
Selection approaches b.) Carrying property meta-data in PIO options and
evolving the client.
Additionally, aggregating the control plane and distribute the DP is
another consideration. With this, one can realize a flat network with
optimized data plane.

We can get there with incremental extensions to the current protocols.
With the approach of allocating short lived sessions, can we not avoid
session re-anchoring and avoid impact to data plane ?

Will this work ?

>to the mobile's current anchor.

But, if the approach is to allocate short lived sessions, then why deal
with re-anchoring issue ? We can completely avoid RIB impact, avoid host
route pollution, or exporting modified locator Id to EID mapping. The
non-optimized DP lives there for a very short period after a MN migration
and for certain sessions and for reasons of global reachability.

Regards
Sri

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 18 Nov 2013 01:29:47 +0000

Hi Pete,

>protocol can take care of it.

The goal of shifting / stitching the flows on the forward path that we
choose sounds perfectly fine from the view of realizing optimized data
plane. But, we still have to show how an operator can manage the
subscriber session and enforce the policies. Without such considerations,
we cannot meaningfully evaluate the solution, IMHO

Regards
Sri

---

From: Alper Yegin <[email-masked]>
Date: Fri, 22 Nov 2013 13:12:08 +0200

Hello folks,

Using tunnels vs. propagating host routes across a domain…

The former is proven to work. The latter appears to have attractive attributes (e.g., absence of tunneling overhead, fully distributed nature, etc.), but there are also aspects that need to be addressed, such as:
- Can it scale (passing host-routes for millions of nodes even in single operator network)?
- Can it converge fast enough for seamless handovers?
- Is it practical from charging, lawful intercept, DPI, policy enforcement point of view?
- How do we deal with the case when the MN moves outside the domain? (probably we need to fall back to using a tunnel-based solution)

The host-route-based schemes need to overcome these challenges to appear as an alternative to tunnel-based solutions. I'm hoping the proponents of those scheme will show us how they handle these issues.

Maybe it'll turn out that under certain conditions host-route-based solutions work just fine (Pete was pointing at local mobility). If so, we can recognize that and tell people they can use such solutions instead of tunnel-based solutions, where applicable. 

For example: If the anchor is within an operator network it can be used (which can substitute for tunnel-based anchoring on a central HA and also on previous AR -- but not for anchoring near the corresponding network which works across the Internet). 

...

But note that, that discussion is just about  one component of DMM solution set. There are other components, which are not impacted by that discussion. Such as:
- The MN stack treating flows differently with respect to their mobility needs (assigning different types [colors/anchor type, etc] of IP addresses)
- The MN stack choosing anchors (i.e., selecting a specific anchor node based in the anchor type selection).

…

And whenever a component involves DP/CP, we should recognize that they are separable and take that into account. 

Alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 22 Nov 2013 13:15:46 +0200

Hi Pete,

> that live forever.  

Most don't, but some do. We need to account for them as well.

> So I think DMM should focus on localized mobility management.

This is not sufficient.
Think of the typical case where MN moves from cellular network of one operator to WiFi network of another operator.
This can be a physically localized, but topologically a global handover.

Alper

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 22 Nov 2013 12:47:09 +0100

Hello Alper,

In this discussion, I may be missing the 'Mobile Router vs Host' dimension.

We would use host-based routes if we need Mobile Hosts, but we'd use 
prefix-based routes if we needed Mobile Routers.

The route convergence speed and domain size scalability aspects apply 
differently.

Additionally, I would shape the question from the other point of view as 
well: is it reasonable for PMIP solution to use tunnels even if the 
mobile stays within the same domain?

Alex

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 22 Nov 2013 16:10:52 +0200

Alper,

> The host-route-based schemes need to overcome these challenges to appear as an alternative to tunnel-based solutions. I'm hoping the proponents of those scheme will show us how they handle these is…

It might be worth looking into what SPRING is doing in this domain.
The new work around source routing might have some useful assets for
our use, specifically if source routes can be added by intermediate
or border nodes.

Maybe there is something "innovative" to do, which would allow us to
go around host routes and related frequent  IGP updates. Maybe the
"innovative" thing just moves or renames the routing problem.. I do
not know :)

- Jouni

---

From: Peter McCann <[email-masked]>
Date: Fri, 22 Nov 2013 16:52:01 +0000

Hi, Alper,

All good questions.  Some comments below.

Alper Yegin wrote:
> Hello folks,
> 
> Using tunnels vs. propagating host routes across a domain...
> 
> The former is proven to work. The latter appears to have attractive
> attributes (e.g., absence of tunneling overhead, fully distributed
> nature, etc.), but there are also aspects that need to be addressed,
> such as:

I think a better way to put this question is "over what scope does it
scale?"  Clearly it should work fine over a limited scope such as the
region spanned by one pool of route reflectors.  In some deployment 
cases (such as when the MN is able to release an old address fairly 
quickly) this may be enough.

> - Can it converge fast enough for seamless handovers?

I see no reason why it can't be just as fast as a tunnel setup, if not
moreso.  You just need to propagate an UPDATE message as far as the
crossover router, and install a route into the FIB.  There is no good
reason why this would take more time than installing a tunnel state.
Some BGP implementations may need to be tuned for proper performance.

> enforcement point of view?

We shouldn't sacrifice fault tolerance and optimal routing on the
altar of these "features".  They won't be needed in every deployment,
and when they are needed, we can find ways to implement them without
forcing the traffic to a central location in an unscalable and
fault-intolerant way.

> - How do we deal with the case when the MN moves outside the domain?
> (probably we need to fall back to using a tunnel-based solution)

Yes, and I think that should be a client-based tunnel to handle the
likely situation where there is no relationship between the old and
new domains other than the fact that they are both connected to the
Internet.

> The host-route-based schemes need to overcome these challenges to
> appear as an alternative to tunnel-based solutions. I'm hoping the
> proponents of those scheme will show us how they handle these issues.

Agree further study is needed.

> Maybe it'll turn out that under certain conditions host-route-based
> solutions work just fine (Pete was pointing at local mobility). If so,
> we can recognize that and tell people they can use such solutions
> instead of tunnel-based solutions, where applicable.

Yes.

> For example: If the anchor is within an operator network it can be
> used (which can substitute for tunnel-based anchoring on a central HA
> and also on previous AR -- but not for anchoring near the
> corresponding network which works across the Internet).

True but anchoring at a CN requires cross-domain coordination for the
network-based mobility management case.

> 
> ...
> 
> But note that, that discussion is just about  one component of DMM
> solution set. There are other components, which are not impacted by
> that discussion. Such as:
> - The MN stack treating flows differently with respect to their
> mobility needs (assigning different types [colors/anchor type, etc] of
> IP addresses)

Yes we still need to have that discussion.  This can be worked out 
independently of the mechanism used by the network-based mobility
scheme.

> - The MN stack choosing anchors (i.e., selecting a specific anchor
> node based in the anchor type selection).

Yes the software in the MN still needs to handle multiple simultaneous
addresses, choosing among them, and managing their lifecycles.  The 
important feature of DMM is to enable a decoupling between the mobility
events and the address lifecycle, so that addresses can be maintained
for some time after a mobility event and new ones can be allocated when
it makes sense to do so (not forced at the time of mobility).

> ...
> 
> And whenever a component involves DP/CP, we should recognize that they
> are separable and take that into account.

Agree but with the caveat that DMM is not the right place to standardized
CP/DP interface protocols.

-Pete

---

From: Alper Yegin <[email-masked]>
Date: Sat, 23 Nov 2013 01:13:56 +0200

Hi Alex,

On Nov 22, 2013, at 1:47 PM, Alexandru Petrescu wrote:

> We would use host-based routes if we need Mobile Hosts, but we'd use prefix-based routes if we needed Mobile Routers.
> 
> The route convergence speed and domain size scalability aspects apply differently.
> 

You are right, we should also account for the mobile router. But I think spreading a specific route for a single host address and doing the same for a single prefix are pretty much the same (in terms of scalability/performance metrics).

> Additionally, I would shape the question from the other point of view as well: is it reasonable for PMIP solution to use tunnels even if the mobile stays within the same domain?
> 

It depends on the solution specifics. We cannot say "shall not use tunnels in that case". But if some solution achieves not using tunnels (assuming w/o doing some funky business), then it sounds attractive. We can look at the details.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Sat, 23 Nov 2013 14:20:43 +0200

Hi Pete,

> quickly) this may be enough.

I presume you are talking about even a subset of an operator network. 
Sure, OK, whatever it is if we can get some description of it, that'd help us understand the applicability of these approaches.

> Some BGP implementations may need to be tuned for proper performance.

We know BGP is not designed for handling many rapid changes (after all non-mobile prefixes are much more stable compared to a moving MN).
But of source that does not necessarily mean BGP cannot handle it.
I'm not a BGP expert to confirm. It may be worth running this by the routing related WGs and collect some feedback.

> forcing the traffic to a central location in an unscalable and

Sounds good. We just need to see the details.

I'm not claiming any of these points are show-stoppers. But these are points that need to be addressed in order for people to feel confident about this alternative.
After all, this whole tunneling-based MIP business was created at the beginning because we couldn't propagate host routes across the Internet.
Now if we are going to go back to host routes, then we need to understand what changed since then or what we missed at the time and decided to go down the tunneling path.

> new domains other than the fact that they are both connected to the

This sounds plausible too. It'd be good to see the details.

> network-based mobility management case.

Can you elaborate on that?

Yes.

Cheers,

Alper

---

From: Peter McCann <[email-masked]>
Date: Mon, 25 Nov 2013 14:40:26 +0000

Hi, Alper,

Alper Yegin wrote:
>>> nature, etc.), but there are also aspects that need to be
>>> addressed, such as:
>> I think a better way to put this question is "over what scope does
>> it scale?"  Clearly it should work fine over a limited scope such as
>> the region spanned by one pool of route reflectors.  In some
>> deployment cases (such as when the MN is able to release an old
>> address fairly
> Sure, OK, whatever it is if we can get some description of it, that'd
> help us understand the applicability of these approaches.

Agreed.

> We know BGP is not designed for handling many rapid changes (after all
> non-mobile prefixes are much more stable compared to a moving MN).
> I'm not a BGP expert to confirm. It may be worth running this by the
> routing related WGs and collect some feedback.

There have been studies of the basic propagation time of an UPDATE
through a BGP router.  It can be done in as little as 2.4ms if the
timers and batching are configured properly.

>> altar of these "features".  They won't be needed in every
>> deployment, and when they are needed, we can find ways to implement
>> them without forcing the traffic to a central location in an
>> unscalable and fault-intolerant way.
>> 
> 
> I'm not claiming any of these points are show-stoppers. But these are
> points that need to be addressed in order for people to feel confident
> about this alternative. After all, this whole tunneling-based MIP
> business was created at the beginning because we couldn't propagate host
> routes across the Internet. Now if we are going to go back to host
> routes, then we need to understand what changed since then or what we
> missed at the time and decided to go down the tunneling path.

We will still need (client-based) tunnels across the Internet.  We are
just trying to buy a little time for the old address (and the current
CoA) so we don't have to have over-the-air tunnel signaling on every 
change of base station.

> This sounds plausible too. It'd be good to see the details.

I think we will need some new mechanisms to enable quick establishment
of a security association with a local HA at the time a local address
is assigned.  I don't want to require RADIUS round-trips (ugh).  Other
than that this is standard MIP.

>> True but anchoring at a CN requires cross-domain coordination for
>> the network-based mobility management case.
>> 
> 

Maybe you didn't propose this, but a network-controlled CN-based anchor
would imply some kind of relationship between the visited and correspondent
networks.

>>> mobility needs (assigning different types [colors/anchor type, etc]
>>> of IP addresses)
>> 
>>> And whenever a component involves DP/CP, we should recognize that
>>> they are separable and take that into account.
>> 
>> Agree but with the caveat that DMM is not the right place to
>> standardized CP/DP interface protocols.
>> 
> 
> Yes.
> 
> Cheers,
> 
> Alper

-Pete

---

From: Alper Yegin <[email-masked]>
Date: Mon, 25 Nov 2013 17:44:26 +0200

Hi Pete,

> timers and batching are configured properly.

A reference would be good.

> CoA) so we don't have to have over-the-air tunnel signaling on every 

OK, then this is positioning the solution to be a localized mobility solution
(not localized like "NETLMM" whose locality covered the whole Internet :-)
Your approach wedges in between the L2-based solutions and MIP-based solutions.

> would imply some kind of relationship between the visited and correspondent

Our draft describes the MN-controlled case, hence CN and VN don't need to have a relationship.
We also left network-controlled case as TBD in the I-D, and that one is likely to require such a relationship.

Cheers,

Alper

---

From: Peter McCann <[email-masked]>
Date: Mon, 25 Nov 2013 15:47:48 +0000

Hi, Alper,

Alper Yegin wrote:
>>> non-mobile prefixes are much more stable compared to a moving MN). But
>>> of source that does not necessarily mean BGP cannot handle it. I'm not
>>> a BGP expert to confirm. It may be worth running this by the routing
>>> related WGs and collect some feedback.
>> 

See, e.g., "Measuring BGP Pass-Through Times" by Feldman, Kong, Maennel, and Tudor
http://www.net.t-labs.tu-berlin.de/papers/FKMT-MBPT-04.pdf

-Pete