MPLS Multicast Encapsulations
draft-ietf-mpls-multicast-encaps-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
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-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 and MPLS Multicast Encapsulations there are no ID nits issues … This is the proto writeup for: MPLS Upstream Label Assignment and Context Specific Label Space and MPLS Multicast Encapsulations 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 |