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

From: Ross Callon <[email-masked]>
Date: Tue, 16 Jul 2013 16:59:54 +0000

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

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 17 Jul 2013 00:48:31 +0000

Support.

发件人: [email-masked] [mailto:[email-masked]] 代表 Ross Callon
发送时间: 2013年7月17日 1:00
收件人: [email-masked]; [email-masked]
抄送: [email-masked]
主题: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03

Working Group,

Ross
for the wg co-chairs

---

From: Ross Callon <[email-masked]>
Date: Wed, 17 Jul 2013 03:43:08 +0000

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,

Ross
for the wg co-chairs

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 26 Jul 2013 13:43:58 -0400

In message <[email-masked]>
Ross Callon writes:
 
> This is to start Working Group last call on
> draft-ietf-mpls-special-purpose-labels-03
>  
> 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.
>  
> 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