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
<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.