The MPLS WG Archive

[Giles Heron <giles@packetexchange.net>]

On Tue, 2002-06-04 at 18:48, neil.2.harrison@bt.com wrote:
> 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. 

not sure I'd agree with that.

> 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

- VPN over MPLS can be implemented with current hardware.

> 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

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.

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

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
> LSPs) is very difficult.

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

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