The MPLS WG Archive

[Giles Heron <giles@packetexchange.net>]

On Thu, 2002-06-06 at 08:29, neil.2.harrison@bt.com wrote:
> 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.

I think we have to agree to disagree on this, and to be careful to
present our views as such rather than as statements of fact?

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

I mean that mis-routing in MPLS is rare (I know you differ on this - but
I guess it depends on your definition of rare).

misrouting in IP is presumably rarer (as it requires a loop or a route
to /dev/null).

But I take Peter's argument that the risk in MPLS is mis-delivery
whereas with IP you would generally only see packets being dropped
(though there are probably pathological cases which would cause
mis-delivery in IP such as a router delivering packets locally instead
of to an outbound interface).

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

I'm not convinced that you need to "merge" the CVs.  If the frequency is
relatively low you can just allow them all through to the sink which can
check that it gets packets from all PEs to which it has a label mapping
learned with LDP?  Remember that if each PE sends the same frequency of
packets into each LSP this will create the same number of CV packets at
the sink as would a mesh of TE tunnels.

But yes, hashing is an issue.  I don't think we have an adequate
solution for this yet :(  The problem is that without knowing a-priori
what the hashing algorithm in your network is you have no way to know if
you have hit all possible hashed paths.

Which is one of the reasons why I would advocate testing using
client-layer tools, or in their absence external probes which can inject
real traffic into the network (the other reason is that errors may occur
in the adaptation function at the edges rather than in the core, and
MPLS OAM will fail to catch these - in fact I have seen more of these
events than MPLS FIB errors, probably because most of the processing
complexity is at the edge?)

> -	note that for both L2 and L3 VPNs there is a single p2p hop above
> the mp2p entity and run CV on that

I don't think this is true with L3 VPNs.  They merge at the VPN level,
don't they? (using mBGP a 2547 PE will likely advertise the same VPN
label to all peers for a given prefix?)

also for some flavours of L2VPN the same may be true.  For VPLS you
advertise a distinct label to each peer PE (to facilitate MAC learning),
but for "IPLS" the same label will most likely be advertised to each PE
(work on this is in progress...)

In general anything that relies on mBGP is likely to advertise the same
label to all peer PEs (as the labels are "broadcast" through the RR
infrastructure).  Whereas anything that relies on tLDP is likely to
advertise a distinct label to each peer PE - though of course there is
nothing (other than breaking the client protocol) to stop a PE
advertising the same label to multiple PEs over different tLDP sessions.

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

But VPNs don't really have anything to do with this?  The mp2p labels in
the core are generally used to carry all services (i.e. they provide box
to box connectivity for all traffic, not service by service
connectivity).  On this basis they will hold until re-routing occurs in
the core?

Giles

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