Subject: [mpls] FW: Mail regarding draft-ietf-mpls-special-purpose-labels

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 14 Feb 2014 16:28:17 -0000

FYI

> -----Original Message-----
> From: Stewart Bryant [mailto:[email-masked]]
> Sent: 14 February 2014 14:54
> To: [email-masked]; [email-masked]
> Cc: Alia Atlas
> Subject: Re: Mail regarding draft-ietf-mpls-special-purpose-labels
> 
> On 11/02/2014 20:07, Adrian Farrel wrote:
> > Hi Stewart,
> >
> > Thanks for this. Can we copy the thread to the WG mailing list?
> 
> Sure. Doing that.
> >
> >> 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.
> > So I cc'ed her here.
> >
> >> 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 can see how you would see this as a new label type. Maybe "compound"
> rather
> > than "couple".
> > However, I am not convinced that it is new that one label leads to the
semantics
> > of the next (for example the entropy label).
> > What is more, I am not sure that there will be more than this instance of
this
> > type of tight coupling.
> > So I would rather leave this point out.
> I can foresee other cases where we might use label pairs to mitigate the
> 20bit limit. I am sure it has been discussed, so creating the reference
> might
> be useful. Just because this was not done in EL, does not mean that
> we should not set down the concept here.
> 
> However I agree compound would be a better term.
> 
> >
> > But as to clarifying ESPL: yes.
> > The XP definition is, I think, clear.
> > How about...
> >
> > ESPL An Extended Special Purpose Label. A Special Purpose Label that
> >       is placed in the label stack after the Extension Label.
> Yes. Indeed it MUST be placed be placed there, however the definition
> above is fine.
> >
> >> ======
> >>
> >> 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.
> > We discussed this at some point on the MPLS list (many centuries ago, I
think)
> > and reached no conclusion.
> > The primary purpose of the XL is to handle the time when 0..15 is depleted.
> > You're right that we could encourage people to start using ESPLs now before
> > 0..15 is depleted. But it is hard to make the case for requiring it when
there
> > is still some of 0..15 available and the rate of burn is not so high.
> >
> > We could put in some text like...
> >
> > When allocating a new Special Purpose Label, protocol designers should
> consider
> > whether they could, instead, use an Extended Special Purpose Label. Doing so
> > would help to preserve the scarce resources of Special Purpose Labels for
use
> in
> > cases where minimizing the label stack size is particularly important.
> That would be useful text.
> >> ======
> >>
> >>   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.
> > Section 3, answer 2 (which you quote) is answering Section 2 question 2.
> > Both explicitly state "special purpose label".
> > It is not until question 5 and its answer that extended special purpose
labels
> > come in.
> > The IANA considerations section describes the allocation policies for ESPLs.
> OK
> >
> >> ======
> >>
> >>     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.
> > I can't tell whether there is an action here for us.
> > There are two "violations" that exist:
> > 1. Some implementations violate 6790. Not sure what we can do about
> > that in this document. Note that the entropy label can help with this
> > but only to a limited extent since the implementations that violate 6790
> > probably also fail to recognise the entropy label.
> > 2. Implementations that conform to 6790 will understand that the XL is
> > a special purpose label and will not use it to load balance. But they will
> > not necessarily understand that the next label is an ESPL that must be
> > skipped as well. Again, there is nothing we can do about this except to
> > note it (done) and possibly to use the EL further up the stack.
> 
> My point was that the may in "It is noted that existing implementations may
> violate this" was a little soft. Most implementations, except the latest
> designs
> of maybe as few as a single vendor, would certainly violate this.
> 
> Also of course you are making a statement of fact and not of permission
> so I think it may be more precise to say:
> 
> It is noted that most existing
> implementations currently violate this, as they do not look for the XL
> and thus for ESPLs.
> 
> 
> >
> >> =====
> >>
> >>   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.
> > OLD
> >     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.
> > NEW
> >     A further question that needed to be settled in this regard was
> >     whether a "regular" special purpose label retains its meaning if it
> >     follows the XL.  This answer to this question is provided in Section
> >     3.1.
> > END
> yes.
> 
> >> =======
> >>
> >>    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?
> > If this was a MUST then there would be no case for handling Label 7 after
XL.
> > There was some concern I believe that implementations might have a path that
> > puts them on to XL insertion processing and then consider what to do next.
At
> > that point they might decide that label 7 is needed.
> >
> > It seems esoteric, but I couldn't see a reason to prohibit it.
> >
> > Maybe "MUST NOT include" and "SHOULD process when received" are
> compatible.
> >
> > Part of me hates the idea of this change just because I don't want another
> > working group last call before we can move forward. How important is it?
> The reason to be stricter at the TX is that the forwarding path can be
> simpler at the
> RX. I cannot see how you would get to the point of putting in L15 and then
> saying "you know I need to put in L7" particularly as no other 0..15 is
> allowed.
> Normally I would think that you would put in the compound label as a pair
> and that is a good reason to use the compound label concept.
> 
> Also I see no reason for the inconsistency between L7 and all of the
> other L0..L15 cases.
> 
> So I think that it's OK, but probably silly to allow L0..L15, but to allow
> the exception of just L7 just complicates things without good cause.
> >
> >> ========
> >>
> >> 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.
> > I think the wording is very fine in terms of setting expectations.
> > The expectation is that there will be IETF consensus and that, along the
way,
> > the MPLS WG will review the decision.
> > I think this is almost certainly business as usual, but writing it down
doesn't
> > seem to hurt.
> OK
> 
> >
> >> 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.
> > Erm, that's what the text says, I think...
> >
> >         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.
> >
> > The "may" in that means that the earliest you can "poll" is 12 months after
the
> > deprecation RFC is published (noting that the RFC won't even get published
> until
> > lots of discussion and consensus to deprecate).
> > Then, *if* the poll response is OK, and then not earlier than 24 months
after
> > the deprecation RFC is published, publication can be requested for a new RFC
> > (which means that the WG has already reached consensus, and that a
> subsequent
> > IETF last call will be held).
> >
> > Frankly, I think that this process is only likely to be executed for SPLs
that
> > are allocated "in error", because other stuff will probably be in the field.
Can
> > you think of a label that was allocated in error? I can :-)
> 
> This seems like a lot of text to specify in detail something we would never
> run. In protocols, including this type of protocol, the fewer words used to
> describe the rarely executed exception path the better.
> 
> 
> >
> >> ===========
> >>
> >>     | 7                   | Allocated; meaning is ELI [RFC6790]         |
> >>
> >> I do not understand why you need the complexity of this exception.
> > So you said above.
> > Is there a problem?
> > Does it break something badly, or is it just not what you would have done?
> I can like with the complexity, but as I noted above complexity rarely
> executed leads to interesting bugs.
> 
> >
> >> ============
> >>
> >> 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!
> > The text does not say that the document makes no changes to the data plane.
> It
> > says no large change to the operation of the data plane.
> >
> > What text would you prefer in the context of the Security Considerations?
> 
> Sorry I misread it and missed the word "large". The text is fine.
> >
> >> ===========
> >>
> >>    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?
> > To a different order of magnitude (different arbitrariness?).
> > One could argue that a large number of {ELI, EL} pairs could be inserted,
where
> > this I-D doesn't really change anything that already exists.
> >
> > Actually, I think this text dates from when XL was a legal ESPL. That was
> > nonsense we managed to squash despite the "architects" who thought it was
> > beautiful.
> >
> > It might be better to say...
> >
> > This document provides a protocol-legal way to
> > increase the label stack through the insertion of additional {XL,ESPL}
> > pairs at a greater rate than insertion of single "rogue" labels. This
> > might provide a way to attack some nodes in a network that can only
> > process label stacks of a certain size without violating the protocol
> > rules.
> Yes, that is better.
> 
> >
> >> ===========
> >>
> >>     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.
> > Section 3.1.1 has
> >     If an LSR encounters the XL at the top of stack and it doesn't
> >     understand extension labels, it SHOULD drop the packet as specified
> >     for the handling of any unknown lable according to [RFC3031].  If an
> >     LSR encounters an ESPL at the top of stack (after the XL) and does
> >     not understand the ESPL, it SHOULD drop the packet, again following
> >     the procedures for unknown labels as set out in [RFC3031].  In either
> >     case, the LSR MAY log the event, but such logging MUST be rate-
> >     limited.
> > Without rate limiting on the logging, this is an attack vector.
> OK and I agree that if the section is null it should not be included.
> I imagine that there will be concerns about how you know that you
> can introduce the feature, and what you do in the event of re-routing
> etc.
> 
> If you do not think there are other considerations we can leave the
> text and get the Ops folks to comment later in the process.
> >
> > What OPS issues had you in mind that need to be addressed? I am a fan of OPS
> > sections, but not a fan of empty OPS sections, and when we looked through
> RFC
> > 6123 (which is my favourite crib for what to describe wrt manageability) we
> > didn't see anything that has changed from pre-existing MPLS.
> >
> > What metadata are you talking about? Is an existing special purpose label
> > metadata? If so, the PM issues are pre-existing. Is there something special
> > introduced by this I-D that constitutes metadata?
> Well what follows an XL is certainly metadata, and one application is
> certainly to introduce tags that would alert the PM devices to take an
> interest.
> 
> >
> >> 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.
> > How do you know if the target can accept a new SPL?
> > I don't think that prevents us from assigning them, and each I-D that
assigns a
> > new one has to worry about backward compatibility. Note that the default
> > backward compatibility is covered by "drop packets with unrecognised
labels".
> > In this respect XL is just another SPL that might be unrecognised.
> > Below XL, each ESPL is just another ESPL that might be unrecognised and will
> > also cause the packet to be dropped (see 3.1.1)
> > Any I-D that defines a new ESPL will have to worry about backward
> compatibility
> > for that ESPL. This I-D does not have that problem.
> 
> OK
> 
> Stewart
> > Cheers,
> > Adrian
> >
> > .
> >
> 
> 
> --
> For corporate legal information go to:
> 
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 14 Feb 2014 17:35:47 -0000

