Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03

From: Loa Andersson <[email-masked]>
Date: Wed, 07 Aug 2013 14:28:33 +0200

Folks, <chair hat off>

I'm trying to sort out the ELI / special purpose labels issue.

If I understand Kireeti correctly what he say is that if we
declare 15/ELI/EL an error (i.e. 15/ELI "reserved do not assign"), then
anyone searching a label stack and fing the ELI needs to check whether
there is a label with the value 15 before it. This creates extra logic
that has to executed and written.

I think this is true. At least if you allow for that some
implementations that today are standard compatible, but just blindly
scans through the label stack to find the ELI and don't bother to
look at the other labels than the EL.

However, I think we need to look if there are other cases there what
is proposed by Kireeti leads to increasing complexity.

If we for example we know that the 16 lowest values are not in
the ranges allocated for extended label space that might simplify
the search of the labels in the extended space.

Any HW aspects on this?

<chair hat on>

/Loa

On 2013-07-26 19:43, Curtis Villamizar wrote:
>
> In message <[email-masked]>
> Ross Callon writes:
>
>> Reminder, please send responses to the MPLS WG email list.
>>
>> Thanks, Ross
>>
>> From: Ross Callon [mailto:[email-masked]]
>> Sent: Tuesday, July 16, 2013 1:00 PM
>> To: [email-masked]; [email-masked]
>> Cc: [email-masked]; VIGOUREUX, MARTIN (MARTIN)
>> Subject: MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03
>>
>> Working Group,
>>
>> This is to start Working Group last call on
>> draft-ietf-mpls-special-purpose-labels-03
>>
>> Please send your comments to the mpls working group mailing list
>> ([email-masked]<mailto:[email-masked]>).
>>
>> Please send both technical comments, and (if you are happy with the
>> document as is) also send indications of support.
>>
>> There are no IPR claims against this draft. The co-authors have
>> earlier stated that they are not aware of any IPR applicable to this
>> draft.
>>
>> If anyone else in the working group is aware of IPRs claims against
>> this draft, the time to disclose that is now.
>>
>> Due to the upcoming IETF meeting in Berlin, this last call will be
>> extended by an extra week (which implies that the last call will be
>> ongoing during the IETF meeting).  This working group last call will
>> end on August 6, 2013.
>>
>> Ross
>> for the wg co-chairs
>
>
> Ross, authors,
>
> I really don't see the value of using 7 as an extended special purpose
> label.
>
>     Values 0-6 and 8-15 of the extended special purpose label registry
>     are set aside as reserved; these MUST NOT appear in the data plane.
>     Label 7 (when received) retains its meaning as ELI whether a regular
>     or an extended special purpose label; this is to simplify the logic
>     for transit LSRs looking for entropy labels.  However, an LSR wishing
>     to insert an entropy label SHOULD insert label 7 as a regular special
>     purpose label, not as an extended special purpose label.
>
> Why insert 15 ELI EL rather than ELI EL.  If only new LSR insert EL,
> why not make the MUST not apply to use of 0-15 as extended special
> purpose labels.  I suggest replacing with:
>
>     Values 0-15 of the extended special purpose label registry are set
>     aside as reserved; these MUST NOT appear in the data plane.
>
> This would also change table 1.
>
> I would also drop bullet 3 from the list in IANA Considerations.  That
> bullet contains the text "Note: any new allocation from the Special
> Purpose MPLS Label Values registry MUST also say whether the same
> value needs to be reserved in the Extended Special Purpose MPLS Label
> Values registry."
>
> BTW "extension label" has a acronym collision with entropy label,
> unless we abbreviate extension label XL.  ESP labels might also be a
> good acronym Extended Special Purpose MPLS Label.  The acronym
> collision with existing use of ESP might actually make sense,
> particularly in regard to the experimental ESP range.  :-)
>
> It might help to introduce the acronyms "XL" and "ESP label" or "ESPL"
> in this document.
>
> Right now the document does not say what an LSR should do if it
> encounters an unknown (to it) ESP label.  This should require a
> separate section entitled "Forwarding Packets with Unknown Extension
> Labels".  If this label is deep in the stack, the it seems that the
> best action would be to always ignore it.
>
> In thinking about what an LSR should do, there are two possibilities
> if the unknown ESP label hits the top of the stack.  One possibility
> is drop the packet.  The other is pop the XL and ESP and process the
> next label or BOS.  One way to accomplish that would be to reserve a
> range for each of these two possibilities.  Tabel 1 becomes.
>
>     +---------------+----------------------------------------------+
>     | Range         | Allocation Policy                            |
>     +---------------+----------------------------------------------+
>     | 0 - 15        | Reserved.  Not to be allocated.  MUST NOT    |
>     |               | appear in the data plane.                    |
>     |               |                                              |
>     | 16 - 127      | Standards Action (drop packet if unknown)    |
>     |               |                                              |
>     | 128 - 239     | Standards Action (pop XL and ESP if unknown) |
>     |               |                                              |
>     | 240 - 247     | Experimental (drop packet if unknown)        |
>     |               |                                              |
>     | 248 - 255     | Experimental (pop XL and ESP if unknown)     |
>     |               |                                              |
>     | 256 - 1048575 | Reserved                                     |
>     +---------------+----------------------------------------------+
>
> The experimental ESP space could also be split in the same way.  The
> experimental space is small.  Maybe that's good.
>
> Only if we think there might be a reason to drop a packet with unknown
> ESP label deep in the stack would we want to further split the space
> to include that possibility.
>
> If there is no concensus behind the changes I've suggested here, then
> I support the document going forward.  I would prefer that the
> suggested changes be seriously considered.
>
> Curtis
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 

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

