Allocating and Retiring Special-Purpose MPLS Labels
draft-ietf-mpls-special-purpose-labels-06

[Ballot comment]
Thank you Alia for spending the 1 min to update the abstract.

This document is difficult to read, as it's not optimized per question/answer.
Look at question 2 in section 2, for which the answer is in section 3, but then points to 3.2 for more details.

[Ballot discuss]
Easy to fix DISCUSS.
The abstract, which only speaks about "new procedures to follow in the allocation and retirement of special purpose labels, as well as a method to extend the special purpose label space" is not complete.

Section "3.1.1. Forwarding Packets with Extended Special Purpose Labels" also speaks about what the LSR behavior.
An extra sentence is required IMO.

[Ballot comment]
This document is difficult to read, as it's not optimized per question/answer.
Look at question 2 in section 2, for which the answer is in section 3, but then points to 3.2 for more details.

[Ballot comment]
No objection here; this all sounds good.

Someone might consider whether it's better to correct the grammar of the second sentence in the abstract (I understand what it means to say, but I can't parse it), or let the RFC Editor do it.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-mpls-special-purpose-labels-05.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA has a question about one of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are four actions which IANA must complete.

First, the Multiprotocol Label Switching Architecture (MPLS) Label Values registry  located at

http://www.iana.org/assignments/mpls-label-values/

is to be renamed both inside the registry itself and on the IANA Parameters Matrix to:

Special Purpose MPLS Label Values

Second, the current registration procedure for this registry ( http://www.iana.org/assignments/mpls-label-values/ ) is currently IETF Consensus.  This will be changed to Standards Action as defined in RFC 5266.

Third, in the newly renamed Special Purpose MPLS Label Values registry located at:

http://www.iana.org/assignments/mpls-label-values/

a new label will be registered as follows:

Value: 15
Description: Extension Label
Reference: [ RFC-to-be ]

Fourth, a new registry called the Extended Special Purpose MPLS Label Values registry will be created. 

IANA QUESTION: Is this to be part of the newly-renamed Special Purpose MPLS Label Values at

http://www.iana.org/assignments/mpls-label-values/

or will it be a new, stand-alone registry at a new URL?

The values for this registry are supplied below.

IANA QUESTION: The document states that early allocation following the policy defined in RFC 7120 is allowed only for those values assigned by Standards Action. However, it appears that Standards Action is the only registration procedure for this registry. Is a note that says "early allocation following the policy defined in RFC 7120 is allowed only for those values assigned by Standards Action" still required at the top of the registry?

Registry Name: Extended Special Purpose MPLS Label Values
Registration Procedure: Standards Action
Reference: [RFC-to-Be]

Value    Name                                        Reference
------  --------------------------  ---------
0-6                  Reserved                                  [RFC-to-be]
7                      ELI                                            [RFC6790]     
8-15                Reserved                                  [RFC-to-be]
16-239            Unassigned
140-255          Reserved for Experimental Use  [RFC-to-be]
256-1048575  Reserved

IANA understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Allocating and Retiring Special Purpose MPLS Labels) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Allocating and Retiring Special Purpose MPLS Labels'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-03-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Some MPLS labels have been allocated for specific purposes.  A block
  of labels (0-15) has been set aside to this end, and are commonly
  called "reserved labels".  They will be called "special purpose
  labels" in this document.

  As there are only 16 of these special purpose labels, caution is
  needed in the allocation of new special purpose labels, yet at the
  same time allow forward progress when one is called for.

  This memo defines new procedures to follow in the allocation and
  retirement of special purpose labels, as well as a method to extend
  the special purpose label space.  Finally, this memo renames the IANA
  registry for these labels to "Special Purpose MPLS Label Values", and
  creates a new one called the "Extended Special Purpose MPLS Label
  Values" registry.

  This document updates a number of previous RFCs that used the term
  "reserved label".




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-special-purpose-labels/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-special-purpose-labels/ballot/


No IPR declarations have been submitted directly on this I-D.

Hi

I have reviewed this draft and have a few comments that I would
like to discuss before it goes to IETF LC.

It is possible that Alia may have some additional comments
and since it will fall to her to take this through the IESG
you should give priority to any comments that she makes.


====

  XL  The Extension Label that indicates that an extended special
        purpose label follows.


  ESPL An Extended Special Purpose Label.

Something that I think would be worthwhile clarifying right at the
front is that a label is an ESPL IFF it is preceded by an XL.
It might even be worth noting that really we have a new label type:
a label couple in which the first label defines the type of the
second label and neither are of any use as individual labels.


======

I think that the draft will need to provide some guidance
on when to allocate a 0..15 and when to allocate an ESPL.

I imagine that a 0..15 should only be used when it can be shown
that the extra stack space of forwarding time is burdensome
but that is a question that the WG should explicitly consider.

======


2.  A Standards Track RFC must accompany a request for allocation of
      Standards Action special purpose labels, as per [RFC5226].


You need to clarify whether this is a 0..15 SPL, an ESPL or both.

======


  6.  [RFC6790] says that special purpose labels MUST NOT be used for
      load balancing.  The same logic applies to extended special
      purpose labels (ESPLs).  Thus, this document specifies that ESPLs
      MUST NOT be used for load balancing.  It is noted that existing
      implementations may violate this, as they do not look for the XL
      and thus for ESPLs.  The consequence is that if ESPLs are used in
      some packets of a flow, these packets may be delivered on
      different paths and so could be re-ordered.  However, it is
      important to specify the correct behavior for future
      implementations, hence the use of "MUST NOT".

I would suggest that most implementations do violate this. I would
also suggest that it seems unlikely that you will get to the point
where it is not violated in the foreseeable future.

