Subject: [mpls] Clarification on source label

From: Mach Chen <[email-masked]>
Date: Tue, 11 Mar 2014 02:25:55 +0000

Hi,

During the second MPLS session last week, there are lot of discussions on the source label, thanks for the discussions!

Regarding to the usage of source label, there may be some misunderstanding. The main purpose of source label is for OAM, although the source label can be applied to real packets, but it's optional, it depends on how you use it.

In addition, regarding to the depth of label stack, IMHO, this is proved that is not an real issue for the new generation hardware (chips and NPs), the depth is only related the need. 

Best regards,
Mach

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 11 Mar 2014 07:24:53 -0400

Just to reiterate what I said at the mike during this discussion, we
can't stop adding new features (and depth) to the label stack if it
has real utility just because some existing equipment or chips can't
handle it. If a service provider wants or needs a new capability, they
will acquire or upgrade equipment that supports it. This is true for
any new features that we add to any protocol, it's not just the label
stack.

Cheers,
Andy

On Mon, Mar 10, 2014 at 10:25 PM, Mach Chen <[email-masked]> wrote:
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 12 Mar 2014 06:16:34 +0000

> -----邮件原件-----
> 发件人: mpls [mailto:[email-masked]] 代表 Andrew G. Malis
> 发送时间: 2014年3月11日 19:25
> 收件人: Mach Chen
> 抄送: [email-masked]
> 主题: Re: [mpls] Clarification on source label
> 
> Just to reiterate what I said at the mike during this discussion, we can't stop
> adding new features (and depth) to the label stack if it has real utility just
> because some existing equipment or chips can't handle it. If a service provider
> wants or needs a new capability, they will acquire or upgrade equipment that
> supports it. This is true for any new features that we add to any protocol, it's not
> just the label stack.

+1

Best regards,
Xiaohu

> > During the second MPLS session last week, there are lot of discussions on the
> source label, thanks for the discussions!
> >
> > Regarding to the usage of source label, there may be some misunderstanding.
> The main purpose of source label is for OAM, although the source label can be
> applied to real packets, but it's optional, it depends on how you use it.
> >
> > In addition, regarding to the depth of label stack, IMHO, this is proved that is
> not an real issue for the new generation hardware (chips and NPs), the depth is
> only related the need.
> >
> >
> > Best regards,
> > Mach
> >

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 12 Mar 2014 19:32:48 -0400

Mach,

Two issues here.  See inline.

btw - you should put draft-chen-mpls-source-label-02 in the subject or
at least somewhere in the message body.

In message <[email-masked]>
Mach Chen writes:
> 
> Hi,
>  
> During the second MPLS session last week, there are lot of discussions
> on the source label, thanks for the discussions!
>  
> Regarding to the usage of source label, there may be some
> misunderstanding. The main purpose of source label is for OAM,
> although the source label can be applied to real packets, but it's
> optional, it depends on how you use it.

It is fine to use source label for OAM in LDP where LSPs are MP2P or
in any type of MP2P or MP2MP LSP.

The current draft should indicate that the source label is not
intended for use in source based routing.  It comes close to this in
stating "Source Labels SHOULD NOT be used for forwarding".  All of the
text regarding "steering" should be removed.  We already have ELI and
EL for that.  SL adds very little entropy.

SL is intended to be used to provide the basis for source specific
counters in MP2[M]P and for OAM that makes use of these source
specific counters.

> In addition, regarding to the depth of label stack, IMHO, this is
> proved that is not an real issue for the new generation hardware
> (chips and NPs), the depth is only related the need.

Since this is for provider use and the chips now on the market that
are in other ways appropriate for provider use don't have a severe
problem with label stack depth, this usage seems OK.  If a provider
finds that for their deployment it is not, then they can defer using
this until they get rid of the faulty equipment.  A specific line of
chips with severe stack depth issues was briefly mentioned at the
meeting but not a line of chips that is appropriate for provider use
for many reasons other than severe stack depth limitations.

> Mach

