MPLS Multicast Encapsulations
RFC 5332
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2018-12-20
|
10 | (System) | Received changes through RFC Editor sync (changed abstract to 'RFC 3032 established two data link layer codepoints for MPLS, used to distinguish whether the … Received changes through RFC Editor sync (changed abstract to 'RFC 3032 established two data link layer codepoints for MPLS, used to distinguish whether the data link layer frame is carrying an MPLS unicast or an MPLS multicast packet. However, this usage was never deployed. This specification updates RFC 3032 by redefining the meaning of these two codepoints. Both codepoints can now be used to carry multicast packets. The second codepoint (formerly the "multicast codepoint") is now to be used only on multiaccess media, and it is to mean "the top label of the following label stack is an upstream-assigned label". RFC 3032 does not specify the destination address to be placed in the "MAC DA" (Medium Access Layer Destination Address) field of an ethernet frame that carries an MPLS multicast packet. This document provides that specification. This document updates RFC 3032 and RFC 4023. [STANDARDS-TRACK]') |
|
2015-10-14
|
10 | (System) | Notify list changed from mpls-chairs@ietf.org, draft-ietf-mpls-multicast-encaps@ietf.org to (None) |
|
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
|
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the No Objection position for Lars Eggert |
|
2008-08-15
|
10 | Cindy Morgan | State Changes to RFC Published from RFC Ed Queue by Cindy Morgan |
|
2008-08-15
|
10 | Cindy Morgan | [Note]: 'RFC 5332' added by Cindy Morgan |
|
2008-08-14
|
10 | (System) | RFC published |
|
2008-06-11
|
10 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2008-06-10
|
10 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
|
2008-06-10
|
10 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
|
2008-06-02
|
10 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
|
2008-06-02
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2008-06-02
|
10 | (System) | IANA Action state changed to In Progress |
|
2008-06-02
|
10 | Cindy Morgan | IESG state changed to Approved-announcement sent |
|
2008-06-02
|
10 | Cindy Morgan | IESG has approved the document |
|
2008-06-02
|
10 | Cindy Morgan | Closed "Approve" ballot |
|
2008-06-02
|
10 | Ross Callon | State Changes to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed by Ross Callon |
|
2008-06-02
|
10 | (System) | New version available: draft-ietf-mpls-multicast-encaps-10.txt |
|
2008-05-22
|
10 | Cindy Morgan | State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation by Cindy Morgan |
|
2008-05-22
|
10 | Dan Romascanu | [Ballot comment] I am wondering whether people have not expressed concerns about making incompatible changes on the wire including usage of semantics of Ethernet codepoints … [Ballot comment] I am wondering whether people have not expressed concerns about making incompatible changes on the wire including usage of semantics of Ethernet codepoints values without obsoleting RFC3032 and RFC4023. It is true that the claim is made that nobody does does MPLS multicast according to RFC 3032 and/or 4023 but how can one be sure that an implementation is not written as we speak, or than another SDO is not building some extension based on what are right now standards-track documents. Would not making this document part of a package that includes also 3032bis and 4023bis documents fixing the deprecated codepoint allocation section be a safer way to avoid potential problems? |
|
2008-05-22
|
10 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu |
|
2008-05-22
|
10 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded by Jari Arkko |
|
2008-05-22
|
10 | Pasi Eronen | [Ballot comment] It seems that upstream-label and multicast-encaps drafts are very difficult to understand without each other; perhaps they should be merged. |
|
2008-05-22
|
10 | Pasi Eronen | [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen |
|
2008-05-22
|
10 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
|
2008-05-21
|
10 | Dan Romascanu | [Ballot discuss] I am wondering whether people have not expressed concerns about making incompatible changes on the wire including usage of semantics of Ethernet codepoints … [Ballot discuss] I am wondering whether people have not expressed concerns about making incompatible changes on the wire including usage of semantics of Ethernet codepoints values without obsoleting RFC3032 and RFC4023. It is true that the claim is made that nobody does does MPLS multicast according to RFC 3032 and/or 4023 but how can one be sure that an implementation is not written as we speak, or than another SDO is not building some extension based on what are right now standards-track documents. Would not making this document part of a package that includes also 3032bis and 4023bis documents fixing the deprecated codepoint allocation section be a safer way to avoid potential problems? |
|
2008-05-21
|
10 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu |
|
2008-05-21
|
10 | (System) | State Changes to IESG Evaluation from IESG Evaluation - Defer by system |
|
2008-05-20
|
10 | Ron Bonica | [Ballot Position Update] Position for Ron Bonica has been changed to No Objection from Yes by Ron Bonica |
|
2008-05-15
|
10 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Scott Kelly. |
|
2008-05-15
|
10 | Mark Townsley | [Ballot Position Update] New position, Yes, has been recorded by Mark Townsley |
|
2008-05-09
|
10 | (System) | Removed from agenda for telechat - 2008-05-08 |
|
2008-05-08
|
10 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert |
|
2008-05-08
|
10 | Jari Arkko | State Changes to IESG Evaluation - Defer from IESG Evaluation by Jari Arkko |
|
2008-05-08
|
10 | Lars Eggert | [Ballot discuss] Section 2., paragraph 5: > This document updates RFC 3032 and RFC 4023 by re-specifying the use > of the codepoints. … [Ballot discuss] Section 2., paragraph 5: > This document updates RFC 3032 and RFC 4023 by re-specifying the use > of the codepoints. Note that an implementation that does MPLS > multicast according to RFC 3032 and/or 4023 will be unable to > interoperate with implementations that do MPLS multicast according to > this document. Any attempt to interoperate two such implementations > will result either in black holes or in misrouted packets. However, > since to the best of our knowledge MPLS multicast done according to > RFC 3032 has never been deployed, it is believed though that this > does not present a problem in practice. This document specifically > deprecates the multicast data plane as specified in RFC 3032. Discuss-discuss: Wouldn't it be better to assign a new codepoint, instead of redefining the original "multicast" codepoint, in order to eliminate the potential for interoperability issues? Or are we extremely short on codepoints? |
|
2008-05-08
|
10 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert |
|
2008-05-07
|
10 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
|
2008-05-07
|
10 | Ron Bonica | [Ballot Position Update] New position, Yes, has been recorded by Ron Bonica |
|
2008-05-07
|
10 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
|
2008-05-07
|
10 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
|
2008-05-06
|
10 | Russ Housley | [Ballot comment] Vijay Gurbani provided a Gen-ART review of -07 on 25 Apr 2008. Since then -08 and -09 have been posted, yet the … [Ballot comment] Vijay Gurbani provided a Gen-ART review of -07 on 25 Apr 2008. Since then -08 and -09 have been posted, yet the minor concerns that were pointed out have not been addressed. Vijay said: - S3, second paragraph: s/If Ru and RD/If Ru and Rd/ - Same paragraph: you may want to consider terminating each numbered item except the last one with a comma. - S3, the numbered list towards the *end* of the section: You may want to consider terminating each numbered item with a period. |
|
2008-05-06
|
10 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
|
2008-05-06
|
10 | Lisa Dusseault | [Ballot comment] In the Abstract, the doc says: "Both codepoints can now be used to carry multicast packets." For accuracy, this should be something like … [Ballot comment] In the Abstract, the doc says: "Both codepoints can now be used to carry multicast packets." For accuracy, this should be something like "Both codepoints can now carry both types of traffic." |
|
2008-05-06
|
10 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
|
2008-05-05
|
10 | David Ward | [Ballot Position Update] New position, Yes, has been recorded by David Ward |
|
2008-05-01
|
10 | Ross Callon | [Ballot Position Update] New position, Yes, has been recorded for Ross Callon |
|
2008-05-01
|
10 | Ross Callon | Ballot has been issued by Ross Callon |
|
2008-05-01
|
10 | Ross Callon | Created "Approve" ballot |
|
2008-05-01
|
10 | Ross Callon | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Ross Callon |
|
2008-05-01
|
10 | Ross Callon | Placed on agenda for telechat - 2008-05-08 by Ross Callon |
|
2008-05-01
|
09 | (System) | New version available: draft-ietf-mpls-multicast-encaps-09.txt |
|
2008-04-28
|
08 | (System) | New version available: draft-ietf-mpls-multicast-encaps-08.txt |
|
2008-04-26
|
10 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Scott Kelly |
|
2008-04-26
|
10 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Scott Kelly |
|
2008-04-25
|
10 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
|
2008-04-23
|
10 | Samuel Weiler | Assignment of request for Last Call review by SECDIR to Tobias Gondrom was rejected |
|
2008-04-21
|
10 | Amanda Baber | IANA Last Call comments: Upon approval of this document, the IANA will make the following changes in the "Ether Types" registry at http://www.iana.org/assignments/ethernet-numbers sub-registry "ETHERNET … IANA Last Call comments: Upon approval of this document, the IANA will make the following changes in the "Ether Types" registry at http://www.iana.org/assignments/ethernet-numbers sub-registry "ETHERNET MULTICAST ADDRESSES" OLD: Ethernet Type Address Field Usage 01-00-5E-00-00-00- 0800 Internet Multicast [RFC1112] 01-00-5E-7F-FF-FF 01-00-5E-80-00-00- ???? Internet reserved by IANA 01-00-5E-FF-FF-FF NEW: Ethernet Type Address Field Usage 01-00-5E-00-00-00- 0800 Internet Multicast [RFC1112] 01-00-5E-7F-FF-FF 01-00-5E-80-00-00- 8847/ MPLS Multicast [RFC-mpls-multicast-encaps-07] 01-00-5E-8F-FF-FF 8848 01-00-5E-90-00-00- ???? Internet reserved by IANA 01-00-5E-FF-FF-FF We understand the above to be the only IANA Action for this document. |
|
2008-04-12
|
10 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Tobias Gondrom |
|
2008-04-12
|
10 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Tobias Gondrom |
|
2008-04-11
|
10 | Amy Vezza | Last call sent |
|
2008-04-11
|
10 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
|
2008-04-11
|
10 | Ross Callon | Last Call was requested by Ross Callon |
|
2008-04-11
|
10 | Ross Callon | State Changes to Last Call Requested from Publication Requested by Ross Callon |
|
2008-04-11
|
10 | (System) | Ballot writeup text was added |
|
2008-04-11
|
10 | (System) | Last call text was added |
|
2008-04-11
|
10 | (System) | Ballot approval text was added |
|
2008-02-25
|
10 | Cindy Morgan | This is the proto writeup for: MPLS Upstream Label Assignment and Context Specific Label Space <draft-ietf-mpls-upstream-label-04.txt> and MPLS Multicast Encapsulations <draft-ietf-mpls-multicast-encaps-07.txt ------------------------------------------------------------------------ … This is the proto writeup for: MPLS Upstream Label Assignment and Context Specific Label Space <draft-ietf-mpls-upstream-label-04.txt> and MPLS Multicast Encapsulations <draft-ietf-mpls-multicast-encaps-07.txt ------------------------------------------------------------------------ 1.a) Have the chairs personally reviewed these versions of the Internet Drafts (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? Yes. Both mpls wg co-chairs reviewed the latest version of both documents. Based on the WG comments, we believe the IDs are ready for publication. 1.b) Has the documents had adequate review from both key WG members and key non-WG members? Yes, the document has been through wg last call, and prior to that been subject for a good discussion in the working group. They have also been reviewed by subject-matter experts that are WG members. Do you have any concerns about the depth or breadth of the reviews that have been performed? No. 1.c) Do you have concerns that the documents need more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? No. 1.d) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. No. The internet-drafts were produced by working group memebers with good expereince from MPLS implentations, architecture and testing. 1.e) 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? These documents represent the WG consensus as a whole: the WG as a whole understands and agrees with it. In fact they are the forerunners on a set of multicast documents that have been widely discussed and will be submitted to the IESG once these two documents are approved. 1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director. No. 1.g) Have the chairs verified that the document adheres to all of the ID nits? (see http://www.ietf.org/ID-Checklist.html). In <draft-ietf-mpls-multicast-encaps-07.txt there is one warning, the copyright year is wrong; We'd prefer this to be fixed if the IESG review leads to a "new ID needed" or in a RFC-ed note. In the <draft-ietf-mpls-upstream-label-02.txt> there are no ID nits issues per the automated ID nits check. 1.h) Is the document split into normative and informative references? Yes, though in the draft-ietf-mpls-multicast-encaps document this is done in two "level 1" sections, not as subsections to a "References", we propose that if we re-spin a new draft or in a RFC-Ed note. Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) No, the draft-ietf-mpls-multicast-encaps references the draft-ietf-mpls-upstream-label informatively, while the draft-ietf-mpls-upstream-label has a normative reference to draft-ietf-mpls-multicast-encaps-07.txt 1.i) For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections: * Technical Summary * Working Group Summary * Protocol Quality 1.j) Please provide such a write-up. Recent examples can be found in the "protocol action" announcements for approved documents. --- Technical Summary draft-ietf-mpls-multicast-encaps -------------------------------- The draft-ietf-mpls-multicast-encaps is an update toRFC 3032 which defined two data link layer codepoints for MPLS: one to indicate that the data link layer frame is carrying an MPLS unicast packet, and the other to indicate that the data link layer frame is carrying an MPLS multicast packet. This specification updates RFC 3032 by redefining the meaning of these two codepoints. The former "multicast codepoint" is now to be used only on multiaccess media, and it is to mean "the top label of the following label stack is an upstream-assigned label". The former "unicast codepoint" is to be used in all other cases. Whether the data link layer payload is a unicast MPLS packet or a multicast MPLS packet is now to be determined by looking up the top label, rather than by the codepoint. RFC 3032 does not specify the destination address to be placed in the "MAC DA" field of an ethernet frame which carries an MPLS multicast packet. This document provides that specification. The document updates RFC 3032 and RFC 4023. draft-ietf-mpls-upstream-label ------------------------------ RFC 3031 limits the MPLS architecture to downstream-assigned MPLS labels. RFC 3031 says: "In the MPLS architecture, the decision to bind a particular label L to a particular Forwarding Equivalence Class (FEC) F is made by the Label Switching Router (LSR) which is DOWNSTREAM with respect to that binding. The downstream LSR then informs the upstream LSR of the binding. Thus labels are "downstream-assigned", and label bindings are distributed in the "downstream to upstream" direction." This document introduces the notion of upstream-assigned MPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific Label Space". However, in an RFC-Ed note we should require that the RFC-Ed adds "Updates RFC 3031". --- Working Group Summary The Working Group has a very solid consensus to publish this document as a Proposed Standard. --- Protocol Quality The documents has been reviewed by experts form the MPLS working group as well as being last called in the working, the comments were well received from the experts and the working group, and their comments has been addressed and the document updated. --- Implementations There are no known implementations of the specifications. For the draft-ietf-mpls-upstream-label-03.txt this is to be expected since it is architectural in nature. Implementation of draft-ietf-mpls-multicast-encaps is quite straightforward. However, in and of itself it is not useful. Rather protocol specifications that will make use of this encapsulation are currently being progressed. The reason for pushing this document forward at this time is because: o It forms a clear means of updating RFC 3032 o Ensures that protocols needing such an encapsulation will be done consistently |
|
2008-02-25
|
10 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
|
2007-11-02
|
07 | (System) | New version available: draft-ietf-mpls-multicast-encaps-07.txt |
|
2007-07-05
|
06 | (System) | New version available: draft-ietf-mpls-multicast-encaps-06.txt |
|
2007-06-01
|
05 | (System) | New version available: draft-ietf-mpls-multicast-encaps-05.txt |
|
2007-04-18
|
04 | (System) | New version available: draft-ietf-mpls-multicast-encaps-04.txt |
|
2007-03-01
|
03 | (System) | New version available: draft-ietf-mpls-multicast-encaps-03.txt |
|
2006-09-27
|
02 | (System) | New version available: draft-ietf-mpls-multicast-encaps-02.txt |
|
2006-09-08
|
01 | (System) | New version available: draft-ietf-mpls-multicast-encaps-01.txt |
|
2006-02-16
|
00 | (System) | New version available: draft-ietf-mpls-multicast-encaps-00.txt |