[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] MPLS with different types of mapping
Hi Iljitsch,
I must admit that I was thinking of using interdomain encapsulation to
be MPLS and in fact I have one idea not related to RRG but to just
labeled BGP RFC3107 but I would like to clarify few of the points you
make below:
> - ITR only gets to choose destination ETR, not alternative ways to get
> there
No matter if you use IP or MPLS encapsulation you are following IP
routing table. Of course I am assuming you are not suggesting
inter-domain internet wide RSVP-TE LSPs, but just label distribution
with LDP/labeled-BGP combination.
> the possibility to specify paths rather than just exit points.
That would be possible with path building ... see above.
> 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.
I would say this is just opposite. Label is allocated by a given
router/ETR. There is no way unless to synchronize the meaning of a label
between decapsulators for the label to mean the same in N nodes. In
fact this is why there was not one hero today to manage to come with
anycasting in MPLS :)
> 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.
That's already done today for host routes .. RFC3107.
> it's useful to make these packets go through the core faster, so it
Note that MPLS marketing used to say back in 1996 that MPLS will make
the packets go faster ... Not true ... IP lookup and MPLS lookups with
corresponding rewrites in today's routers are of the same speed.
To conclude I do not see it feasible for hosts to support MPLS ...
further I do not see this src (host or router) based path selection
flexibility you are describing and last I fail to see the reduction of
global routing table size in your proposal.
Cheers,
R.
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