Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures
draft-ietf-mpls-rfc4379bis-09

Request for posting confirmation emailed to previous authors: "Mach Chen" , "Kireeti Kompella" , "Nagendra Kumar" , mpls-chairs@ietf.org, "Carlos Pignataro" , "George Swallow" , "Sam Aldrin"

[Ballot discuss]
Thank you for writing this document. I will recommend its approval, but before that we have a fix a couple of issues.

A Gen-ART review by Elwyn Davies raised a number of valid points. The ones worthy of a Discuss are the following:

1. Section 3.4 protocol definition refers to Appendix A.2 which is depracated/non-normative. I think you have to decide which parts are still in the normative spec, and keep those in the body of the document.

2. Reference to the R flag in 6.2.3 seems wrong, as the flag isn't actually allocated in RFC 6426 due to an oversight. Maybe either explain the situation and the existing errata, or just define the flag in this RFC and be done with it?

[Ballot comment]
The document authors will increase by one (to a total of six) as due to a mix up of communications, George Swallow was omitted. We had planned to fix with the next update when addressing the Gen-Art comments last week but got delayed.

[Ballot comment]
A few not very important comments:

1) To me it seems a bit unfortunate that this draft points to rfc6425 and rfc6426 for the definition of the T and R flags, given the goal was to have all specifications in one doc. Not sure if that can or should be fixed. Just wanted to mention it.

2) I would expect that the security section recommends border filtering of MPLS ping message, given that these are usually used within one domain, no?

3) I know this is a bis doc but I'm still wondering why this TTL trick is used here. For ICMP that was a way that utilizes the existing specification and implementation to get further information. However here, you could just have used a flag in the header either saying 'only forward to the end' or 'reply and still forward', or something like this, to cover the two modes. This would also allow to just send one packet to the end instead of sending one for each hop. Is there a rational for copying this ICMP hack?

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-mpls-rfc4379bis-07.txt. If any part of this review is inaccurate, please let us know.

We have a question about some of the actions requested in the IANA Considerations section of this document.

Upon approval of this document, we understand that there are eleven registry actions to complete.

Question: As this document is a bis for RFC 4379, should references to RFC 4379 in the IANA Matrix and in registries contained in the protocol registries be changed to reference the new [ RFC-to-be ] instead?

In the IANA Considerations section, the subregistries of the Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters located at:

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

First, in the Message Types subregistry, the document provides registrations for two existing values. We understand that the reference for these values will be changed to [ RFC-to-be ].

Question --> are the other values, already existing in the registry, to remain there?

Second, in the Reply Modes subregistry, the document provides registrations for four existing values. We understand that the reference for these values will be changed to [ RFC-to-be ].

Question --> is the other value, already in the registry, to remain there?

Third, in the Return Codes subregistry, the document provides for (in section 3.1) fifteen existing values. We understand that the reference for these values will be changed to [ RFC-to-be ].

Question --> are the other nineteen values, already in the registry, to remain there?

Fourth, in the TLV subregistry, this document makes permanent the assignment of the type 1 TLV and changes its reference to [ RFC-to-be ]. In addition, for type 2-10 and type 20, this document make permanent the existing registrations and changes the references to [ RFC-to-be ].

Fifth, in the Sub-TLVs for TLV Types 1, 16, and 21 subregistry, this document provides for eighteen existing values. We understand that the reference for these values will be changed to [ RFC-to-be ].

Question --> are the other values, already in the registry, to remain there?

Sixth, in the Global Flags subregistry, we understand that the registry is to be changed to the following:

Bit number | Name | Reference
------------+----------------------------+--------------
15 | V Flag | [ RFC-to-be ]
14 | T Flag | [RFC6425]
13 | R Flag | [RFC6426]
12-0 | Unassigned | [ RFC-to-be ]

Seventh, in the Downstream Detailed Mapping Address Type subregistry, we understand that the registry is changed to the following:

Type # Address Type K Octets Reference
------ ------------ -------- --------------------
1 IPv4 Numbered 16 [ RFC-to-be ]
2 IPv4 Unnumbered 16 [ RFC-to-be ]
3 IPv6 Numbered 40 [ RFC-to-be ]
4 IPv6 Unnumbered 28 [ RFC-to-be ]
5 Non IP 12 [ RFC 6426 ]

