Subject: RE: Basic LDP Question

From: [email-masked]
Date: Mon, 3 Jun 2002 11:26:06 +0100

Ajay,  Let me take you back to the point of Shahram's orginal
question.....which in essence, if I have understood it correctly, was 'what
problem/application is LDP solving/addressing that cannot be done either (i)
using IP directly or (ii) ER LSPs?'.....and which must also take a wider
pro/con analysis of the implications of using LDP-LSPs vs ER-LSPs (or IP
directly).

Please also see below.   Regards, Neil

Ajay Simha wrote 01 June 2002 04:15
 
> The point is MPLS effectively decouples the forwarding 
> portion from the
> routing.
NH=> Well I agree, this is vital and it's what is needed.  And it's
something we in Telco-land have known/used for years, ie decoupling of the
traffic carrying data-plane and its control-plane (both its own data-plane,
where appropriate, and its routing and signalling protocols).  But LDP does
nothing more than instantiate labels per hop that are locked to the IGP.
That is (i) they take the same SPF routes as the IGP would use for IP
fowarding and (ii) the LSPs change as the IGP changes.  I would argue this
is not a required behaviour for applications where LSPs are long-holding
and/or must not be affected by ad hoc routing changes or failures of routing
protocols (eg VPNs).  Further, because LDP is so tightly coupled to the IGP
then one has to introduce 'layer violations' to make it work a bit better,
eg Load-balancing using IP-level hashing......its hard to take seriously
anyone claiming this is MPLS label forwarding when one has to look at the
client/IP level (which it may not always be, ie XoverMPLS) to make
switching/forwarding decisions.

> This makes MPLS a service enabler.
NH=> I don't agree that *LDP* makes MPLS a 'service-enabler'.  Considered
against a VPN service, the behaviour noted above is not what is needed.  Now
take the fact that QoS (a pkt forwarding attribute) and survivability (an
LSP attribute) need decoupling so that per VPN QoS/availability SLAs can be
defined/measured (independent of other VPNs) and look what LDP does to
that.....it mangles then both so they can't be decoupled, and now VPN
QoS/survivability behaviour is no longer independent on a per VPN basis.
Again this is not the required behaviour for VPNs.

> For instance I 
> did not see anyone
> mention things like QoS transparency that MPLS can achieve.
NH=> How can you claim this in view of the above observations?  Further, on
what basis are you discussing QoS?  That is, unless you can automatically
fault-manage MPLS I fail to see how anyone has any basis on which to discuss
QoS with any conviction......you have to define availability 1st, since QoS
metrics *only* have relevance to the up-state, and availability is dependent
of having defects defined.  So where are the defects defined and where is
availability defined?....once you can point at these then we can
meaningfully discuss QoS, but not before.
 
> Sure you can
> monkey around with IP to make IP have everything that MPLS 
> has.
NH=> No, you have to monkey around with LDP (eg load-balancing) because it
does not provide sufficient decoupling from IP behaviour as I noted above.

> 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?
NH=> I have no problems with people defining solution's for a restricted
perspective of the problem-space if that is all they need/want from MPLS,
just so long as they don't try to stop others defining solutions which have
a more general application.  I have a strong sense that some people want to
do this....and therein lies the real problem IMO. 
> 
> -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
> >:
> 
> -- 
>

---

From: Giles Heron <[email-masked]>
Date: 03 Jun 2002 12:46:08 +0000

> switching/forwarding decisions.
[rest snipped]

not at all.

The decision as to what set of outbound interfaces to use to forward the
packet is made entirely using MPLS.

The decision as to how to hash traffic over that set of outbound
interfaces may be made entirely using MPLS (e.g. by using the next label
in the stack - if present), or may be made using information from the
next protocol layer.  Note that load balancing is an entirely local and
value-added behaviour.

Note also that load balancing using information from the next protocol
layer is a common technique in clns networks.  Many "layer 3" Ethernet
switches support IP-based load-balancing when switching traffic at
"layer 2".

Giles

-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================

---

From: Eric Osborne <[email-masked]>
Date: Mon, 3 Jun 2002 10:01:11 -0400

