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

From: "Lizhong Jin" <[email-masked]>
Date: Thu, 20 Feb 2014 09:37:07 +0800

I am happy to see the change to "MUST". That will simplify the dataplane
implementation.

Regards
Lizhong

> 
> Message: 1
> Date: Tue, 18 Feb 2014 16:59:32 +0000
> From: Stewart Bryant <[email-masked]>
> To: Alia Atlas <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>,
> 	"[email-masked]"
> 	<[email-masked]>
> Subject: Re: [mpls] Mail regarding
> 	draft-ietf-mpls-special-purpose-labels
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
> 
> 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.
> > 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
> >>
> >>          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."
> >>
> > 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]
> > <mailto:[email-masked]>> wrote:
> >
> >     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
> >>     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.
> >>
> >>             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.
> >>
> >>
> >>         [Alia] Sure - I took the original text and modified it.
> >>
> >>             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.
> >>
> >>
> >>         [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:
> >>
> >>
> >>             "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.
> >>
> >>                 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 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 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] <mailto:[email-masked]>
> >>                 <mailto:[email-masked]
> >>                 <mailto:[email-masked]>>> 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
> >>                 [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]>
> >>     https://www.ietf.org/mailman/listinfo/mpls
> >
> >
> >     --
> >     For corporate legal information go to:
> >
> >     http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> >
> >
> 
> 
> --
> For corporate legal information go to:
> 
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-
> archive/web/mpls/attachments/20140218/27ab9440/attachment.html>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
> 
> 
> ------------------------------
> 
> End of mpls Digest, Vol 118, Issue 73
> *************************************

---

From: Loa Andersson <[email-masked]>
Date: Thu, 20 Feb 2014 10:49:30 +0100

Lizhong,

Is this the text you want.

"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 MUST insert the ELI as a regular special purpose label, not as
  an ESPL."

I think that this is equivalent to say:

"When an LSR insert an entropy label it MUST insert the ELI as a
  regular special purpose label, not as an ESPL."

Then we should also say that "Labels 0-15 in the ESPL space are
reserved, and shall not be allocated".

The case where we have "the risk" of finding Label value 7, when it
is not a regular special purpose label disappears.

OK, great I can live with that.

However we are now looping of the same territory for the n-th time,
we have tried to do this before and met strong opposition.

/Loa

-- 

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

---

From: "Lizhong Jin" <[email-masked]>
Date: Thu, 20 Feb 2014 18:16:30 +0800

Hi Loa,
The new text is OK for me. The discussion this time is great, and finally we
get new agreement.

Lizhong

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: 2014年2月20日 17:50
> To: Lizhong Jin; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls] Mail regarding draft-ietf-mpls-special-purpose-labels
> 
> Lizhong,
> 
> Then we should also say that "Labels 0-15 in the ESPL space are reserved,
and
> shall not be allocated".
> 
> The case where we have "the risk" of finding Label value 7, when it is not
a
> regular special purpose label disappears.
> 
> However we are now looping of the same territory for the n-th time, we
> have tried to do this before and met strong opposition.
> 
> /Loa
> 
> 
> 
> > I am happy to see the change to "MUST". That will simplify the
> > dataplane implementation.
> >
> > Regards
> > Lizhong
> >
> >>
> >> Message: 1
> >>> If you think that Loa's text is sufficiently strong about not
> >>> sending XL, ESPL, then I am fine with his text.
label
> >>> 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
> >>>
> >>>
> >>>> whether
> >> -------------- next part -------------- An HTML attachment was
> >> scrubbed...