Skip to main content

Definition of Time to Live TLV for LSP-Ping Mechanisms
RFC 7394

Revision differences

Document history

Date Rev. By Action
2020-01-21
10 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2015-10-14
10 (System) Notify list changed from mpls-chairs@ietf.org, draft-ietf-mpls-lsp-ping-ttl-tlv@ietf.org to (None)
2014-11-14
10 (System) RFC published
2014-11-10
10 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-10-24
10 (System) RFC Editor state changed to AUTH48 from EDIT
2014-10-09
10 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2014-10-08
10 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2014-10-06
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2014-10-06
10 Amy Vezza IESG state changed to RFC Ed Queue from Approved-announcement sent
2014-10-06
10 (System) RFC Editor state changed to EDIT
2014-10-06
10 (System) Announcement was received by RFC Editor
2014-10-06
10 (System) IANA Action state changed to In Progress
2014-10-06
10 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2014-10-06
10 Amy Vezza IESG has approved the document
2014-10-06
10 Amy Vezza Closed "Approve" ballot
2014-09-25
10 Adrian Farrel Ballot approval text was generated
2014-09-25
10 Adrian Farrel Ballot writeup was changed
2014-09-25
10 Adrian Farrel IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2014-09-25
10 Kathleen Moriarty [Ballot comment]
Thanks, the concerns are addressed in the referenced RFC in the latest revision.
2014-09-25
10 Kathleen Moriarty [Ballot Position Update] Position for Kathleen Moriarty has been changed to No Objection from Discuss
2014-09-25
10 Ted Lemon
[Ballot comment]
It looks like my DISCUSS has been addressed.  The DISCUSS was:

I'm probably missing something here, so please help me out.  The text …
[Ballot comment]
It looks like my DISCUSS has been addressed.  The DISCUSS was:

I'm probably missing something here, so please help me out.  The text in 4.2 says:

  It is possible that the MPLS Echo Request packet was intercepted
  before the intended destination for reason other than label TTL
  expiry. This could be due network faults, misconfiguration or other
  reasons. In such cases, if the return TTL is set to the value
  specified in the TTL TLV then the echo response packet will continue
  beyond the originating node. This becomes a security issue.

  To prevent this, the label TTL value used in the MPLS Echo Reply
  packet MUST be modified by deducting the incoming label TTL on the
  received packet from TTL TLV value. If the MPLS Echo Request packet
  is punted to the CPU before the incoming label TTL is deducted, then
  another 1 MUST be deducted. In other words:

  Return TTL Value on the MPLS Echo Reply packet = (TTL TLV Value)-
  (Incoming Label TTL) + 1

