Re: [CCAMP] New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt

["Rakesh Gandhi (rgandhi)" <[e-mail]>]

Hi Gert,

Not sure why IETF would abondan widely deployed protocol [RFC4090] and
associated technology for bidirectional Packet LSPs. I like to hear
comments from the WGs.

Thanks,
Rakesh


On 2014-02-24 7:05 PM, "Gregory Mirsky" <[e-mail]>
wrote:

>Hi Rakesh,
>for the NNHOP bypass you'll not have truly local protection. One would
>either have to monitor segment between Upstream and Downstream PLRs or
>use some sort of PSC between the two. In any of these cases, Segment
>protection based on RFC 6378 offers the solution.
>
>	Regards,
>		Greg
>
>-----Original Message-----
>From: Rakesh Gandhi (rgandhi) [mailto:[e-mail]]
>Sent: Monday, February 24, 2014 3:55 PM
>To: Gregory Mirsky; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaad);
>Mike Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia; [e-mail]
>Cc: CCAMP
>Subject: Re: New Version Notification for
>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt
>
>Hi Greg,
>
>Two issues being addressed in this draft apply equally to the link
>protection case when using [RFC4090]:
>
>1. bypass assignment co-ordination and
>2. sending Resv (from upstream PLR) over reverse bypass to avoid state
>timeout.
>
>For NNHOP bypass, this just corrects the asymmetry of co-routed LSP
>forward and reverse paths.
>
>FYI, this draft was originally published to MPLS WG but then moved to
>CCAMP WG. Not sure which is the right WG for this work.
>
>BTW, [RFC4873] does not state that one can not use [RFC4090] with GMPLS
>signalling. Pleas see [RFC4873] Section 2:
>"
>When [RFC4090] isn't being used, the association between segment recovery
>LSPs with other LSPs is indicated using the ASSOCIATION  object defined
>in [RFC4872]. "
>
>
>This draft simply addresses the gaps when using [RFC4090] for GMPLS
>packet LSPs.
>
>Thanks,
>Rakesh
>
>
>
>On 2014-02-24 6:16 PM, "Gregory Mirsky" <[e-mail]>
>wrote:
>
>>Hi Rakesh,
>>I understand motivation of authors. Applicability of RFC 4090 to
>>bi-directional co-routed LSP was discussed as part of MPLS-TP
>>survivability framework (RFC 6372). I think that we've agreed that
>>applicability of RFC 4090 is limited to link protection and segment
>>protection should be recommended as providing more generic coverage.
>>Have authors considered bringing discussion and presenting the proposal
>>to MPLS WG?
>>Hope you wouldn't mind me adding MPLS WG to the discussion.
>>
>>	Regards,
>>		Greg
>>
>>-----Original Message-----
>>From: Rakesh Gandhi (rgandhi) [mailto:[e-mail]]
>>Sent: Monday, February 24, 2014 2:58 PM
>>To: Gregory Mirsky; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaad);
>>Mike Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia
>>Cc: CCAMP
>>Subject: Re: New Version Notification for
>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt
>>
>>Hi Greg,
>>
>>Thank you for your comments.
>>
>>As you know, proposed draft addresses the two issues (state timeout and
>>bypass assignment) where FRR [RFC4090] is used for GMPLS packet tunnels.
>>
>>Motivations for using FRR here is that it is widely deployed in the
>>packet MPLS-TE networks today and can leverage all existing FRR
>>detection and restoration mechanisms and not have to deploy new
>>protocol such as PSC [RFC6378] for protection switchover co-ordination.
>>
>>Thanks,
>>Rakesh
>>
>>
>>
>>
>>On 2014-02-03 9:40 PM, "Gregory Mirsky" <[e-mail]>
>>wrote:
>>
>>>Hi Rakesh, et. al,
>>>since bi-directional co-routed LSP is MPLS-TP construct I believe that
>>>if local node protection is indeed required it should not use RFC 4090
>>>signaling but use ASSOCIATION object as described in Section 2.3 RFC
>>>6689 and RFC 6378 MPLS-TP Linear Protection instead.
>>>
>>>	Regards,
>>>		Greg
>>>
>>>-----Original Message-----
>>>From: CCAMP [mailto:[e-mail]] On Behalf Of Rakesh Gandhi
>>>(rgandhi)
>>>Sent: Monday, February 03, 2014 5:52 AM
>>>To: Lizhong Jin; Lizhong Jin; Frederic Jounay; Tarek Saad (tsaad);
>>>Mike Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia; Zafar Ali
>>>(zali); Mike Taillon (mtaillon); Tarek Saad (tsaad); Frederic JOUNAY;
>>>Manav Bhatia
>>>Cc: CCAMP
>>>Subject: Re: [CCAMP] New Version Notification for
>>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt
>>>
>>>Hi WG,
>>>
>>>New revision of the published draft contains following updates:
>>>
>>>- Remove unidirectional bypass LSP (as per previous comments)
>>>- Fix syntax of the BYPASS_ASSIGNMENT object.
>>>- Misc editorial cleanup.
>>>
>>>
>>>Please provide your review comments.
>>>
>>>Thanks,
>>>Rakesh
>>>
>>> 
>>>
>>>On 2014-02-03 8:44 AM, "[e-mail]"
>>><[e-mail]> wrote:
>>>
>>>>
>>>>A new version of I-D,
>>>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt
>>>>has been successfully submitted by Rakesh Gandhi and posted to the
>>>>IETF repository.
>>>>
>>>>Name:		draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute
>>>>Revision:	03
>>>>Title:		Extensions to Resource Reservation Protocol For Fast Reroute of
>>>>Bidirectional Co-routed Traffic Engineering LSPs
>>>>Document date:	2014-02-03
>>>>Group:		Individual Submission
>>>>Pages:		12
>>>>URL:           
>>>>http://www.ietf.org/internet-drafts/draft-tsaad-ccamp-rsvpte-bidir-ls
>>>>p
>>>>-
>>>>fas
>>>>treroute-03.txt
>>>>Status:        
>>>>https://datatracker.ietf.org/doc/draft-tsaad-ccamp-rsvpte-bidir-lsp-f
>>>>a
>>>>s
>>>>tre
>>>>route/
>>>>Htmlized:      
>>>>http://tools.ietf.org/html/draft-tsaad-ccamp-rsvpte-bidir-lsp-fastrer
>>>>o
>>>>u
>>>>te-
>>>>03
>>>>Diff:          
>>>>http://www.ietf.org/rfcdiff?url2=draft-tsaad-ccamp-rsvpte-bidir-lsp-f
>>>>a
>>>>s
>>>>tre
>>>>route-03
>>>>
>>>>Abstract:
>>>>   This document defines Resource Reservation Protocol - Traffic
>>>>   Engineering (RSVP-TE) signaling extensions to support Fast Reroute
>>>>   (FRR) of bidirectional co-routed Traffic Engineering (TE) LSPs.
>>>>These
>>>>   extensions enable the re-direction of bidirectional traffic and
>>>>   signaling onto bypass tunnels that ensure co-routedness of data and
>>>>   signaling paths in the forward and reverse directions after FRR. In
>>>>   addition, the RSVP-TE signaling extensions allow the coordination of
>>>>   bypass tunnel assignment protecting a common facility in both
>>>>forward
>>>>   and reverse directions prior to or post failure occurrence.
>>>>
>>>>
>>>>               
>>>>        
>>>>
>>>>
>>>>Please note that it may take a couple of minutes from the time of
>>>>submission until the htmlized version and diff are available at
>>>>tools.ietf.org.
>>>>
>>>>The IETF Secretariat
>>>>
>>>
>>>_______________________________________________
>>>CCAMP mailing list
>>>[e-mail]
>>>https://www.ietf.org/mailman/listinfo/ccamp
>>
>