[snip]

> > rather than "couple".
semantics
this
> might be useful. Just because this was not done in EL, does not mean that

OK, I updated to...

   ESPL An Extended Special Purpose Label. A Special Purpose Label that
        is placed in the label stack after the Extension Label.  The
        combination of XL and ESPL might be regarded as a new form of
        "compound label" comprising more than one consecutive entry in
        the label stack.

..to cover your other point as well.

think)
there
> > consider whether they could, instead, use an Extended Special Purpose
> > Label. Doing so would help to preserve the scarce resources of Special 
> > Purpose Labels for use in cases where minimizing the label stack size is
> > particularly important.
>

Added as new section 3.1.2 with slight tweak to wording.

[snip]

> designs of maybe as few as a single vendor, would certainly violate this.
> 

OK.

I've gone with...

       It is noted that existing
       implementations would violate this, as they do not recognise XL 
       as anything other than a single Special Purpose Label and will 
       not expect an ESPL to follow.

[snip]

XL.
At
> simpler at the RX. I cannot see how you would get to the point of putting
> in L15 and then saying "you know I need to put in L7" particularly as no
> other 0..15 is allowed.

I'm not in a position to argue on this one as the debate and text were driven by
others.

I believe that the claim was that allowing L7 to be inserted anywhere made
processing it easier not harder at the receiver.
Note that {XL,7} would be an error case in your way of looking at things so the
receiver should (must?) not process it.
But the claim was that h/w will simply search the stack for L7 so that allowing
{L7} and {XL, L7} to be treated in the same way made life easier for the h/w.

Bottom line, however, seems to be that you have a preference for doing it one
way, and the WG has a preference for doing it a different way. How to resolve
that?

Given the posting deadline, I've not made any change for this. We can continue
to discuss.

> >> 3.2.  Process for Retiring Special Purpose Labels

[snip]

the
> > until lots of discussion and consensus to deprecate).
after
> > subsequent IETF last call will be held).
> >
that
Can
> describe the rarely executed exception path the better.

The case was considered worthy of inclusion because the SPL range is so small.
If any SPL can be reclaimed at some future time it will be very valuable and so
a mechanism needs to be documented against that happy day.

[snip]
[snip]
> >> However that brings me to
> > RFC 6123 (which is my favourite crib for what to describe wrt manageability)
we
> certainly to introduce tags that would alert the PM devices to take an

OK it is a form of metadata as existing SPLs are metadata.
The XL alerts a DPI that an ESPL follows, and an SPL alerts the DPI that the SPL
is there.
What has changed?
We could certainly sit down and write an I-D about the implications of using
MPLS in an environment where PM might be present (BTW, I assume this is
Pervasive Monitoring. Would be embarrassing to find you meant something else
:-). I think such an I-D would discuss SPLs as indicative metadata and would
then note that ESPLs are in the same category.
Is *this* the I-D in which to have that discussion?

[snip]

I'll post the revised I-D in a few minutes and others can throw vegetables
(rotten or otherwise).

Adrian

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 14 Feb 2014 14:54:12 +0000

Sure. Doing that.
> I can see how you would see this as a new label type. Maybe "compound" rather
> than "couple".
> However, I am not convinced that it is new that one label leads to the semantics
> What is more, I am not sure that there will be more than this instance of this
> type of tight coupling.

> We discussed this at some point on the MPLS list (many centuries ago, I think)
> 0..15 is depleted. But it is hard to make the case for requiring it when there
> When allocating a new Special Purpose Label, protocol designers should consider
> would help to preserve the scarce resources of Special Purpose Labels for use in
> It is not until question 5 and its answer that extended special purpose labels
> come in.
OK

yes.

> If this was a MUST then there would be no case for handling Label 7 after XL.
> puts them on to XL insertion processing and then consider what to do next. At
> Maybe "MUST NOT include" and "SHOULD process when received" are compatible.
>

> The expectation is that there will be IETF consensus and that, along the way,
> I think this is almost certainly business as usual, but writing it down doesn't
> seem to hurt.
OK

> The "may" in that means that the earliest you can "poll" is 12 months after the
> deprecation RFC is published (noting that the RFC won't even get published until
> Then, *if* the poll response is OK, and then not earlier than 24 months after
> (which means that the WG has already reached consensus, and that a subsequent
> Frankly, I think that this process is only likely to be executed for SPLs that
> are allocated "in error", because other stuff will probably be in the field. Can

> The text does not say that the document makes no changes to the data plane. It

> One could argue that a large number of {ELI, EL} pairs could be inserted, where
Yes, that is better.

> sections, but not a fan of empty OPS sections, and when we looked through RFC

> I don't think that prevents us from assigning them, and each I-D that assigns a
> backward compatibility is covered by "drop packets with unrecognised labels".
> Any I-D that defines a new ESPL will have to worry about backward compatibility

OK

Stewart

---

From: Alia Atlas <[email-masked]>
Date: Fri, 14 Feb 2014 21:52:45 -0500

Adrian and others,

Having reviewed the 05 of this draft and this thread, I have the following
suggestions.  Other than these, I'm quite happy with how this draft has
improved.

a) In Sec 3.1, the following paragraph could be updated from:

" 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."

to:

"An LSR wishing to insert an entropy label MUST insert label value 7
(meaning ELI) as a regular special purpose

label and not as an ESPL.  Value 7 MUST NOT be sent as an ESPL in the
data plane.  However, to simplify

the data plane implementation for Entropy Labels, an implementation MAY

interpret an ESPL of 7 as meaning ELI and, unlike for values 0-6 and
8-15, an implementation

MAY choose to not treat the packet as malformed and thus discard it.
The data plane simplification thus enabled

is the ability to determine if any label value is 7 without needing to
verify that the previous label in the stack is not the XL value of
15."

b) In Sec 3.2: "An RFC with at least Informational status is
required."   How is this different from IETF Review in RFC 5226?  Do
BCPs count? What is "at least Informational status"?

On the concern about Pervasive Monitoring, the only advantage that (XL,
ESPL) offers is that the labels wouldn't (eventually) be hashed for
load-balancing.  Otherwise, the label stack offers the ability for
meta-data already where only the receiver would need to understand it.
 Consistent paths are very useful, but there are other ways of doing this
already - with the most trivial being just using label 15.  I have a hard
time seeing this as a new attack vector (but I'm not professionally
paranoid yet).

Alia

On Fri, Feb 14, 2014 at 12:35 PM, Adrian Farrel <[email-masked]> wrote:

> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Loa Andersson <[email-masked]>
Date: Sat, 15 Feb 2014 12:58:04 +0800

Alia,

Two comments on this.

First a nit "An LSR wishing to insert an ...", LSR are boxes and can't
wish anything for themselves, a Simple change would be "When an LSR
insert..."

Actually the same is true for the current text and should be changed the
same way.

Second, and this is maybe more tricky - the reason given "simplify the
data plane implementation" is not true and might even be wrong.
The reason put always using the ELI as a "regular special purpose label"
is backwards compatibility.
I would claim that the treatment of the ELI is an (well motivated)
exception, but exceptions always mean that things get more complicated.

I don't want to propose a final text,but something along these lines:

"Label 7 (when received) retains its meaning as ELI whether a
  regular special purpose label or an ESPL; this is because of backwards
  compatibility with existing implemented and deployed code and hardware
  that looks for the ELI without verifying if the previous label
  is XL or not. However, when an LSR insert an entropy label it SHOULD
  insert the ELI as a regular special purpose label, not as an ESPL."

/Loa

On 2014-02-15 10:52, Alia Atlas wrote:
> Adrian and others,
>
> Having reviewed the 05 of this draft and this thread, I have the
> following suggestions.  Other than these, I'm quite happy with how this
> draft has improved.
>
> "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."
>
>
> to:
>
>
> "An LSR wishing to insert an entropy label MUST insert label value 7 (meaning ELI) as a regular special purpose
>
> label and not as an ESPL.Value 7 MUST NOT be sent as an ESPL in the data plane.  However, to simplify
>
> interpret an ESPL of 7 as meaning ELI and, unlike for values 0-6 and 8-15, an implementation
>
> MAY choose to not treat the packet as malformedand thus discard it.  The data plane simplification thus enabled
>
> is the ability to determine if any label value is 7 without needing to verify that the previous label in the stack is not the XL value of 15."
>
>
> b)In Sec 3.2: "An RFC with at  least Informational status is required."   How is this different from IETF Review in RFC 5226?  Do BCPs count? What is "at least Informational status"?
>
>
>   Consistent paths are very useful, but there are other ways of doing
> this already - with the most trivial being just using label 15.  I have
> a hard time seeing this as a new attack vector (but I'm not
> professionally paranoid yet).
>
> Alia
>
> On Fri, Feb 14, 2014 at 12:35 PM, Adrian Farrel <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     [snip]
>
>     [email-masked] <mailto:[email-masked]>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Alia Atlas <[email-masked]>
Date: Sat, 15 Feb 2014 00:24:26 -0500

Loa,

> Actually the same is true for the current text and should be changed the

[Alia] Sure - I took the original text and modified it.

> exception, but exceptions always mean that things get more complicated.

[Alia] There were three purposes to my suggested text change.  First, to
specify that
an LSR MUST NOT insert the ELI as an ESPL.   Second, to say that a
receiving LSR
MAY choose to not discard a packet with the ELI as an ESPL.  Third, I
wanted to see
a clearer justification for why this exception is worth making.

[Alia] Since the whole draft is about a data-plane change, what we've been
putting in doesn't
really articulate the full problem.  Prelim text would around that would be
better as:

"ELI is an exception because each LSR examines the whole label stack to see
if the ELI
appears; pre-existing implementations of [Entropy-Label] do this
examination without verifying
that the label above the ELI is not XL.  If a packet used an ESPL of 7 and
that did not mean
ELI, then when that packet transited deployed LSRs, which implement
[Entropy-Label] and not this document,
the meaning of the ESPL would be misinterpreted.  Such a misinterpretation
could result in poor traffic behavior (large flows,
reordered flows, etc.) depending on the label after the ESPL of 7.  It is
to avoid such issues that ELI is defined as an exception
that can appear as an regular special label or as an ESPL with the same
value of 7."

What do you think?

Alia

I don't want to propose a final text,but something along these lines:
>> verify that the previous label in the stack is not the XL value of 15."
>>
>>
>> b)In Sec 3.2: "An RFC with at  least Informational status is required."
>> How is this different from IETF Review in RFC 5226?  Do BCPs count? What is
>> "at least Informational status"?
>>
>>
>>

---

From: Alia Atlas <[email-masked]>
Date: Sat, 15 Feb 2014 12:09:45 -0500

