'[mpls] request for publication: draft-ietf-mpls-mldp-in-band-signaling'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mpls
Subject:    [mpls] request for publication: draft-ietf-mpls-mldp-in-band-signaling
From:       Loa Andersson <loa () pi ! nu>
Date:       2012-09-07 12:59:37
Message-ID: 5049EFB9.4080309 () pi ! nu
[Download RAW message or body]

IESG,

The MPLS working group request that:

    Multipoint LDP in-band signaling for Point-to-Multipoint and
              Multipoint-to-Multipoint Label Switched Paths

                draft-ietf-mpls-mldp-in-band-signaling-06

is published as an RFC on the standards track.

Please find the shepherd write-up included.

/Loa

-- 

Loa Andersson                         email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager            loa@pi.nu
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

["mldp-inband-signaling.txt" (text/plain)]

 (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 MPLS working group request that: 

   Multipoint LDP in-band signaling for Point-to-Multipoint and 

             Multipoint-to-Multipoint Label Switched Paths

               draft-ietf-mpls-mldp-in-band-signaling-06

   is published as an RFC on the standards track.

   Since this is an extension to mLDP, (a standard track document), 
   it also need to be on the standards track. There are service 
   provider looking to use this solution in production networks.

(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

   Sometimes an IP multicast tree, constructed by Protocol Independent

   Multicast (PIM), needs to pass through an MPLS domain in which

   Multipoint LDP (mLDP) Point-to-Multipoint and/or Multipoint-to-

   Multipoint Labels Switched Paths (LSPs) can be created. The part of

   the IP multicast tree that traverses the MPLS domain can be

   instantiated as a multipoint LSP. When a PIM Join message is

   received at the border of the MPLS domain, information from that

   message is encoded into mLDP messages.  When the mLDP messages reach

   the border of the next IP domain, the encoded information is used to

   generate PIM messages that can be sent through the IP domain.  The

   result is an IP multicast tree consisting of a set of IP multicast

   sub-trees that are spliced together with a multipoint LSP.

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?

   The MPLS working group has a few non-MPLS-TP documents that fell

   into the cracks when we were allocating almost all of our time to

   wrapping up the MPLS-TP documents. This document is one of them. 
   Version -04 of the document was working group last called in 
   October 2011, it was updated based on on comments during working
   group last call. After that the shepherd fumbled and left the 
   draft without attention for almost 6 months.

   When we finally go around to pau attention to the document again
   the document shepherd re-reviewed it and found there were no

   reason to re-issue a working group last call. The draft is stable. 

   This document has a strong support in the working group

   and has been well reviewed. We had good discussions both

   on the mailing list and at the f2f meetings.

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?

   We know of existing implementations and intentions to implement

   this specification.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area

  Director?

   Loa Andersson is the document shepherd.

   Adrian Farrel is/will be 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 have reviewed the document several times, 

   e.g. before issueing to poll to see if there were support to make
   it a working hroup document, before the WG last call, and recently
   when deciding to progress the document without a new working 
   group last call.

   The document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or

breadth of the reviews that have been performed?

   No.

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

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

.

   Before requesting publication the working group chairs did an IPR poll

   in the working group and the authors, asking any members of the working 

   group to speak up if they were aware of IPRs. The same poll required  

   the authors either to indicate if they were aware of IPRs or say that 

   they were not.

   All the authors said they were not aware of any IPRs, other than the

   previously filed IPR claim (ID #1305).

(8) Has an IPR disclosure been filed that references this document?

If so, summarize any WG discussion and conclusion regarding the IPR

disclosures.

   There is one IPR claim filed for this document (ID #1305).

   The IPR was original filed against the individual "ancestor" 
   document draft-wijnands-mpls-mldp-in-band-signaling-02.

   The filing is no longer visible from the mpls working group web 
   page, but hs been brought to the attention of the working.

(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 working group is behind this document. It has been well discussed

   and reviewed.  

(10) Has anyone threatened an appeal or otherwise indicated extreme 

discontent? If so, please summarize 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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts

Checklist). Boilerplate checks are not enough; this check needs to be

thorough.

   The idnits-tool flags three "problems"

   1. There are three outdated references

   2. There is a disclaimer for pre-RFC5378 work, that is not 

      really needed.

   3. Some of the references are to older version of the referenced
      document

   The authors will be required to fix this if a new version is 

   needed or it will be captured in a RFC Editors note.

   No other nits found.

(12) Describe how the document meets any required formal review

criteria, such as the MIB Doctor, media type, and URI type reviews.

   There are no such formal review criteria.

(13) Have all references within this document been identified as

either normative or informative?

   Yes.

(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?

   There is one normative reference that point to an Internet Draft,

   but this this draft has however been published as an RFC.

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

   No.

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

   This document requests four standards action values from "LDP MP 

   Opaque Value Element basic type" a registry defined in RFC 6388.

   The requests for IANA allocation are clearly written.

(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 requires 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 formal language.

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

[prev in list] [next in list] [prev in thread] [next in thread] 