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

Hi Nobo,

Thanks for your comments!

Please see my replies inline...

> -----Original Message-----
> From: Nobo Akiya (nobo) [mailto:nobo@cisco.com]
> Sent: Friday, October 17, 2014 8:34 AM
> To: Stewart Bryant (stbryant); 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
> 
> Kudos to the authors of draft-chen-mpls-source-label for coming up with an
> interesting solution.

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

> 
> I think it is a good idea to take a step back and discuss the problem scope.
> 
> Thanks!
> 
> -Nobo
> 
> > -----Original Message-----
> > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant
> > (stbryant)
> > Sent: Thursday, October 16, 2014 8: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