Rereading the draft it would be shorter and more to the point if all
the steering and source filtering applications were removed and
strongly discouraged.  The source filtering argument is weak and
likely invalid.  Only the OAM use should remain in section 3.

Also note that steering and source filtering contradicts with the
following.

  4.2.  Transit LSR

   There is no change in forwarding behavior for transit LSRs.  But if
   a transit LSR can recognize the SLI, it can use the SL to collect
   traffic throughput and/or measure the performance of the LSP.

You should request an extended special purpose label.  In order to do
that you have to list Kireeti's special purpose label draft as
normative and cite the new registry that is created.  I'm not sure
this is a good use of one of the remaining 0-14 label space but that
is something that should be discussed on the list.

Also note that LSP_ATTRIBUTES flag bits are in short supply.  Perhaps
another mechanism should be considered.

Curtis

---

From: Mach Chen <[email-masked]>
Date: Thu, 13 Mar 2014 02:08:39 +0000

Hi Curtis,

Thanks for your comments and suggestions!

See my reply inline...

> -----Original Message-----
> From: mpls [mailto:[email-masked]] On Behalf Of Curtis Villamizar
> Sent: Thursday, March 13, 2014 7:33 AM
> To: Mach Chen
> Cc: [email-masked]
> Subject: Re: [mpls] Clarification on source label
> 
> 
> Mach,
> 
> btw - you should put draft-chen-mpls-source-label-02 in the subject or at least
> somewhere in the message body.

Yes, my fault.

Thank you for putting it here :-)

> 
> In message
> <[email-masked]
> wei.com>
> Mach Chen writes:
> >
> > Hi,
> >
> It is fine to use source label for OAM in LDP where LSPs are MP2P or in any type
> of MP2P or MP2MP LSP.
> 
> The current draft should indicate that the source label is not intended for use in
> source based routing.  It comes close to this in stating "Source Labels SHOULD
> NOT be used for forwarding".  All of the text regarding "steering" should be
> removed.  We already have ELI and EL for that.  SL adds very little entropy.

I am personally fine to remove those steering related text.

> 
> SL is intended to be used to provide the basis for source specific counters in
> MP2[M]P and for OAM that makes use of these source specific counters.
> 
> Since this is for provider use and the chips now on the market that are in other
> ways appropriate for provider use don't have a severe problem with label stack
> depth, this usage seems OK.  If a provider finds that for their deployment it is
> not, then they can defer using this until they get rid of the faulty equipment.  A
> specific line of chips with severe stack depth issues was briefly mentioned at the
> meeting but not a line of chips that is appropriate for provider use for many
> reasons other than severe stack depth limitations.

Agree.

> 
> > Best regards,
> > Mach
> 
> Rereading the draft it would be shorter and more to the point if all the steering
> and source filtering applications were removed and strongly discouraged.  The
> source filtering argument is weak and likely invalid.  Only the OAM use should
> remain in section 3.

OK.

> 
> Also note that steering and source filtering contradicts with the following.
> 
>   4.2.  Transit LSR
> 
> You should request an extended special purpose label.  In order to do that you
> have to list Kireeti's special purpose label draft as normative and cite the new
> registry that is created.  I'm not sure this is a good use of one of the remaining
> 0-14 label space but that is something that should be discussed on the list.

Sure, will add the reference in the next revision.

> 
> Also note that LSP_ATTRIBUTES flag bits are in short supply.  Perhaps another
> mechanism should be considered.

I guess you missed this LSP_ATTRIBUTES flag [RFC5420] with the SESSION_ATTRIBUTE object Flags field that has only 8 bits.

According to the definition in Section 3.1. of RFC5420:

"The Attribute Flags TLV Value field is an array of units of 32 flags
   numbered from the most significant bit as bit zero.  The Length field
   for this TLV is therefore always a multiple of four bytes, regardless
   of the number of bits carried, and no padding is required.
"
Seems the LSP_Attribute Flags TLV has enough bits for using. 

Thanks,
Mach