Skip to main content

Last Call Review of draft-ietf-mpls-special-purpose-labels-05

Request Review of draft-ietf-mpls-special-purpose-labels
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-03-03
Requested 2014-02-20
Authors Kireeti Kompella , Loa Andersson , Adrian Farrel
I-D last updated 2014-03-13
Completed reviews Genart Last Call review of -05 by Roni Even (diff)
Genart Telechat review of -06 by Roni Even
Secdir Last Call review of -05 by Taylor Yu (diff)
Assignment Reviewer Taylor Yu
State Completed
Review review-ietf-mpls-special-purpose-labels-05-secdir-lc-yu-2014-03-13
Reviewed revision 05 (document currently at 06)
Result Has Nits
Completed 2014-03-13
[Sorry for the resend; I got the tools address for the draft wrong at

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Summary: ready with nits

I believe the Security Considerations section of this document is

Query: I'm not very familiar with MPLS; is the handling of the Entropy
Label Indicator the only situation where a Label Switching Router
would need to inspect (as opposed to hash for load balancing) labels
below the top of the label stack?

I was confused by the explanation of why Label 7 (ELI) has meaning as
both an ordinary Special Label and an Extended Special Purpose Label
until I read RFC 6790.  Perhaps explain that looking for the ELI is
typically the only reason why a LSR would inspect the middle of the
label stack?

Re answer 6 of Section 3:

If an ingress LSR pushes ESPLs onto the label stack, any downstream
LSRs that do not understand ESPLs could erroneously use the ESPLs as
load balancing inputs.  Would it be a good idea to recommend that
ingress LSRs avoid pushing ESPLs onto the label stack if their policy
cannot tolerate variations in downstream load balancing caused by
inappropriate use of the ESPLs as load balancing inputs by downstream
LSRs that don't understand ESPLs?