Subject: RE: Basic LDP Question

From: [email-masked]
Date: Tue, 4 Jun 2002 19:48:13 +0100

Please see below, regards Neil.

Eric Osborne wrote 03 June 2002 19:21
<snipped>
> > The remote peering mode of LDP is useful, but you could use 
> BGP or even RSVP-TE/CR-LDP too with the same scalability 
> level. The question was regarding the mp2p mode of LDP not 
> the p2p remote peering.
> > 
> 
> I don't think RSVP is appropriate for service label signalling in this
> case.
NH=> Agree
> 
> Sure, one could use BGP, but there's all sorts of things to consider
> there, too.  We could use BGP between every pair of directly connected
> neighbors (a la rfc3107) and not use LDP there, either.  But we don't;
> BGP and LDP are different.
NH=> Agree
> 
> Why are you trying to get rid of LDP?  It certainly seems like
> that...:)
NH=> Can't get rid of it....its already here.  We have to live with it.
What I think we are trying to find out is whether there is any strong reason
to use LDP in the core of a network when used to create mp2p constructs.
Remote peering of LDP is useful for certain application such as what you
described in PWE3 VC label distribution. But the general application of mp2p
LDP used in the core of networks creates lots of management problems that
don't exist in IP. 

The following is a comparison between LDP-MPLS (mp2p core) and IP, based on
the comments seen so far:

LDP-MPLS:
- Need another control-plane protocol (i.e., LDP signalling) on top of IP
control-plane (routing only)
- Packets could be mis-routed to wrong destination now because of LDP
failures. Therefore needs an LSP maintenance tool (such as LSP-ping) to run
continuously to detect defects (operators need automatic defect detection
and handling, waiting for a customer complaint is simply not good enough).
- Prevents spoofing

IP:

- Needs only IP control-plane (rouing only)
- Packets can't be mis-routed to wrong destination (except in rare cases)
due to use of IP addressing which is network unique rather than just
hop/node unique
- Is subject to spoofing, therefore needs filtering at the edge
- Requires 16 bytes more header per packet in VPN applications

So the question is which one is better to choose:
-	LDP software on all routers + periodic connectivity test, or
-	Filtering IP addresses (ACL) at the edge + 16 bytes more
header/packet for VPN
 
Note that doing a connectivity test on a constantly moving target (LDP-based
LSPs) is very difficult.
<snipped to end NH>

---

From: Giles Heron <[email-masked]>
Date: 05 Jun 2002 16:38:07 +0000

> LDP used in the core of networks creates lots of management problems that

not sure I'd agree with that.

> and handling, waiting for a customer complaint is simply not good enough).

- VPN over MPLS can be implemented with current hardware.

> due to use of IP addressing which is network unique rather than just

but mis-routing is a rare case even in MPLS networks.  You say you need
to be able to test for this.

but you say that there is no need to test for rarer cases.

I think we need some way to quantify how rare these cases (FIB
corruption and FIB corruption where the egress interface is null or is
an interface that will result in traffic being forwarded back to the
router with the corrupted entry) are?  It is non-obvious to me that the
first needs detection whilst the second doesn't.

> -	Filtering IP addresses (ACL) at the edge + 16 bytes more

or option 3 - LDP software on all routers and no connectivity test. 
That's what the majority of SPs run today AFAIK.

> Note that doing a connectivity test on a constantly moving target (LDP-based

I'm not convinced that is the case.  As long as the LSRs can inject
packets into LSPs with source and destination IDs in the packet then I
think you should get a reasonable CV for those LSPs?

And in fact there is no reason why LDP-based LSPs should move any more
than ER LSPs.  The routing only changes when the topology changes, after
all?

Giles

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

---

From: Peter Willis <[email-masked]>
Date: Thu, 06 Jun 2002 11:13:08 +0100

> first needs detection whilst the second doesn't.

The issue is not to do with the frequency of the fault but the impact of the 
fault:

In case where we use IP in IP tunnels if there is a forwarding error then the 
tunnel packets will normally go into a routing loop so the VPN IP packets do 
not get delivered to the wrong customer so there is no security problem.

In the case of MPLS if there is a forwarding error the VPN IP packets can get 
delivered to the wrong customer so there is a security problem.

So for IP VPNs using IP in IP tunnels we can live without detection of 
mis-routing (although a tunnel livelness indicator would still be useful).
But for IP VPNs using MPLS we need something to detect mis-routing.

Peter.