Skip to main content

Shepherd writeup

    The MPLS working group request that 

  Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures

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.

  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.


  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

  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 and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be

  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 

  - 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 
    <CODE BEGINS> and <CODE ENDS> 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.