Eighth, in the DS Flags subregistry, this document provides for two existing values. We understand that the reference for these values will be changed to [ RFC-to-be ].

Question --> are the other two values, early registrations from other documents and already in the registry, to remain there?

Ninth, in the Multipath Types subregistry, this document provides for five existing values. We understand that the reference for these values will be changed to [ RFC-to-be ]. This document also provides for two ranges of values, 11-250 and 251-254. We understand that the reference for these ranges will be changed to [ RFC-to-be ].

Question --> is the other value, an early registration from another document for value 10 and already in the registry, to remain there?

Tenth, in the Pad Types subregistry, we understand that the registry has the following registration policies:

0-250 Standards Action
251-254 Experimental Use
255 Standards Action

And the registry is changed to the following:

Value Meaning Reference
---------- ---------------------------- -------------
0 Reserved [ RFC-to-be ]
1 Drop Pad TLV from reply [ RFC-to-be ]
2 Copy Pad TLV to reply [ RFC-to-be ]
3-250 Unassigned
251-254 Experimental Use [ RFC-to-be ]
255 Reserved [ RFC-to-be ]

Eleventh, in the Interface and Label Stack Address Type subregistry, we understand that the registry is changed to the following:

Value Meaning Reference
---------- ---------------------- -------------
0 Reserved [ RFC-to-be ]
1 IPv4 Numbered [ RFC-to-be ]
2 IPv4 Unnumbered [ RFC-to-be ]
3 IPv6 Numbered [ RFC-to-be ]
4 IPv6 Unnumbered [ RFC-to-be ]
5-250 Unassigned
251-254 Experimental Use [ RFC-to-be ]
255 Reserved [ RFC-to-be ]

We understand that these eleven actions are the only ones required to be completed 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.

Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: mpls@ietf.org, db3546@att.com, draft-ietf-mpls-rfc4379bis@ietf.org, mpls-chairs@ietf.org, "Loa Andersson" , loa@pi.nu
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures'
  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 2016-10-18. 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


  This document describes a simple and efficient mechanism that can be
  used to detect data plane failures in Multi-Protocol Label Switching
  (MPLS) Label Switched Paths (LSPs).  There are two parts to this
  document: information carried in an MPLS "echo request" and "echo
  reply" for the purposes of fault detection and isolation, and
  mechanisms for reliably sending the echo reply.

  This document obsoletes RFCs 4379, 6424, 6829, and 7537.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc4379bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc4379bis/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2826/

    The MPLS working group request that

  Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures
                  draft-ietf-mpls-rfc4379bis

Is publsihed as an RFC on the standards track.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  We request that the document is publsihed as a Proposed Standard.
  The document header says "Standards Track".
  The document is a bis of a widely implemented and deployed
  standards track specification.

  Background:
  When the working group started to work on this update of RFC 4379
  (draft-ietf-mpls-rfc4379bis) the intention was to go for an
  Internet Standard. However, when working on the updates,
  especially incorporaating and obsoleting newer RFCs we found that
  we needed more time to go through the and verify the criteria for
  Internet Standard, we have therefor choosen to request publication
  of a Proposed Standard version and will within the coming year try
  to be ready to supply all the information necessary for IS.

  The cuurent editor team has agreed to continue to work to complete
  the IS.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary


  The document specifies an efficient mechanism to detect data plane
  failures in MPLS data plane failures, i.e. failures of an LSPs. 
  The specification consists of two parts:
  - information carried in an MPLS "echo request" and "echo reply"
    for the purposes of fault detection and isolation
  - mechanisms for reliably sending the echo reply messages.

Working Group Summary

  This has been a major work performed by a dedicated to team and
  the work has regularly been reported in f2f meetings and on the
  working group mailing list.

  There is a wide spread recognition that there is a need to
  consolidate the LSP Ping specificaion (a widely deployed
  technology) into a smaller number of documents.

  The support for publishing this document is solid.

Document Quality

  RFC 4379 is one of the most widely implemented and deployed MPLS
  specifications, the documents that are being obsoleted are also
  widely implemented and well deployed.

  No specific reviews, other than what has been done within the
  working group, are necessary.