---

From: Pablo Frank <[email-masked]>
Date: Thu, 8 Aug 2013 13:45:18 -0400

I'm not sure a transit LSR needs to enforce the rule, does it?  If we rely
on the LERs to enforce the rule then the worst that will happen is that a
broken packet may get accidentally hashed down the wrong component of a LAG
or ECMP but will get discarded anyway when it arrives at the destination.

Are there router implementations that do an exhaustive integrity check on
the rest of the labels in a label stack once it decides to swap the
outermost label?  I suspect most don't.  I could see a packet coming in
with a broken label stack that's missing the BOS bit that could result in
erroneous parsing of an "ELI".  Or maybe it has on-the-wire implicit NULL
label somewhere in the stack.  We don't expect transit LSRs to go hunting
for these types of problems, right?  So why should it hunt for problems
with the disposition of the special purpose labels?

regards,
Pablo

On Wed, Aug 7, 2013 at 8:28 AM, Loa Andersson <[email-masked]> wrote:

>> In message <62CCD4C52ACDAD4481149BD5D8A72**FD316D6FE01@CH1PRD0510MB355.**
>> namprd05.prod.outlook.com<[email-masked]>
>> >
>> Ross Callon writes:
>>
>>> To: [email-masked]; draft-ietf-mpls-special-**
>>> [email-masked]<[email-masked]>
>>> Subject: MPLS WG last call on draft-ietf-mpls-special-**
>>> purpose-labels-03
>>>
>>> Working Group,
>>>
>>> draft-ietf-mpls-special-**purpose-labels-03
>>>
>>> ([email-masked]<mailto:mpls@**ietf.org <[email-masked]>>).
>>>
>>     +---------------+-------------**------------------------------**---+
>>     +---------------+-------------**------------------------------**---+
>>     +---------------+-------------**------------------------------**---+
>>
>> ______________________________**_________________
>> mpls mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/mpls<https://www.ietf.org/mailman/listinfo/mpls>
>>
>>
> --
>
>
> ______________________________**_________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mpls<https://www.ietf.org/mailman/listinfo/mpls>
>

---

From: Eric Rosen <[email-masked]>
Date: Thu, 08 Aug 2013 14:33:10 -0400

> I'm not sure a transit LSR needs to enforce the rule, does it?

That's not the issue; the issue is whether the transit LSR, when it hashes
on the entropy label, is following the entropy label hashing spec.

> If we rely on the LERs to enforce the rule then the worst that will happen
> is that a broken packet may get accidentally hashed down the wrong
> component

