Subject: [RRG] MPLS with different types of mapping

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 6 Feb 2008 21:59:09 +0100

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 [email-masked] 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

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 06 Feb 2008 13:24:08 -0800

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 

 > - ITR only gets to choose destination ETR, not alternative ways to get

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

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 :)

 > 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.

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 7 Feb 2008 09:42:57 +0100

Hi Iljitsch,

Since MPLS encapsulation is quite light may be usefull to explore  
this direction.

Yet, I have few questions:

Would not the path set up mechanism be a big issue in inter-domain  
context?

Do we really need path set up?

Can you explain how this will help make the Internet scale larger?  
(i.e. what is the gain on the BGP tables?)

> - requires new code and new ways of doing things

We cannont re-architecture the Internet with old code ;-)
(Even using MPLS, you can partly re-use the code. )

Luigi

> - ITR only gets to choose destination ETR, not alternative ways to  
> get there
> 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.
>
> 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.
>
> 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.
>
> --

Luigi Iannone

[email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 7 Feb 2008 08:11:47 -0800

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.)
>
> 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.
>
> 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  
> 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.
>