Subject: RE: LSR Self test in Charter

From: "David Allan" <[email-masked]>
Date: Fri, 3 Oct 2003 09:22:18 -0400

Hi George:

> > 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?
> 
> No, if the packet arrives unlabeled then you necessarily had 
> to have given out an explicit null label for that FEC.  

Seems to me there are a lot of potential reasons for an unlabelled packet
turning up at the downstream LSR besides the downstream LSR offering
implicit NULL.

> 
> > 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...?
> 
> The reference to BGP was just for VPNs.  I haven't given a 
> lot of thought to CSC yet.

 I have to admit I have trouble envisioning applicability to other than LDP
or RSVP.

> 
> > > 
> > > 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)"?
> 
> No, I meant that you're neighbor gave you an implicit null 
> label so that instead of your normal swap operation of remove 
> and replace the top label, you just remove the label.

I get the feeling we're crossing up explicit and implicit NULLs in this
dialog. my understanding is that implicit null would never appear in the
dataplane. Your reference above to appending an implicit NULL to the stack
runs counter to my understanding.

rgds
Dave

> 
> Cheers,
> 
> ...George
> 
> 
> ==============================================================
> ==========
> George Swallow             Cisco Systems                  
> (978) 936-1398
>                            1414 Massachusetts Avenue
>                            Boxborough, MA 01719
> 
>

---

From: George Swallow <[email-masked]>
Date: Fri, 03 Oct 2003 11:01:27 -0400

> turning up at the downstream LSR besides the downstream LSR offering

Yes!  But the only valid one is that you gave out an explicit null.
So you check that you did in fact do that.  If not it's an error.

>  I have to admit I have trouble envisioning applicability to other than LDP

The applicability to other things comes with the FEC stack.  I've also
suggested that the error reporting procedures use the error subcode to
point to where in the stack the error occurred.  So far my co-authors
have not gotten back to me.  So I'll post my suggestions to the list
later today.

> dataplane. 

Right!

> Your reference above to appending an implicit NULL to the stack

That's why appending an implicit null results in a PoP!

...George

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719