[+ietf]

Loa,

To clarify a bit better, what I'm trying to get clarified into the text is
why the ELI value as an ESPL
needs to be an exception (as the draft indicates).  I believe it is because
forbidding an ESPL of 7
can break some existing and deployed versions of RFC 6790 such that the
transit traffic flows are affected.
There may also be implementations of RFC 6790 that aren't affected.

Regards,
Alia

On Sat, Feb 15, 2014 at 12:24 AM, Alia Atlas <[email-masked]> wrote:

> really articulate the full problem.  Prelim text would around that would
> be better as:
>
> "ELI is an exception because each LSR examines the whole label stack to
> see if the ELI
>>>   How is this different from IETF Review in RFC 5226?  Do BCPs count? What
>>> is "at least Informational status"?
>>>
>>>
>>>

---

From: Loa Andersson <[email-masked]>
Date: Sun, 16 Feb 2014 17:53:15 +0800

Alia,

Of course I can take a spin on the text, once I'm convinced this is
necessary and useful.

Reading things a third or fourth time, I still think that the text
Adrian had in the draft is the best so far.

However, the draft is now in ietf last call, and wisdom says that we
shall not change documents while they are in last call. We have at least
two weeks to discuss this and converge on what we want to change if
anything.

My point is that there no other reason that the ELI is an exception than
that we have running code (that were standards compatible when
  implemented) that breaks if we don't make the exception.

/Loa

