Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context
draft-ietf-l3vpn-mldp-vrf-in-band-signaling-03
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2014-05-27
|
03 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2014-05-05
|
03 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2014-05-05
|
03 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2014-03-14
|
03 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
2014-03-07
|
03 | Adrian Farrel | Shepherding AD changed to Adrian Farrel |
2014-03-04
|
03 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2014-03-03
|
03 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2014-03-03
|
03 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2014-03-02
|
03 | (System) | IANA Action state changed to In Progress |
2014-03-01
|
03 | Cindy Morgan | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2014-02-28
|
03 | (System) | RFC Editor state changed to EDIT |
2014-02-28
|
03 | (System) | Announcement was received by RFC Editor |
2014-02-27
|
03 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed |
2014-02-27
|
03 | Cindy Morgan | IESG has approved the document |
2014-02-27
|
03 | Cindy Morgan | Closed "Approve" ballot |
2014-02-27
|
03 | Cindy Morgan | Ballot approval text was generated |
2014-02-27
|
03 | Stewart Bryant | Ballot writeup was changed |
2014-02-27
|
03 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2014-02-21
|
03 | Stewart Bryant | Ballot writeup was changed |
2014-02-20
|
03 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2014-02-20
|
03 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2014-02-20
|
03 | Brian Haberman | [Ballot comment] Thanks for the discussion on the handling of scoped IPV6 scoped multicast addresses. Moved to a COMMENT for historical reasons... I have a … [Ballot comment] Thanks for the discussion on the handling of scoped IPV6 scoped multicast addresses. Moved to a COMMENT for historical reasons... I have a general concern, but I am not sure if it is the fault of this document, RFC 6513, or RFC 6826 so let's discuss it here for the time being... How are non-global-scoped IPv6 multicast addresses handled? There is no discussion in this document about verifying that the creation of an MDT is not violating a scope boundary. RFC 4007 (section 10) is very clear on the rules that must be followed when creating forwarding state. If these rules are not followed, scoped packets can leak out of their allowed zone creating a vulnerability. Notionally, I would have expected to see something in Section 2 saying that scopes need to be checked as a part of the signaling procedure. There does not appear to be any discussion of scoped addresses in 6513, 6512, or 6826. Where in the MPLS VPN specs is support for scoped multicast addresses defined? |
2014-02-20
|
03 | Brian Haberman | [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from Discuss |
2014-02-20
|
03 | Stewart Bryant | Ballot writeup was changed |
2014-02-20
|
03 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2014-02-20
|
03 | Brian Haberman | [Ballot discuss] I have a general concern, but I am not sure if it is the fault of this document, RFC 6513, or RFC … [Ballot discuss] I have a general concern, but I am not sure if it is the fault of this document, RFC 6513, or RFC 6826 so let's discuss it here for the time being... How are non-global-scoped IPv6 multicast addresses handled? There is no discussion in this document about verifying that the creation of an MDT is not violating a scope boundary. RFC 4007 (section 10) is very clear on the rules that must be followed when creating forwarding state. If these rules are not followed, scoped packets can leak out of their allowed zone creating a vulnerability. Notionally, I would have expected to see something in Section 2 saying that scopes need to be checked as a part of the signaling procedure. There does not appear to be any discussion of scoped addresses in 6513, 6512, or 6826. Where in the MPLS VPN specs is support for scoped multicast addresses defined? |
2014-02-20
|
03 | Brian Haberman | [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman |
2014-02-20
|
03 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2014-02-20
|
03 | Stephen Farrell | [Ballot comment] It seems kind of incredible that the security considerations here are so simple, when we're glueing together two different ways to do multicast. … [Ballot comment] It seems kind of incredible that the security considerations here are so simple, when we're glueing together two different ways to do multicast. Surely at least the security considerations relevant to PIM ought be noted? Would it (un)fair of me to guess that perhaps nobody has really looked for potential new vulnerabilities here? As it happens, I don't have the time before the telechat, nor probably the MC clue, to help with that so this is not a DISCUSS, but you could set my mind at rest if you told me that yes, a bunch of folks with that clue and some security clue have really spent time looking at this. |
2014-02-20
|
03 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2014-02-20
|
03 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2014-02-19
|
03 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2014-02-19
|
03 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2014-02-19
|
03 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2014-02-19
|
03 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2014-02-17
|
03 | Barry Leiba | [Ballot comment] No objection, and no complaint at all here... just an observation: I find it interesting that an 11-page document has six authors. |
2014-02-17
|
03 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2014-02-16
|
03 | Adrian Farrel | [Ballot comment] The last paragraph of Section 1 begins: In order to use the mLDP in-band signaling procedures... ...but "the mLDP in-band signaling" is … [Ballot comment] The last paragraph of Section 1 begins: In order to use the mLDP in-band signaling procedures... ...but "the mLDP in-band signaling" is a new term. It turns out that it meas exactly what the previous paragraph ended up saying, viz. encoded into the mLDP FEC element. So I suggest that you update the end of the previous paragraph to read encoded into the mLDP FEC element in what this document terms "mLDP in-band signaling." |
2014-02-16
|
03 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2014-02-15
|
03 | Stewart Bryant | IESG state changed to IESG Evaluation from Waiting for Writeup |
2014-02-15
|
03 | Stewart Bryant | Placed on agenda for telechat - 2014-02-20 |
2014-02-15
|
03 | Stewart Bryant | Changed consensus to Yes from Unknown |
2014-02-15
|
03 | Stewart Bryant | Ballot has been issued |
2014-02-15
|
03 | Stewart Bryant | [Ballot Position Update] New position, Yes, has been recorded for Stewart Bryant |
2014-02-15
|
03 | Stewart Bryant | Created "Approve" ballot |
2014-02-15
|
03 | Stewart Bryant | Ballot writeup was changed |
2014-02-14
|
03 | Francis Dupont | Assignment of request for Last Call review by GENART to Francis Dupont was rejected |
2014-02-12
|
03 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2014-02-10
|
03 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2014-02-10
|
03 | Amanda Baber | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-l3vpn-mldp-vrf-in-band-signaling-03. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-l3vpn-mldp-vrf-in-band-signaling-03. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. IANA's reviewer has the following comments/questions: IANA understands that, upon approval of this document, there is a single action which must be completed. In the the Label Distribution Protocol (LDP) Parameters registry "LDP MP Opaque Value Element basic type," located at http://www.iana.org/assignments/ldp-namespaces/ four new LDP MP Opaque Value Elements are to be registered as follows: Value [ TBD-at-registration ] Name: Transit VPNv4 Source TLV type Reference: [ RFC-to-be ] Value [ TBD-at-registration ] Name: Transit VPNv6 Source TLV type Reference: [ RFC-to-be ] Value [ TBD-at-registration ] Name: Transit VPNv4 Bidir TLV type Reference: [ RFC-to-be ] Value [ TBD-at-registration ] Name: Transit VPNv6 Bidir TLV type Reference: [ RFC-to-be ] IANA notes that the authors have requested a value of: 250 for the Transit VPNv4 Source TLV type, and 251 for the Transit VPNv6 Source TLV type IANA will make every effort to accommodate those requests. IANA understands that this is the only action 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. |
2014-02-02
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Juergen Quittek |
2014-02-02
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Juergen Quittek |
2014-01-31
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2014-01-31
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2014-01-30
|
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Warren Kumari |
2014-01-30
|
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Warren Kumari |
2014-01-29
|
03 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2014-01-29
|
03 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Multipoint Label Distribution Protocol In-Band … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Multipoint Label Distribution Protocol In-Band Signaling in a VRF Context) to Proposed Standard The IESG has received a request from the Layer 3 Virtual Private Networks WG (l3vpn) to consider the following document: - 'Multipoint Label Distribution Protocol In-Band Signaling in a VRF Context' 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 2014-02-12. 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 An IP Multicast Distribution Tree (MDT) may traverse both label switching (i.e. - Multi-Protocol Label Switching, or MPLS) and non- label switching regions of a network. Typically the MDT begins and ends in non-MPLS regions, but travels through an MPLS region. In such cases, it can be useful to begin building the MDT as a pure IP MDT, then convert it to an MPLS Multipoint Label Switched Path (MP- LSP) when it enters an MPLS-enabled region, and then convert it back to a pure IP MDT when it enters a non-MPLS-enabled region. Other documents specify the procedures for building such a hybrid MDT, using Protocol Independent Multicast (PIM) in the non-MPLS region of the network, and using Multipoint Extensions to Label Distribution Protocol (mLDP) in the MPLS region. This document extends those procedures to handle the case where the link connecting the two regions is a "Virtual Routing and Forwarding Table" (VRF) link, as defined in the "BGP IP/MPLS VPN" specifications. However, this document is primarily aimed at particular use cases where VRFs are used to support multicast applications other than Multicast VPN. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-l3vpn-mldp-vrf-in-band-signaling/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-l3vpn-mldp-vrf-in-band-signaling/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2216/ |
2014-01-29
|
03 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2014-01-29
|
03 | Stewart Bryant | Last call was requested |
2014-01-29
|
03 | Stewart Bryant | Ballot approval text was generated |
2014-01-29
|
03 | Stewart Bryant | Ballot writeup was generated |
2014-01-29
|
03 | Stewart Bryant | State changed to Last Call Requested from Publication Requested |
2014-01-29
|
03 | Stewart Bryant | Last call announcement was generated |
2014-01-17
|
03 | Martin Vigoureux | IETF WG state changed to Submitted to IESG for Publication |
2014-01-17
|
03 | Martin Vigoureux | IESG state changed to Publication Requested |
2014-01-17
|
03 | Martin Vigoureux | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (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 requested status is Proposed Standard. The Document is a protocol specification which requires the assignment of code points by the IANA, from a "Standards Action" registry. This justifies the type of RFC being requested. (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 An IP Multicast Distribution Tree (MDT) may traverse both label switching (i.e. - Multi-Protocol Label Switching, or MPLS) and non- label switching regions of a network. Typically the MDT begins and ends in non-MPLS regions, but travels through an MPLS region. In such cases, it can be useful to begin building the MDT as a pure IP MDT, then convert it to an MPLS Multipoint Label Switched Path (MP- LSP) when it enters an MPLS-enabled region, and then convert it back to a pure IP MDT when it enters a non-MPLS-enabled region. Other documents specify the procedures for building such a hybrid MDT, using Protocol Independent Multicast (PIM) in the non-MPLS region of the network, and using Multipoint Extensions to Label Distribution Protocol (mLDP) in the MPLS region. This document extends those procedures to handle the case where the link connecting the two regions is a "Virtual Routing and Forwarding Table" (VRF) link, as defined in the "BGP IP/MPLS VPN" specifications. However, this document is primarily aimed at particular use cases where VRFs are used to support multicast applications other than Multicast VPN. Working Group Summary The WG supports this Document and its progress. Document Quality Two implementations of this protocol specification are known. The Document has been reviewed by experts and these experts are acknowledged in the appropriate section of the Document. Personnel Martin Vigoureux (L3VPN co-chair) is the Document Shepherd Stewart Bryant 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 has reviewed the recent revisions of this document and the last version as well. 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 concern. The Document has been thoroughly reviewed as part of a Routing Directorate review. (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 specific additional review is 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. There is no specific issue or concern with this Document. (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. Yes, all authors have confirmed that they are not aware of any undisclosed IPR that applies 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. Yes, an IPR disclosure exists: https://datatracker.ietf.org/ipr/2216/ The formal disclosure came a little bit late in the process (at the time of WG Last Call). However, the lead author had notified the Working Group (at the time of adoption by the Working Group) that an existing IPR disclosure (on another draft) was also applicable to this Document. This information has been reminded to the group within the WG Last Call e-mail. Satisfactory explanations were also given regarding why the appropriate disclosure took time. The Working Group was given the opportunity to speak with regards to the "late" disclosure. No concern has been raised. (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 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 extreme position/situation exists for that Document. (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 result of the thorough nits check is clean. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review criteria needed. (13) Have all references within this document been identified as either normative or informative? Yes. The references are appropriately categorized. (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? No. All Normative references are in RFC status. (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 reference. (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 does not change the status of existing RFCs. However as per the Document, it "extends the procedures from RFC6826 to handle the case where the link connecting the two regions is a "Virtual Routing and Forwarding Table" (VRF) link, as defined in the "BGP IP/MPLS VPN" specifications [RFC6513].", but no changes are brought to RFC6826. (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 Document requests the IANA to assign 4 new code-points from an existing registry (LDP MP Opaque Value Element basic type), defined by RFC 6388 and for which the registration procedure is by Standards Action. Out of these 4 new code points the Documents kindly asks the IANA to assign two specific values (250 for the Transit VPNv4 Source TLV and 251 for the Transit VPNv6 Source TLV). These values are strongly suggested as they are already part of an existing implementation. An early allocation procedure should have been followed in such a situation. It has not been the case. The WG co-Chairs have decided that initiating the procedure when the document is ready for publication would not bring a lot of benefits, thus the maintained direct request in the 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 registry is required and thus no expert review needed. (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 such section in the Document. |
2014-01-17
|
03 | Martin Vigoureux | State Change Notice email list changed to l3vpn-chairs@tools.ietf.org, draft-ietf-l3vpn-mldp-vrf-in-band-signaling@tools.ietf.org |
2014-01-17
|
03 | Martin Vigoureux | Responsible AD changed to Stewart Bryant |
2014-01-17
|
03 | Martin Vigoureux | Working group state set to Submitted to IESG for Publication |
2014-01-17
|
03 | Martin Vigoureux | IESG state set to Publication Requested |
2014-01-17
|
03 | Martin Vigoureux | IESG process started in state Publication Requested |
2014-01-17
|
03 | Martin Vigoureux | Changed document writeup |
2014-01-17
|
03 | Martin Vigoureux | Changed document writeup |
2014-01-17
|
03 | IJsbrand Wijnands | New version available: draft-ietf-l3vpn-mldp-vrf-in-band-signaling-03.txt |
2014-01-08
|
02 | Martin Vigoureux | Changed document writeup |
2013-12-10
|
02 | Martin Vigoureux | Intended Status changed to Proposed Standard from None |
2013-12-10
|
02 | Martin Vigoureux | Document shepherd changed to Martin Vigoureux |
2013-12-10
|
02 | Martin Vigoureux | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2013-12-10
|
02 | Martin Vigoureux | Annotation tag Other - see Comment Log cleared. |
2013-11-19
|
02 | IJsbrand Wijnands | New version available: draft-ietf-l3vpn-mldp-vrf-in-band-signaling-02.txt |
2013-10-17
|
(System) | Posted related IPR disclosure: Cisco's Statement of IPR Related to draft-ietf-l3vpn-mldp-vrf-in-band-signaling-01 | |
2013-06-21
|
01 | IJsbrand Wijnands | New version available: draft-ietf-l3vpn-mldp-vrf-in-band-signaling-01.txt |
2012-12-20
|
00 | Thomas Morin | Annotation tag Other - see Comment Log set. |
2012-12-20
|
00 | Thomas Morin | Please mark as Replaces: draft-wijnands-l3vpn-mldp-vrf-in-band-signaling . Thanks. |
2012-12-20
|
00 | IJsbrand Wijnands | New version available: draft-ietf-l3vpn-mldp-vrf-in-band-signaling-00.txt |