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

[Lou Berger <[e-mail]>]

Hi George,
	I had a little trouble understanding what additional functionality you
were identifying in your message, but after rereading it a few times, I
think I may understand what you are looking for. Unless I'm mistaken it
comes down to:
> want to have a means of signaling bidirectional TE LSPs,
> preserving the ability to have node and link FRR.

And this is independent from co-routed or not.

Is this correct?

Assuming it is, I think there are two related use cases:

1) When the bidirectional data paths are established using a GMPLS
bidirectional LSP, and

2) When the bidirectional data paths are established using the extension
defined in rsvpte-ext-associated-lsp-03 (note not -04)

In the case of (1), GMPLS birdirectional LSPs with FRR, I think you're
right. This would require additional specification. Clearly (as John
suggested) discussion on such mechanisms would need to at least start
based on an independent (new) draft. I personally don't think there's
any reason why someone couldn't author and submit such an independent draft.

In the case of (2), as you're not suggesting co-routed recovery, why
can't FRR just be used with procedures defined in
rsvpte-ext-associated-lsp-03 (note not -04)?  It's even possible to
specify the ERO and FRR related objects for the reverse/upstream LSP
using the REVERSE_LSP object. Are you just suggesting the need for an
informative "Recovery Considerations" section that covers interaction of
associated bidirectional LSPs with recovery/FRR?  Or something more?

Lou

On 8/21/2012 5:53 PM, George Swallow (swallow) wrote:
> All -
> 
> It is interesting that we have before us a draft which has both TP and TE
> in the name.  I believe that has much to do with the disagreements here.
> 
> I've spoken with operators who are interested in applying some but not all
> aspects of TP to TE.
> 
> The aspects that they want are bidirectionality and "better OAM" where the
> details of this may vary, but generally include BFD be it of the TP-in-GAL
> variety or just BFD bootstrapped (as normal) across a bidirectional
> forwarding adjacency.
> 
> One aspect of TE that many would like to preserve is FRR.  Both node and
> link.  That is they don't care if in a failure things are not strictly
> co-routed.  And some have uses for bidirectional adjacencies that aren't
> co-routed.
> 
> I also note in passing that some want no-php, but also see cases where php
> servers their needs and is more efficient on their deployed hardware.
> 
> Personally, I see no need to update RFC5654 as I'm happy to have all this
> fall under the ruberic of TE.
> 
> But I very much want to have a means of signaling bidirectional TE LSPs,
> preserving the ability to have node and link FRR.  I also think it would
> be wrong to call this TP.  Let TP stand as the narrowly drawn profile it
> is.  But the middle ground between TE and TP will get filled in.  And that
> can all be extensions to TE.
> 
> ...George
> 
> On 8/20/12 2:00 PM, "Lou Berger" <[e-mail]> wrote:
> 
>>
>>
>> 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
>>
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
> 
>