Re: [DMM] Preparing for DMM future steps and rechartering
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
On 11/10/13 3:13 PM, Peter McCann peter.mcc...@huawei.com wrote:
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
Re: [DMM] Preparing for DMM future steps and rechartering
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
On 11/11/13 7:51 AM, Alexandru Petrescu alexandru.petre...@gmail.com
wrote:
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
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Preparing for DMM future steps and rechartering
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) sgund...@cisco.com wrote: 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 On 11/10/13 3:13 PM, Peter McCann peter.mcc...@huawei.com wrote: 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
Re: [DMM] Preparing for DMM future steps and rechartering
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:
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 :
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
On 11/11/13 7:51 AM, Alexandru Petrescu
alexandru.petre...@gmail.com wrote:
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
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
