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

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 <adrian@olddog.co.uk> wrote:

> [snip]
>
> > >> 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.
>
> 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.
>
> > >> ======
> > >>
> > >> 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.
>
> Added as new section 3.1.2 with slight tweak to wording.
>
> [snip]
>
> > >>     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.
>
> 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]
>
> > >>    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.
>
> 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]
>
> > >> 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.
>
> 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
> > >> 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.
> > >
> > > 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.
>
> 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
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>