On 2014-02-16 01:09, Alia Atlas wrote:
> [+ietf]
>
> Loa,
>
> To clarify a bit better, what I'm trying to get clarified into the text
> is why the ELI value as an ESPL
> needs to be an exception (as the draft indicates).  I believe it is
> because forbidding an ESPL of 7
> On Sat, Feb 15, 2014 at 12:24 AM, Alia Atlas <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Loa,
>
>     On Fri, Feb 14, 2014 at 11:58 PM, Loa Andersson <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Alia,
>
>         Two comments on this.
>
>     [Alia] There were three purposes to my suggested text change.
>       First, to specify that
>     MAY choose to not discard a packet with the ELI as an ESPL.  Third,
>     I wanted to see
>     [Alia] Since the whole draft is about a data-plane change, what
>     we've been putting in doesn't
>     really articulate the full problem.  Prelim text would around that
>     would be better as:
>
>     "ELI is an exception because each LSR examines the whole label stack
>     to see if the ELI
>     that the label above the ELI is not XL.  If a packet used an ESPL of
>     7 and that did not mean
>     the meaning of the ESPL would be misinterpreted.  Such a
>     misinterpretation could result in poor traffic behavior (large flows,
>     reordered flows, etc.) depending on the label after the ESPL of 7.
>       It is to avoid such issues that ELI is defined as an exception
>     that can appear as an regular special label or as an ESPL with the
>     same value of 7."
>     What do you think?
>
>     Alia
>
>             "An LSR wishing to insert an entropy label MUST insert label
>             value 7 (meaning ELI) as a regular special purpose
>
>             MAY choose to not treat the packet as malformedand thus
>             discard it.  The data plane simplification thus enabled
>
>
>             is the ability to determine if any label value is 7 without
>             needing to verify that the previous label in the stack is
>             not the XL value of 15."
>
>
>             b)In Sec 3.2: "An RFC with at  least Informational status is
>             required."   How is this different from IETF Review in RFC
>             5226?  Do BCPs count? What is "at least Informational status"?
>
>
>
>             On Fri, Feb 14, 2014 at 12:35 PM, Adrian Farrel
>             <[email-masked] <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>>
>             wrote:
>
>                  [snip]
>
>                   > >> It might even be worth noting that really we have
>             a new label
>                  type:
>                   > > I can see how you would see this as a new label
>             type. Maybe
>                  "compound"
>                   > > rather than "couple".
>                   > > However, I am not convinced that it is new that
>             one label leads
>                  to the
>                  semantics
>                   > > What is more, I am not sure that there will be
>             more than this
>                  instance of
>                  this
>                   > > type of tight coupling.
>                   > I can foresee other cases where we might use label
>             pairs to
>                  mitigate the
>                   > 20bit limit. I am sure it has been discussed, so
>             creating the
>                  reference
>                   > might be useful. Just because this was not done in
>             EL, does not
>                  mean that
>                   > > ESPL An Extended Special Purpose Label. A Special
>             Purpose Label
>                  that
>                   > > The primary purpose of the XL is to handle the
>             time when 0..15
>                  is depleted.
>                   > > You're right that we could encourage people to
>             start using
>                  ESPLs now before
>                   > > is still some of 0..15 available and the rate of
>             burn is not so
>                  high.
>                   > >
>                   > > When allocating a new Special Purpose Label,
>             protocol designers
>                  should
>                   > > consider whether they could, instead, use an
>             Extended Special
>                  Purpose
>                   > > Label. Doing so would help to preserve the scarce
>             resources of
>                  Special
>                   > > Purpose Labels for use in cases where minimizing
>             the label
>                  stack size is
>                   > > particularly important.
>                   >
>                   > >>     6.  [RFC6790] says that special purpose
>             labels MUST NOT be
>                  used for
>                   > >>        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
>                   > > that in this document. Note that the entropy label
>             can help
>                  with this
>                   > > but only to a limited extent since the
>             implementations that
>                  violate 6790
>                   > > 2. Implementations that conform to 6790 will
>             understand that
>                  the XL is
>                   > > a special purpose label and will not use it to
>             load balance.
>                  But they will
>                   > > not necessarily understand that the next label is
>             an ESPL that
>                  must be
>                   > > skipped as well. Again, there is nothing we can do
>             about this
>                  except to
>                   > violate this" was a little soft. Most
>             implementations, except the
>                  latest
>                   > designs of maybe as few as a single vendor, would
>             certainly
>                  violate this.
>                   >
>                   > Also of course you are making a statement of fact
>             and not of
>                  permission
>                   > implementations currently violate this, as they do
>             not look for
>                  the XL
>                   > and thus for ESPLs.
>
>                  OK.
>
>                  I've gone with...
>
>                   > >>    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.
>                   > >>
>                   > > If this was a MUST then there would be no case for
>             handling
>                  Label 7 after
>                  XL.
>                   > > There was some concern I believe that
>             implementations might
>                  have a path that
>                   > > puts them on to XL insertion processing and then
>             consider what
>                  to do next.
>                  At
>                   > > Part of me hates the idea of this change just
>             because I don't
>                  want another
>                   > > working group last call before we can move
>             forward. How
>                  important is it?
>                   >
>                   > The reason to be stricter at the TX is that the
>             forwarding path
>                  can be
>                   > simpler at the RX. I cannot see how you would get to
>             the point of
>                  putting
>                   > Normally I would think that you would put in the
>             compound label
>                  as a pair
>                   > So I think that it's OK, but probably silly to allow
>             L0..L15, but
>                  to allow
>                  I'm not in a position to argue on this one as the
>             debate and text
>                  were driven by
>                  others.
>
>                  I believe that the claim was that allowing L7 to be
>             inserted
>                  anywhere made
>                  Note that {XL,7} would be an error case in your way of
>             looking at
>                  things so the
>                  But the claim was that h/w will simply search the stack
>             for L7 so
>                  that allowing
>                  {L7} and {XL, L7} to be treated in the same way made
>             life easier for
>                  the h/w.
>
>                  Bottom line, however, seems to be that you have a
>             preference for
>                  doing it one
>                  way, and the WG has a preference for doing it a
>             different way. How
>                  to resolve
>                  that?
>
>                  Given the posting deadline, I've not made any change
>             for this. We
>                  can continue
>                  to discuss.
>
>                   > >> ========
>                   > >>
>                   > >> Secondly I think the timescales are ridiculously
>             optimistic.
>                  To get
>                   > >> such time as it is determined that reallocation
>             would do not
>                  harm and
>                   > >         12 months after the RFC deprecating the
>             label value is
>                  published,
>                   > > The "may" in that means that the earliest you can
>             "poll" is 12
>                  months after
>                  the
>                   > > deprecation RFC is published (noting that the RFC
>             won't even
>                  get published
>                   > > Then, *if* the poll response is OK, and then not
>             earlier than
>                  24 months
>                  after
>                   > > the deprecation RFC is published, publication can
>             be requested
>                  for a new RFC
>                   > > Frankly, I think that this process is only likely
>             to be
>                  executed for SPLs
>                  that
>                   > > are allocated "in error", because other stuff will
>             probably be
>                  in the field.
>                  Can
>                   > This seems like a lot of text to specify in detail
>             something we
>                  would never
>                   > run. In protocols, including this type of protocol,
>             the fewer
>                  words used to
>                  The case was considered worthy of inclusion because the
>             SPL range is
>                  so small.
>                  If any SPL can be reclaimed at some future time it will
>             be very
>                  valuable and so
>                   > > What OPS issues had you in mind that need to be
>             addressed? I am
>                  a fan of OPS
>                   > > sections, but not a fan of empty OPS sections, and
>             when we
>                  looked through
>                   > > RFC 6123 (which is my favourite crib for what to
>             describe wrt
>                  manageability)
>                  we
>                   > > What metadata are you talking about? Is an
>             existing special
>                  purpose label
>                   > > metadata? If so, the PM issues are pre-existing.
>             Is there
>                  something special
>                   > certainly to introduce tags that would alert the PM
>             devices to
>                  take an
>                   > interest.
>
>                  The XL alerts a DPI that an ESPL follows, and an SPL
>             alerts the DPI
>                  that the SPL
>                  is there.
>                  What has changed?
>                  We could certainly sit down and write an I-D about the
>             implications
>                  of using
>                  Pervasive Monitoring. Would be embarrassing to find you
>             meant
>                  something else
>                  :-). I think such an I-D would discuss SPLs as
>             indicative metadata
>                  and would
>                  I'll post the revised I-D in a few minutes and others
>             can throw
>                  vegetables
>                  (rotten or otherwise).
>
>                  Adrian
>
>                  _________________________________________________
>                  mpls mailing list
>             [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>
>             https://www.ietf.org/mailman/__listinfo/mpls
>             <https://www.ietf.org/mailman/listinfo/mpls>
>
>
>
>
>
>             _________________________________________________
>             mpls mailing list
>             https://www.ietf.org/mailman/__listinfo/mpls
>             <https://www.ietf.org/mailman/listinfo/mpls>
>
>
>         --
>
>
>         Loa Andersson                        email:
>         [email-masked] <mailto:[email-masked]>
>         Senior MPLS Expert [email-masked] <mailto:[email-masked]>
>         <tel:%2B46%20739%2081%2021%2064>
>
>
>

--

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 18 Feb 2014 14:46:52 +0000

This has me worried.

Assume that nothing implements ESPL yet, there is no reason why
all SPL implementations are not required to send L7 only as
a regular (single) SPL. As Loa says, this would be a useful
simplification, and one which I raised earlier with the authors.

If that is the case, a parser will always get it right.

The only problem I see is if a compound label is ever created
L15, Lx, <0..maxLabel> but one one has defined such an
Lx and to do so would be unwise.

So I don't think Alia is correct in her proposed text change and
I have yet to see a valid technical reason for not accepting Loa's
proposed change.

- Stewart

On 15/02/2014 17:09, Alia Atlas wrote:
> [+ietf]
>
> Loa,
>
> To clarify a bit better, what I'm trying to get clarified into the 
> text is why the ELI value as an ESPL
> can break some existing and deployed versions of RFC 6790 such that 
> the transit traffic flows are affected.
>     MAY choose to not discard a packet with the ELI as an ESPL.
>      Third, I wanted to see
>     "ELI is an exception because each LSR examines the whole label
>     stack to see if the ELI
>     that the label above the ELI is not XL.  If a packet used an ESPL
>     of 7 and that did not mean
>     ELI, then when that packet transited deployed LSRs, which
>     implement [Entropy-Label] and not this document,
>             "An LSR wishing to insert an entropy label MUST insert
>             label value 7 (meaning ELI) as a regular special purpose
>
>             label and not as an ESPL.Value 7 MUST NOT be sent as an
>             ESPL in the data plane.  However, to simplify
>
>
>             is the ability to determine if any label value is 7
>             without needing to verify that the previous label in the
>             stack is not the XL value of 15."
>
>
>             b)In Sec 3.2: "An RFC with at  least Informational status
>             is required."   How is this different from IETF Review in
>             RFC 5226?  Do BCPs count? What is "at least Informational
>             status"?
>
>
>
>                  > >> It might even be worth noting that really we
>             have a new label
>                 type:
>             Purpose Label that
>                  > > We discussed this at some point on the MPLS list
>             (many
>                 centuries ago, I
>                 think)
>                  > > 0..15 is depleted. But it is hard to make the
>             case for
>                 requiring it when
>                 there
>                  > >>  implementations may violate this, as they do
>             not look
>                 for the XL
>                  > > that in this document. Note that the entropy
>             label can help
>                 with this
>                  > > skipped as well. Again, there is nothing we can
>             do about this
>                 except to
>                  > >>    Label 7 (when received) retains its meaning
>             as ELI whether
>                 a regular
>                  > >>    and need not verify that the previous label
>             in the stack is
>                 not the
>                  > > If this was a MUST then there would be no case
>             for handling
>                 Label 7 after
>                 XL.
>                  > simpler at the RX. I cannot see how you would get
>             to the point of
>                 putting
>                  > So I think that it's OK, but probably silly to
>             allow L0..L15, but
>                 to allow
>                 But the claim was that h/w will simply search the
>             stack for L7 so
>                 that allowing
>                  > >> A more realistic schedule would be to poll at
>             12month
>                 intervals until
>                  > > are allocated "in error", because other stuff
>             will probably be
>                 in the field.
>                 Can
>                 The case was considered worthy of inclusion because
>             the SPL range is
>                 so small.
>                 If any SPL can be reclaimed at some future time it
>             will be very
>                 valuable and so
>                  > > sections, but not a fan of empty OPS sections,
>             and when we
>                 looked through
>                 Pervasive Monitoring. Would be embarrassing to find
>             you meant
>                 something else
>         <mailto:[email-masked]>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 18 Feb 2014 14:50:26 +0000

