This document was returned to the working group and the authors after
AD evaluation and some very late comment. The document has been updated and
a refresh of the Shepherd Writeup is necessary. The Shepherd has chose to do
this refresh creating a zebra document, i.e. the new information has been
introduced into the earlier "white" document as "black" stripes. The "black"
stripes are preceeded by "2014-09-30"
Changes are expected over time. This version is dated 24 February 2012.
2014-09-30
This version is dated 2014-09-30.
The MPLS working group request that
Updates to LDP for IPv6
draft-ietf-mpls-ldp-ipv6-10
2014-09-30
draft-ietf-mpls-ldp-ipv6-14
ís published 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?
The Label Distribution Protocol (LDP) specification defines procedures
to exchange label bindings over either IPv4, or IPv6 or networks that
uses both IPv4 and IPv6. This document corrects and clarifies the LDP
proceedures and behaviors when IPv6 network is used (with or without IPv4).
In doing so this document updates RFC 5036 and needs to be published
on Standards Track-
It should be published as a Proposed Standard, the document header says
"Standards track"!.
(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 LDP [RFC5036] specification defines procedures and messages for
exchanging FEC-label bindings over either IPv4 or IPv6 or networks deploying
both types of technologies (e.g. dual-stack networks).
Although LDP is defined in RFC5036 so that it may be used over IPv4
and/or IPv6, RFC 5036 really does not really allow for interoperable
implementations of LDP over IPv6. In this respect RFC 5036 is too
under-specified to be implemented over IPv6.
Consequently, this document list 7 deficiencies in RFC5036 (see the Introduction)
that needs to be addressed to allow interoperable LDP implementations in
IPv6 networks
.
The documen and also specifies how these deficiencies should be adressed
in regards to IPv6 usage. In general there can be said that RFC 5036 lack
in detail, rules and procedures for using LDP in IPv6 enabled networks
(IPv6-only or Dual-stack networks).
Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?
This document has a rather long history even though it is a document that is
focused to address a limited scope of issues - some of the issues are in
themselves of considerable complexity
The first individual version of this draft was published in February 2008,
it was well received, but the timing was a bit unfortunate, it was about the same
time as the start of the MPLS-TP work and the MPLS wg were a bit swamped
by a large number of MPLS-TP drafts.
However, we had a good discussion on the list and the document was accepted
as a working group document in November 2010. Followed by a good discussion,
and the wglc in Aug 2011 were uneventful due to that the issues had been
addressed. However after reposting a new version there were some questions
put to the working group and that generated further comments. One of these
comments turned out to be hard to resolve given the disagreement between the
authors and reviewers.. It had to do with the number of LDP Hello
adjacencies needed to be kept and maintained on the receiver side between
a pair LSRs with both IPv4 and IPv6 stacks, it did take us quite a long time
to resolve this.
When we had the resolution we did a short working group last call on the
changes that been introduced between the two working group last calls.
This short wglc call only received supportive comments. The current version
is agreed upon by all parties.
However it would not be this document if we had not received a new set of
comments outside the scope of the short working group last call. The comments
are supportive and will improve the document. A new version has been posted
addressing these comments.
2014-09-30
The document was returned to the wg and the authors due to comments during
the AD Evaluation and late comments.
These comments were resolved and were verified (mostly) in a short wglc (July 12, 2014).
However there were comments claiming that "some" implementations were not
RFC 5036 compatible and started to flap LDP sessions. In one case we have been able
to verify that this a temporary issue that has been resolved.
It was proposed that this document should be fixed so that both RFC 5036 compatible
and non-comptible implementations would work.
In general the Shepherd and wg chairs belive that implementations should be RFC 5036
compatible.
Some text has been added to this document to address the comment(s). see section 8
paragraph 2.
Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?
A mail has been sent to the working group asking for implementations and
the shepherd write-up will be updated as we receive this information.
So far this implementation poll has resulted in that we know of one
implementation under way.
The key reviewers are all mentioned in the acknowledgment section.
There are significant vendor and operator interest in this draft.
No MIB Doctor or Media Type reviews are necessary.
2014-09-30
We are aware of at least two implementations of this draft.
Personnel
Who is the Document Shepherd? Who is the Responsible Area
Director?
Loa Andersson is the Document Shepherd.
Adrian Farrel is the responsible AD.
(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 has reviewed the document several times, before
the wg adoption poll and both wglc's. But also while resolving the outstanding
issues.
2014-09-30
The Shepherd reviewed the document prior to the short wglc, and has also had
the oportunity to review the document several times (the entire document and
in part) during the discussion after the short wglc.
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
No such concerns!
2014-09-30
However see the response to question 9.
(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 needed.
(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, all the outstanding issues have been resolved.
(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 authors has stated on the working group mailing list that they
unaware of an IPR related to this document.
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
There are no IPR disclosures relevant to this 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?
It has taken time, but the working group does now support this document.
2014-09-30
We have not been able to fully converge on the last comment, the Shepherd
and wg chairs are convinced that version -14 represent the working group
consensus and think we should progress the document now.
(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!
2014-09-30
Having said that, it is also likely that we will see some of the comments
from the short wglc repeated in IETF LC.
(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
The document passes the nits tool clean.
The nits tool gives a warning about IP addresses not compliant to
and RFC3849: however the IP addresses in the document are not
examples in the sense defined in these RFCs.
The nits tool also point that we use a "disclaimer for pre-RFC5378 work".
For the time being this disclaimer is correct, but for reasons partly
outside the scope of this document we have started process to see if
if the authors/contributors to RFC 3036, RFC 5036 and this document
are willing to grant the BCP 78 rights to the IPR trust.
We have identified 17 authors and contributors to RFC 3036, RFC 5036 and
draft-ietf-mpls-ldp-ipv6 that needs to grant the BFC 78 rights for these documents
to the IETF Trust.
So far there are two (2) that we have are not certain that we have managed to
find mail addresses to; there are eight (8) that have not yet responded to the mail
sent out; and seven (7) that have responded that they are willing to grant their
BCP 78 rights. Considering that this has been done during the Holiday season
it is not bad.
The shepherd write-up will be updated as further responses are received.
Note: that if we fail to receive acknowledgment from all, we can still go ahead
keeping the pre-BCP boilerplate 78 in the document.
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
No such reviews necessary
(13) Have all references within this document been identified as
either normative or informative?
Yes they have been correctly split.
(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 as to existing standards 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 updates RFC5036, this is well captured in the Abstract and
and in the Introduction.
(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).
There are no requests for IANA actions in 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 new IANA registries that require Expert Review.
(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.
No sections written in formal language.