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

From: Gregory Mirsky <[email-masked]>
Date: Mon, 24 Feb 2014 23:16:34 +0000

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:[email-masked]] 
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 network 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" <[email-masked]>
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:[email-masked]] 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, "[email-masked]"
><[email-masked]> 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-lsp
>>-
>>fas
>>treroute-03.txt
>>Status:         
>>https://datatracker.ietf.org/doc/draft-tsaad-ccamp-rsvpte-bidir-lsp-fa
>>s
>>tre
>>route/
>>Htmlized:       
>>http://tools.ietf.org/html/draft-tsaad-ccamp-rsvpte-bidir-lsp-fastrero
>>u
>>te-
>>03
>>Diff:           
>>http://www.ietf.org/rfcdiff?url2=draft-tsaad-ccamp-rsvpte-bidir-lsp-fa
>>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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ccamp

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Mon, 24 Feb 2014 23:55:29 +0000

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" <[email-masked]>
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?
>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
>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
>
>
>
>

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 25 Feb 2014 00:05:08 +0000

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:[email-masked]] 
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; [email-masked]
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" <[email-masked]>
wrote:

>protection should be recommended as providing more generic coverage. 
>Have authors considered bringing discussion and presenting the proposal 
>to MPLS WG?
>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
>
>
>
>
>>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

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Tue, 25 Feb 2014 00:34:07 +0000

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" <[email-masked]>
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
>
>Mike Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia; [email-masked]
>Cc: CCAMP
>LSPs with other LSPs is indicated using the ASSOCIATION  object defined
>in [RFC4872]. "
>
>

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 25 Feb 2014 01:32:31 +0000

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:[email-masked]]
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; [email-masked]
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" <[email-masked]<mailto:[email-masked]>>
wrote:

>Mike Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia; [email-masked]<mailto:[email-masked]>
>Cc: CCAMP
>When [RFC4090] isn't being used, the association between segment
>recovery LSPs with other LSPs is indicated using the ASSOCIATION
>object defined in [RFC4872]. "
>
>
>On 2014-02-24 6:16 PM, "Gregory Mirsky" <[email-masked]<mailto:[email-masked]>>
>wrote:
>
>>Hi Rakesh,
>>Have authors considered bringing discussion and presenting the
>>proposal to MPLS WG?
>>As you know, proposed draft addresses the two issues (state timeout
>>and bypass assignment) where FRR [RFC4090] is used for GMPLS packet tunnels.
>>
>>On 2014-02-03 9:40 PM, "Gregory Mirsky" <[email-masked]<mailto:[email-masked]>>
>>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
>>>On 2014-02-03 8:44 AM, "[email-masked]<mailto:[email-masked]>"
>>><[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>>
>>>>A new version of I-D,
>>>>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:
>>>[email-masked]<mailto:[email-masked]>

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Tue, 25 Feb 2014 02:11:37 +0000

Thanks Greg.

From: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Monday, 24 February, 2014 8:32 PM
To: Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>, "Lizhong com>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Tarek Saad (tsaad)" <[email-masked]<mailto:[email-masked]>>, "=SMTP:mtaillon@cisco. com" <[email-masked]<mailto:[email-masked]>>, Zafar Ali <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: CCAMP <[email-masked]<mailto:[email-masked]>>
Subject: RE: New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt

Hi Rakesh,

        Regards,
                Greg

-----Original Message-----
From: Rakesh Gandhi (rgandhi) [mailto:[email-masked]]
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; [email-masked]<mailto:[email-masked]>
Cc: CCAMP
Subject: Re: New Version Notification for draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-03.txt

Hi Gert,

Thanks,
Rakesh