>  implemented) that breaks if we don't make the exception.
Yes, but! I don't see how forbidding the extended version of L7 can possibly
break anything. The only think it could break is a pre-standards version of
the extended label that used this format. However it is unreasonable for
the existing code to place a burden of complexity on all future 
implementations.

Stewart

---

From: Alia Atlas <[email-masked]>
Date: Tue, 18 Feb 2014 09:55:22 -0500

Stewart,

If you think that Loa's text is sufficiently strong about not sending XL,
ESPL, then I am fine with his text.
I was striving for more clarity on why the exception was made and
suggesting MUST rather than SHOULD.

Loa's text says:

""Label 7 (when received) retains its meaning as ELI whether a

> This doesn't explain that bad traffic side-effects could happen, but I
think the wording for why the
exception is there is clear.

Alia

On Tue, Feb 18, 2014 at 9:46 AM, Stewart Bryant <[email-masked]> wrote:

>>  [Alia] There were three purposes to my suggested text change.  First,
>> to specify that
>>  [Alia] Since the whole draft is about a data-plane change, what we've
>> been putting in doesn't
>> that the label above the ELI is not XL.  If a packet used an ESPL of 7
>> and that did not mean
>>>>  MAY choose to not treat the packet as malformedand thus discard it.
>>>> required."   How is this different from IETF Review in RFC 5226?  Do BCPs
>>>> count? What is "at least Informational status"?
>>>>
>>>>
>>>>
>>>>  The
>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64<%2B46%20739%2081%2021%2064>
>>>
>>
>>
>
>
> mpls mailing [email-masked]://www.ietf.org/mailman/listinfo/mpls
>
>
>
> --

---

From: John E Drake <[email-masked]>
Date: Tue, 18 Feb 2014 15:16:24 +0000

Hi,

Stewart is correct.  An implementation of 6790 would use a regular label 7 since that is what 6790 says to do.  It would not use an ESL of 7 and so there is absolutely no reason to set aside an ESL value of 7. 

Yours Irrespectively,

John

