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

[Shahram Davari <[e-mail]>]

Also why ILM is not acceptable?

Thx
SD

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

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:[e-mail]] 
Sent: Friday, October 17, 2014 11:26 AM
To: Shahram Davari; Mach Chen
Cc: Ross Callon; [e-mail]; [e-mail]; [e-mail]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

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:[e-mail]] 
Sent: Friday, October 17, 2014 11:23 AM
To: Gregory Mirsky; Mach Chen
Cc: Ross Callon; [e-mail]; [e-mail]; [e-mail]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

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:[e-mail]]
Sent: Friday, October 17, 2014 11:15 AM
To: Shahram Davari; Mach Chen
Cc: Ross Callon; [e-mail]; [e-mail]; [e-mail]
Subject: RE: [mpls] IPR poll for draft-chen-mpls-source-label

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:[e-mail]] On Behalf Of Shahram Davari
Sent: Friday, October 17, 2014 8:46 AM
To: Mach Chen
Cc: Ross Callon; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label

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


> On Oct 16, 2014, at 8:10 PM, "Mach Chen" <[e-mail]> wrote:
> 
> 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
> 
>> -----Original Message-----
>> From: Shahram Davari [mailto:[e-mail]]
>> Sent: Friday, October 17, 2014 2:38 AM
>> To: [e-mail]; Ross Callon; [e-mail]; 
>> [e-mail]
>> Cc: [e-mail]
>> 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
>> 
>> -----Original Message-----
>> From: mpls [mailto:[e-mail]] On Behalf Of Shahram Davari
>> Sent: Thursday, October 16, 2014 11:26 AM
>> To: [e-mail]; Ross Callon; [e-mail]; 
>> [e-mail]
>> Cc: [e-mail]
>> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label
>> 
>> 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:[e-mail]] On Behalf Of Stewart Bryant
>> Sent: Thursday, October 16, 2014 5:49 AM
>> To: Ross Callon; [e-mail];
>> [e-mail]
>> Cc: [e-mail]
>> 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.
>> 
>> 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
>> 
>> 
>> _______________________________________________
>> mpls mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls
>> 
>> _______________________________________________
>> mpls mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls