Skip to main content

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