The second paragraph concludes by saying "another 1 must be deducted," but the math in the third paragraph appears to be adding one, possibly because not enough parentheses were used.  What was intended here?
2014-09-25
10 Ted Lemon [Ballot Position Update] Position for Ted Lemon has been changed to No Objection from Discuss
2014-08-19
10 Barry Leiba [Ballot comment]
Version -10 has addressed my DISCUSS.  Thanks for that, and for also addressing my other comments.
2014-08-19
10 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss
2014-08-19
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2014-08-19
10 Sami Boutros IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2014-08-19
10 Sami Boutros New version available: draft-ietf-mpls-lsp-ping-ttl-tlv-10.txt
2014-08-18
09 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2014-08-07
09 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2014-08-07
09 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2014-08-07
09 Kathleen Moriarty
[Ballot discuss]
Since a traceroute method is described, you are able to map the path, enabling a new network reconnaissance method for MPLS.  This should …
[Ballot discuss]
Since a traceroute method is described, you are able to map the path, enabling a new network reconnaissance method for MPLS.  This should be mentioned as a security consideration as you can map paths to destinations that could be used in DoS or other attacks (you know the nodes to attack to impact availability).
2014-08-07
09 Kathleen Moriarty [Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty
2014-08-07
09 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2014-08-07
09 Jari Arkko
[Ballot comment]
This document got on the agenda on August 4th, for the August 7th meeting. I got a complaint from the Secdir secretary that …
[Ballot comment]
This document got on the agenda on August 4th, for the August 7th meeting. I got a complaint from the Secdir secretary that it is too short time for them to do their usual re-review for the telechat. He believes there is no issue in this document, but can we avoid this situation in the future?
2014-08-07
09 Jari Arkko Ballot comment text updated for Jari Arkko
2014-08-06
09 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2014-08-06
09 Pete Resnick
[Ballot comment]
In section 3.1, do you want to put in the usual "Reserved - MUST be zero (MBZ) when sending and ignored on receipt."? …
[Ballot comment]
In section 3.1, do you want to put in the usual "Reserved - MUST be zero (MBZ) when sending and ignored on receipt."?

Barry's covered the rest.
2014-08-06
09 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2014-08-06
09 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2014-08-06
09 Ted Lemon
[Ballot discuss]
I'm probably missing something here, so please help me out.  The text in 4.2 says:

  It is possible that the MPLS Echo …
[Ballot discuss]
I'm probably missing something here, so please help me out.  The text in 4.2 says:

  It is possible that the MPLS Echo Request packet was intercepted
  before the intended destination for reason other than label TTL
  expiry. This could be due network faults, misconfiguration or other
  reasons. In such cases, if the return TTL is set to the value
  specified in the TTL TLV then the echo response packet will continue
  beyond the originating node. This becomes a security issue.

  To prevent this, the label TTL value used in the MPLS Echo Reply
  packet MUST be modified by deducting the incoming label TTL on the
  received packet from TTL TLV value. If the MPLS Echo Request packet
  is punted to the CPU before the incoming label TTL is deducted, then
  another 1 MUST be deducted. In other words:

  Return TTL Value on the MPLS Echo Reply packet = (TTL TLV Value)-
  (Incoming Label TTL) + 1

The second paragraph concludes by saying "another 1 must be deducted," but the math in the third paragraph appears to be adding one, possibly because not enough parentheses were used.  What was intended here?
2014-08-06
09 Ted Lemon [Ballot comment]
I also agree with Barry's discuss.
2014-08-06
09 Ted Lemon [Ballot Position Update] New position, Discuss, has been recorded for Ted Lemon
2014-08-06
09 Richard Barnes [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes
2014-08-06
09 Brian Haberman [Ballot comment]
I support Barry's DISCUSS point on section 3.2.
2014-08-06
09 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2014-08-05
09 Pearl Liang IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2014-08-05
09 Adrian Farrel IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2014-08-05
09 Adrian Farrel IESG state changed to Waiting for AD Go-Ahead::AD Followup from IESG Evaluation
2014-08-05
09 Adrian Farrel IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2014-08-04
09 (System) IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2014-08-04
09 Barry Leiba
[Ballot discuss]
I find Section 3.2 sufficiently confusingly worded and unclear that I think we need to have a discussion about re-wording it.  I offer …
[Ballot discuss]
I find Section 3.2 sufficiently confusingly worded and unclear that I think we need to have a discussion about re-wording it.  I offer suggested re-wording below, but please bear with my thought process on the way there:

  This TLV SHALL be included in the MPLS Echo Request by the originator
  of request. The use of this TLV is optional.

That "SHALL" conflicts with the second sentence.  My sense is that it's not really a MUST.  Perhaps you mean "MAY be included"?  In which case, you don't need the second sentence at all, because that's what "MAY" says.

  (Type value of
  TLV is assumed to be in the range of optional TLV's which SHOULD be
  ignored if an implementation does not support or understand them)

"Assumed to be"?  Shouldn't this simply be "is"?

  If a receiver understands the TTL TLV, and the TTL TLV is present in
  the MPLS Echo Request, the receiver MUST use the TTL value specified
  in TLV in the MPLS header of the MPLS Echo Reply. In other words, if
  the value of the TTL provided by this TLV does not match the TTL
  determined by other means, such as Switching Point TLV in MS-PW, then
  TTL TLV MUST be used. This will aid the originator of the LSP-Ping
  echo request in analyzing the return path.

I find this to be impossibly confusing in its wording, and I had to read it several times before I thought I understood what you're trying to say.  Whenever you need to put in "in other words," you should consider that a clue that re-wording would help.

As I find the whole section to be awkward, and as the section isn't long, may I presume to suggest re-wording for the section?  Of course, please correct any inaccuracies I might have introduced here... but please do consider a re-wording such as this.

NEW
3.2. Usage

  The TTL TLV MAY be included in the MPLS Echo Request by the
  originator of the request.
 
  If the TTL TLV is present and the receiver does not understand TTL
  TLVs, it will simply ignore the TLV, as is the case for all optional
  TLVs.  If the TTL TLV is not present or is not processed by the
  receiver, any determination of the TTL value used in the MPLS label
  on the LSP-Ping echo reply is beyond the scope of this document.

  If the TTL TLV is present and the receiver understands TTL TLVs, one
  of the following two conditions apply:
 
  o  If the TTL TLV value field is zero, the LSP-Ping echo request
      packet SHOULD be dropped.

  o  Otherwise, the receiver MUST use the TTL value specified in the
      TTL TLV when it creates the MPLS header of the MPLS Echo Reply.
      The TTL value in the TTL TLV takes precedence over any TTL value
      determined by other means, such as from the Switching Point TLV
      in the MS-PW.  This precedence will aid the originator of the
      LSP-Ping echo request in analyzing the return path.
END
2014-08-04
09 Barry Leiba
[Ballot comment]
-- Section 1 --

  But, if the
  originator is not at the end of the MS-PW, the receiver of the MPLS …
[Ballot comment]
-- Section 1 --

  But, if the
  originator is not at the end of the MS-PW, the receiver of the MPLS
  Echo Request MAY need to know how many hops away the originator

Tiny point: this is not a 2119 "MAY", so it shouldn't be in all caps.  If you want to indicate stress, please use "*may*" or "_may_", though you can probably skip that and just make it "may".

-- Section 4 --

  D detects the TTL TLV in the request, and use the TTL value
  (i.e., 2) specified in the TLV on the MPLS label of the MPLS Echo
  Reply.

This has a similar problem to part of what confused me in Section 3.2.  It looks like you mean it to be parsed this way:

"...and use (the TTL value (2) that is specified in the TLV on the MPLS label of the MPLS Echo Reply) [for what?]."

But I think you actually mean it to be parsed this way:

"...and use (the TTL value (2) that is specified [in the Echo Request]) and put it into the TLV on the MPLS label of the MPLS Echo Reply."

Am I correct here?  If so, then wording it that way would be *much* clearer:

NEW
  D detects the TTL TLV in the request, and uses that TTL value (2)
  to put into the TLV on the MPLS label of the MPLS Echo Reply.
END

  The same operation will apply in the case a co-routed bidirectional
  LSP and we want to check connectivity from an intermediate LSR B to
  another LSR D, from B.

I can't parse this.  I think you mean this:

NEW
  The same operation will apply when we have a co-routed
  bidirectional LSP, and we want to check connectivity from an
  intermediate LSR "B" to another LSR "D".
END

-- Section 4.1 --

  In the traceroute mode TTL value in the TLV is successively set to 1,
  2, and so on. This is similar to the TTL values used for the label
  set on the packet.

May I suggest this, as perhaps clearer (this one is far less important a suggestion than the earlier ones)?:

NEW
  In traceroute mode, the TTL value in the TLV is set to 1 for the
  first Echo Request, then to 2 for the next, and so on. This is
  similar to the TTL values used for the label set on the packet.
END
2014-08-04
09 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2014-08-04
09 Adrian Farrel Ballot has been issued
2014-08-04
09 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel
2014-08-04
09 Adrian Farrel Created "Approve" ballot
2014-08-04
09 Adrian Farrel Placed on agenda for telechat - 2014-08-07
2014-08-04
09 Adrian Farrel Changed consensus to Yes from Unknown
2014-08-04
09 Sami Boutros New version available: draft-ietf-mpls-lsp-ping-ttl-tlv-09.txt
2014-07-30
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2014-07-30
08 Sami Boutros IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2014-07-30
08 Sami Boutros New version available: draft-ietf-mpls-lsp-ping-ttl-tlv-08.txt
2014-05-09
07 Roni Even Request for Last Call review by GENART Completed: Ready. Reviewer: Roni Even.
2014-04-10
07 Adrian Farrel IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead
2014-04-07
07 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2014-04-03
07 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2014-04-03
07 Amanda Baber
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-mpls-lsp-ping-ttl-tlv-07.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-mpls-lsp-ping-ttl-tlv-07.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that there is a single action which needs to be completed upon approval of this document.

In the TLVs registry in the Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters page at

http://www.iana.org/assignments/mpls-lsp-ping-parameters/

a new TLV type value is to be registered as follows:

Type: [ TBD-at-registration ]
TLV Name: Time to Live
Reference: [ RFC-to-be ]

IANA notes that the type value must be assigned from the range (32768-49161) of optional TLVs.

IANA understands that this is the only action required upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.
2014-04-03
07 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Paul Hoffman.
2014-03-28
07 Tina Tsou Request for Last Call review by OPSDIR is assigned to Peter Schoenmaker
2014-03-28
07 Tina Tsou Request for Last Call review by OPSDIR is assigned to Peter Schoenmaker
2014-03-27
07 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2014-03-27
07 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2014-03-27
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Paul Hoffman
2014-03-27
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Paul Hoffman
2014-03-24
07 Amy Vezza IANA Review state changed to IANA - Review Needed
2014-03-24
07 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Definition of Time-to-Live TLV for …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Definition of Time-to-Live TLV for LSP-Ping Mechanisms) to Proposed Standard

The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Definition of Time-to-Live TLV for LSP-Ping Mechanisms'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-04-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  LSP-Ping is a widely deployed Operation, Administration, and
  Maintenance (OAM) mechanism in MPLS networks. However, in the present
  form, this mechanism is inadequate to verify connectivity of a
  segment of a Multi-Segment PseudoWire (MS-PW) from any node on the
  path of the MS-PW. This document defines a TLV to address this
  shortcoming.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-ttl-tlv/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-ttl-tlv/ballot/

No IPR declarations have been submitted directly on this I-D.
2014-03-24
07 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2014-03-24
07 Adrian Farrel Last call was requested
2014-03-24
07 Adrian Farrel Ballot approval text was generated
2014-03-24
07 Adrian Farrel IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2014-03-24
07 Adrian Farrel Last call announcement was changed
2014-03-24
07 Adrian Farrel Last call announcement was generated
2014-03-24
07 Adrian Farrel Last call announcement was generated
2014-03-24
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2014-03-24
07 Sami Boutros New version available: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt
2013-11-29
06 Adrian Farrel
AD review
========
Hi,

Thanks for this simple little I-D.

Just a few bits and pieces to resolve before we move forward.

Cheers,
Adrian

=== …
AD review
========
Hi,

Thanks for this simple little I-D.

Just a few bits and pieces to resolve before we move forward.

Cheers,
Adrian

===

Obviously, the idnits issues need to be sorted out.

---

Section 1
s/is being proposed/is defined/
s/this document this TLV/this document.  This TLV/

---

Surely this mechanism only works if the echo reply is sent down the
co-routed return path LSP. All other mechanisms for returning the echo
reply make this mechanisms worse than silly! While you do say...
  The scope of this TTL TLV is currently limited to MS-PW or
  Bidirectional co-routed MPLS LSPs.
...I don't believe that actually applies the necessary constraint.
Shouldn't this somehow be tied to require the use of the return path
LSP, either by making the new TLV only valid when the return path is
specified to be that LSP, or by saying that the presence of the TLV
implies the use of the return path LSP. In either case, you have to
describe what happens if the return path is specified using some other
mechanism and yet the TLV is present.

---

I think your security section should reference the security section of
4379. But there we find...

  To protect against unauthorized sources using MPLS echo request
  messages to obtain network information, it is RECOMMENDED that
  implementations provide a means of checking the source addresses of
  MPLS echo request messages against an access list before accepting
  the message.

You will need to explain how that recommendation is met since you have
opened the box from just the ingress to any node along the path.

Furthermore, you now have a field in the Echo Request that we can have
fun over-writing. What would happen if I modified the TTL TLV value
field in transit?

---

The following paragraph in the IANA section needs work

  Time To Live TLV (See Section 3). The value should be assigned from
  the range (32768-49161) of optional TLV's which SHOULD be ignored if
  an implementation does not support or understand them as defined in
  section 3 of RFC 4379 [RFC4379].

1. I think you mean that it must be assigned from 32768-49161
2. You can truncate the text at "...optional TLV's."
3. s/TLV's/TLVs/
2013-11-29
06 Adrian Farrel State changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2013-11-29
06 Adrian Farrel Ballot writeup was changed
2013-11-29
06 Adrian Farrel Ballot writeup was generated
2013-11-18
06 Adrian Farrel State changed to AD Evaluation from Publication Requested
2013-10-24
06 Loa Andersson IETF WG state changed to Submitted to IESG for Publication
2013-10-24
06 Loa Andersson IESG state changed to Publication Requested
2013-10-24
06 Loa Andersson State Change Notice email list changed to mpls-chairs@tools.ietf.org, draft-ietf-mpls-lsp-ping-ttl-tlv@tools.ietf.org
2013-10-24
06 Loa Andersson Responsible AD changed to Adrian Farrel
2013-10-24
06 Loa Andersson Working group state set to Submitted to IESG for Publication
2013-10-24
06 Loa Andersson IESG state set to Publication Requested
2013-10-24
06 Loa Andersson IESG process started in state Publication Requested
2013-10-24
06 Loa Andersson IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Consensus: Waiting for Write-Up
2013-10-24
06 Loa Andersson Annotation tag Doc Shepherd Follow-up Underway cleared.
2013-10-24
06 Loa Andersson Changed document writeup
2013-10-23
06 Loa Andersson Changed document writeup
2013-10-23
06 Martin Vigoureux IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Consensus: Waiting for Write-Up
2013-10-23
06 Martin Vigoureux Annotation tag Other - see Comment Log cleared.
2013-10-18
06 Loa Andersson Changed document writeup
2013-10-18
06 Loa Andersson Changed document writeup
2013-10-18
06 Loa Andersson Changed document writeup
2013-10-18
06 Loa Andersson Changed document writeup
2013-10-18
06 Loa Andersson Changed document writeup
2013-10-17
06 Loa Andersson Intended Status changed to Proposed Standard from None
2013-10-17
06 Loa Andersson Implementation poll started!
2013-10-17
06 Loa Andersson IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead
2013-10-17
06 Loa Andersson Annotation tags Doc Shepherd Follow-up Underway, Other - see Comment Log set. Annotation tag Revised I-D Needed - Issue raised by WGLC cleared.
2013-10-17
06 Sami Boutros New version available: draft-ietf-mpls-lsp-ping-ttl-tlv-06.txt
2013-10-09
05 Loa Andersson IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2013-10-09
05 Loa Andersson Annotation tag Revised I-D Needed - Issue raised by WGLC set. Annotation tag Other - see Comment Log cleared.
2013-09-18
05 Loa Andersson IETF WG state changed to In WG Last Call from WG Document
2013-09-05
05 Loa Andersson IPR poll is running
2013-05-20
05 Loa Andersson IETF WG state changed to WG Document from Waiting for WG Chair Go-Ahead
2013-05-20
05 Loa Andersson Document shepherd changed to Loa Andersson
2013-04-20
05 Loa Andersson Waiting to resolve issues on the IPR poll.
2013-04-20
05 Sami Boutros New version available: draft-ietf-mpls-lsp-ping-ttl-tlv-05.txt
2013-04-20
04 Loa Andersson IETF WG state changed to Waiting for WG Chair Go-Ahead from WG Document
2013-04-20
04 Loa Andersson Annotation tag Other - see Comment Log set.
2012-10-20
04 Loa Andersson Document will expire on April 23, need to be reposted.
The document is in IPR poll, lacking one author response
2012-10-20
04 Loa Andersson IPR Poll started
2012-10-20
04 Loa Andersson Waiting for IPR poll
2012-10-20
04 Sami Boutros New version available: draft-ietf-mpls-lsp-ping-ttl-tlv-04.txt
2012-09-09
03 Sami Boutros New version available: draft-ietf-mpls-lsp-ping-ttl-tlv-03.txt
2012-03-06
02 Siva Sivabalan New version available: draft-ietf-mpls-lsp-ping-ttl-tlv-02.txt
2011-10-28
01 (System) New version available: draft-ietf-mpls-lsp-ping-ttl-tlv-01.txt
2011-06-29
00 (System) New version available: draft-ietf-mpls-lsp-ping-ttl-tlv-00.txt