Re: [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03

Lou,

This sounds like a textbook definition of 'feature creep' and is a really bad idea.

Thanks,

John

Sent from my iPhone

> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of Lou Berger
> Sent: Wednesday, August 15, 2012 9:34 AM
> To: zhang.fei3@zte.com.cn
> Cc: CCAMP; jingrq@ctbri.com.cn; Robert Sawaya (rsawaya);
> yang.fan5@zte.com.cn
> Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-
> associated-lsp-03
> 
> Fei/Rakeash,
> 	Co-routed associated is already supported in 3473 using
> bidirectional LSPs. So, to signal co-routed all that needs to be done
> is use the existing procedures.  What issue is being addressed (i.e.,
> function being added) by adding the proposed co-routed related
> mechanisms?
> 
> Keep in mind, it's generally a *very* bad idea to define 2 mechanisms
> in the same protocol for the same function.
> 
> Lou
> 
> On 8/3/2012 5:16 AM, zhang.fei3@zte.com.cn wrote:
> > Snipped the other parts for easy reading, sorry for the delayed
> > response
> >
> > <RG3> There are applications that require co-routed LSPs. So I think
> > we should have a flag to indicate that LSPs must be co-routed, else
> > node will send a path error for example if request cannot be met.  I
> > agree with you about complexity with double sided provisioning model
> though.
> >
> > <fei> Since you believe that a common mechanism used for the
> > non-corouted and corouted cases is useful, we will add the texts in
> > the next version.
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp