[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] MPLS with different types of mapping
Iljitsch, this is a non-starter. There is no way ISPs will do MPLS
with each other. This is a huge (read: enormous) deployment barrier.
Some points:
1) MPLS is not fairly easy to deploy. You need to deploy a label
binding protocol from
every source site to every destination site. The "LISP new code"
is only in CE routers.
And there are wars between vendors on which is the best label
binding protocol to use.
2) Modifying BGP in all routers from a source site to a destination
site is a non-starter.
How is this incrementally deployable?
3) Not all network devices in the universe support MPLS. So you'll
have to figure a way to
jump over them.
4) IXCs don't and won't support MPLS.
5) You still have the same problem LISP does where you need to solve
upgraded sites talking
to legacy sites.
6) There is no overhead problem, we have plenty of bandwidth and MTU
to encapsulate. IPsec
based VPNs can atest to this.
7) The number of labels required it the number of sites times the
number of ETRs across the
entire Internet. You just built flat routing with flat addressing.
Label stacking can help
but you still get choke points. More choke points then has been
claimed (but unproven)
from the comments people make about LISP-ALT.
Dino
On Feb 6, 2008, at 12:59 PM, Iljitsch van Beijnum wrote:
Hi all,
I'm a bit behind on the recent discussions, but I want to throw out
a new idea. Please let me know whether you would like to see this
worked out in detail. (Yes/no in private mail is acceptable, as is
discussion on the list, of course.)
LISP is prominently on the table along with a variety of mapping
mechanisms. However, LISP suffers from a number of issues:
- requires new code and new ways of doing things
- incremental deployment looks hard
- ITR only gets to choose destination ETR, not alternative ways to
get there
- packet overhead is relatively large
What I propose is use MPLS instead. The MPLS equivalent of the ITR/
ETR functions are widely available in implementations today. MPLS
has the potential to have relatively little packet overhead, and it
allows for the possibility to specify paths rather than just exit
points. Because MPLS uses a label rather than a tunnel endpoint
address, it's much easier to decapsulate packets at arbitrary
locations rather than at one exactly specified point.
It's fairly easy to deploy MPLS today and put labels on packets when
they enter an ISP network, tunnel them through the core and pop the
label at a border router and egress the packet from the AS.
Next step would be something along the lines of distributing labels
in eBGP between consenting neighboring ASes, so that AS A can tell
AS B to put label L on packets towards prefix X, so that B's ingress
router doesn't have to do a full table lookup, either. Fairly boring
stuff.
But it gets more interesting if we give sources (could be site exit
routers or middleboxes, but ideally source hosts) the ability to put
a label stack on packets. That would work like this: at some point,
a source decides that it's sending so many packets to a destination
that it's useful to make these packets go through the core faster,
so it sends out a bubble packet. This is an IP packet with as its
destination address the destination in question, preceded by an MPLS
header with a special "bubble" label value. If the ISP doesn't
support this mechanism, the packet is simply dropped and nothing
happens. (Remember, this packet is not part of the ongoing
communication with the destination.) If the ISP supports the
mechanism, it returns to the source a set of label stacks with
priorities. The source now encapsulates packets to the destination
in one of the label stacks. It monitors return traffic to see if the
path works, and switches to a different one if it doesn't. (So this
requires state, want this to happen close to the source.) The source
can then send a packet that has one of the thusly discovered label
stacks followed by a bubble to discover label stacks for paths
through the next AS. And so on until it knows a full path or
possibly a number of full paths.
This mechanism allows for multihoming and network (even host?)
mobility by having a destination declare that it's currently
residing at an alternative address. The source then sends a bubble
for that address, but when it has a full path, it encapslates
packets with the original destination address using the MPLS stack
for the path towards the care of address.
The thing that I really like about this is that it allows for a
source to find different paths towards the same destination, which
gives the host ways to optimize its communication that don't exist
today.
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg