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

From: Lizhong Jin <[email-masked]>
Date: Mon, 8 Jul 2013 21:56:43 +0800

Hi Kireeti,
I do not quite understand why having two entropy label possibilities would
simplify the parsing. From my knowledge of the switching asic, the asic
would always parse all the MPLS labels, and check each MPLS reserve label
by indexing (not hashing) to a content register which indicates the entropy
label property. If we have two possibilities for entropy label, then we
have to use two registers in hardware for the same purpose. I do not see
the benefit yet. Could you please indicate a bit?

Regards
Lizhong

>
> Message: 2
> Date: Sun, 7 Jul 2013 11:51:28 -0700
> From: Kireeti Kompella <[email-masked]>
> To: MPLS <[email-masked]>
> Cc: Ross Callon <[email-masked]>, Loa Andersson <[email-masked]>
> Subject: [mpls] draft-ietf-mpls-special-purpose-labels-01
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi All,
>
> I have updated this document with the following:
> a) the range of Standards Action extended special purpose labels is
> 16-239; experimental is 240-255.  The rest are reserved for now.
> b) I've added a question/answer on whether to use extended special purpose
> labels in load balancing -- saying MUST NOT.
> c) Clarified text regarding a label following an extended special purpose
> (Xuxiaohu's comment).
>
> Finally, I note Lizhong's comment regarding label 7.  The goal in allowing
> label 7 as either a regular special purpose label or an extended special
> purpose label is to simplify parsing when searching for an entropy label.
>  I added text around this, but did not change SHOULD NOT to MUST NOT.
>
> WG chairs, I believe this doc is ready for WG LC.
>
> Kireeti.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.ietf.org/mail-archive/web/mpls/attachments/20130707/a100d7d4/attachment.htm
> >
>
> ------------------------------
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>
> End of mpls Digest, Vol 111, Issue 13
> *************************************
>

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 8 Jul 2013 22:50:40 -0700

Hi Lizhong,

In the fast path in a transit LSR, would you prefer:
a) look for label 7; then use the label after it as the entropy label; OR
b) look for a two label combination of <not label 15, label 7>, then use the label after it as the entropy label?

Let me explain (b).  If we are strict about having only one entropy label possibility, then an implementation _should_ look for a label sequence of:
< … !15 7 EL … > to truly identify an entropy label., since < … 15 7 L … > is illegal, and does not identify L as an entropy label.  (Ignore the special case that the first label is 7.)

In other words, if we say "MUST NOT use label 7 as an extended special purpose label", then in principle, (b) is needed.

If we are loose, then an implementation can simply look for < … 7 EL … > without worrying about whether the label before 7 is 15.  Of course, this means that LSRs inserting an entropy label have two choices, but they can choose just to use one.  Senders have an easy time; I want transit LSRs to have an easy time as well.  Of course, receivers will have to parse both possibilities.  I can add: "Receivers processing label 7 after an extension label MAY drop the packet" to re-emphasize the "SHOULD NOT", but that seems like an overkill.

Does that make sense?  (Question to WG at large as well.)

Kireeti.

On Jul 8, 2013, at 06:56 , Lizhong Jin <[email-masked]> wrote:

> Hi Kireeti,
> I do not quite understand why having two entropy label possibilities would simplify the parsing. From my knowledge of the switching asic, the asic would always parse all the MPLS labels, and check each MPLS reserve label by indexing (not hashing) to a content register which indicates the entropy label property. If we have two possibilities for entropy label, then we have to use two registers in hardware for the same purpose. I do not see the benefit yet. Could you please indicate a bit?
> 
> Regards
> Lizhong
> 
> 
>  
> 
> Message: 2
> a) the range of Standards Action extended special purpose labels is 16-239; experimental is 240-255.  The rest are reserved for now.
> b) I've added a question/answer on whether to use extended special purpose labels in load balancing -- saying MUST NOT.
> c) Clarified text regarding a label following an extended special purpose (Xuxiaohu's comment).
> 
> Finally, I note Lizhong's comment regarding label 7.  The goal in allowing label 7 as either a regular special purpose label or an extended special purpose label is to simplify parsing when searching for an entropy label.  I added text around this, but did not change SHOULD NOT to MUST NOT.
> 
> URL: <http://www.ietf.org/mail-archive/web/mpls/attachments/20130707/a100d7d4/attachment.htm>
>

---

From: "Vivek Kumar" <[email-masked]>
Date: Tue, 9 Jul 2013 06:20:44 +0000

Hi Kireeti,
   One question. Why someone want to  send  label 15 ,label  7, EL when same thing can be achieved by sending label 7,EL  .
   IMHO , label 15 should be used only when someone wants to use extended special purpose registry .

Regards,
Vivek

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kireeti Kompella
Sent: Tuesday, July 09, 2013 11:21 AM
To: Lizhong Jin
Cc: Ross Callon; [email-masked]; Loa Andersson
Subject: Re: [mpls] draft-ietf-mpls-special-purpose-labels-01

Hi Lizhong,

Let me explain (b).  If we are strict about having only one entropy label possibility, then an implementation _should_ look for a label sequence of:
< ... !15 7 EL ... > to truly identify an entropy label., since < ... 15 7 L ... > is illegal, and does not identify L as an entropy label.  (Ignore the special case that the first label is 7.)

If we are loose, then an implementation can simply look for < ... 7 EL ... > without worrying about whether the label before 7 is 15.  Of course, this means that LSRs inserting an entropy label have two choices, but they can choose just to use one.  Senders have an easy time; I want transit LSRs to have an easy time as well.  Of course, receivers will have to parse both possibilities.  I can add: "Receivers processing label 7 after an extension label MAY drop the packet" to re-emphasize the "SHOULD NOT", but that seems like an overkill.

Kireeti.

On Jul 8, 2013, at 06:56 , Lizhong Jin <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kireeti,

Regards
Lizhong

Message: 2
Date: Sun, 7 Jul 2013 11:51:28 -0700
From: Kireeti Kompella <[email-masked]<mailto:[email-masked]>>
To: MPLS <[email-masked]<mailto:[email-masked]>>
Cc: Ross Callon <[email-masked]<mailto:[email-masked]>>, Loa Andersson <[email-masked]<mailto:[email-masked]>>
Subject: [mpls] draft-ietf-mpls-special-purpose-labels-01
Message-ID: <[email-masked]<mailto:[email-masked]>>
Content-Type: text/plain; charset="us-ascii"

Hi All,

Kireeti.
-------------- next part --------------

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

---

From: Alia Atlas <[email-masked]>
Date: Tue, 9 Jul 2013 08:29:06 -0400

I think it makes sense and helps clarify the reasoning.  It would be useful
to have a sentence or two in the draft changing:

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

to

"Label 7 (when received) retains its meaning as ELI whether a regular or an
extended special purpose label; 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 Extension Label 15.

Alia

On Tue, Jul 9, 2013 at 1:50 AM, Kireeti Kompella <[email-masked]
> wrote:

> Let me explain (b).  If we are strict about having only one entropy label
> possibility, then an implementation _should_ look for a label sequence of:
> < … !15 7 EL … > to truly identify an entropy label., since < … 15 7 L … >
> is illegal, and does not identify L as an entropy label.  (Ignore the
> special case that the first label is 7.)
>
> In other words, if we say "MUST NOT use label 7 as an extended special
> purpose label", then in principle, (b) is needed.
>
> If we are loose, then an implementation can simply look for < … 7 EL … >
> without worrying about whether the label before 7 is 15.  Of course, this
> means that LSRs inserting an entropy label have two choices, but they can
> choose just to use one.  Senders have an easy time; I want transit LSRs to
> have an easy time as well.  Of course, receivers will have to parse both
> possibilities.  I can add: "Receivers processing label 7 after an extension
> label MAY drop the packet" to re-emphasize the "SHOULD NOT", but that seems
> like an overkill.
>
>> b) I've added a question/answer on whether to use extended special
>> purpose labels in load balancing -- saying MUST NOT.
>> Finally, I note Lizhong's comment regarding label 7.  The goal in
>> allowing label 7 as either a regular special purpose label or an extended
>> special purpose label is to simplify parsing when searching for an entropy
>> label.  I added text around this, but did not change SHOULD NOT to MUST NOT.
>>

---

From: Lizhong Jin <[email-masked]>
Date: Tue, 9 Jul 2013 22:55:46 +0800

Hi Kireeti,

On Tue, Jul 9, 2013 at 1:50 PM, Kireeti Kompella <[email-masked]

> special case that the first label is 7.)
[Lizhong] I understand your motivation now. But the ASIC will always parse
all MPLS labels, and it is not necessary to get the specific EL value by
looking up 7, LSR could simply hash all MPLS labels (except RSV label) to
do the forwarding. In some implementation, the purpose of label 7 is to get
the next service label for forwarding by skipping EL, not to get the EL. I
mean two ELI possibilities will not simplify the logic to get EL, hardware
will parse every label whatever it is EL or not.

Regards
Lizhong

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 12 Jul 2013 01:18:30 +0000

The label 7 after label 15 can't be used for other purpose than ELI. Otherwise, it may be confused to some early implementations of the entropy label which may just search label 7 in the label stack without worrying about whether the label before label 7 is label 15

Hence, either reserving the label 7 after label 15 while relaxing the restriction on transit LSRs (as suggested by Kireeti) or defining the label 7 after 15 as an ELI as well is fine, IMO.

Best regards

Xiaohu

发件人: [email-masked] [mailto:[email-masked]] 代表 Kireeti Kompella
发送时间: 2013年7月9日 13:51
收件人: Lizhong Jin
抄送: Ross Callon; [email-masked]; Loa Andersson
主题: Re: [mpls] draft-ietf-mpls-special-purpose-labels-01

Hi Lizhong,

Kireeti.

Hi Kireeti,

Regards
Lizhong

Message: 2

Hi All,

Kireeti.

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Sat, 13 Jul 2013 23:50:59 +0000

Hi Kireeti,

A comment on the ranges of Extended Special Purpose MPLS Labels:

(1)   Shouldn’t there be a larger Unassigned range (using terminology of RFC 5226)?

(2)   Why is Reserved range so large? What is the purpose?

Maria

Message: 2

Hi All,

Kireeti.