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 |