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

On 17/10/2014 04:10, Mach Chen 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 :-)
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
>
> Best regards,
> Mach
>
>> -----Original Message-----
>> From: Shahram Davari [mailto:davari@broadcom.com]
>> Sent: Friday, October 17, 2014 2:38 AM
>> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org;
>> draft-chen-mpls-source-label@tools.ietf.org
>> Cc: mpls-chairs@tools.ietf.org
>> 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:mpls-bounces@ietf.org] On Behalf Of Shahram Davari
>> Sent: Thursday, October 16, 2014 11:26 AM
>> To: stbryant@cisco.com; Ross Callon; mpls@ietf.org;
>> draft-chen-mpls-source-label@tools.ietf.org
>> Cc: mpls-chairs@tools.ietf.org
>> 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:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant
>> Sent: Thursday, October 16, 2014 5:49 AM
>> To: Ross Callon; mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.org
>> Cc: mpls-chairs@tools.ietf.org
>> 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
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
> .
>

-- 
For corporate legal information go to:

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