No, the worst that can happen is that is that the transit LSR is declared to
be non-compliant with the specs, since the label on which it is hashing does
not appear immediately after a valid ELI.

The sort of bureaucrat who would make such a declaration will not be
dissuaded by the argument that this violation of the specs is of no
practical import.  And one cannot simply assume that such bureaucrats will
have no influence on purchasing or deployment decisions.

So if we don't want the transit LSR to have to check that a 7 is not
preceded by a 15, it is best to make 15/7 legal, and to give it the same
meaning as a 7 that is not preceded by a 15.

> I could see a packet coming in with a broken label stack that's missing
> the BOS bit that could result in erroneous parsing of an "ELI"

Not analogous.  If the BOS bit is missing, the transit LSR will parse past
the intended end of the stack, but that's what it is supposed to do per the
specifications.

> Or maybe it has on-the-wire implicit NULL label somewhere in the stack.

Not analogous.  The transit LSR will not take any action on the label value
3, so it can't be faulted.  But it will act on the label value 7, which
could give rise to the bureaucratic objection above.

---

From: Pablo Frank <[email-masked]>
Date: Fri, 9 Aug 2013 09:42:45 -0400

Okay, I can buy the argument that it's just an "insurance policy against
bureaucrats".  The text, as written, says that an implementation SHOULD use
7/<entropy> over 15/7/<entropy> which means we're at least _discouraging_
the use of 15/7/<entropy>.  That seems okay to me now.

thanks,
Pablo

---

From: Kireeti Kompella <[email-masked]>
Date: Sat, 10 Aug 2013 08:22:54 -0700

On Jul 26, 2013, at 10:43 , Curtis Villamizar <[email-masked]> wrote:

> Why insert 15 ELI EL rather than ELI EL.  

Don't.  Ever :)

The only purpose of keeping XL ELI in the table is to simplify transit LSR behavior.  See Eric's email (Aug 8, 11:33 PDT) or Loa's email (Aug 7, 5:28 PDT).

<snipped>

> value needs to be reserved in the Extended Special Purpose MPLS Label

Good catch!

> It might help to introduce the acronyms "XL" and "ESP label" or "ESPL"

Will add text.

> range for each of these two possibilities.  Tabel 1 becomes.

The behavior today is to 
a) ignore any label not at top of stack, except for load balancing purposes; and
b) to drop a packet that has a reserved label unknown to the router.

So, I agree with your suggestion to add a section on what to do with an unknown ESPL, but I would keep it simple and say drop the packet :)

If people think splitting the space the way you suggest is a good idea, I'll add it.  If not, we can always add another registry later.

<snipped>

> suggested changes be seriously considered.

I think some are good, and will add them.  Thanks for the comments!

Kireeti.

---

From: Kireeti Kompella <[email-masked]>
Date: Sat, 10 Aug 2013 15:30:35 +0000

> meaning as a 7 that is not preceded by a 15.

Exactly!  Thanks, Eric.

Kireeti

---

From: Kireeti Kompella <[email-masked]>
Date: Sat, 10 Aug 2013 15:32:29 +0000

Hi Loa,

> that has to executed and written.

Yes.

<snipped>

> the search of the labels in the extended space.

I don't believe so, and unless someone speaks up, I'll assume not :)

Kireeti.

---

From: Kireeti Kompella <[email-masked]>
Date: Sat, 10 Aug 2013 09:09:49 -0700

> best action would be to always ignore it.

New text:

3.1.1.  Forwarding Packets with Extended Special Purpose Labels

   If an LSR encounters an extension label at the top of stack and it
   doesn't understand extension labels, it SHOULD drop the packet.  If
   an LSR encounters an extended special purpose label at the top of
   stack that it doesn't understand, it SHOULD drop the packet.  In
   either case, it MAY log the event, but such logging MUST be rate-
   limited.

   An LSR SHOULD NOT make forwarding decisions on labels not at the top
   of stack.  For load balancing decisions, see Answer 6 of Section 3.

I expect Adrian to ask "why SHOULD and not MUST?"

Is there is reference for the second para (say in 3031/3032)?

Kireeti