Skip to main content

MPLS Upstream Label Assignment and Context-Specific Label Space
RFC 5331

Revision differences

Document history

Date Rev. By Action
2020-01-21
07 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2015-10-14
07 (System) Notify list changed from mpls-chairs@ietf.org, draft-ietf-mpls-upstream-label@ietf.org to (None)
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Lisa Dusseault
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Pasi Eronen
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Jari Arkko
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Lars Eggert
2009-02-09
(System) Posted related IPR disclosure: Juniper's Statement of IPR related to RFC 5331
2008-08-15
07 Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2008-08-15
07 Cindy Morgan [Note]: 'RFC 5331' added by Cindy Morgan
2008-08-14
07 (System) RFC published
2008-07-11
07 (System) IANA Action state changed to No IC from In Progress
2008-07-11
07 (System) IANA Action state changed to In Progress
2008-07-11
07 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2008-07-11
07 Cindy Morgan IESG state changed to Approved-announcement sent
2008-07-11
07 Cindy Morgan IESG has approved the document
2008-07-11
07 Cindy Morgan Closed "Approve" ballot
2008-07-10
07 Ross Callon State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Ross Callon
2008-07-10
07 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko
2008-07-10
07 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-07-10
07 (System) New version available: draft-ietf-mpls-upstream-label-07.txt
2008-07-09
07 Ross Callon State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Ross Callon
2008-06-16
07 Jari Arkko
[Ballot discuss]
This remains:

4. Both IPv4 and IPv6 need to be addressed in a specification that
  does not relate to something intrinsic to …
[Ballot discuss]
This remains:

4. Both IPv4 and IPv6 need to be addressed in a specification that
  does not relate to something intrinsic to only one of them.
  In some cases we have approved specifications where we knew there
  was a corresponding v4/v6 counterpart in the works. Is there one
  in this case -- after a brief search I could not find one? If not,
  Section 8 needs to be complemented with a specification that works
  for IPv6 as well.