> From: mpls [mailto:[email-masked]] On Behalf Of Stewart Bryant
> Sent: Tuesday, February 18, 2014 6:50 AM
> To: Loa Andersson; Alia Atlas
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels
> 
> > shall not change documents while they are in last call. We have at
> > least two weeks to discuss this and converge on what we want to change
> > if anything.
> >
> > My point is that there no other reason that the ELI is an exception
> > than that we have running code (that were standards compatible when
> break anything. The only think it could break is a pre-standards version of the
> extended label that used this format. However it is unreasonable for the
> existing code to place a burden of complexity on all future implementations.
> 
> Stewart
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 18 Feb 2014 11:22:16 -0500

I agree with Stewart that a very useful simplification is forbidding
the sending of the extended version of label 7. Thus, in the draft,
label 7 would simply join the list of reserved labels in section 5,
and the paragraph regarding label 7 can be removed altogether from
section 3.1.  Thus, the label stack would never contain the
combination <XL><ELI> on reception since it would never be
transmitted.

Cheers,
Andy

---

From: John E Drake <[email-masked]>
Date: Tue, 18 Feb 2014 16:37:33 +0000

Exactly

Yours Irrespectively,

John

> From: mpls [mailto:[email-masked]] On Behalf Of Andrew G. Malis
> Sent: Tuesday, February 18, 2014 8:22 AM
> To: Stewart Bryant
> I agree with Stewart that a very useful simplification is forbidding the sending
> of the extended version of label 7. Thus, in the draft, label 7 would simply join
> the list of reserved labels in section 5, and the paragraph regarding label 7 can
> be removed altogether from section 3.1.  Thus, the label stack would never
> contain the combination <XL><ELI> on reception since it would never be
> transmitted.
> 
> Cheers,
> Andy
> 
> >> least two weeks to discuss this and converge on what we want to
> >> change if anything.
> >>
> > Yes, but! I don't see how forbidding the extended version of L7 can
> > possibly break anything. The only think it could break is a
> > pre-standards version of the extended label that used this format.
> > However it is unreasonable for the existing code to place a burden of
> > complexity on all future implementations.
> >
> > Stewart
> >
> >

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 18 Feb 2014 16:59:32 +0000

Alia

Maybe we are out of sync.

I think that the text should say that L7 MUST be sent as a single label, and
MUST NOT be sent as a compound/extended label, and I think simplicity
alone is sufficient justification.

Stewart

On 18/02/2014 14:55, Alia Atlas wrote:
> Stewart,
>
> If you think that Loa's text is sufficiently strong about not sending 
> XL, ESPL, then I am fine with his text.
> On Tue, Feb 18, 2014 at 9:46 AM, Stewart Bryant <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     This has me worried.
>
>>     To clarify a bit better, what I'm trying to get clarified into
>>     the text is why the ELI value as an ESPL
>>     needs to be an exception (as the draft indicates).  I believe it
>>     is because forbidding an ESPL of 7
>>     can break some existing and deployed versions of RFC 6790 such
>>     that the transit traffic flows are affected.
>>         an LSR MUST NOT insert the ELI as an ESPL.   Second, to say
>>         that a receiving LSR
>>         [Alia] Since the whole draft is about a data-plane change,
>>         what we've been putting in doesn't
>>         really articulate the full problem.  Prelim text would around
>>         that would be better as:
>>
>>         "ELI is an exception because each LSR examines the whole
>>         label stack to see if the ELI
>>         appears; pre-existing implementations of [Entropy-Label] do
>>         this examination without verifying
>>         that the label above the ELI is not XL.  If a packet used an
>>         ESPL of 7 and that did not mean
>>         reordered flows, etc.) depending on the label after the ESPL
>>         of 7.  It is to avoid such issues that ELI is defined as an
>>         exception
>>         that can appear as an regular special label or as an ESPL
>>         with the same value of 7."
>>         What do you think?
>>
>>         Alia
>>
>>                 "An LSR wishing to insert an entropy label MUST
>>                 insert label value 7 (meaning ELI) as a regular
>>                 special purpose
>>
>>                 label and not as an ESPL.Value 7 MUST NOT be sent as
>>                 an ESPL in the data plane.  However, to simplify
>>
>>
>>                 MAY choose to not treat the packet as malformedand
>>                 thus discard it.  The data plane simplification thus
>>                 enabled
>>
>>
>>                 without needing to verify that the previous label in
>>                 the stack is not the XL value of 15."
>>
>>
>>                 b)In Sec 3.2: "An RFC with at  least Informational
>>                 status is required."   How is this different from
>>                 IETF Review in RFC 5226?  Do BCPs count? What is "at
>>                 least Informational status"?
>>
>>
>>
>>                 <mailto:[email-masked]
>>                 <mailto:[email-masked]>>> wrote:
>>
>>                     [snip]
>>
>>                      > >> It might even be worth noting that really
>>                 we have a new label
>>                     type:
>>                      > > I can see how you would see this as a new
>>                 label type. Maybe
>>                     "compound"
>>                      > > rather than "couple".
>>                      > > However, I am not convinced that it is new
>>                 that one label leads
>>                     to the
>>                     semantics
>>                      > > What is more, I am not sure that there will
>>                 be more than this
>>                     instance of
>>                     this
>>                      > > type of tight coupling.
>>                      > I can foresee other cases where we might use
>>                 label pairs to
>>                     mitigate the
>>                      > 20bit limit. I am sure it has been discussed,
>>                 so creating the
>>                     reference
>>                      > might be useful. Just because this was not
>>                 done in EL, does not
>>                     mean that
>>                      > > ESPL An Extended Special Purpose Label. A
>>                 Special Purpose Label
>>                     that
>>                      > > We discussed this at some point on the MPLS
>>                 list (many
>>                     centuries ago, I
>>                     think)
>>                      > > The primary purpose of the XL is to handle
>>                 the time when 0..15
>>                     is depleted.
>>                      > > You're right that we could encourage people
>>                 to start using
>>                     ESPLs now before
>>                      > > 0..15 is depleted. But it is hard to make
>>                 the case for
>>                     requiring it when
>>                     there
>>                      > > is still some of 0..15 available and the
>>                 rate of burn is not so
>>                     high.
>>                      > >
>>                      > > Label. Doing so would help to preserve the
>>                 scarce resources of
>>                     Special
>>                      > > Purpose Labels for use in cases where
>>                 minimizing the label
>>                     stack size is
>>                      > > particularly important.
>>                      >
>>                      > >>    implementations may violate this, as
>>                 they do not look
>>                     for the XL
>>                      > > a special purpose label and will not use it
>>                 to load balance.
>>                     But they will
>>                      > > not necessarily understand that the next
>>                 label is an ESPL that
>>                     must be
>>                      > > skipped as well. Again, there is nothing we
>>                 can do about this
>>                     except to
>>                      > My point was that the may in "It is noted that
>>                 existing
>>                     implementations may
>>                      > designs of maybe as few as a single vendor,
>>                 would certainly
>>                     violate this.
>>                      >
>>                      > Also of course you are making a statement of
>>                 fact and not of
>>                     permission
>>                      > implementations currently violate this, as
>>                 they do not look for
>>                     the XL
>>                      > and thus for ESPLs.
>>
>>                     OK.
>>
>>                     I've gone with...
>>
>>                      > >>  Label 7 (when received) retains its
>>                 meaning as ELI whether
>>                     a regular
>>                      > >>  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.
>>                      > >>
>>                      > > If this was a MUST then there would be no
>>                 case for handling
>>                     Label 7 after
>>                     XL.
>>                      > > puts them on to XL insertion processing and
>>                 then consider what
>>                     to do next.
>>                     At
>>                      > > Part of me hates the idea of this change
>>                 just because I don't
>>                     want another
>>                      > The reason to be stricter at the TX is that
>>                 the forwarding path
>>                     can be
>>                      > simpler at the RX. I cannot see how you would
>>                 get to the point of
>>                     putting
>>                      > in L15 and then saying "you know I need to put
>>                 in L7"
>>                     particularly as no
>>                      > other 0..15 is allowed.
>>                      > Normally I would think that you would put in
>>                 the compound label
>>                     as a pair
>>                     I believe that the claim was that allowing L7 to
>>                 be inserted
>>                     anywhere made
>>                     Note that {XL,7} would be an error case in your
>>                 way of looking at
>>                     things so the
>>                     {L7} and {XL, L7} to be treated in the same way
>>                 made life easier for
>>                     the h/w.
>>
>>                     Given the posting deadline, I've not made any
>>                 change for this. We
>>                     can continue
>>                     to discuss.
>>
>>                      > >> ========
>>                      > >>
>>                      > >> Secondly I think the timescales are
>>                 ridiculously optimistic.
>>                     To get
>>                      > >> 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
>>                      > > The "may" in that means that the earliest
>>                 you can "poll" is 12
>>                     months after
>>                     the
>>                      > > deprecation RFC is published (noting that
>>                 the RFC won't even
>>                     get published
>>                      > > Then, *if* the poll response is OK, and then
>>                 not earlier than
>>                     24 months
>>                     after
>>                      > > the deprecation RFC is published,
>>                 publication can be requested
>>                     for a new RFC
>>                      > > Frankly, I think that this process is only
>>                 likely to be
>>                     executed for SPLs
>>                     that
>>                      > > are allocated "in error", because other
>>                 stuff will probably be
>>                     in the field.
>>                     Can
>>                      > This seems like a lot of text to specify in
>>                 detail something we
>>                     would never
>>                      > run. In protocols, including this type of
>>                 protocol, the fewer
>>                     words used to
>>                     The case was considered worthy of inclusion
>>                 because the SPL range is
>>                     so small.
>>                     If any SPL can be reclaimed at some future time
>>                 it will be very
>>                     valuable and so
>>                      > > What OPS issues had you in mind that need to
>>                 be addressed? I am
>>                     a fan of OPS
>>                      > > sections, but not a fan of empty OPS
>>                 sections, and when we
>>                     looked through
>>                      > > RFC 6123 (which is my favourite crib for
>>                 what to describe wrt
>>                     manageability)
>>                     we
>>                      > > metadata? If so, the PM issues are
>>                 pre-existing. Is there
>>                     something special
>>                      > certainly to introduce tags that would alert
>>                 the PM devices to
>>                     take an
>>                      > interest.
>>
>>                     The XL alerts a DPI that an ESPL follows, and an
>>                 SPL alerts the DPI
>>                     that the SPL
>>                     is there.
>>                     What has changed?
>>                     We could certainly sit down and write an I-D
>>                 about the implications
>>                     of using
>>                     Pervasive Monitoring. Would be embarrassing to
>>                 find you meant
>>                     something else
>>                     I'll post the revised I-D in a few minutes and
>>                 others can throw
>>                     vegetables
>>                     (rotten or otherwise).
>>
>>                     Adrian
>>
>>                 <mailto:[email-masked] <mailto:[email-masked]>>
>>             Huawei Technologies (consultant)     phone: +46 739 81 21
>>             64 <tel:%2B46%20739%2081%2021%2064>
>>
>>
>>
>>
>>

---

From: Alia Atlas <[email-masked]>
Date: Tue, 18 Feb 2014 12:17:22 -0500

Stewart,

Yes, I agree with that text.  MUST send as 7 and MUST NOT as the compound.
That's what was lacking in Loa's text.

With that behavior, I'm not sure that it needs to be an exception for
receiving, but ok with what the WG says.

Alia
On Feb 18, 2014 11:59 AM, "Stewart Bryant" <[email-masked]> wrote:

>>     This doesn't explain that bad traffic side-effects could happen, but
> I think the wording for why the
> On Tue, Feb 18, 2014 at 9:46 AM, Stewart Bryant <[email-masked]>wrote:
>
>>  This has me worried.
>>
>>> reordered flows, etc.) depending on the label after the ESPL of 7.  It
>>> is to avoid such issues that ELI is defined as an exception
>>>>>      > > However, I am not convinced that it is new that one label
>>>>> leads
>>>>>     to the
>>>>>     semantics
>>>>>      > > ESPL An Extended Special Purpose Label. A Special Purpose
>>>>> Label
>>>>>     that
>>>>>      > > is still some of 0..15 available and the rate of burn is not
>>>>> so
>>>>>     high.
>>>>>      > >
>>>>>      > > When allocating a new Special Purpose Label, protocol
>>>>> designers
>>>>>     should
>>>>>      > >>     6.  [RFC6790] says that special purpose labels MUST NOT
>>>>> be
>>>>>     used for
>>>>>      > violate this" was a little soft. Most implementations, except
>>>>> the
>>>>>     latest
>>>>>      > >>    special purpose label or an ESPL; this simplifies a
>>>>> transit
>>>>>     LSR's
>>>>>      > >>    and need not verify that the previous label in the stack
>>>>> is
>>>>>     not the
>>>>>      > simpler at the RX. I cannot see how you would get to the point
>>>>> of
>>>>>     putting
>>>>>      > So I think that it's OK, but probably silly to allow L0..L15,
>>>>> but
>>>>>     to allow
>>>>>     {L7} and {XL, L7} to be treated in the same way made life easier
>>>>> for
>>>>>     the h/w.
>>>>>
>>>>>     The case was considered worthy of inclusion because the SPL range
>>>>> is
>>>>>     so small.
>>>>>      > > What OPS issues had you in mind that need to be addressed? I
>>>>> am
>>>>>     a fan of OPS

---

From: John E Drake <[email-masked]>
Date: Tue, 18 Feb 2014 17:18:48 +0000

Stewart,

My thoughts exactly.  This is also what RFC 6790 currently states.

Yours Irrespectively,

John

From: mpls [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Tuesday, February 18, 2014 9:00 AM
To: Alia Atlas
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels

Alia

Stewart

If you think that Loa's text is sufficiently strong about not sending XL, ESPL, then I am fine with his text.
I was striving for more clarity on why the exception was made and suggesting MUST rather than SHOULD.

Loa's text says:

This doesn't explain that bad traffic side-effects could happen, but I think the wording for why the

Alia

On Tue, Feb 18, 2014 at 9:46 AM, Stewart Bryant <[email-masked]<mailto:[email-masked]>> wrote:
This has me worried.

- Stewart

Loa,

To clarify a bit better, what I'm trying to get clarified into the text is why the ELI value as an ESPL
needs to be an exception (as the draft indicates).  I believe it is because forbidding an ESPL of 7
can break some existing and deployed versions of RFC 6790 such that the transit traffic flows are affected.
There may also be implementations of RFC 6790 that aren't affected.

Regards,
Alia

On Sat, Feb 15, 2014 at 12:24 AM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:
Loa,

On Fri, Feb 14, 2014 at 11:58 PM, Loa Andersson <[email-masked]<mailto:[email-masked]>> wrote:
Alia,

Two comments on this.

[Alia] There were three purposes to my suggested text change.  First, to specify that
an LSR MUST NOT insert the ELI as an ESPL.   Second, to say that a receiving LSR
MAY choose to not discard a packet with the ELI as an ESPL.  Third, I wanted to see
a clearer justification for why this exception is worth making.

[Alia] Since the whole draft is about a data-plane change, what we've been putting in doesn't
really articulate the full problem.  Prelim text would around that would be better as:

"ELI is an exception because each LSR examines the whole label stack to see if the ELI
appears; pre-existing implementations of [Entropy-Label] do this examination without verifying
that the label above the ELI is not XL.  If a packet used an ESPL of 7 and that did not mean
ELI, then when that packet transited deployed LSRs, which implement [Entropy-Label] and not this document,
the meaning of the ESPL would be misinterpreted.  Such a misinterpretation could result in poor traffic behavior (large flows,
reordered flows, etc.) depending on the label after the ESPL of 7.  It is to avoid such issues that ELI is defined as an exception
that can appear as an regular special label or as an ESPL with the same value of 7."

What do you think?

Alia

/Loa

to:

Alia

On Fri, Feb 14, 2014 at 12:35 PM, Adrian Farrel <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    [snip]

    semantics
    this

    OK, I updated to...

    think)
    there

    [snip]

    OK.

    I've gone with...

    [snip]

    XL.
    At
     > the exception of just L7 just complicates things without good cause.

    I'm not in a position to argue on this one as the debate and text
    were driven by
    others.

    I believe that the claim was that allowing L7 to be inserted
    anywhere made
    processing it easier not harder at the receiver.
    Note that {XL,7} would be an error case in your way of looking at
    things so the
    receiver should (must?) not process it.
    But the claim was that h/w will simply search the stack for L7 so
    that allowing
    {L7} and {XL, L7} to be treated in the same way made life easier for
    the h/w.

    Bottom line, however, seems to be that you have a preference for
    doing it one
    way, and the WG has a preference for doing it a different way. How
    to resolve
    that?

    Given the posting deadline, I've not made any change for this. We
    can continue
    to discuss.

    [snip]

    the
    after
    that
    Can
     > describe the rarely executed exception path the better.

    The case was considered worthy of inclusion because the SPL range is
    so small.
    If any SPL can be reclaimed at some future time it will be very
    valuable and so
    a mechanism needs to be documented against that happy day.

    [snip]
    [snip]
    we

    OK it is a form of metadata as existing SPLs are metadata.
    The XL alerts a DPI that an ESPL follows, and an SPL alerts the DPI
    that the SPL
    is there.
    What has changed?
    We could certainly sit down and write an I-D about the implications
    of using
    MPLS in an environment where PM might be present (BTW, I assume this is
    Pervasive Monitoring. Would be embarrassing to find you meant
    something else
    :-). I think such an I-D would discuss SPLs as indicative metadata
    and would
    then note that ESPLs are in the same category.
    Is *this* the I-D in which to have that discussion?

    [snip]

    I'll post the revised I-D in a few minutes and others can throw
    vegetables
    (rotten or otherwise).

    Adrian

    _______________________________________________
    mpls mailing list
    [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
    https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

--

Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>
Huawei Technologies (consultant)     phone: +46 739 81 21 64<tel:%2B46%20739%2081%2021%2064>

mpls mailing list

[email-masked]<mailto:[email-masked]>

--

--