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

[Gregory Mirsky <[e-mail]>]

Hi Rakesh,
I don't see this as "abandon" RFC 4090 but rather clarify its applicability for bi-directional co-routed LSP case.
More comments from both WGs certainly are most welcome and appreciated.

        Regards,
                Greg

-----Original Message-----
From: Rakesh Gandhi (rgandhi) [mailto:[e-mail]]
Sent: Monday, February 24, 2014 4:34 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 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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>"
>>><[e-mail]<mailto:[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-l
>>>>s
>>>>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-fastre
>>>>r
>>>>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]<mailto:[e-mail]>
>>>https://www.ietf.org/mailman/listinfo/ccamp
>>
>