Subject: RE: Basic LDP Question

From: Shahram Davari <[email-masked]>
Date: Fri, 31 May 2002 12:06:31 -0700

This is not about OAM debate. It is about security. If you are allergic to this name let's call it "maintenance" or "X" or anything you like. What will you do in your VPN network to make sure that a customer's traffic is not forwarded to wrong destination? You need "X" don't you? 

-Shahram

> -----Original Message-----
> From: Giles Heron [mailto:[email-masked]]
> Sent: Friday, May 31, 2002 4:00 PM
> To: Shahram Davari
> Cc: 'Yakov Rekhter'; [email-masked]'; [email-masked]'
> Subject: RE: Basic LDP Question
> 
> 
> On Fri, 2002-05-31 at 18:39, Shahram Davari wrote:
> >  
> > > > in IP also you can do ACL.
> > > 
> > > yes, but it has its own cost/complexity.
> > 
> > Sure, but using LDP you are forced to run some kind of OAM, 
> to detect
> > mis-config of LSRs. So nothing is gained. The 
> cost/complexity of filtering is
> > replaced with cost/complexity of OAM.
> 
> please let's not turn this into yet another MPLS OAM debate.
> 
> Giles
> 
> > 
> > -Shahram
> > 
> -- 
> =================================================================
> Giles Heron    Principal Network Architect    PacketExchange Ltd.
> ph: +44 7880 506185              "if you build it they will yawn"
> =================================================================
>

---

From: Giles Heron <[email-masked]>
Date: 31 May 2002 20:12:48 +0000

no - I don't need "X".

and yes - this is the OAM debate!!!

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 31 May 2002 21:20:30 +0200

> This is not about OAM debate. It is about security. If you are allergic to this name let's call it "maintenance" or "X" or anything you like. What will you do in your VPN network to make sure that…

You need this both for LDP LSP as well for any IP tunneling as well to
make sure your PE-PE tunnel whatever it can be is up & running and your
VPN customers can in fact communicate. Sure we could argue long about
that one but I don't think this is really significant issue any more.
See lsp-ping draft if you have doubts :).

As to the original question from the real deployment point of view there
are three main reasons:

A) performance and availability of MPLS encapsulation versus IP
encapsulation. AFAIK most widely shipping boxes require an extra
hardware to do IP encapsulation at an acceptable rate while MPLS
encapsulation is supported at line rate much wider.

B) Overhead 20 bytes (or more if key is used) versus 4 is from a
practical point of view a big difference. Even with extra 4 bytes the
headache of MTU problems still exists.

C) Loadbalancing in the core ... See when you encapsulate all of your
PE-PE traffic in one IP header, the FIB hash will be identical to all
VPN customers residing on those PEs hence all the packets will take the
same path. This is very bad indeed. In MPLS we can build the hash based
on labels or even look higher at the original VPN IP packet so the
distribution of VPN flows in the core is much more larger. 

D) Security or I should rather say protection of data integrity.

Rgs,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 31 May 2002 21:34:20 +0200

Hu Juha,

Currently deployed hardware & software. Besides the whole beauty to use
pure IP encapsulation is that P boxes just do IP forwarding and don't
have to do anything special. Clearly taking into account l2tp session
does not meet those conditions.

R.

> [email-masked] wrote:
> 
> Robert Raszuk writes:
> 
> what would prevent you from taking into account l2tp session id when
> calculating the hash?
> 
> -- juha

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 31 May 2002 21:41:46 +0200

Very true statement indeed :) :) ...

Thx Juha,

Robert

>  > Currently deployed hardware & software.
> 
> your current router hardware can't do many other things either, like
> learning mac addresses.  so when you re-spin it, you could also consider
> adding real support for ip tunneling for those who don't like the
> complexity of mpls control plane.
> 
> -- juha

---

From: [email-masked]
Date: Fri, 31 May 2002 22:31:07 +0300

-- juha

---

From: [email-masked]
Date: Fri, 31 May 2002 22:39:51 +0300

-- juha

---

From: Ajay Simha <[email-masked]>
Date: Fri, 31 May 2002 23:15:02 -0400 (EDT)

On Fri, 31 May 2002 [email-masked] wrote:

The point is MPLS effectively decouples the forwarding portion from the
routing. This makes MPLS a service enabler. For instance I did not see anyone
mention things like QoS transparency that MPLS can achieve. Sure you can
monkey around with IP to make IP have everything that MPLS has. May be even a
fixed length tag and call it something else :).

Why do it when this extension already exists as an IETF based standards where
folks like us can debate issues and come up with solutions that are acceptable
to most?

-ajay

>:Robert Raszuk writes:
>:
>: > Currently deployed hardware & software.
>:
>:your current router hardware can't do many other things either, like
>:learning mac addresses.  so when you re-spin it, you could also consider
>:adding real support for ip tunneling for those who don't like the
>:complexity of mpls control plane.
>:
>:-- juha
>:

--