Personnel

  Loa Andersson is Document Shepherd.
  Deborah Brungard is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd reviewed the entire set of LSP Ping documents
  (RFCs and working in progress). After discussing with other members
  of the working group, the shepherd/wg chair was part of preparing
  the proposal to initiate a document consolidation. The proposal was
  accepted by the working group.
  The shepherd has closely followed the work since the start and
  reviewed the document several times, including the inital work
  plans, the first version of the individual document, the version
  going into MPLS-RT review and wg adoption poll, as well as the
  version for MPLS wg last call.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No such concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No such reviews necessary.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No such concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  All the memebers of the editor team have (on the wg maiing list)
  verified two things
  - that they are unaware of any IPR that relates to the draft in
    general, other than what has already been disclosed against the
    RFCs that are being obsoleted (if approved) — see question (8)”
  - that they unaware of an IPRs that relates to the delta
    information added as part of producing the bis-document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  Being a bis document the IPR situation is a bit complicated, since
  part of creating the the bis involves merging documents that some
  of them has IPRs disclosed against them.

  This is the information given to the working group at wglc:

  "There are no IPR disclosures directly against draft. However there
  are IPR disclosure against the RFC's that will be obsoleted if
  rfc4379bis is approved.

  There is one IPR disclosure against RFC 4379.

  There is one IPR disclosure against RFC 6424.

  There is one IPR disclosure against RFC 6829.

  The other obsoleted draft has no IPR disclosures."

  The holder of the IPR disclosure against RFC 4379, chose to update
  the disclosure so it now also cover draft-ietf-mpls-rfc4379bis.

  The existing IPR disclosures has not caused any concerns when it
  comes to progressing the document.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  The consensus is very solid. 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No such threats.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  The idnits tool gives a couple of warnings
  - the boiler plate, since the work on RFC 4379 pre-dats RFC 5378
    and it has not been possible to contact all the authors and
    contributors for RFC 4379 we are using the pre-RFC5378
    disclaimer.

  - use of IP addresses, the idnits gives gives us a warning on the
    use of IP addresses and raise the question if we should use
    "example" addresses instead. We have rechecked the use of IP
    addresses and found nothing that needs to be changed.

  - the idnits also ask about "code sections" which it is says may
    be present in the document, this is not so and the addition of
    and is not required.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No such formal reviews required.

(13) Have all references within this document been identified as
either normative or informative?

  Yes, the references are correctly identified.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  All normative references are to existing standard track RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No downward references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  This document obsoletes RFCs 4379, 6424, 6829, and 7537.

  They are all listed in the Abstract and Introduction.
  (Even though the nits tool claim that the RFC 7537 is missing in
  the abstract.)


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  The IANA section of draft-ietf-mpls-rfc4379bis combines the IANA
  sections of all the obsoleted RFCs, the only real change that IANA
  is asked to perform is to change the references so they point to
  this document.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No such registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  Other than idnits, no such reviews necessary.





    The MPLS working group request that

  Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures
                  draft-ietf-mpls-rfc4379bis

Is publsihed as an RFC on the standards track.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  We request that the document is publsihed as a Proposed Standard.
  The document header says "Standards Track".
  The document is a bis of a widely implemented and deployed
  standards track specification.

  Background:
  When the working group started to work on this update of RFC 4379
  (draft-ietf-mpls-rfc4379bis) the intention was to go for an
  Internet Standard. However, when working on the updates,
  especially incorporaating and obsoleting newer RFCs we found that
  we needed more time to go through the and verify the criteria for
  Internet Standard, we have therefor choosen to request publication
  of a Proposed Standard version and will within the coming year try
  to be ready to supply all the information necessary for IS.

  The cuurent editor team has agreed to continue to work to complete
  the IS.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary


  The document specifies an efficient mechanism to detect data plane
  failures in MPLS data plane failures, i.e. failures of an LSPs. 
  The specification consists of two parts:
  - information carried in an MPLS "echo request" and "echo reply"
    for the purposes of fault detection and isolation
  - mechanisms for reliably sending the echo reply messages.

