The MPLS WG Archive

[neil.2.harrison@bt.com]

Giles,  please see below, regards, Neil

Giles Heron wrote 05 June 2002 17:38

<sniped>
> > > 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.
NH=> Well, I have thought long and hard about this, discussed it with lots
of people and sat down with the Ops guys here listening to their tales of
woe......its just a fact seen in practice, and its even relatively simple to
figure out anyway from the architecture as I have have tried to explain many
times now.

<snipped>
> 
> but mis-routing is a rare case even in MPLS networks.  You 
> say you need
> to be able to test for this.
NH=> Things break in many ways....we have plenty of evidence of this to say
its not so rare.  However, its only needs to happen once with some very
important customer to get bad press.  In any case, I think is a pretty
obvious requirement (or it should be) to have some form of check in the
data-plane that confirms that source X is truly connected to sink Y.  This
is not asking for the Earth....it's simply common-sense.
> 
> but you say that there is no need to test for rarer cases.
NH=> Not sure what you mean by this Giles.
<snipped>

> > 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.
NH=> Yes I know.....this is what we were given so far and that is what we
are having to live with.
> 
> > 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?
NH=> Yes you can do this.  Problem is the CVs build-up as the LSP is
considered closer and closer to its root.  You could scale this linearly (ie
1 cv/s on all mp2p segments) if CV/TTSI is consolidated at merge
points......but then this breaks the MPLS arch IMO by having to look at the
label stack to spot CV pkts.  The intention was to make CV transparent to
core LSRs, ie only relevant/seen at source/sink points.  However, since
LDP/mp2p constructs track the IGP and do SPF, then load balancing has to be
used to get around the traffic/topology sensitivities this creates.  Now you
could argue this too breaks the MPLS arch because you now have to perform a
hash function on the pkts.....so perhaps CV consolidation is only the same?
However, given all the other problems mp2p constructs create perhaps the
most pragamtic way to deal with them is:
-	note that for both L2 and L3 VPNs there is a single p2p hop above
the mp2p entity and run CV on that
-	this now detects any problems both at this level and below
-	if problems detected and no L1 indications of failure, then this
tells one to get out some other ad hoc tools (like some form of trace/ping
funcions) and start touble-shooting the mp2p entities.
At least now we would be aware of the problems before the customer (current
case) and could start to offer consistent SLAs.
> 
> 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?
NH=> You have to differentiate private and public services.  In the case of
VPNs their topologies are invariably long-holding, and once established you
don't actually to want them moving about at all (except under failures of
the *data-plane* where you would use prot-sw).  Ideally they should be
decoupled from ad hoc routing changes and protected from a
misbehaving/faulty control-plane (either routing or signalling).