The MPLS WG Archive

[neil.2.harrison@bt.com]

Thanks Giles.....some good points in your full response.  Few minor remarks
below on snipped extract below.

regards, Neil

Giles Heron wrote 06 June 2002 16:13
<snipped>

> 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.
NH=> This is indeed 1 possibility.  However, changing the frequency of CV
generation is not without implications wrt defect entry/exit criteria.
There are 4 directions to consider wrt  connectivity defects: p2p=>p2p,
p2p=>mp2p, mp2p=>p2p and mp2p=>mp2p.  The more variability on CV rate the
more complex this gets.  Taking just 1 example of 1 particular
direction......suppose 1 LSP had a CV rate of 1/min and another 1/s.  If the
1/min CV LSP was mismerging into the 1/s CV LSP, starting at some point T,
then we would get a cycle of:
-	declare dMismerge after T+3s
-	clear dMismerge after T+6s
-	declare dMismerge after T+63s
-	etc
Further, mismerge from mp2p closer to root than leaf would generate higher
'bad' CV rate....so this would be yet another variable.
So changing CV rate is a possibility, but it would need to be done in a
consistent way across all LSPs IMO and there would still be difficulties
with mp2p depending on from which point on the mp2p tree the leaking was
occurring.
> 
> 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.
NH=> Agreed.  Architecturally the effect of hashing is doing something like:
terminate the LSPs, go up the stack, make a decision of forwarding direction
and then come back down the stack to new LSPs.  So its like have inv-muxing
subnetworks......and each of these trails ought to monitored in its own
right (since they too may malfunction independently).
> 
> 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?)
NH=> I agree problems are certainly not restricted to faulty LSPs.  But one
of the things to bear in mind here is that we want the flexibility to use
the same LSPs constructs for a whole range of client layer signals and
applications....so we need some method of fault-management that is
common/simple to MPLS alone.  But I agree, we also need higher level tools
specific to the actual protocol carried (esp if it has no fault-management
of its own defined).
> 
> > -	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?)
NH=> Yes this is quite true.  But they are subtley different IMO.  In mp2p
there really is traffic merging post a given P LSR with a common label.  In
the top-level LSPs its more of a "converge" at the PE rather than a merge,
ie there is no subsequent common label at the LSP level.  So I think it
ought to be possible to have a simple CV flow on these.  Now how that would
get configured is a different question.
<snipped>