Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

[Lou Berger <[e-mail]>]

On 8/20/2012 7:32 AM, [e-mail] wrote:
> On 8/17/2012 1:44 PM, Gregory Mirsky wrote:
> But I would question whether operators will use independent monitoring
> and protection on, what looks exactly like, bi-directional co-routed
> LSP. I think that c2) is not a separate case, but rather "an accident".
> If an operator wants to build c2) he/she needs to use procedures defined
> for b).
> 
> <fei>We need to heare opinions from the operators, and one of Rekesh's
> argument is listed below for reference:
> <RG1> It is fine to have non co-routed as default. RFC 3473 is a GMPLS
> signaling procedure. It may not be optimal  to have two different
> signaling procedures, one for non co-routed (ext associated object) and
> one for co-routed (RFC 3473) procedures. By adding a flag for co-routed,
> same signaling (ext associated object) can be used for both which is
> nice. We believe comparing of RRO can be misleading because two LSPs can
> be on the same path even though provisioned to be non co-routed.
>  
>     Regards,
>         Greg

Fei,
	I personally think we have plenty of input on requirements, at least in
the TP context, captured in rfc5654.

At this point, if someone wants to add a second control plane mechanism
for controlling co-routed bidirectional, I (as co-chair) think, they
need to make the case for it and get WG buy-in.  In other words, I
believe *current* working group consensus does *not* support introducing
a second co-route bidirectional LSP signaling mechanism.

I believe Rakesh said he'd read up on what's already supported and get
back to the WG (presumably if he thinks another mechanism is justified).
Of course, you and anyone else are free to make the case yourself.

Lou