Skip to main content

Definition of Time to Live TLV for LSP-Ping Mechanisms

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: RFC Editor <>,
    mpls mailing list <>,
    mpls chair <>
Subject: Protocol Action: 'Definition of Time-to-Live TLV for LSP-Ping Mechanisms' to Proposed Standard (draft-ietf-mpls-lsp-ping-ttl-tlv-10.txt)

The IESG has approved the following document:
- 'Definition of Time-to-Live TLV for LSP-Ping Mechanisms'
  (draft-ietf-mpls-lsp-ping-ttl-tlv-10.txt) as Proposed Standard

This document is the product of the Multiprotocol Label Switching Working

The IESG contact persons are Adrian Farrel and Alia Atlas.

A URL of this Internet Draft is:

Ballot Text

Technical Summary

     LSP-Ping is a widely deployed Operation, Administration, and Maintenance
     (OAM) mechanism in MPLS networks. However, as it is currently defined
     there is no way to verify the connectivity of one or more segments of an
     MS-PW. This document specifies a method by which any T-PE or S-PE
     can verify the connectivity to any other T-PE or S-PE.
    This document defines a new LSP Ping TLV to support this type of
    connectivity verification. 

Working Group Summary

    The WG process was pretty straight-forward. The only thing even remotely
    close to needing to be mentioned is that the IPR poll took unreasonably
    long (started March 15 and ended September 18), for a poll that
    resulted in that "We are not aware of any IPR that relates to this 

Document Quality

    The Working Group chairs asked for implementation status on the 
    working group mailing list. They received feedback on this poll and
    know of implementations of the draft. There have also been 
    statements saying that vendors intend to implement this specification .

    The document has been reviewed through the normal WG process.
    No  MIB Doctor, Media Type or other expert review been performed or


    Loa Andersson is the document Shepherd.
    Adrian Farrel is the responsible AD.

RFC Editor Note