> pro/con analysis of the implications of using LDP-LSPs vs ER-LSPs (or IP

LDP lets you easily integrate IP and ATM; call it cell mode, call it
LC_ATM, call it IP+ATM (I'm not sure which terms are cisco
marketing-speak and which are standardized).  It's not immediately
clear to me how you could do that with IP while using the existing ATM
switch hardware and with only a control-plane upgrade.

Perhaps I've missed something, but I've not seen a response to my last
email that pointed this out, so until someone demonstrates otherwise,
I'm going to keep pointing it out. :)

LDP is also being used as the signalling protocol for p2p services, a
la the Martini draft.  IP alone can't easily do this, as you need not
only a label to transport across the IGP, but also a service label so
that the edge can demux to the proper l2 circuit.  You could do
something involving destination protocol type/port as a demux header,
but that'd be non-trivial forwarding hardware.

eric

---

From: Ajay Simha <[email-masked]>
Date: Mon, 3 Jun 2002 10:23:20 -0400 (EDT)

On Mon, 3 Jun 2002 [email-masked] wrote:

>:Ajay,  Let me take you back to the point of Shahram's orginal
>:question.....which in essence, if I have understood it correctly, was 'what
>:problem/application is LDP solving/addressing that cannot be done either (i)
>:using IP directly or (ii) ER LSPs?'.....and which must also take a wider
>:pro/con analysis of the implications of using LDP-LSPs vs ER-LSPs (or IP
>:directly).
>:
>:Please also see below.   Regards, Neil
>:
>:Ajay Simha wrote 01 June 2002 04:15
>:
>:> The point is MPLS effectively decouples the forwarding
>:> portion from the
>:> routing.
>:NH=> Well I agree, this is vital and it's what is needed.  And it's
>:something we in Telco-land have known/used for years, ie decoupling of the
>:traffic carrying data-plane and its control-plane (both its own data-plane,
>:where appropriate, and its routing and signalling protocols).  But LDP does
>:nothing more than instantiate labels per hop that are locked to the IGP.
>:That is (i) they take the same SPF routes as the IGP would use for IP
>:fowarding and (ii) the LSPs change as the IGP changes.  I would argue this
>:is not a required behaviour for applications where LSPs are long-holding
>:and/or must not be affected by ad hoc routing changes or failures of routing
>:protocols (eg VPNs).  Further, because LDP is so tightly coupled to the IGP
>:then one has to introduce 'layer violations' to make it work a bit better,
>:eg Load-balancing using IP-level hashing......its hard to take seriously
>:anyone claiming this is MPLS label forwarding when one has to look at the
>:client/IP level (which it may not always be, ie XoverMPLS) to make
>:switching/forwarding decisions.
>:
>:> This makes MPLS a service enabler.
>:NH=> I don't agree that *LDP* makes MPLS a 'service-enabler'.  Considered
>:against a VPN service, the behaviour noted above is not what is needed.  Now
>:take the fact that QoS (a pkt forwarding attribute) and survivability (an
>:LSP attribute) need decoupling so that per VPN QoS/availability SLAs can be
>:defined/measured (independent of other VPNs) and look what LDP does to
>:that.....it mangles then both so they can't be decoupled, and now VPN
>:QoS/survivability behaviour is no longer independent on a per VPN basis.
>:Again this is not the required behaviour for VPNs.

I'll have to disagree here. Let us take L3VPNs for instance. If you run LDP,
you can add PEs dynamically without having to go an creat some tunnel between
this PE and all other PEs. If you use IP for this every time you have a new PE
you'll have to create end to end tunnels so that the mid-points don't drop the
packet because they have no earthly idea how  this private address on the
packet should be routed.

-ajay

>:
>:> For instance I
>:> did not see anyone
>:> mention things like QoS transparency that MPLS can achieve.
>:NH=> How can you claim this in view of the above observations?  Further, on
>:what basis are you discussing QoS?  That is, unless you can automatically
>:fault-manage MPLS I fail to see how anyone has any basis on which to discuss
>:QoS with any conviction......you have to define availability 1st, since QoS
>:metrics *only* have relevance to the up-state, and availability is dependent
>:of having defects defined.  So where are the defects defined and where is
>:availability defined?....once you can point at these then we can
>:meaningfully discuss QoS, but not before.
>:
>:> Sure you can
>:> monkey around with IP to make IP have everything that MPLS
>:> has.
>:NH=> No, you have to monkey around with LDP (eg load-balancing) because it
>:does not provide sufficient decoupling from IP behaviour as I noted above.
>:
>:> 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?
>:NH=> I have no problems with people defining solution's for a restricted
>:perspective of the problem-space if that is all they need/want from MPLS,
>:just so long as they don't try to stop others defining solutions which have
>:a more general application.  I have a strong sense that some people want to
>:do this....and therein lies the real problem IMO.
>:>
>:> -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
>:> >:
>:>
>:> --
>:>
>:

--

---

From: David Charlap <[email-masked]>
Date: Mon, 10 Jun 2002 13:21:59 -0400

Eric Osborne wrote:
> clear to me how you could do that with IP while using the existing
> ATM switch hardware and with only a control-plane upgrade.

It can also be done with LANE or CLIP, but these protocols have much
more overhead and can't directly connect with non-ATM switches, since
they don't use an IP-based control plane.

-- David

---

From: David Charlap <[email-masked]>
Date: Mon, 10 Jun 2002 13:21:59 -0400

-- David