Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label

From: Stewart Bryant <[email-masked]>
Date: Thu, 16 Oct 2014 13:49:01 +0100

Ross

You state that you are starting an IPR poll with a view
to determining whether this draft is ready for adoption as a WG draft.

It is my view that it is premature to adopt a solution draft such as this
without first achieving a common understanding of all the requirements.
In this particular case, the solution on the table will require a hardware
re-spin and will consume a precious 0..15 reserved label which
is something that we should not do lightly.

In addition I am not convinced that the full set of requirements
are taken into account in the proposed design. For example
the solution only proposes to identify the source LSR, whereas
it seems likely that a finer granularity of flow identification will be
needed in practice. Additionally in the only use case cited
(performance monitoring) it seems likely that accounting
demarcation will be be needed to allow for different delays
of the ECMP paths and the distribution of packets across
multiple receiver interfaces.

I think that we need to backup the process and start by agreeing
the set of requirements before we embark on a design which will
be expensive in MPLS protocol and implementation resource.

As such I think the IPR poll, and the  imminent intention to adopt
is premature.

- Stewart

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 16 Oct 2014 16:33:52 +0000

Hi Stewart,
thank you for your interest in the proposal, detailed and thought provoking comments. Please find my notes in-lined and tagged GIM>>.

	Regards,
		Greg

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Thursday, October 16, 2014 5:49 AM
To: Ross Callon; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label

Ross

You state that you are starting an IPR poll with a view to determining whether this draft is ready for adoption as a WG draft.

It is my view that it is premature to adopt a solution draft such as this without first achieving a common understanding of all the requirements.
In this particular case, the solution on the table will require a hardware re-spin and will consume a precious 0..15 reserved label which is something that we should not do lightly.
GIM>> With creation of the Extended Special Purpose Label space SLI (Source Label Indicator) may well come be allocated from that space, not from original 0...15. Though I agree, we must be considerate and thorough when allocating (extended) special purpose label, any label.

In addition I am not convinced that the full set of requirements are taken into account in the proposed design. For example the solution only proposes to identify the source LSR, whereas it seems likely that a finer granularity of flow identification will be needed in practice. Additionally in the only use case cited (performance monitoring) it seems likely that accounting demarcation will be be needed to allow for different delays of the ECMP paths and the distribution of packets across multiple receiver interfaces.
GIM>> I believe that purpose of SL in OAM is not to uniquely identify particular flow but only identify maintenance point, whether as source of OAM test packets in case of active measurements, or OAM observation point in case of passive measurements. True MEP ID, as in RFC 6428, may be used but SL is viewed by authors as lighter, more generic method that is applicable not only to MPLS-TP but to other MPLS networks, including IP/MPLS and Segment Routing with MPLS dataplane.

I think that we need to backup the process and start by agreeing the set of requirements before we embark on a design which will be expensive in MPLS protocol and implementation resource.

As such I think the IPR poll, and the  imminent intention to adopt is premature.

- Stewart

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 16 Oct 2014 19:06:13 +0200

Stewart,

To add to Greg's response, in a vacuum, I would agree with your email.
Howver, there has already been considerable discussion on the mpls list of
real operational issues that this draft addresses, such as packet loss in
mobile backhaul networks using mp-to-p MPLS. This will allow both the
ability to measure loss ratios and also to generate traffic matrices to see
if judicial TE would improve things. Perhaps this could be added to the
draft, but the draft isn't being written as an academic excercse, but to
address networks issues.

Cheers,
Andy

On Thu, Oct 16, 2014 at 6:33 PM, Gregory Mirsky <[email-masked]
> wrote:

> Hi Stewart,
> thank you for your interest in the proposal, detailed and thought
> provoking comments. Please find my notes in-lined and tagged GIM>>.
>
>         Regards,
>                 Greg
>
> To: Ross Callon; [email-masked];
> [email-masked]
> You state that you are starting an IPR poll with a view to determining
> whether this draft is ready for adoption as a WG draft.
>
> re-spin and will consume a precious 0..15 reserved label which is something
> that we should not do lightly.
> GIM>> With creation of the Extended Special Purpose Label space SLI
> (Source Label Indicator) may well come be allocated from that space, not
> from original 0...15. Though I agree, we must be considerate and thorough
> when allocating (extended) special purpose label, any label.
>
> In addition I am not convinced that the full set of requirements are taken
> into account in the proposed design. For example the solution only proposes
> to identify the source LSR, whereas it seems likely that a finer
> granularity of flow identification will be needed in practice. Additionally
> in the only use case cited (performance monitoring) it seems likely that
> accounting demarcation will be be needed to allow for different delays of
> the ECMP paths and the distribution of packets across multiple receiver
> interfaces.
> GIM>> I believe that purpose of SL in OAM is not to uniquely identify
> particular flow but only identify maintenance point, whether as source of
> OAM test packets in case of active measurements, or OAM observation point
> in case of passive measurements. True MEP ID, as in RFC 6428, may be used
> but SL is viewed by authors as lighter, more generic method that is
> applicable not only to MPLS-TP but to other MPLS networks, including
> IP/MPLS and Segment Routing with MPLS dataplane.
>
> I think that we need to backup the process and start by agreeing the set
> of requirements before we embark on a design which will be expensive in
> MPLS protocol and implementation resource.
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Shahram Davari <[email-masked]>
Date: Thu, 16 Oct 2014 18:26:29 +0000

Hi,

I agree with Stewart. I am not convinced such a label is required. This draft adds multiple labels to the label stack (makes the label stack much larger than it already is) and requires a respin of chips due to its special label handling in the data-plane.

An alternative solution for MP2MP or MP2P Loss Measurement is to use ILM from RFC6374.

So until a solid argument is put forward that existing solutions (ILM in RFC 6374) or possible other solutions not requiring HW change are not adequate, I think it is premature To adopt this draft. 

Thanks
Shahram

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Thursday, October 16, 2014 5:49 AM
To: Ross Callon; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label

Ross

- Stewart

---

From: Shahram Davari <[email-masked]>
Date: Thu, 16 Oct 2014 18:37:49 +0000

Hi,

This is similar to the Traffic Engineering argument. If a service provider wants to use MPL S and do traffic Engineering then they should use P2P RSVP-TE LSPs, otherwise then can use MP2MP LDP LSPs. 

Similarly in this case, if a service provider wants to use MPL S and do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE LSPs, otherwise they can use MP2MP LDP LSPs.

Thanks
Shahram

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Thursday, October 16, 2014 11:26 AM
To: [email-masked]; Ross Callon; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label

Hi,

Thanks
Shahram

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Thursday, October 16, 2014 5:49 AM
To: Ross Callon; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label

Ross

- Stewart

---

From: Ross Callon <[email-masked]>
Date: Thu, 16 Oct 2014 19:25:02 +0000

MPLS working group;

There have been a number of comments, both public and private, about whether or not source labels are needed and/or worth the cost of implementing this approach. It is clear that we need a discussion in public on the MPLS email list of this issue. In principle this discussion could occur either before or as part of the call for adoption. However, due to the strong interest of several folks to focus on this issue, and the possibility that the outcome of this discussion might motivate changes to the document, I think that we should have this discussion prior to the call for adoption. 

I would like to therefore encourage MPLS participants to reply to Stewart's email (and the few replies that have already occurred) and to continue this discussion. The requirements and use cases for source labels, whether source labels are needed, what the cost of implementation would be, and alternatives to satisfy the same use cases, are all explicitly topics that should be considered (as well as any other issues that people feel is important in determining whether the MPLS WG should work on source labels). 

In the hope of coming to a timely consensus, I would encourage people who have opinions on this issue to respond within two weeks (by Friday October 31). 

Thanks, Ross

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Thursday, October 16, 2014 8:49 AM
To: Ross Callon; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label

Ross

- Stewart

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 17 Oct 2014 00:33:37 +0000

Kudos to the authors of draft-chen-mpls-source-label for coming up with an interesting solution.

However, I agree with Stewart. The Introduction only specifies that "performance monitoring" is the only concrete requirement for this solution. From "performance monitoring" perspective, the proposed only provides a solution to limited [1] LSP types (and UHP/PHP of them) and [2] granularity of measurements. 

For example, let's say node A has X number of Segment Routing steered path to node B. Even assuming that measurement is to be taken per steered path basis, there needs to be X number of labels for node B to keep statistics on. The number of required labels can increase quite fast with increasing number of devices x number of paths x level of measurement granularity.

I think it is a good idea to take a step back and discuss the problem scope.

Thanks!

-Nobo

> (stbryant)
> In this particular case, the solution on the table will require a hardware re-
> spin and will consume a precious 0..15 reserved label which is something
> into account in the proposed design. For example the solution only
> proposes to identify the source LSR, whereas it seems likely that a finer
> granularity of flow identification will be needed in practice. Additionally in
> the only use case cited (performance monitoring) it seems likely that
> I think that we need to backup the process and start by agreeing the set of
> requirements before we embark on a design which will be expensive in

---

From: Mach Chen <[email-masked]>
Date: Fri, 17 Oct 2014 02:44:07 +0000

Hi Stewart,

Thanks for raising this discussion!

Please see my replies inline...

> Sent: Thursday, October 16, 2014 8:49 PM
> You state that you are starting an IPR poll with a view to determining whether this
> draft is ready for adoption as a WG draft.
> 
> It is my view that it is premature to adopt a solution draft such as this without first
> achieving a common understanding of all the requirements.
> In this particular case, the solution on the table will require a hardware re-spin
> and will consume a precious 0..15 reserved label which is something that we
> should not do lightly.
As Greg pointed out, Extended Special Purpose (ESP) label is also applicable. I will let the WG to decide whether this solution deserves a 0..15 reserved label or an ESP label.

No hardware re-spin is a good thing, but I don't think hardware re-spin is a hurdle for accepting a solution in IETF. I always believe "no pain no gain". 
> 
> In addition I am not convinced that the full set of requirements are taken into
> account in the proposed design. For example the solution only proposes to
> identify the source LSR, whereas it seems likely that a finer granularity of flow
> identification will be needed in practice. Additionally in the only use case cited

The solution does allow multiple Source Identifiers to be allocated and correlated to an LSR, hence it could provide a finer granularity of flow identification when needed.
 
> (performance monitoring) it seems likely that accounting demarcation will be be
> needed to allow for different delays of the ECMP paths and the distribution of
> packets across multiple receiver interfaces.

This document is talking about how to do source identification, accounting demarcation is out of the scope although it is another important thing for passive performance measurement, you may refer to: http://tools.ietf.org/html/draft-chen-ippm-coloring-based-ipfpm-framework-02, it proposed a way to do accounting demarcation even with ECMP paths.

> requirements before we embark on a design which will be expensive in MPLS
> protocol and implementation resource.

Given that RFC6374 is there, I think that the WG has made the agreement on passive performance measurement. 

And for MP2P and MP2MP based LSP, it's obviously that source identification is needed when do passive performance measurement. So, IMHO, the requirement is clear and straightforward.

Best regards,
Mach

---

From: Mach Chen <[email-masked]>
Date: Fri, 17 Oct 2014 03:10:33 +0000

HI Shahram,

> Similarly in this case, if a service provider wants to use MPL S and do Direct Loss
> Measurement (DLM), then they must use P2P RSVP-TE LSPs, otherwise they can
> use MP2MP LDP LSPs.

If I was a service provider, I will not buy this logic. It just like someone's son is not good at math, then you suggest him to replace the son with someone else who is good at math :-)

Best regards,
Mach

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Friday, October 17, 2014 2:38 AM
> To: [email-masked]; Ross Callon; [email-masked];
> Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label
> 
> Hi,
> 
> This is similar to the Traffic Engineering argument. If a service provider wants to
> use MPL S and do traffic Engineering then they should use P2P RSVP-TE LSPs,
> otherwise then can use MP2MP LDP LSPs.
> 
> Similarly in this case, if a service provider wants to use MPL S and do Direct Loss
> Measurement (DLM), then they must use P2P RSVP-TE LSPs, otherwise they can
> use MP2MP LDP LSPs.
> 
> Thanks
> Shahram
> 
> To: [email-masked]; Ross Callon; [email-masked];
> I agree with Stewart. I am not convinced such a label is required. This draft adds
> multiple labels to the label stack (makes the label stack much larger than it
> already is) and requires a respin of chips due to its special label handling in the
> data-plane.
> 
> So until a solid argument is put forward that existing solutions (ILM in RFC 6374)
> or possible other solutions not requiring HW change are not adequate, I think it is
> premature To adopt this draft.
> 
> 
> Thanks
> Shahram
>

---

From: Mach Chen <[email-masked]>
Date: Fri, 17 Oct 2014 07:28:50 +0000

Hi Nobo,

Thanks for your comments!

> From: Nobo Akiya (nobo) [mailto:[email-masked]]
> Sent: Friday, October 17, 2014 8:34 AM
> To: Stewart Bryant (stbryant); Ross Callon; [email-masked];

Thanks for your "kudos" :-)

> 
> However, I agree with Stewart. The Introduction only specifies that
> "performance monitoring" is the only concrete requirement for this solution.
> From "performance monitoring" perspective, the proposed only provides a
> solution to limited [1] LSP types (and UHP/PHP of them) and [2] granularity of
> measurements.

The solution is intended to solve an existing real problem. We do not expect the solution that could apply to any scenario and solve future occur issues, although it may have the potentiality. This is also the tradition of IETF.

> 
> For example, let's say node A has X number of Segment Routing steered path to
> node B. Even assuming that measurement is to be taken per steered path basis,
> there needs to be X number of labels for node B to keep statistics on. The
> number of required labels can increase quite fast with increasing number of
> devices x number of paths x level of measurement granularity.

Regarding the granularity, the Source Identifier (SI) is very similar to the situation of BFD discriminator (DISC). I think you would agree that the SI and DISC themselves are not the issue. The crux is that how many flows/BFD sessions you want to monitor/enable, and the hardware resource(e.g., timers) is the critical constraint. 

Best regards,
Mach

> > It is my view that it is premature to adopt a solution draft such as
> > this without first achieving a common understanding of all the requirements.
> > In this particular case, the solution on the table will require a
> > hardware re- spin and will consume a precious 0..15 reserved label
> > which is something that we should not do lightly.
> >
> > In addition I am not convinced that the full set of requirements are
> > taken into account in the proposed design. For example the solution
> > only proposes to identify the source LSR, whereas it seems likely that
> > a finer granularity of flow identification will be needed in practice.
> > Additionally in the only use case cited (performance monitoring) it
> > seems likely that accounting demarcation will be be needed to allow
> > for different delays of the ECMP paths and the distribution of packets
> > across multiple receiver interfaces.
> >
> > I think that we need to backup the process and start by agreeing the
> > set of requirements before we embark on a design which will be
> > expensive in MPLS protocol and implementation resource.
> >

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 17 Oct 2014 11:15:25 +0100

Andy

As urgent as you might feel the requirement, jumping to a solution 
without properly understanding the requirement just costs everyone time 
and money and at the end of the day may not deliver anything of use to 
the customer.

If you have ECMP, which many networks do, and you have multiple core 
facing line cards at the egress you need other information besides the 
SA. Now you can declare this out of scope if the requirements say it is 
not needed. However whilst that may be the case for MW it is certainly 
needed in the core.

Why do we assume that SA-DA measurement granularity is sufficient? Will 
you never be required to report on a finer granularity than that?

Why do we need do this by introducing SA? Why not do it with some 
destination based approach?

Why do we need to have the reserved labels, why not have a new FEC for 
delivery which always includes an SA as the next label?

MW usually deploys systems that have highly restricted imposition 
capability, can we really afford to introduce three labels as Greg suggests?

If you want to generate a traffic matrix, why would you not do this with 
IPFIX? Are there any other methods that can leverage control plane 
capabilities without the need to spin new h/w which would be required by 
the proposed dataplane change.

- Stewart

On 16/10/2014 18:06, Andrew G. Malis wrote:
> Howver, there has already been considerable discussion on the mpls 
> list of real operational issues that this draft addresses, such as 
> packet loss in mobile backhaul networks using mp-to-p MPLS. This will 
> allow both the ability to measure loss ratios and also to generate 
> traffic matrices to see if judicial TE would improve things. Perhaps 
> this could be added to the draft, but the draft isn't being written as 
> an academic excercse, but to address networks issues.
>
> Cheers,
> Andy
>
>
> On Thu, Oct 16, 2014 at 6:33 PM, Gregory Mirsky 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Stewart,
>     From: Stewart Bryant [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     To: Ross Callon; [email-masked] <mailto:[email-masked]>;
>     <mailto:[email-masked]>
>     Cc: [email-masked] <mailto:[email-masked]>
>     You state that you are starting an IPR poll with a view to
>     determining whether this draft is ready for adoption as a WG draft.
>
>     It is my view that it is premature to adopt a solution draft such
>     as this without first achieving a common understanding of all the
>     requirements.
>     hardware re-spin and will consume a precious 0..15 reserved label
>     GIM>> With creation of the Extended Special Purpose Label space
>     SLI (Source Label Indicator) may well come be allocated from that
>     space, not from original 0...15. Though I agree, we must be
>     considerate and thorough when allocating (extended) special
>     purpose label, any label.
>
>     are taken into account in the proposed design. For example the
>     solution only proposes to identify the source LSR, whereas it
>     seems likely that a finer granularity of flow identification will
>     be needed in practice. Additionally in the only use case cited
>     demarcation will be be needed to allow for different delays of the
>     ECMP paths and the distribution of packets across multiple
>     receiver interfaces.
>     GIM>> I believe that purpose of SL in OAM is not to uniquely
>     identify particular flow but only identify maintenance point,
>     whether as source of OAM test packets in case of active
>     measurements, or OAM observation point in case of passive
>     measurements. True MEP ID, as in RFC 6428, may be used but SL is
>     viewed by authors as lighter, more generic method that is
>     applicable not only to MPLS-TP but to other MPLS networks,
>     including IP/MPLS and Segment Routing with MPLS dataplane.
>
>     the set of requirements before we embark on a design which will be
>     [email-masked] <mailto:[email-masked]>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 17 Oct 2014 11:21:31 +0100

> GIM>> With creation of the Extended Special Purpose Label space SLI (Source Label Indicator) may well come be allocated from that space, not from original 0...15. Though I agree, we must be conside…

SB> This adds three labels to the stack. Are we sure that the edge boxes 
can afford to do this?
> GIM>> I believe that purpose of SL in OAM is not to uniquely identify particular flow but only identify maintenance point, whether as source of OAM test packets in case of active measurements, or O…
SB> SL on it's own is not sufficient to cope with ECMP.

SB> Why do we need reserved labels? Why not a new FEC with dual labels?

Stewart
> .

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 17 Oct 2014 11:34:40 +0100

> No hardware re-spin is a good thing, but I don't think hardware re-spin is a hurdle for accepting a solution in IETF. I always believe "no pain no gain".
Setting aside the fact that SL on its work is insufficient in an ECMP 
case, and that a lot can be done with multiple delivery labels, a new 
FEC would mean that you did not need any reserved labels.

> The solution does allow multiple Source Identifiers to be allocated and correlated to an LSR, hence it could provide a finer granularity of flow identification when needed.
I agree you could have a source block, you could also have an additional 
label.
> This document is talking about how to do source identification, accounting demarcation is out of the scope although it is another important thing for passive performance measurement, you may refer…
Indeed, but the question is whether we need one solution or two.
> And for MP2P and MP2MP based LSP, it's obviously that source identification is needed when do passive performance measurement. So, IMHO, the requirement is clear and straightforward.
The requirement to do the measurement is there, but I remain unconvinced 
that the full set of requirements for the solution is on the table, nor 
am I yet convinced that the solution you propose is optimum.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 17 Oct 2014 11:49:16 +0100

> If I was a service provider, I will not buy this logic. It just like someone's son is not good at math, then you suggest him to replace the son with someone else who is good at math :-)
Your opinion would depend on whether you were the son, a more capable 
child competing for the school/job, the parent, the parent of another 
child, the teacher, the maths quiz team captain, the admissions tutor, 
the employer.....

Solutions meet requirements in a context, and the proposal is that we 
start by building a common understanding of the requirements before we 
jump to a solution.

- Stewart

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 17 Oct 2014 13:05:45 +0000

Hi Stewart,
I recall that the question of SLI/SL impact on MPLS label stack depth was discussed, probably in London.
Yes, some nodes would not be able to support SLI/SL and thus would not advertise SLC. I think that is no different from how ELI/EL and ELC case been handled.

	Regards,
		Greg

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Friday, October 17, 2014 3:22 AM
To: Gregory Mirsky; Ross Callon; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label

Stewart

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 17 Oct 2014 13:35:48 +0000

Hi Stewart,
If the case is when ECMP segment is at the very ingress LSR, at the source, then, I’d assume, ELI/EL will be used and thus egress can use it in combination with SLI/SL to identify the actual component of the ECMP segment that been traversed.
True, that would add even more labels to the stack but if certainty, absolute certainty is the preeminent requirement, then one will accept the solution.

                Regards,
                                Greg

From: Stewart Bryant [mailto:[email-masked]]
Sent: Friday, October 17, 2014 3:15 AM
To: Andrew G. Malis; Gregory Mirsky
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label

Andy

As urgent as you might feel the requirement, jumping to a solution without properly understanding the requirement just costs everyone time and money and at the end of the day may not deliver anything of use to the customer.

If you have ECMP, which many networks do, and you have multiple core facing line cards at the egress you need other information besides the SA. Now you can declare this out of scope if the requirements say it is not needed. However whilst that may be the case for MW it is certainly needed in the core.

Why do we assume that SA-DA measurement granularity is sufficient? Will you never be required to report on a finer granularity than that?

Why do we need do this by introducing SA? Why not do it with some destination based approach?

Why do we need to have the reserved labels, why not have a new FEC for delivery which always includes an SA as the next label?

MW usually deploys systems that have highly restricted imposition capability, can we really afford to introduce three labels as Greg suggests?

If you want to generate a traffic matrix, why would you not do this with IPFIX? Are there any other methods that can leverage control plane capabilities without the need to spin new h/w which would be required by the proposed dataplane change.

- Stewart

To add to Greg's response, in a vacuum, I would agree with your email. Howver, there has already been considerable discussion on the mpls list of real operational issues that this draft addresses, such as packet loss in mobile backhaul networks using mp-to-p MPLS. This will allow both the ability to measure loss ratios and also to generate traffic matrices to see if judicial TE would improve things. Perhaps this could be added to the draft, but the draft isn't being written as an academic excercse, but to address networks issues.

Cheers,
Andy

On Thu, Oct 16, 2014 at 6:33 PM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Stewart,
thank you for your interest in the proposal, detailed and thought provoking comments. Please find my notes in-lined and tagged GIM>>.

        Regards,
                Greg

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, October 16, 2014 5:49 AM
To: Ross Callon; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label

Ross

- Stewart

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

--

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 17 Oct 2014 15:19:22 +0100

Greg, the interesting ECMP case is where it occurs at the egress and results
in delivery to multiple line cards. However where ever it happens to get
flow discontinuity that needs to be reconciled.

In modern networks packet loss is so low that close to absolute certainty
is surely the only case of interest?

Or are you aiming this at a very course granularity of loss, in which case
that needs to be made very clear early on the draft.

Stewart

On 17/10/2014 14:35, Gregory Mirsky wrote:
>
> Hi Stewart,
>
> If the case is when ECMP segment is at the very ingress LSR, at the 
> source, then, I’d assume, ELI/EL will be used and thus egress can use 
> it in combination with SLI/SL to identify the actual component of the 
> ECMP segment that been traversed.
>
> True, that would add even more labels to the stack but if certainty, 
> absolute certainty is the preeminent requirement, then one will accept 
> the solution.
>
> Regards,
>
> Greg
>
> *From:*Stewart Bryant [mailto:[email-masked]]
> *Sent:* Friday, October 17, 2014 3:15 AM
> *To:* Andrew G. Malis; Gregory Mirsky
> *Cc:* Ross Callon; [email-masked]; 
> [email-masked]; [email-masked]
> *Subject:* Re: [mpls] IPR poll for draft-chen-mpls-source-label
>
> Andy
>
> without properly understanding the requirement just costs everyone 
> time and money and at the end of the day may not deliver anything of 
> use to the customer.
>
> SA. Now you can declare this out of scope if the requirements say it 
> is not needed. However whilst that may be the case for MW it is 
> certainly needed in the core.
>
> Why do we assume that SA-DA measurement granularity is sufficient? 
> Will you never be required to report on a finer granularity than that?
>
> If you want to generate a traffic matrix, why would you not do this 
> with IPFIX? Are there any other methods that can leverage control 
> plane capabilities without the need to spin new h/w which would be 
> required by the proposed dataplane change.
>
> - Stewart
>
>
>     To add to Greg's response, in a vacuum, I would agree with your
>     email. Howver, there has already been considerable discussion on
>     the mpls list of real operational issues that this draft
>     addresses, such as packet loss in mobile backhaul networks using
>     mp-to-p MPLS. This will allow both the ability to measure loss
>     ratios and also to generate traffic matrices to see if judicial TE
>     would improve things. Perhaps this could be added to the draft,
>     but the draft isn't being written as an academic excercse, but to
>     address networks issues.
>
>     Cheers,
>
>     Andy
>

---

From: Shahram Davari <[email-masked]>
Date: Fri, 17 Oct 2014 14:39:30 +0000

Hi

This is a funny example that does not represent my alternative solution.

My example is solid as applies to TE case today and SPs are buying it. Otherwise why no SP has ever proposed to add TE to MP2P LSPs ?

Regards,
Shahram

> On Oct 16, 2014, at 8:10 PM, "Mach Chen" <[email-masked]> wrote:
> 
> HI Shahram,
>

---

From: Shahram Davari <[email-masked]>
Date: Fri, 17 Oct 2014 15:45:40 +0000

Let me give you a proper example instead.

This is like adding a custom made motor to your son's bike since he wants to get to school faster. While a better solution is just give him a motorcycle or car instead of inventing something new. 

The solution to DLM already exists. 

You might say this is optional but as we know vendors have to implement options too.

I think the 3 extra labels this solution adds to solve a problem that can be solved using other methods is by itself a show stopper.

As Stewart said we need another 2-3 labels for the EL. 

Another possible way of doing this is by just using SIP from the encapsulated IP header or SA from the encapsulated Ethernet header.

Regards,
Shahram

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 17 Oct 2014 18:14:43 +0000

Hi Shahram,
using characteristic information from IP or Ethernet layer to measure MPLS performance? That would be another layer violation, would it not? And what if your payload is neither IP, nor Ethernet, just of academic argument sake?
IP has IP PM with OWAMP/TWAMP as active measurement protocol. Ethernet - Y.1731. And in both cases none relies on another layer addressing information. I think that what you're suggesting is not the right way, even if customers are buying it for the time being.

	Regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Friday, October 17, 2014 8:46 AM
To: Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label

Regards,
Shahram

>> Similarly in this case, if a service provider wants to use MPL S and 
>> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE 
>> LSPs, otherwise they can use MP2MP LDP LSPs.
> 
> If I was a service provider, I will not buy this logic. It just like 
> someone's son is not good at math, then you suggest him to replace the 
> son with someone else who is good at math :-)
> 
> 
> Best regards,
> Mach
> 
>> This is similar to the Traffic Engineering argument. If a service 
>> provider wants to use MPL S and do traffic Engineering then they 
>> should use P2P RSVP-TE LSPs, otherwise then can use MP2MP LDP LSPs.
>> 
>> Similarly in this case, if a service provider wants to use MPL S and 
>> do Direct Loss Measurement (DLM), then they must use P2P RSVP-TE 
>> LSPs, otherwise they can use MP2MP LDP LSPs.
>> 
>> Thanks
>> Shahram
>> 
>> I agree with Stewart. I am not convinced such a label is required. 
>> This draft adds multiple labels to the label stack (makes the label 
>> stack much larger than it already is) and requires a respin of chips 
>> due to its special label handling in the data-plane.
>> 
>> So until a solid argument is put forward that existing solutions (ILM 
>> in RFC 6374) or possible other solutions not requiring HW change are 
>> not adequate, I think it is premature To adopt this draft.
>> 
>> 
>> Thanks
>> Shahram
>> 
>> only proposes to identify the source LSR, whereas it seems likely 
>> that a finer granularity of flow identification will be needed in 
>> practice. Additionally in the only use case cited (performance 
>> monitoring) it seems likely that accounting demarcation will be be 
>> needed to allow for different delays of the ECMP paths and the distribution of packets across multiple receiver interfaces.
>>

---

From: Shahram Davari <[email-masked]>
Date: Fri, 17 Oct 2014 18:22:44 +0000

Hi Greg,

How about using a combination of (LSP label + PW Label) to uniquely identify the source of the LSP? 

Thanks
Shahram

-----Original Message-----
From: Gregory Mirsky [mailto:[email-masked]] 
Sent: Friday, October 17, 2014 11:15 AM
To: Shahram Davari; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Shahram,

	Regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Friday, October 17, 2014 8:46 AM
To: Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label

Regards,
Shahram

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 17 Oct 2014 18:25:35 +0000

Hi Shahram,
and if this is EVPN and no PW exist? Are you going to offer piecemeal solutions or look for more generic mechanism? I do believe that SLI/SL, though may cause some pain, is useful and generic solution to the real problem.

	Regards,
		Greg 

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Friday, October 17, 2014 11:23 AM
To: Gregory Mirsky; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Greg,

Thanks
Shahram

-----Original Message-----
From: Gregory Mirsky [mailto:[email-masked]]
Sent: Friday, October 17, 2014 11:15 AM
To: Shahram Davari; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Shahram,

	Regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Friday, October 17, 2014 8:46 AM
To: Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label

Regards,
Shahram

---

From: Shahram Davari <[email-masked]>
Date: Fri, 17 Oct 2014 18:34:54 +0000

Hi Greg

I think you are jumping too far. The draft only mentions RFC5036 and RFC4364 as requirements and not EVPN. Are you adding new requirements on the fly?
We will solve the  EVPN LM when the time comes. (LSP+PW) label counting can be done today without any HW change.

Thanks
Shahram

-----Original Message-----
From: Gregory Mirsky [mailto:[email-masked]] 
Sent: Friday, October 17, 2014 11:26 AM
To: Shahram Davari; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Shahram,

	Regards,
		Greg 

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Friday, October 17, 2014 11:23 AM
To: Gregory Mirsky; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Greg,

Thanks
Shahram

-----Original Message-----
From: Gregory Mirsky [mailto:[email-masked]]
Sent: Friday, October 17, 2014 11:15 AM
To: Shahram Davari; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Shahram,

	Regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Friday, October 17, 2014 8:46 AM
To: Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label

Regards,
Shahram

---

From: Shahram Davari <[email-masked]>
Date: Fri, 17 Oct 2014 18:35:45 +0000

Also why ILM is not acceptable?

Thx
SD

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Friday, October 17, 2014 11:35 AM
To: Gregory Mirsky; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Greg

Thanks
Shahram

-----Original Message-----
From: Gregory Mirsky [mailto:[email-masked]] 
Sent: Friday, October 17, 2014 11:26 AM
To: Shahram Davari; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Shahram,

	Regards,
		Greg 

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Friday, October 17, 2014 11:23 AM
To: Gregory Mirsky; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Greg,

Thanks
Shahram

-----Original Message-----
From: Gregory Mirsky [mailto:[email-masked]]
Sent: Friday, October 17, 2014 11:15 AM
To: Shahram Davari; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Shahram,

	Regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Friday, October 17, 2014 8:46 AM
To: Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label

Regards,
Shahram

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 17 Oct 2014 18:39:00 +0000

Hi Shahram,
thank you for pointing this. We will review references and update the document with reference to draft-salam-l2vpn-evpn-oam-req-frmwk, draft-kumar-spring-sr-oam-requirement, and draft-ashwood-nvo3-oam-requirements, if any is missing.

	Regards,
		Greg

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Friday, October 17, 2014 11:35 AM
To: Gregory Mirsky; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Greg

Thanks
Shahram

-----Original Message-----
From: Gregory Mirsky [mailto:[email-masked]]
Sent: Friday, October 17, 2014 11:26 AM
To: Shahram Davari; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Shahram,

	Regards,
		Greg 

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Friday, October 17, 2014 11:23 AM
To: Gregory Mirsky; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Greg,

Thanks
Shahram

-----Original Message-----
From: Gregory Mirsky [mailto:[email-masked]]
Sent: Friday, October 17, 2014 11:15 AM
To: Shahram Davari; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Shahram,

	Regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Friday, October 17, 2014 8:46 AM
To: Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label

Regards,
Shahram

---

From: Shahram Davari <[email-masked]>
Date: Fri, 17 Oct 2014 18:52:18 +0000

Hi Greg,

draft-salam-l2vpn-evpn-oam-req-frmwk is expired., besides it is just a framework and not requirements. I believe the EVPN OAM has much more requirements than just adding a Source label.  You have to consider the Load balancing at multiple points, aliasing, Multi-homing, etc.

This requires much more discussion and a thorough requirements analysis before coming to a quick rush solution such a source-label.

Thanks
Shahram 

-----Original Message-----
From: Gregory Mirsky [mailto:[email-masked]] 
Sent: Friday, October 17, 2014 11:39 AM
To: Shahram Davari; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Shahram,

	Regards,
		Greg

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Friday, October 17, 2014 11:35 AM
To: Gregory Mirsky; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Greg

Thanks
Shahram

-----Original Message-----
From: Gregory Mirsky [mailto:[email-masked]]
Sent: Friday, October 17, 2014 11:26 AM
To: Shahram Davari; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Shahram,

	Regards,
		Greg 

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Friday, October 17, 2014 11:23 AM
To: Gregory Mirsky; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Greg,

Thanks
Shahram

-----Original Message-----
From: Gregory Mirsky [mailto:[email-masked]]
Sent: Friday, October 17, 2014 11:15 AM
To: Shahram Davari; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Shahram,

	Regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Friday, October 17, 2014 8:46 AM
To: Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label

Regards,
Shahram

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 17 Oct 2014 18:58:41 +0000

Hi Shahram,
I'll check with the authors of the EVPN OAM document on their plans.
I agree, there are many other interesting problems to solve. And we're not claiming that SLI/SL is solving all of them. Some, perhaps, but not all.

	Regards,
		Greg

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Friday, October 17, 2014 11:52 AM
To: Gregory Mirsky; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Greg,

Thanks
Shahram 

-----Original Message-----
From: Gregory Mirsky [mailto:[email-masked]]
Sent: Friday, October 17, 2014 11:39 AM
To: Shahram Davari; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Shahram,

	Regards,
		Greg

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Friday, October 17, 2014 11:35 AM
To: Gregory Mirsky; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Greg

Thanks
Shahram

-----Original Message-----
From: Gregory Mirsky [mailto:[email-masked]]
Sent: Friday, October 17, 2014 11:26 AM
To: Shahram Davari; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Shahram,

	Regards,
		Greg 

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Friday, October 17, 2014 11:23 AM
To: Gregory Mirsky; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Greg,

Thanks
Shahram

-----Original Message-----
From: Gregory Mirsky [mailto:[email-masked]]
Sent: Friday, October 17, 2014 11:15 AM
To: Shahram Davari; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Shahram,

	Regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Friday, October 17, 2014 8:46 AM
To: Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label

Regards,
Shahram

---

From: Shahram Davari <[email-masked]>
Date: Fri, 17 Oct 2014 19:04:05 +0000

Hi Greg,

> solution to limited [1] LSP types (and UHP/PHP of them) and [2] granularity of

Mach: The solution is intended to solve an existing real problem. We do not expect the solution that could apply to any scenario and solve future occur issues, although it may have the potentiality. This is also the tradition of IETF.

SD> First of all Mach says this is an existing real problem. Therefore I would conclude  he is not solving the EVPN LM. Secondly he says this is not a generalized solution for future (aka EVPN).  So just use the LSP+PW counting and it will solve your problem quickly and without any respin of HW. No standard is even required, just information RFC. 

Thanks
Shahram

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Friday, October 17, 2014 11:52 AM
To: Gregory Mirsky; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Greg,

Thanks
Shahram 

-----Original Message-----
From: Gregory Mirsky [mailto:[email-masked]] 
Sent: Friday, October 17, 2014 11:39 AM
To: Shahram Davari; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Shahram,

	Regards,
		Greg

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Friday, October 17, 2014 11:35 AM
To: Gregory Mirsky; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Greg

Thanks
Shahram

-----Original Message-----
From: Gregory Mirsky [mailto:[email-masked]]
Sent: Friday, October 17, 2014 11:26 AM
To: Shahram Davari; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Shahram,

	Regards,
		Greg 

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Friday, October 17, 2014 11:23 AM
To: Gregory Mirsky; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Greg,

Thanks
Shahram

-----Original Message-----
From: Gregory Mirsky [mailto:[email-masked]]
Sent: Friday, October 17, 2014 11:15 AM
To: Shahram Davari; Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

Hi Shahram,

	Regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Friday, October 17, 2014 8:46 AM
To: Mach Chen
Cc: Ross Callon; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label

Regards,
Shahram

---

From: "George Swallow (swallow)" <[email-masked]>
Date: Fri, 17 Oct 2014 20:33:27 +0000

Folks -

We need a clear set of requirements!  This is a huge change to MPLS.  We
certainly do not want to do it to meet a narrow set of requirements.  We
need to clearly articulate what we need in the way of loss/delay
measurement.  Then we need to explore possible solutions.  If a solution
can be found that does not have a major hardware impact, then we should
adopt that.  

George

On 10/17/14 3:04 PM, "Shahram Davari" <[email-masked]> wrote:

>Mach: The solution is intended to solve an existing real problem. We do
>not expect the solution that could apply to any scenario and solve future
>occur issues, although it may have the potentiality. This is also the
>tradition of IETF.
>
>
>SD> First of all Mach says this is an existing real problem. Therefore I
>would conclude  he is not solving the EVPN LM. Secondly he says this is
>not a generalized solution for future (aka EVPN).  So just use the LSP+PW
>counting and it will solve your problem quickly and without any respin of
>HW. No standard is even required, just information RFC.
>
>Thanks
>Shahram
>
>Cc: Ross Callon; [email-masked]; [email-masked];
>draft-salam-l2vpn-evpn-oam-req-frmwk is expired., besides it is just a
>framework and not requirements. I believe the EVPN OAM has much more
>requirements than just adding a Source label.  You have to consider the
>Load balancing at multiple points, aliasing, Multi-homing, etc.
>
>This requires much more discussion and a thorough requirements analysis
>before coming to a quick rush solution such a source-label.
>
>
>Thanks
>Shahram 
>
>Cc: Ross Callon; [email-masked]; [email-masked];
>thank you for pointing this. We will review references and update the
>document with reference to draft-salam-l2vpn-evpn-oam-req-frmwk,
>draft-kumar-spring-sr-oam-requirement, and
>draft-ashwood-nvo3-oam-requirements, if any is missing.
>
>	Regards,
>		Greg
>
>Cc: Ross Callon; [email-masked]; [email-masked];
>I think you are jumping too far. The draft only mentions RFC5036 and
>RFC4364 as requirements and not EVPN. Are you adding new requirements on
>the fly?
>Cc: Ross Callon; [email-masked]; [email-masked];
>and if this is EVPN and no PW exist? Are you going to offer piecemeal
>solutions or look for more generic mechanism? I do believe that SLI/SL,
>though may cause some pain, is useful and generic solution to the real
>problem.
>
>	Regards,
>		Greg 
>
>Cc: Ross Callon; [email-masked]; [email-masked];
>Cc: Ross Callon; [email-masked]; [email-masked];
>using characteristic information from IP or Ethernet layer to measure
>MPLS performance? That would be another layer violation, would it not?
>And what if your payload is neither IP, nor Ethernet, just of academic
>argument sake?
>IP has IP PM with OWAMP/TWAMP as active measurement protocol. Ethernet -
>Y.1731. And in both cases none relies on another layer addressing
>information. I think that what you're suggesting is not the right way,
>even if customers are buying it for the time being.
>
>	Regards,
>		Greg
>
>Cc: Ross Callon; [email-masked]; [email-masked];
>This is like adding a custom made motor to your son's bike since he wants
>to get to school faster. While a better solution is just give him a
>motorcycle or car instead of inventing something new.
>
>I think the 3 extra labels this solution adds to solve a problem that can
>be solved using other methods is by itself a show stopper.
>
>Another possible way of doing this is by just using SIP from the
>encapsulated IP header or SA from the encapsulated Ethernet header.
>
>Regards,
>Shahram
>
>
>>> needed to allow for different delays of the ECMP paths and the
>>>distribution of packets across multiple receiver interfaces.
>>>

---

From: John E Drake <[email-masked]>
Date: Fri, 17 Oct 2014 21:09:38 +0000

George,

>From the draft:

"For some applications, source identification is a critical requirement.  For example, performance monitoring, the monitoring nodes need to identify where packets were sent from and then can count the packets according to some constraints."

What do you think could possibly be added to make this list of requirements either more clear or more complete 8->?  It should also be blindingly obvious to the informed participant that to address this very complete set of requirements the use of global source labels is the solution that immediately springs to mind even thought it is completely at odds w/ the MPLS architecture.   "This isn't right. This isn't even wrong." -- Wolfgang Pauli

Is it possible euthanize to an I-D?

Yours Irrespectively,

John

> From: mpls [mailto:[email-masked]] On Behalf Of George Swallow
> (swallow)
> Sent: Friday, October 17, 2014 1:33 PM
> To: Shahram Davari; Gregory Mirsky; Mach Chen
> certainly do not want to do it to meet a narrow set of requirements.  We need
> to clearly articulate what we need in the way of loss/delay measurement.
> Then we need to explore possible solutions.  If a solution can be found that
> does not have a major hardware impact, then we should adopt that.
> 
> George
> 
> >> From "performance monitoring" perspective, the proposed only provides
> >>a  solution to limited [1] LSP types (and UHP/PHP of them) and [2]
> >>granularity of  measurements.
> >
> >not expect the solution that could apply to any scenario and solve
> >future occur issues, although it may have the potentiality. This is
> >also the tradition of IETF.
> >
> >
> >SD> First of all Mach says this is an existing real problem. Therefore
> >SD> I
> >not a generalized solution for future (aka EVPN).  So just use the
> >LSP+PW counting and it will solve your problem quickly and without any
> >respin of HW. No standard is even required, just information RFC.
> >
> >Thanks
> >Shahram
> >
> >RFC4364 as requirements and not EVPN. Are you adding new requirements
> >on the fly?
> >IP has IP PM with OWAMP/TWAMP as active measurement protocol.
> Ethernet
> >- Y.1731. And in both cases none relies on another layer addressing
> >This is like adding a custom made motor to your son's bike since he
> >wants to get to school faster. While a better solution is just give him
> >a motorcycle or car instead of inventing something new.
> >
> >I think the 3 extra labels this solution adds to solve a problem that
> >can be solved using other methods is by itself a show stopper.
> >
> >> someone's son is not good at math, then you suggest him to replace
> >> the son with someone else who is good at math :-)
> >>
> >>
> >> Best regards,
> >> Mach
> >>
> >>> So until a solid argument is put forward that existing solutions
> >>> (ILM in RFC 6374) or possible other solutions not requiring HW
> >>> change are not adequate, I think it is premature To adopt this draft.
> >>>
> >>>
> >>> Thanks
> >>> Shahram
> >>>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 17 Oct 2014 21:11:41 +0000

Hi Ross,

Since you are asking, let me share a couple of high level thoughts.

As already mentioned, the document only lists PM as the application that needs source labels. Based on that, this draft adds a Source Label Indicator and a Source Label, without really analyzing the use cases and requirements for PM. IOW, this draft provides one solution but it is not clear if that is solving the right problem in the context of PM. For example, what happens when PHP? What happens if a finer granularity than the source node is needed?

Basically, two or three labels are added to the label stack, and some serious forwarding (and HW) requirements. It also lists some constraining control plane requirements (e.g., extending LDP signaling on a per-FEC basis!, extending BGP, and extending IGPs). It also requires per-domain unique identifiers. Given this dramatic set of extensions and strong requirements, it seems prudent to me to better understand the problem space of PM gaps before adopting a solution.

The document also seems to contradict itself in parts. First it says that a "Source Identifier (SI) identifies the ingress Label Switching Router (LSR) of a Label Switched Path (LSP)", but then the definition breaks with text like "Each node in a domain MUST be allocated one or more unique SIs" and "For most of the use cases, one SI per LSR would be sufficient.  But for some cases, there may be need for more than one SIs."

Many of the RFC 2119 requirements also seem to be self-contradicting -- for example, "An ingress LSR MUST make sure that the egress LSR is able to process the {SLI;SL} pair (or trio!)", and "an egress LSR SHOULD signal its capability to process SL". 

I had mentioned to the authors privately (and on list as well if I remember correctly) in rev -00 that the unique label requirement coupled with distribution of those assignments and the addition of 2-3 labels all seemed far from insignificant changes, making the need to understand the scope of the problem more important. It seemed to me as this is "what other {indicator; label} can we invent similar to {ELI; EL}" draft.

I have not seen the discussion of the problem space on the list, other than "needed for PM".

I hope these comments are useful.

Thanks,

Carlos.

---

From: "S. Davari" <[email-masked]>
Date: Fri, 17 Oct 2014 14:39:59 -0700

Many things can be added, for example is ECMP support required? What is the required granularity of the required PM? Is EVPN support required? Why can't other methods such as ILM be used? Etc.

Engineers shouldn't just focus on the first obvious solution that come to mind no matter what is the cost.

Regards,
Shahram

> On Oct 17, 2014, at 2:09 PM, John E Drake <[email-masked]> wrote:
> 
> George,
> 
>> From the draft:
>

---

From: Eric Rosen <[email-masked]>
Date: Fri, 17 Oct 2014 18:19:55 -0400

Carlos> Basically, two or three labels are added to the label stack,

Actually, that's two or three labels per LSP.  A packet may be going through a nested set of LSPs, which each label in the stack representing one of those LSPs.  Each LSP may have its own source label.  Since a source label is likely to require three label stack entries, the number of labels in the stack could be quadrupled.  And for what?

Carlos> the document only lists PM as the application that needs source labels.

There doesn't seem to be general agreement that this is a compelling use case.  Certainly not compelling enough to justify the complexity and the overhead that it brings.

Carlos> What happens if a finer granularity than the source node is needed?

This is inevitable.  How long before folks are complaining "we can't run our network unless the egress LSR can determine the ingress interface for each packet".  This could lead to thousands of source label values for each ingress LSR.  And what will happen when someone decides that the granularity needs to be per-subscriber, not merely per-interface?

And it's not just "finer granularity" we have to worry about.  What if someone decides that an ingress LSR needs to convey an arbitrary amount of "meta-data" about an LSP to the egress LSR.  Will the label stack become a set of labels alternating with meta-data containers?

Do we really want to put stuff that doesn't affect the packet forwarding into the label stack?  Where will we draw the line?

I don't think the authors really intend the mechanism to be generalized in this manner.  They're probably thinking "But we only intend for this to be deployed in a very simple case, where packets are being tunneled, where the ingress LSR knows who the egress LSR is, where they're in the same administrative domain, etc. etc.  You're really exaggerating the negatives."  But the proposed mechanisms do lend themselves to abuse or this sort.  Once we start putting stuff in the label stack that isn't used for forwarding, how will we know when to stop?

Carlos> Given this dramatic set of extensions and strong requirements, it seems prudent to me to better understand the problem space of PM gaps before adopting a solution.

I agree.  I think Stewart has made a good case that further analysis is needed.  The problem isn't that there is no use for source labels, the problem is that the mechanism seems to bring a lot of problems with it.  Is this really the only solution?  And if so, is it so important to be able to do PM that we should be willing to take on all these problems?

I also think the proposed LDP and BGP extensions are problematic, but those issues are really of secondary importance right now.

So I don't support the adoption of this draft.

---

From: John E Drake <[email-masked]>
Date: Sat, 18 Oct 2014 16:36:15 +0000

Hi,

In case any missed them, the operative phrases in my email, below, regarding the disposition of draft-chen-mpls-source-label are:

1)   "This isn't right. This isn't even wrong." -- Wolfgang Pauli

2)   Is it possible to euthanize an I-D?

I.e., this draft is not even ill-considered and I oppose its adoption as a WG draft.

Yours Irrespectively,

John

> From: John E Drake
> Sent: Friday, October 17, 2014 2:10 PM
> To: 'George Swallow (swallow)'; Shahram Davari; Gregory Mirsky; Mach Chen
> "For some applications, source identification is a critical requirement.  For
> example, performance monitoring, the monitoring nodes need to identify
> where packets were sent from and then can count the packets according to
> some constraints."
> 
> What do you think could possibly be added to make this list of requirements
> either more clear or more complete 8->?  It should also be blindingly obvious to
> the informed participant that to address this very complete set of
> requirements the use of global source labels is the solution that immediately
> springs to mind even thought it is completely at odds w/ the MPLS
> architecture.   "This isn't right. This isn't even wrong." -- Wolfgang Pauli
> 
> > draft-chen-mpls- [email-masked]
> > We need a clear set of requirements!  This is a huge change to MPLS.
> > We certainly do not want to do it to meet a narrow set of
> > requirements.  We need to clearly articulate what we need in the way of
> loss/delay measurement.
> > Then we need to explore possible solutions.  If a solution can be
> > found that does not have a major hardware impact, then we should adopt
> that.
> >
> > George
> >
> > >> From "performance monitoring" perspective, the proposed only
> > >>provides a  solution to limited [1] LSP types (and UHP/PHP of them)
> > >>and [2] granularity of  measurements.
> > >
> > >Mach: The solution is intended to solve an existing real problem. We
> > >do not expect the solution that could apply to any scenario and solve
> > >SD> First of all Mach says this is an existing real problem.
> > >SD> Therefore I
> > >would conclude  he is not solving the EVPN LM. Secondly he says this
> > >is not a generalized solution for future (aka EVPN).  So just use the
> > >LSP+PW counting and it will solve your problem quickly and without
> > >LSP+any
> > >draft-salam-l2vpn-evpn-oam-req-frmwk is expired., besides it is just
> > >a framework and not requirements. I believe the EVPN OAM has much
> > >more requirements than just adding a Source label.  You have to
> > >consider the Load balancing at multiple points, aliasing, Multi-homing, etc.
> > >
> > >This requires much more discussion and a thorough requirements
> > >analysis before coming to a quick rush solution such a source-label.
> > >
> > >
> > >Thanks
> > >Shahram
> > >
> > >We will solve the  EVPN LM when the time comes. (LSP+PW) label
> > >counting can be done today without any HW change.
> > >
> > >Thanks
> > >Shahram
> > >
> > >solutions or look for more generic mechanism? I do believe that
> > >SLI/SL, though may cause some pain, is useful and generic solution to
> > >the real problem.
> > >
> > >	Regards,
> > >		Greg
> > >
> > >And what if your payload is neither IP, nor Ethernet, just of
> > >academic argument sake?
> > >information. I think that what you're suggesting is not the right
> > >way, even if customers are buying it for the time being.
> > >
> > >	Regards,
> > >		Greg
> > >
> > >wants to get to school faster. While a better solution is just give
> > >him a motorcycle or car instead of inventing something new.
> > >
> > >>> Similarly in this case, if a service provider wants to use MPL S
> > >>> and do Direct Loss Measurement (DLM), then they must use P2P
> > >>> RSVP-TE LSPs, otherwise they can use MP2MP LDP LSPs.
> > >>
> > >> If I was a service provider, I will not buy this logic. It just
> > >> like someone's son is not good at math, then you suggest him to
> > >> replace the son with someone else who is good at math :-)
> > >>
> > >>
> > >> Best regards,
> > >> Mach
> > >>
> > >>> Similarly in this case, if a service provider wants to use MPL S
> > >>> and do Direct Loss Measurement (DLM), then they must use P2P
> > >>> RSVP-TE LSPs, otherwise they can use MP2MP LDP LSPs.
> > >>>
> > >>> Thanks
> > >>> Shahram
> > >>>
> > >>> This draft adds multiple labels to the label stack (makes the
> > >>> label stack much larger than it already is) and requires a respin
> > >>> of chips due to its special label handling in the data-plane.
> > >>>
> > >>>solution only proposes to identify the source LSR, whereas it seems
> > >>>likely that a finer granularity of flow identification will be
> > >>>(performance

---

From: Mach Chen <[email-masked]>
Date: Mon, 20 Oct 2014 10:04:17 +0000

Hi Eric , Carlos, Stewart and others,

Thanks for the discussion! Sorry for the top post.

I do think that you're really exaggerating the complexity and negatives. Given an LSR can support EL, Segment Routing, MVPN, context label, etc, IMHO it's not difficult for such kind of routers to support SL.

I looked though the whole discussions so far, and I am not going to reply each email one by email, I summarized the topics as follows:

1) Requirement 
Whether the requirement is compelling depends on whether you need it. We did receive the requirements from SPs to support passive PM for MP2P based LSPs, especially for the case of MPLS based IP backhaul network. So for those SPs, it's a compelling requirement. Indeed, PM is not an easy work, and in IETF, several dedicated WGs work on PM related stuff, some WGs have worked on it over decade.

This draft is mainly about how to do source identification that is one of the critical requirements of the passive PM, it is not intended to cover all aspects of PM. This is clearly stated in the document. Other aspects, for example, the multiple line cards in the egress as Stewart pointed out, I do really think that is an implementation issue. For that case, you do need a centralized component to sum up and analyze the statistics and their correlations.

2) Label stack depth
Regarding the label stack depth, there were some related discussions (including this WG and other WGs) , some vendors have showed that is not a big problem, especially for those new generation modern routers/switches.

3) Granularity
It depends on how you use it. In theory, the solution can support any number flows. But there always be some tradeoff, as I replied in a precious email, the SI number itself is not the issue, the HW resource (e.g., the timers) is the critical constraint. That means, you cannot expect a router to support unlimited flows. For SI number, I guess that the main concern is mainly about the state maintenance and advertisement, actually it could be optimized to maintain and advertize a single SI block for each LSR. This way, the state and advertisement is a fixed number corresponding to the number of the LSR in the domain. 

Best regards,
Mach

> From: mpls [mailto:[email-masked]] On Behalf Of Eric Rosen
> Sent: Saturday, October 18, 2014 6:20 AM
> To: Carlos Pignataro (cpignata); Ross Callon
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Actually, that's two or three labels per LSP.  A packet may be going through a
> nested set of LSPs, which each label in the stack representing one of those LSPs.
> Each LSP may have its own source label.  Since a source label is likely to require
> three label stack entries, the number of labels in the stack could be quadrupled.
> And for what?
> 
> There doesn't seem to be general agreement that this is a compelling use case.
> Certainly not compelling enough to justify the complexity and the overhead that
> it brings.
> 
> This is inevitable.  How long before folks are complaining "we can't run our
> network unless the egress LSR can determine the ingress interface for each
> packet".  This could lead to thousands of source label values for each ingress LSR.
> And what will happen when someone decides that the granularity needs to be
> per-subscriber, not merely per-interface?
> 
> And it's not just "finer granularity" we have to worry about.  What if someone
> decides that an ingress LSR needs to convey an arbitrary amount of "meta-data"
> about an LSP to the egress LSR.  Will the label stack become a set of labels
> alternating with meta-data containers?
> 
> Do we really want to put stuff that doesn't affect the packet forwarding into the
> label stack?  Where will we draw the line?
> 
> I don't think the authors really intend the mechanism to be generalized in this
> manner.  They're probably thinking "But we only intend for this to be deployed
> in a very simple case, where packets are being tunneled, where the ingress LSR
> knows who the egress LSR is, where they're in the same administrative domain,
> etc. etc.  You're really exaggerating the negatives."  But the proposed
> mechanisms do lend themselves to abuse or this sort.  Once we start putting
> stuff in the label stack that isn't used for forwarding, how will we know when to
> stop?
> 
> Carlos> Given this dramatic set of extensions and strong requirements, it seems
> prudent to me to better understand the problem space of PM gaps before
> adopting a solution.
> 
> I agree.  I think Stewart has made a good case that further analysis is needed.
> The problem isn't that there is no use for source labels, the problem is that the
> mechanism seems to bring a lot of problems with it.  Is this really the only
> solution?  And if so, is it so important to be able to do PM that we should be
> willing to take on all these problems?
> 
> I also think the proposed LDP and BGP extensions are problematic, but those
> issues are really of secondary importance right now.
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 20 Oct 2014 12:10:28 +0100

Mach

> I do think that you're really exaggerating the complexity and negatives. Given an LSR can support EL, Segment Routing, MVPN, context label, etc, IMHO it's not difficult for such kind of routers to…
Those solutions are not the same.

ELs - have no impact on the receiver. I admit that they have an impact 
on the transmitter (but only two labels) but the only flow state is that 
an EL needs to be generated, you do not need additional transmitter 
context since this is generated from the packet itself.

SR - has no impact at ay node other than the transmitter, and in many 
cases the impact is one or two labels. It does not change the dataplane..

Context labels - I am not sure how wide the support  for the general 
context label use case is.

What you are proposing is  a far more fundamental change to the 
dataplane than any of the above.

> Whether the requirement is compelling depends on whether you need it. We did receive the requirements from SPs to support passive PM for MP2P based LSPs, especially for the case of MPLS based IP ba…
I am not disputing the requirement for a method of measuring loss of 
customer traffic.

However the requirement for domain wide source labels is not 
established. It is one method of identifying the source in a PM 
measurement, but it is not the only method.
>
> This draft is mainly about how to do source identification that is one of the critical requirements of the passive PM,
It is about one method. The method you propose is not the only method.

Also you have jumped directly to a S-D identification approach, without 
justifying this as being the required unit of identification.
> it is not intended to cover all aspects of PM. This is clearly stated in the document. Other aspects, for example, the multiple line cards in the egress as Stewart pointed out, I do really think that is an implementation issue. For that case, you do need a centralized component to sum up and analyze the statistics and their correlations.
It is not that simple as you know from your other draft, and it does not 
make sense to me to address the two requirements as ships in the night 
solutions. Given that you receive a packet on one line card, you have no 
idea whether a packet received on another line card (or even line 
interface on that card) was transmitted before of after the one you are 
taking as your accounting  reference point.
> Regarding the label stack depth, there were some related discussions (including this WG and other WGs) , some vendors have showed that is not a big problem, especially for those new generation mode…
That is an assumption that you need to justify, particular at the 
network edge.
> It depends on how you use it. In theory, the solution can support any number flows. But there always be some tradeoff, as I replied in a precious email, the SI number itself is not the issue, the H…

The timers can be in s/w in the supervisor, since the time that a 
measurement is taken is not critical, so whilst there might be a filter 
and counter issue in the h/w, though no worse than IPFIX, there is not 
h/w issue with timers.

Stewart

---

From: Eric Rosen <[email-masked]>
Date: Mon, 20 Oct 2014 10:50:56 -0400

Mach> Given an LSR can support EL, Segment Routing, MVPN, context label, 
etc, IMHO it's not difficult for such kind of routers to support SL.

I don't see the argument here. In all these applications of MPLS, the 
label lookup produces information that is used for determining how to 
dispatch the packet, i.e., how to choose the adjacency to which it must 
be forwarded, or how to determine the context for further processing. 
The SL is very different, as it carries data about the packet that is 
not used for determining how to dispatch the packet.

The use of the label stack to carry arbitrary information about the 
packet, for use by monitoring applications, is quite different. That's 
why folks keep pointing out that it's a change to the MPLS architecture.

Mach> Regarding the label stack depth, there were some related 
discussions (including this WG and other WGs) , some vendors have showed 
that is not a big problem, especially for those new generation modern 
routers/switches.

I wasn't complaining about the cost of adding a few more labels, but 
about the potential explosion in the label stack size if a packet has to 
travel through a set of nested LSPs, and each LSP augments the stack 
with information needed to monitor that LSP. Perhaps the previous 
discussions did not take this possibility into account.  I think the 
case of nested LSPs certainly has to be taken into account.

Mach> We did receive the requirements from SPs to support passive PM for 
MP2P based LSPs, especially for the case of MPLS based IP backhaul 
network. So for those SPs, it's a compelling requirement.

I think that's a non-sequitur.  I'm sure some SPs want to do PM, but 
perhaps not at any cost.

Mach> 3) Granularity -- It depends on how you use it

How do we know that the supported granularity meets the requirements without running into scaling problems?

Mach> This draft is mainly about how to do source identification that is one of the critical requirements of the passive PM, it is not intended to cover all aspects of PM.

Then it certainly doesn't seem wise to adopt this draft in isolation.

---

From: Mach Chen <[email-masked]>
Date: Tue, 21 Oct 2014 07:19:04 +0000

Hi Stewart,

> Sent: Monday, October 20, 2014 7:10 PM
> To: Mach Chen; Eric Rosen; Carlos Pignataro (cpignata); Ross Callon
> > I do think that you're really exaggerating the complexity and negatives. Given
> an LSR can support EL, Segment Routing, MVPN, context label, etc, IMHO it's not
> difficult for such kind of routers to support SL.
> ELs - have no impact on the receiver. I admit that they have an impact on the
> transmitter (but only two labels) but the only flow state is that an EL needs to be
> generated, you do not need additional transmitter context since this is generated
> from the packet itself.
> 
> SR - has no impact at ay node other than the transmitter, and in many cases the
> impact is one or two labels. It does not change the dataplane..
> 
> Context labels - I am not sure how wide the support  for the general context
> label use case is.
> 
> What you are proposing is  a far more fundamental change to the dataplane
> than any of the above.

I may have different view on this, let me make a little bit comparison between SL and EL:

1) For ingress LSR, it's almost the same, except that EL requires the ingress LSR to generate the Entropy, then both just put information into the label stack; 

2) For transit LSR, EL requires the LSR to know how to handle the ELI and EL, otherwise cannot benefit from the EL; SL does not bring any requirement to transit LSR;

3) For egress LSR, it's almost the same, pop the EL/SL; of cause, when do SL based PM, the egress LSR has to use the SL for accounting, but such accounting is basic and necessary work for PM;

Based above, from the dataplane point of view, the processing and complexity is as the same level of EL, and it DOES NOT bring "fundamental" change to the dataplane;

> 
> >
> > I looked though the whole discussions so far, and I am not going to reply each
> email one by email, I summarized the topics as follows:
> >
> > 1) Requirement
> > Whether the requirement is compelling depends on whether you need it. We
> did receive the requirements from SPs to support passive PM for MP2P based
> LSPs, especially for the case of MPLS based IP backhaul network. So for those SPs,
> it's a compelling requirement. Indeed, PM is not an easy work, and in IETF,
> several dedicated WGs work on PM related stuff, some WGs have worked on it
> over decade.
> I am not disputing the requirement for a method of measuring loss of customer
> traffic.
> 
> However the requirement for domain wide source labels is not established. It is
> one method of identifying the source in a PM measurement, but it is not the only
> method.

Actually, the latest version DOES NOT require domain wide source labels, the source label is just a carrier that is used to carry the domain wide unique Source Identifier (SI); the SI is transparent to the SL, from the convey information point of view, it's the same as EL. 

> >
> > This draft is mainly about how to do source identification that is one
> > of the critical requirements of the passive PM,
> Also you have jumped directly to a S-D identification approach, without justifying
> this as being the required unit of identification.

Other than S-D identification, I am not sure that there are other ways that could be used to perform passive PM. I noticed you mention destination based approach in another email, can you please elaborate how it works?

> > it is not intended to cover all aspects of PM. This is clearly stated in the
> document. Other aspects, for example, the multiple line cards in the egress as
> Stewart pointed out, I do really think that is an implementation issue. For that
> case, you do need a centralized component to sum up and analyze the statistics
> and their correlations.
> It is not that simple as you know from your other draft, and it does not make
> sense to me to address the two requirements as ships in the night solutions.
> Given that you receive a packet on one line card, you have no idea whether a
> packet received on another line card (or even line interface on that card) was
> transmitted before of after the one you are taking as your accounting
> reference point.

We have a prototype doing IP based passive PM and do consider such scenario and it works. In this case, you do need a centralized component (which could reside in a linecard, the main control card or an external entity (e.g., NMS)) that can collect all statistic information of the tested flow. 

> > 2) Label stack depth
> > Regarding the label stack depth, there were some related discussions (including
> this WG and other WGs) , some vendors have showed that is not a big problem,
> especially for those new generation modern routers/switches.
> That is an assumption that you need to justify, particular at the network edge.

We will see such devices come out, especially when Segment Routing progressing.

> >
> > 3) Granularity
> > It depends on how you use it. In theory, the solution can support any number
> flows. But there always be some tradeoff, as I replied in a precious email, the SI
> number itself is not the issue, the HW resource (e.g., the timers) is the critical
> constraint. That means, you cannot expect a router to support unlimited flows.
> For SI number, I guess that the main concern is mainly about the state
> maintenance and advertisement, actually it could be optimized to maintain and
> advertize a single SI block for each LSR. This way, the state and advertisement is a
> fixed number corresponding to the number of the LSR in the domain.
> 
> The timers can be in s/w in the supervisor, since the time that a measurement is
> taken is not critical, so whilst there might be a filter and counter issue in the h/w,
> though no worse than IPFIX, there is not h/w issue with timers.

It depends on how you implement the measurement, timer for measurement is important, it sometime determines the accurate of the measurement. And I also agree that filter and counter are the other critical issues. And all these belong to the HW resource. So, I am trying to say, when consider these HW constraints, the SI state should be not a bit deal. Because you cannot monitor unlimited flows on a device.

Best regards,
Mach

> >> Actually, that's two or three labels per LSP.  A packet may be going
> >> through a nested set of LSPs, which each label in the stack representing one
> of those LSPs.
> >> Each LSP may have its own source label.  Since a source label is
> >> likely to require three label stack entries, the number of labels in the stack
> could be quadrupled.
> >> And for what?
> >>
> >> Certainly not compelling enough to justify the complexity and the
> >> overhead that it brings.
> >>
> >> This is inevitable.  How long before folks are complaining "we can't
> >> run our network unless the egress LSR can determine the ingress
> >> interface for each packet".  This could lead to thousands of source label
> values for each ingress LSR.
> >> And what will happen when someone decides that the granularity needs
> >> to be per-subscriber, not merely per-interface?
> >>
> >> And it's not just "finer granularity" we have to worry about.  What
> >> if someone decides that an ingress LSR needs to convey an arbitrary amount
> of "meta-data"
> >> about an LSP to the egress LSR.  Will the label stack become a set of
> >> labels alternating with meta-data containers?
> >>
> >> Do we really want to put stuff that doesn't affect the packet
> >> forwarding into the label stack?  Where will we draw the line?
> >>
> >> I don't think the authors really intend the mechanism to be
> >> generalized in this manner.  They're probably thinking "But we only
> >> intend for this to be deployed in a very simple case, where packets
> >> are being tunneled, where the ingress LSR knows who the egress LSR
> >> is, where they're in the same administrative domain, etc. etc.
> >> You're really exaggerating the negatives."  But the proposed
> >> mechanisms do lend themselves to abuse or this sort.  Once we start
> >> putting stuff in the label stack that isn't used for forwarding, how will we know
> when to stop?
> >>
> >> Carlos> Given this dramatic set of extensions and strong
> >> Carlos> requirements, it seems
> >> prudent to me to better understand the problem space of PM gaps
> >> before adopting a solution.
> >>
> >> The problem isn't that there is no use for source labels, the problem
> >> is that the mechanism seems to bring a lot of problems with it.  Is
> >> this really the only solution?  And if so, is it so important to be
> >> able to do PM that we should be willing to take on all these problems?
> >>
> >> I also think the proposed LDP and BGP extensions are problematic, but
> >> those issues are really of secondary importance right now.
> >>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 21 Oct 2014 09:10:51 +0000

Hi Mach,

Please find one set of comments inline. 

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

> On Oct 21, 2014, at 3:19 AM, Mach Chen <[email-masked]> wrote:
> 
> Hi Stewart,
> 

The EL is used for forwarding/dispatch decisions. The SL is metadata, not used for forwarding. The fundamental change to the dataplane is using it to carry metadata. 

> 3) For egress LSR, it's almost the same, pop the EL/SL; of cause, when do SL based PM, the egress LSR has to use the SL for accounting, but such accounting is basic and necessary work for PM;

Extrapolating from your argument, we could add a number of labels to the stack that do not carry forwarding instructions without any concerns. SL, what's next?

> Based above, from the dataplane point of view, the processing and complexity is as the same level of EL, and it DOES NOT bring "fundamental" change to the dataplane;

The change, in my view, is in the semantics of the label. 

Given how fundamental this is (in my mind) it calls for a more comprehensive understanding of the problem being solved. 

Thanks,

Carlos.

---

From: Mach Chen <[email-masked]>
Date: Tue, 21 Oct 2014 09:54:35 +0000

Hi Carlos,

Thanks for sharing your point!

> The EL is used for forwarding/dispatch decisions. The SL is metadata, not used for
> forwarding. The fundamental change to the dataplane is using it to carry
> metadata.

If the criteria is whether a label is used for forwarding, how about GAL?

Best regards,
Mach

> From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
> Sent: Tuesday, October 21, 2014 5:11 PM
> To: Mach Chen
> Cc: Stewart Bryant (stbryant); Eric Rosen; Ross Callon;
> [email-masked]; [email-masked];
> >> an LSR can support EL, Segment Routing, MVPN, context label, etc,
> >> IMHO it's not difficult for such kind of routers to support SL.
> >> ELs - have no impact on the receiver. I admit that they have an
> >> impact on the transmitter (but only two labels) but the only flow
> >> state is that an EL needs to be generated, you do not need additional
> >> transmitter context since this is generated from the packet itself.
> >>
> The EL is used for forwarding/dispatch decisions. The SL is metadata, not used for
> forwarding. The fundamental change to the dataplane is using it to carry
> metadata.
> 
> > 1) For ingress LSR, it's almost the same, except that EL requires the
> > ingress LSR to generate the Entropy, then both just put information
> > into the label stack;
> >
> > 2) For transit LSR, EL requires the LSR to know how to handle the ELI
> > and EL, otherwise cannot benefit from the EL; SL does not bring any
> > requirement to transit LSR;
> >
> > 3) For egress LSR, it's almost the same, pop the EL/SL; of cause, when
> > do SL based PM, the egress LSR has to use the SL for accounting, but
> > such accounting is basic and necessary work for PM;
> >
> 
> Extrapolating from your argument, we could add a number of labels to the stack
> that do not carry forwarding instructions without any concerns. SL, what's next?
> 
> > Based above, from the dataplane point of view, the processing and
> > complexity is as the same level of EL, and it DOES NOT bring
> > "fundamental" change to the dataplane;
> >
> 
> Given how fundamental this is (in my mind) it calls for a more comprehensive
> understanding of the problem being solved.
> 
> Thanks,
> 
> Carlos.
> 
> >>
> >>>
> >> did receive the requirements from SPs to support passive PM for MP2P
> >> based LSPs, especially for the case of MPLS based IP backhaul
> >> network. So for those SPs, it's a compelling requirement. Indeed, PM
> >> is not an easy work, and in IETF, several dedicated WGs work on PM
> >> related stuff, some WGs have worked on it over decade.
> > Actually, the latest version DOES NOT require domain wide source labels, the
> source label is just a carrier that is used to carry the domain wide unique Source
> Identifier (SI); the SI is transparent to the SL, from the convey information point
> of view, it's the same as EL.
> >
> >>>
> >>> This draft is mainly about how to do source identification that is
> >>> one of the critical requirements of the passive PM,
> >> Also you have jumped directly to a S-D identification approach,
> >> without justifying this as being the required unit of identification.
> >
> > Other than S-D identification, I am not sure that there are other ways that could
> be used to perform passive PM. I noticed you mention destination based
> approach in another email, can you please elaborate how it works?
> >
> >> document. Other aspects, for example, the multiple line cards in the
> >> egress as Stewart pointed out, I do really think that is an
> >> implementation issue. For that case, you do need a centralized
> >> component to sum up and analyze the statistics and their correlations.
> >> It is not that simple as you know from your other draft, and it does
> >> not make sense to me to address the two requirements as ships in the night
> solutions.
> >> Given that you receive a packet on one line card, you have no idea
> >> whether a packet received on another line card (or even line
> >> interface on that card) was transmitted before of after the one you
> >> are taking as your accounting reference point.
> >
> > We have a prototype doing IP based passive PM and do consider such scenario
> and it works. In this case, you do need a centralized component (which could
> reside in a linecard, the main control card or an external entity (e.g., NMS)) that
> can collect all statistic information of the tested flow.
> >
> >>> 2) Label stack depth
> >> this WG and other WGs) , some vendors have showed that is not a big
> >> problem, especially for those new generation modern routers/switches.
> >> flows. But there always be some tradeoff, as I replied in a precious
> >> email, the SI number itself is not the issue, the HW resource (e.g.,
> >> the timers) is the critical constraint. That means, you cannot expect a router to
> support unlimited flows.
> >> For SI number, I guess that the main concern is mainly about the
> >> state maintenance and advertisement, actually it could be optimized
> >> to maintain and advertize a single SI block for each LSR. This way,
> >> the state and advertisement is a fixed number corresponding to the number
> of the LSR in the domain.
> >>
> >> measurement is taken is not critical, so whilst there might be a
> >> filter and counter issue in the h/w, though no worse than IPFIX, there is not
> h/w issue with timers.
> >
> > It depends on how you implement the measurement, timer for measurement
> is important, it sometime determines the accurate of the measurement. And I
> also agree that filter and counter are the other critical issues. And all these belong
> to the HW resource. So, I am trying to say, when consider these HW constraints,
> the SI state should be not a bit deal. Because you cannot monitor unlimited flows
> on a device.
> >
> > Best regards,
> > Mach
> >
> >>
> >> Stewart
> >>>
> >>> Best regards,
> >>> Mach
> >>>
> >>>> Carlos> Basically, two or three labels are added to the label
> >>>> Carlos> stack,
> >>>>
> >>>> Actually, that's two or three labels per LSP.  A packet may be
> >>>> going through a nested set of LSPs, which each label in the stack
> >>>> representing one
> >> of those LSPs.
> >>>> Carlos> the document only lists PM as the application that needs
> >>>> Carlos> source
> >> labels.
> >>>>
> >>>> There doesn't seem to be general agreement that this is a
> >>>> compelling use
> >> case.
> >>>> This is inevitable.  How long before folks are complaining "we
> >>>> can't run our network unless the egress LSR can determine the
> >>>> ingress interface for each packet".  This could lead to thousands
> >>>> of source label
> >>>> And what will happen when someone decides that the granularity
> >>>> needs to be per-subscriber, not merely per-interface?
> >>>>
> >>>> about an LSP to the egress LSR.  Will the label stack become a set
> >>>> of labels alternating with meta-data containers?
> >>>>
> >>>> I agree.  I think Stewart has made a good case that further
> >>>> analysis is
> >> needed.
> >>>> The problem isn't that there is no use for source labels, the
> >>>> problem is that the mechanism seems to bring a lot of problems with
> >>>> it.  Is this really the only solution?  And if so, is it so
> >>>> important to be able to do PM that we should be willing to take on all these
> problems?
> >>>>
> >>>> I also think the proposed LDP and BGP extensions are problematic,
> >>>> but those issues are really of secondary importance right now.
> >>>>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 21 Oct 2014 12:21:03 +0100

GAL tells an LSR what to do with the pkt - it says please  dispatch to 
the OAM handler.

- Stewart

---

From: Mach Chen <[email-masked]>
Date: Wed, 22 Oct 2014 00:52:45 +0000

Hi Stewart,

OK, if this is the logic, then SL/SLI tells the LSR dispatch the packet to PM engine for accounting then keep processing.

Best regards,
Mach

> Sent: Tuesday, October 21, 2014 7:21 PM
> To: Mach Chen; Carlos Pignataro (cpignata)
> Cc: Eric Rosen; Ross Callon; [email-masked];
> [email-masked]; [email-masked]
> GAL tells an LSR what to do with the pkt - it says please  dispatch to the OAM
> handler.
> 
> - Stewart
> 
> >> The EL is used for forwarding/dispatch decisions. The SL is metadata,
> >> not used for forwarding. The fundamental change to the dataplane is
> >> using it to carry metadata.
> >>>> state is that an EL needs to be generated, you do not need
> >>>> additional transmitter context since this is generated from the packet itself.
> >>>>
> >>>> SR - has no impact at ay node other than the transmitter, and in
> >>>> many cases the impact is one or two labels. It does not change the
> dataplane..
> >>>>
> >>>> Context labels - I am not sure how wide the support  for the
> >>>> general context label use case is.
> >>>>
> >>> I may have different view on this, let me make a little bit
> >>> comparison between
> >> SL and EL:
> >> The EL is used for forwarding/dispatch decisions. The SL is metadata,
> >> not used for forwarding. The fundamental change to the dataplane is
> >> using it to carry metadata.
> >>
> >>> 1) For ingress LSR, it's almost the same, except that EL requires
> >>> the ingress LSR to generate the Entropy, then both just put
> >>> information into the label stack;
> >>>
> >>> 2) For transit LSR, EL requires the LSR to know how to handle the
> >>> ELI and EL, otherwise cannot benefit from the EL; SL does not bring
> >>> any requirement to transit LSR;
> >>>
> >>> 3) For egress LSR, it's almost the same, pop the EL/SL; of cause,
> >>> when do SL based PM, the egress LSR has to use the SL for
> >>> accounting, but such accounting is basic and necessary work for PM;
> >>>
> >> Extrapolating from your argument, we could add a number of labels to
> >> the stack that do not carry forwarding instructions without any concerns. SL,
> what's next?
> >>
> >> Given how fundamental this is (in my mind) it calls for a more
> >> comprehensive understanding of the problem being solved.
> >>
> >> Thanks,
> >>
> >> Carlos.
> >>
> >>>> did receive the requirements from SPs to support passive PM for
> >>>> network. So for those SPs, it's a compelling requirement. Indeed,
> >>>> PM is not an easy work, and in IETF, several dedicated WGs work on
> >>>> PM related stuff, some WGs have worked on it over decade.
> >>>> I am not disputing the requirement for a method of measuring loss
> >>>> of customer traffic.
> >>>>
> >> source label is just a carrier that is used to carry the domain wide
> >> unique Source Identifier (SI); the SI is transparent to the SL, from
> >> the convey information point of view, it's the same as EL.
> >> be used to perform passive PM. I noticed you mention destination
> >> based approach in another email, can you please elaborate how it works?
> >>>> document. Other aspects, for example, the multiple line cards in
> >>>> the egress as Stewart pointed out, I do really think that is an
> >>>> It is not that simple as you know from your other draft, and it
> >>>> does not make sense to me to address the two requirements as ships
> >>>> in the night
> >> solutions.
> >> and it works. In this case, you do need a centralized component
> >> (which could reside in a linecard, the main control card or an
> >> external entity (e.g., NMS)) that can collect all statistic information of the
> tested flow.
> >>>>> 2) Label stack depth
> >>>> flows. But there always be some tradeoff, as I replied in a
> >>>> precious email, the SI number itself is not the issue, the HW
> >>>> resource (e.g., the timers) is the critical constraint. That means,
> >>>> you cannot expect a router to
> >> support unlimited flows.
> >> is important, it sometime determines the accurate of the measurement.
> >> And I also agree that filter and counter are the other critical
> >> issues. And all these belong to the HW resource. So, I am trying to
> >> say, when consider these HW constraints, the SI state should be not a
> >> bit deal. Because you cannot monitor unlimited flows on a device.
> >>> Best regards,
> >>> Mach
> >>>
> >>>> Stewart
> >>>>> Best regards,
> >>>>> Mach
> >>>>>
> >>>>>> Carlos> What happens if a finer granularity than the source node
> >>>>>> Carlos> is
> >> needed?
> >>>>>> And it's not just "finer granularity" we have to worry about.
> >>>>>> What if someone decides that an ingress LSR needs to convey an
> >>>>>> arbitrary amount
> >>>> of "meta-data"
> >>>>>> about an LSP to the egress LSR.  Will the label stack become a
> >>>>>> set of labels alternating with meta-data containers?
> >>>>>>
> >>>>>> generalized in this manner.  They're probably thinking "But we
> >>>>>> only intend for this to be deployed in a very simple case, where
> >>>>>> packets are being tunneled, where the ingress LSR knows who the
> >>>>>> egress LSR is, where they're in the same administrative domain, etc. etc.
> >>>>>> mechanisms do lend themselves to abuse or this sort.  Once we
> >>>>>> start putting stuff in the label stack that isn't used for
> >>>>>> forwarding, how will we know
> >>>> when to stop?
> >>>>>> problem is that the mechanism seems to bring a lot of problems
> >>>>>> with it.  Is this really the only solution?  And if so, is it so

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 22 Oct 2014 02:38:46 +0000

Hi Carlos,

> The EL is used for forwarding/dispatch decisions. The SL is metadata, not used
> for forwarding. The fundamental change to the dataplane is using it to carry
> metadata.

In fact, one of other use cases of the SL is to make the MP2P LDP available for multicast VPN in the ingress replication mode (For more details, see 6.4.5. Ingress Replication of RFC6513). In this use case, the SL is now used for forwarding decisions. We could add this use case in the next revision.

Best regards,
Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 22 Oct 2014 06:42:48 +0000

> From: Xuxiaohu [mailto:[email-masked]]
> Sent: Wednesday, October 22, 2014 10:39 AM
> To: Carlos Pignataro (cpignata); Mach Chen
> Cc: [email-masked]; [email-masked]; Ross Callon;
> In fact, one of other use cases of the SL is to make the MP2P LDP available for
> multicast VPN in the ingress replication mode (For more details, see 6.4.5.
> Ingress Replication of RFC6513). In this use case, the SL is now used for
> forwarding decisions. We could add this use case in the next revision.

To better understand the need for identifying the ingress PE of the received multicast VPN packet by the egress PE in the ingress replication mode,  please refer to section 6.1. of draft-rosen-l3vpn-ir-01 (http://tools.ietf.org/html/draft-rosen-l3vpn-ir-01#section-6.1).

Best regards,
Xiaohu

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 22 Oct 2014 12:18:10 +0000

Hi, Mach,

The fundamental difference is that a GAL dispatches to packet to an OAM processing engine (i.e., what to do *with* the packet), whereas the SL tells a counter to increment itself while the packet continues its face (i.e., what to do *about* the packet, and not *with* the packet). My comment is that it's an expensive change without understanding the problem space. Is really SL/SLI the best solution for that (given the granularily, label stack, and other comments)?

Thanks,

Carlos.

> On Oct 21, 2014, at 8:52 PM, Mach Chen <[email-masked]> wrote:
> 
> Hi Stewart,
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 22 Oct 2014 12:19:29 +0000

Hi Mach,

I do not think it is healthy to cherry pick random orthogonal requirements to fit a proposed solution for something else. I believe the right argument is understanding the universe of the problem being solved first, and then find the best (i.e., minimal) solution for it.

Thanks,

Carlos.

> On Oct 21, 2014, at 10:38 PM, Xuxiaohu <[email-masked]> wrote:
> 
> Hi Carlos,
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 22 Oct 2014 12:21:52 +0000

[Apologies, I meant ³Hi, Xiaohu,², mis-addressed to Mach]

-----Original Message-----
From: Carlos Pignataro <[email-masked]>
Date: Wednesday, October 22, 2014 at 8:19 AM
To: Xiaohu Xu <[email-masked]>
Cc: "[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>, Ross Callon <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label

>Hi Mach,
>
>I do not think it is healthy to cherry pick random orthogonal
>requirements to fit a proposed solution for something else. I believe the
>right argument is understanding the universe of the problem being solved
>first, and then find the best (i.e., minimal) solution for it.
>
>Thanks,
>
>Carlos.
>
>>>not used
>> In fact, one of other use cases of the SL is to make the MP2P LDP
>>available for multicast VPN in the ingress replication mode (For more
>>details, see 6.4.5. Ingress Replication of RFC6513). In this use case,
>>the SL is now used for forwarding decisions. We could add this use case
>>in the next revision.
>> 
>> Best regards,
>> Xiaohu
>> 
>

---

From: Eric Rosen <[email-masked]>
Date: Wed, 22 Oct 2014 09:14:25 -0400

On 10/21/2014 8:52 PM, Mach Chen wrote:
Mach> OK, if this is the logic, then SL/SLI tells the LSR dispatch the 
packet
Mach> to PM engine for accounting then keep processing.

If you really want a label for this purpose, the egress can assign one 
dynamically (perhaps distributing it via IGP extensions), and there is 
no need to include a source identifier (or other meta-data) in the label 
stack.  This would then require only one label stack entry, not three.

It's also hard to believe that folks who are monitoring their traffic 
will want to ignore traffic that comes from ingress LSRs that don't 
support the source label.

Xiaohu> In fact, one of other use cases of the SL is to make the MP2P 
Xiaohu> LDP available for multicast VPN in the ingress replication mode

This seems incompatible with the idea that the purpose of the label is 
to mark the packet as needing PM.

Also, per draft-rosen-l3vpn-ir-01, there is no need for a source label 
when using MP2P LDP for MVPN IR, as the labels carried in the Leaf A-D 
routes are perfectly satisfactory for that purpose.  These labels allow 
you to tell when a packet comes from the expected ingress VRF (a fact 
needed for extranet), and they also allow you to determine the set of 
egress VRFs for a given packet.  This is just not a good application for 
source labels.

Carlos> I do not think it is healthy to cherry pick random orthogonal 
Carlos> requirements to fit a proposed solution for something else. I 
Carlos> believe the right argument is understanding the universe of the 
Carlos> problem being solved first, and then find the best (i.e., 
Carlos> minimal) solution for it.

I think Carlos has put it very well.

I'm sure that if we had a source label we could invent a variety of uses 
for it (not necessarily all compatible), but that is just not a good 
enough reason to have it.