=====

A further question to be settled in this regard is whether a
  "regular" special purpose label retains its meaning if it follows the
  XL; see Section 3.1.

The way that you start the para it looks like this is an open question
could I suggest rewording so that it is clear that this is a resolved
matter.

=======


  Label 7 (when received) retains its meaning as ELI whether a regular
  special purpose label or an ESPL; this simplifies a transit LSR's
  task of looking for entropy labels since it may just look for label 7
  and need not verify that the previous label in the stack is not the
  XL 15.  However, an LSR wishing to insert an entropy label SHOULD
  insert label 7 as a regular special purpose label, not as an ESPL.


Why is this not a MUST! There is no ESPL in the wild running an
alternate behaviour, so why not simply mandate this?

========

3.2.  Process for Retiring Special Purpose Labels

  While the following process is defined for the sake of completeness,
  note that retiring special purpose labels is difficult.  It is
  recommended that this process be used sparingly.

  a.  A label value that has been assigned from the "Special Purpose
      MPLS Label Values" may be deprecated by IETF consensus with
      review by the MPLS working group (or designated experts if the
      working group or a successor does not exist).  An RFC with at
      least Informational status is required.

      The RFC will direct the IANA to mark the label value as
      "deprecated" in the registry, but will not release it at this
      stage.

      Deprecating means that no further specifications using the
      deprecated value will be documented.

      At the same time this is an indication to vendors not to include
      the deprecated value in new implementations, and to operators to
      avoid including it in new deployments.

  b.  12 months after the RFC deprecating the label value is published,
      an IETF-wide survey may be conducted to determine if the
      deprecated label value is still in use.  If the survey indicates
      that the deprecated label value is in use, the survey may be
      repeated after a further 6 months.

  c.  24 months after the RFC that deprecated the label value was
      published and if the survey indicates that deprecated label value
      is not in use, publication may be requested of an IETF Standards
      Track Internet-Draft that retires the deprecated the label value.
      This document will request IANA to release the label value for
      for future use and assignment.


I have two comments on this. Firstly why is it necessary to specify the
MPLS WG. If the action is IETF consensus, then this will get picked but
my MPLS WG then IETF LC and then ADs. There are enough checks and
balances in the system that there is no need to call up a specific
WG that may or may not be in existence.

Secondly I think the timescales are ridiculously optimistic. To get
a label out of circulation in 24 months seems most unlikely. Also
6 month checks is a lot of work.

A more realistic schedule would be to poll at 12month intervals until
such time as it is determined that reallocation would do not harm and
then give a further 12 months notice.

===========


  | 7                  | Allocated; meaning is ELI [RFC6790]        |

I do not understand why you need the complexity of this exception.

============

6.  Security Considerations

  This document does not make a large change to the operation of the
  MPLS data plane

That is an incorrect statement! This memo explicitly makes changes
to the MPLS DP!

===========

  This document provides a protocol-legal way to
  arbitrarily increase the label stack and so might provide a way to
  attack some nodes in a network without violating the protocol rules.

I think that this already exists with the ELI doesn't it?

===========


  This document also describes events that may cause an LSR to issue
  event logs at a per-packet rate.  It is critically important that
  implementations rate-limit such logs.

I do not see any text on this at all! However that brings me to
suggest that you probably need to write an OPs section and
you might want to think about the PM implications of the extra
metatdata in the packets.

How do you know if the target can accept ESPLs? Do you need to specify
some sort if ICMP response given that there could be a lot more
SPLs as a result of this.

(1) What type of RFC is being requested

  Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Some MPLS labels have been allocated for specific purposes.  A block
  of labels (0-15) has been set aside to this end, and are commonly
  called "reserved labels". As there are only 16 of these special purpose
  labels, caution is needed in the allocation of new special purpose labels,
  yet at the same time allow forward progress when one is called for.

  This document defines new procedures to follow in the allocation and
  retirement of special purpose labels, as well as a method to extend
  the special purpose label space.  Finally, this memo renames the IANA
  registry for these labels to "Special Purpose MPLS Label Values", and
  creates a new one called the "Extended Special Purpose MPLS Label
  Values" registry.

Working Group Summary

  no controversy. Some contructive discussion of the details.

Document Quality

  The document has been well reviewed, and has been updated to reflect
  comments received in WG last call. Due to the nature of this document it
  needs to be published in final form (as an RFC) prior to implementation
  but authors and reviewers include multiple vendors who would need to
  implement the extension to the special purpose label space.

Personnel

  Ross Callon is the document shepherd. The AD for MPLS (Adrian
  Farrel) is co-author, and so the other routing AD (Stewart Bryant) will
  act as responsible AD. 

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The shepherd has read the document, has checked it against last call
  comments, and has run IDnits. There is one obsolete normative reference
  but this can be fixed along with any comments received during IETF last
  call or during final editting.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

  no concerns

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  not applicable.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  no concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  All authors have confirmed that they are not aware of any IPR on this
  draft.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures.

(9) 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? 

  solid consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  no threat of appeal.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  The reference to RFC 4020 should be updated to RFC 7120.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  not applicable.

(13) Have all references within this document been identified as
either normative or informative?

  yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  all normative references are to existing RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  no downrefs. All normative references are to proposed standard or BCP
  RFCs.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  This document does not change the status of any other RFC. There are
  12 previous RFCs, listed in section 4, that use the term "reserved labels".
  This RFC changes the term to "special purpose labels" and thereful
  updates these previous RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  The shepherd believes that the IANA considerations section is clear
  and consistent with the document.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  none.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  no such sections.