Subject: LSR Self test in Charter

From: "David Allan" <[email-masked]>
Date: Thu, 2 Oct 2003 15:16:28 -0400

LSR self test is a milestone in this charter, yet I've seen NO discussion of
this on the list other than Loa's brief email soliciting comment back in
July. I understand that normally some interest beyond a few friends hands is
usually a pre-requisite to adopting work......

......So I'll ask a simple technical question to try and spark some
discussion after the fact. If I have an LSR popping the stack in error, I
suspect this will not be detected by an LSR testing itself. As PHP is
considered acceptable behavior, the downstream LSR would NOT observe that
the PING packet on which TTL expired did not arrive as a labelled packet, it
simply looks at the FEC TLV and goes ***OK, it looks reasonable***. There is
no guarantee that the LSR downstream of the defective pop would catch this
either via its use of LSR self test mechanisms as the path into the
defective LSR is assuredly different than that of real traffic.

IMHO if my LSRs are generating a ping transaction for every ILM entry in my
network (which is a s***load of a lot of pings no matter how slowly I run
this stuff), am I really accomplishing anything if discontinuties in the
label switched path cannot be detected by this mechanism? 

cheers
Dave

---

From: George Swallow <[email-masked]>
Date: Thu, 02 Oct 2003 16:17:50 -0400

Dave -

There was strong interest expressed in the room in Vienna.  Due to
that, Loa only asked for nay sayers to speak up.  No one objected.  

I've attached the original message.

...George

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

Date: Thu, 17 Jul 2003 11:14:46 +0200
From: Loa Andersson <[email-masked]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MPLS WG <[email-masked]>, George Swallow <[email-masked]>,
        Alex Zinin
 <[email-masked]>
Subject: draft-swallow-mpls-lsr-self-test-01.txt, to wg draft
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Working Group,

at the Vienna MPLS WG meeting the

     Label Switched Router Self-Test
     <draft-swallow-mpls-lsr-self-test-01.txt>

was discussed. There were support for making it a wg draft.
We will go ahead and do so shortly, this is a chance you who were
not in the meeting (or did not speak up) to comment on this.

-- 
/Loa

mobile + 46 739 81 21 64
email: [email-masked]

---

From: George Swallow <[email-masked]>
Date: Thu, 02 Oct 2003 17:00:25 -0400

Dave -

> label switched path cannot be detected by this mechanism? 

Excellent point you raise.  One that I've been worried about.  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.  And that that protocol distributed a label (including NULL) for
that FEC.  Note, I say associated since and LDP session can pertain to
multiple interfaces and BGP can pertain to all core facing interfaces.

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.

...George