The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

Hi George:

> <snipped>
> 
> 
> Excellent point you raise.  One that I've been worried about. 

OK

>  I've sent some new procedures and error conditions to my 
> co-authors on lsp-ping.  One change that I have requested is 
> is that you must check whether the protocol that would have 
> distributed the FEC you have is actually associated with the 
> interface that you received the packet on.  

OK , that will catch a discontinuity when you've neglected to configure LDP
on a link and its a direct adjacency. That's one scenario.... 

> And that that 
> protocol distributed a label (including NULL) for that FEC.  

So we're inferring correctness here. If I got a ping on an interface, and
there is a control adjacency that handed out a FEC label binding on that
interface and the FEC seems legit, then everything must be OK? 

IMHO only an e2e ping that uses the 127/8 can actually catch a real problem
when the unroutable packet comes up for air and the receiving LSR trys to
forward it further...

> Note, I say associated since and LDP session can pertain to 
> multiple interfaces and BGP can pertain to all core facing interfaces.

Are you envisioning self test for CSC...? 

> 
> Another change, intended to help diagnose the problem, is 
> that when you do a trace with a Downstream Mapping TLV, you 
> MUST include null labels in the stack. That way, if you reach 
> the PHP router and it is doing a PoP and forward because it 
> is the end of the LSP (got no label from it's neighbor) it 
> will send back an empty stack, whereas if it was appending an 
> implicit NULL label (still a PHP) it would send back a stack 
> with just the null label as the first entry.

Did you mean "appending an explicit NULL (still a PHP)"?

rgds
Dave

>