2008-06-12
07 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk
2008-06-12
07 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk
2008-06-09
07 Pasi Eronen [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen
2008-06-05
07 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-06-05
06 (System) New version available: draft-ietf-mpls-upstream-label-06.txt
2008-05-12
07 Lisa Dusseault [Ballot Position Update] Position for Lisa Dusseault has been changed to No Objection from Discuss by Lisa Dusseault
2008-05-09
07 (System) Removed from agenda for telechat - 2008-05-08
2008-05-08
07 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Stephen Farrell.
2008-05-08
07 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert
2008-05-08
07 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2008-05-08
07 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2008-05-08
07 Chris Newman [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman
2008-05-08
07 Pasi Eronen
[Ballot discuss]
It seems that upstream-label and multicast-encaps drafts are very
difficult to understand without each other; perhaps they should be
merged.

In particular, upstream-label …
[Ballot discuss]
It seems that upstream-label and multicast-encaps drafts are very
difficult to understand without each other; perhaps they should be
merged.

In particular, upstream-label is missing some information that is
essential to understanding it (that they can't be used for unicast,
and the rules for combining the two labels types on page 5 of
multicast-encaps).
2008-05-08
07 Pasi Eronen [Ballot Position Update] Position for Pasi Eronen has been changed to Discuss from No Objection by Pasi Eronen
2008-05-08
07 Lars Eggert [Ballot comment]
I agree with Jari's and especially Lisa's DISCUSSes.
2008-05-08
07 Lars Eggert
[Ballot discuss]
INTRODUCTION, paragraph 13:

>    RFC 3031 limits the MPLS architecture to downstream-assigned MPLS
>    labels.  This document introduces the notion of …
[Ballot discuss]
INTRODUCTION, paragraph 13:

>    RFC 3031 limits the MPLS architecture to downstream-assigned MPLS
>    labels.  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".

  Discuss-discuss: Does this document describe a new
  mandatory-to-implement update to the MPLS architecture?
2008-05-08
07 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert
2008-05-07
07 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2008-05-07
07 Ron Bonica [Ballot Position Update] New position, Yes, has been recorded by Ron Bonica
2008-05-07
07 Tim Polk
[Ballot discuss]
This is a discuss discuss and I fully expect to clear before the
telechat.  However, I am curious:

draft-ietf mpls-multicast-encaps includes the statement …
[Ballot discuss]
This is a discuss discuss and I fully expect to clear before the
telechat.  However, I am curious:

draft-ietf mpls-multicast-encaps includes the statement "Unicast labels
MUST be downstream-assigned."  I suspect this will demonstrate my lack
of mpls clue, but I did not get that from this document.  Is there
a discontinuity here?
2008-05-07
07 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Discuss from No Objection by Tim Polk
2008-05-07
07 Tim Polk
[Ballot comment]
[I know I'm beating a dead horse, but that is why it's a comment rather
than a discuss.]

While the document does not …
[Ballot comment]
[I know I'm beating a dead horse, but that is why it's a comment rather
than a discuss.]

While the document does not address procedures for distributing
upstream-assigned labels, there is a section (6) describing the
requirement to do so.  If there are known security considerations
that apply to this requirement it would be useful to say so in
the security considerations.  Inclusion by reference is fine, of course.
2008-05-07
07 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2008-05-07
07 Russ Housley
[Ballot comment]
Section 8 says:
  >
  > The procedure described below applies to LSRs using IPv4 and does
  > not apply to …
[Ballot comment]
Section 8 says:
  >
  > The procedure described below applies to LSRs using IPv4 and does
  > not apply to LSRs only using IPv6. A solution for IPv6 LSRs is
  > outside the scope of this document.
  >
  I hope this is a heads up that another document is coming.
2008-05-07
07 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2008-05-07
07 Pasi Eronen
[Ballot comment]
I agree with Jari's DISCUSS about handling IPv6.

Stephen Farrell's SecDir review identified a number of places
that were slightly difficult to understand, …
[Ballot comment]
I agree with Jari's DISCUSS about handling IPv6.

Stephen Farrell's SecDir review identified a number of places
that were slightly difficult to understand, and could benefit
from some minor editorial changes.

It wouldn't hurt if the security considerations text contained
a pointer to draft-ietf-mpls-mpls-and-gmpls-security-framework.
2008-05-07
07 Pasi Eronen [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen
2008-05-06
07 Jari Arkko
[Ballot discuss]
I believe that there is a need for upstream labels, and that we need
to have a document that specifies them. However, there …
[Ballot discuss]
I believe that there is a need for upstream labels, and that we need
to have a document that specifies them. However, there are technical
issues in this document that need to be corrected before this document
can move forward:

1. The document discusses the concept of a context. The document
  also requires that the label distribution protocol be able to
  indicate the use of upstream labels. But merely knowing that
  upstream labels are used is not a sufficient condition for the
  correct processing to occur. The endpoints must also have the
  same understanding of what context to use. I would suggest
  that the document require the communication of context as well.
  Such communication can be explicit "here's the context" or
  implicit "for protocol X, the context is always the source address
  of the signaling message used to set the label up".

  Perhaps the latter is what the text in Section 7 attempts to do?

    If the tunnel on which Rd receives MPLS packets with a top label
    L is a MPLS tunnel, then Rd determines a) That L is upstream-
    assigned and b) The context for L, from the labels above L in
    the label stack.

  But if so, it needs to be more clearly stated. I cannot determine
  if the above statement says all MPLS tunnels will be upstream
  assigned, or if the appearance of a specific label L will cause the
  receiver to determine that the following labels are the context.

2. What is the upstream label space that Rd reserves for Ru to allocate
  specific values from? The entire syntactically available label space?
  Something that is agreed upon between the two entities? This needs
  to be specified, and if the two entities need to agree on it, that
  must be a requirement for the label distribution protocol.

3. If a downstream node Rd has received an upstream label L from
  node Ru with context C, what guarantee there exists that there is
  no other upstream node that uses the same context C for MPLS
  packets (with either upstream or downstream labels)?

  Perhaps the answer relates to the definition of contexts (item 1)
  but this isn't clear from the document.

4. Both IPv4 and IPv6 need to be addressed in a specification that
  does not relate to something intrinsic to only one of them.
  In some cases we have approved specifications where we knew there
  was a corresponding v4/v6 counterpart in the works. Is there one
  in this case -- after a brief search I could not find one? If not,
  Section 8 needs to be complemented with a specification that works
  for IPv6 as well.
2008-05-06
07 Jari Arkko
[Ballot discuss]
I believe that there is a need for upstream labels, and that we need
to have a document that specifies them. However, there …
[Ballot discuss]
I believe that there is a need for upstream labels, and that we need
to have a document that specifies them. However, there are technical
issues in this document that need to be corrected before this document
can move forward:

1. The document discusses the concept of a context. The document
  also requires that the label distribution protocol be able to
  indicate the use of upstream labels. But merely knowing that
  upstream labels are used is not a sufficient condition for the
  correct processing to occur. The endpoints must also have the
  same understanding of what context to use. I would suggest
  that the document require the communication of context as well.
  Such communication can be explicit "here's the context" or
  implicit "for protocol X, the context is always the source address
  of the signaling message used to set the label up".

  Perhaps the latter is what the text in Section 7 attempts to do?

    If the tunnel on which Rd receives MPLS packets with a top label
    L is a MPLS tunnel, then Rd determines a) That L is upstream-
    assigned and b) The context for L, from the labels above L in
    the label stack.

  But if so, it needs to be more clearly stated. I cannot determine
  if the above statement says all MPLS tunnels will be upstream
  assigned, or if the appearance of a specific label L will cause the
  receiver to determine that the following labels are the context.