Working Group Summary

  This has been a major work performed by a dedicated to team and
  the work has regularly been reported in f2f meetings and on the
  working group mailing list.

  There is a wide spread recognition that there is a need to
  consolidate the LSP Ping specificaion (a widely deployed
  technology) into a smaller number of documents.

  The support for publishing this document is solid.

Document Quality

  RFC 4379 is one of the most widely implemented and deployed MPLS
  specifications, the documents that are being obsoleted are also
  widely implemented and well deployed.

  No specific reviews, other than what has been done within the
  working group, are necessary.


Personnel

  Loa Andersson is Document Shepherd.
  Deborah Brungard is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd reviewed the entire set of LSP Ping documents
  (RFCs and working in progress). After discussing with other members
  of the working group, the shepherd/wg chair was part of preparing
  the proposal to initiate a document consolidation. The proposal was
  accepted by the working group.
  The shepherd has closely followed the work since the start and
  reviewed the document several times, including the inital work
  plans, the first version of the individual document, the version
  going into MPLS-RT review and wg adoption poll, as well as the
  version for MPLS wg last call.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No such concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No such reviews necessary.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No such concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  All the memebers of the editor team have (on the wg maiing list)
  verified two things
  - that they are unaware of any IPR that relates to the draft in
    general, other than what has already been disclosed against the
    RFCs that are being obsoleted (if approved) — see question (8)”
  - that they unaware of an IPRs that relates to the delta
    information added as part of producing the bis-document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  Being a bis document the IPR situation is a bit complicated, since
  part of creating the the bis involves merging documents that some
  of them has IPRs disclosed against them.

  This is the information given to the working group at wglc:

  "There are no IPR disclosures directly against draft. However there
  are IPR disclosure against the RFC's that will be obsoleted if
  rfc4379bis is approved.

  There is one IPR disclosure against RFC 4379.

  There is one IPR disclosure against RFC 6424.

  There is one IPR disclosure against RFC 6829.

  The other obsoleted draft has no IPR disclosures."

  The holder of the IPR disclosure against RFC 4379, chose to update
  the disclosure so it now also cover draft-ietf-mpls-rfc4379bis.

  The existing IPR disclosures has not caused any concerns when it
  comes to progressing the document.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  The consensus is very solid. 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No such threats.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  The idnits tool gives a couple of warnings
  - the boiler plate, since the work on RFC 4379 pre-dats RFC 5378
    and it has not been possible to contact all the authors and
    contributors for RFC 4379 we are using the pre-RFC5378
    disclaimer.

  - use of IP addresses, the idnits gives gives us a warning on the
    use of IP addresses and raise the question if we should use
    "example" addresses instead. We have rechecked the use of IP
    addresses and found nothing that needs to be changed.

  - the idnits also ask about "code sections" which it is says may
    be present in the document, this is not so and the addition of
    and is not required.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No such formal reviews required.

(13) Have all references within this document been identified as
either normative or informative?

  Yes, the references are correctly identified.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  All normative references are to existing standard track RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No downward references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  This document obsoletes RFCs 4379, 6424, 6829, and 7537.

  They are all listed in the Abstract and Introduction.
  (Even though the nits tool claim that the RFC 7537 is missing in
  the abstract.)


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  The IANA section of draft-ietf-mpls-rfc4379bis combines the IANA
  sections of all the obsoleted RFCs, the only real change that IANA
  is asked to perform is to change the references so they point to
  this document.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No such registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  Other than idnits, no such reviews necessary.

(20) Authors listed - this bullet has been added by the shepherd
since a former AD has pointed out that is praxis that the authors of
the updated RFC (RFC 4379) are listed on the first page.

  The shepherd doubt that this is the praxis, it might have been done
  for some bis documents, but it is not a praxis across the board.

  In this case it would mean that we would add one name to the front
  page of the updated document. There are only two names on the
  RFC 4379 front page, and since one of the original authors are part
  of the current editor team, the delta is just one name. This would
  make the total number of authors listed on the front page six.
 
  The shepherd think it would be a good idea to add George as a
  sixth name becasue of his solid contribution to LSP Ping over
  the years. Comments from George, authors and AD appreciated.