3. Both IPv4 and IPv6 need to be addressed in a specification that
  does not relate to something intrinsic to only one of them.
  In some cases we have approved specifications where we knew there
  was a corresponding v4/v6 counterpart in the works. Is there one
  in this case -- after a brief search I could not find one? If not,
  Section 8 needs to be complemented with a specification that works
  for IPv6 as well.
2008-05-06
07 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2008-05-06
07 Lisa Dusseault
[Ballot discuss]
This is a DISCUSS entered so that I can get a better understanding of this document and the significant changes it introduces, before …
[Ballot discuss]
This is a DISCUSS entered so that I can get a better understanding of this document and the significant changes it introduces, before we move quickly onward.

Upstream-assigned labels change the RFC3031 architecture quite significantly.  Since it has the support of both Routing ADs and is the basis for a bunch of further work in MPLS, I can only assume it's had significant review.  I did some searching, however, and was unable to find direct evidence of that review -- e.g. the WGLC seemed to receive no replies. 

Also, I don't usually look for a bunch of justification and requirements in standards, but for this big a change I'm definitely looking around.  It took me a while to arrive at RFC3353 sections 9 and 10.4 -- and section 10.4 lists benefits for downstream-assignment as well as upstream. 

I'm particularly interested in the backwards-compatibility and security characteristics of this change.  Do we have implementation experience on this yet?
- Section 5 talks about assigning labels that do not conflict with downstream-assigned labels, but all the requirements are SHOULD (and even 'could').  Aren't conflicts here bad?
- Don't downstream-assigned labels give downstream LSRs a great deal of control over how labels are subsequently looked up?  Is this practically of little value?  Should upstream-assigned labels be used sparingly -- or in *preference* to downstream-assigned labels -- or is there really no preference?
2008-05-06
07 Lisa Dusseault [Ballot Position Update] Position for Lisa Dusseault has been changed to Discuss from No Objection by Lisa Dusseault
2008-05-06
07 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2008-05-06
07 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2008-05-05
07 David Ward [Ballot Position Update] New position, Yes, has been recorded by David Ward
2008-05-01
07 Ross Callon [Ballot Position Update] New position, Yes, has been recorded for Ross Callon
2008-05-01
07 Ross Callon Ballot has been issued by Ross Callon
2008-05-01
07 Ross Callon Created "Approve" ballot
2008-05-01
07 Ross Callon State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Ross Callon
2008-05-01
07 Ross Callon Placed on agenda for telechat - 2008-05-08 by Ross Callon
2008-04-30
05 (System) New version available: draft-ietf-mpls-upstream-label-05.txt
2008-04-25
07 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-04-22
07 Amanda Baber IANA Last Call comments:

As described in the IANA Considerations section, we understand this document
to have NO IANA Actions.
2008-04-12
07 Samuel Weiler Request for Last Call review by SECDIR is assigned to Stephen Farrell
2008-04-12
07 Samuel Weiler Request for Last Call review by SECDIR is assigned to Stephen Farrell
2008-04-11
07 Amy Vezza Last call sent
2008-04-11
07 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2008-04-11
07 Ross Callon Last Call was requested by Ross Callon
2008-04-11
07 Ross Callon State Changes to Last Call Requested from Publication Requested by Ross Callon
2008-04-11
07 (System) Ballot writeup text was added
2008-04-11
07 (System) Last call text was added
2008-04-11
07 (System) Ballot approval text was added
2008-02-25
07 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
07 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2008-02-22
04 (System) New version available: draft-ietf-mpls-upstream-label-04.txt
2007-11-13
03 (System) New version available: draft-ietf-mpls-upstream-label-03.txt
2007-03-08
02 (System) New version available: draft-ietf-mpls-upstream-label-02.txt
2006-12-12
01 (System) New version available: draft-ietf-mpls-upstream-label-01.txt
2006-03-10
00 (System) New version available: draft-ietf-mpls-upstream-label-00.txt