Subject: [CCAMP] question on rerouting with reversion

From: "Ong, Lyndon" <[email-masked]>
Date: Thu, 23 Feb 2012 11:13:24 -0500

Hi Folks,

We would like to be able to  support of a version of rerouting that has the following characteristics:

-          First the original LSP is established on demand.

-          Secondly failure of the original LSP causes an alternate LSP to be created without any prior reservation of backup resources, potentially sharing some resources

-          Finally, traffic reverts to the original LSP path once the failure is repaired.
We wanted to get the benefit of CCAMP's expertise and knowledge as to whether this combination of reversion and rerouting is supported in the existing recovery specifications or not.  We have taken a read through some of the specifications and haven't found an exact fit yet.

In our reading of RFC4872, section 11, full LSP rerouting (protection type 0x01) involves tearing down the original LSP, although it says make-before-break can be used to establish the alternate LSP before tearing down the original, so that some of the resources can be reused.

Rerouting without extra traffic (protection type 0x02) involves pre-establishment of the alternate LSP using a disjoint path, with no sharing of resources.

We also found that section 12 on reversion describes how reversion is supported for 1+1 bidirectional protection, 1:n protection with extra traffic, and rerouting without extra traffic, but has no description for reversion for the full LSP rerouting case.

Is there a procedure that would support the kind of rerouting with reversion above that we may have missed or does a procedure might need to be added to the specifications for this?  We are preparing a draft that would identify the functionality and requirements and it would help us to get your input on whether you think this is already supported or will need extensions to the specifications (or if you see potential problems supporting something like this).

Thanks for your help!

Best regards,

Lyndon Ong
Evelyne Roch

---

From: Lou Berger <[email-masked]>
Date: Thu, 23 Feb 2012 12:47:04 -0500

Hi Lyndon,

See below.

On 2/23/2012 11:13 AM, Ong, Lyndon wrote:
> -          Secondly failure of the original LSP causes an alternate LSP
> to be created without any prior reservation of backup resources,
> potentially sharing some resources
> 

I see nothing that precludes this in the current specs.  (I believe
someone mentioned to me that they support exactly this behavior.) As
described, this is largely handled at an application level above signaling.

> We wanted to get the benefit of CCAMP’s expertise and knowledge as to
> whether this combination of reversion and rerouting is supported in the
> existing recovery specifications or not.  We have taken a read through
> some of the specifications and haven’t found an exact fit yet.
> 
>  
> 
> In our reading of RFC4872, section 11, full LSP rerouting (protection
> type 0x01) involves tearing down the original LSP, although it says
> make-before-break can be used to establish the alternate LSP before
> tearing down the original, so that some of the resources can be reused. 
> 

As you note, the make-before-break is listed as an informative option.
Furthermore, the text does no include any required behavior on the
alternate LSP. I can't speak for the authors, but I can see why they
didn't include required behavior as there is no interoperability issues
with several of the different approaches.

That said, I think documenting the options, with or without a
recommended approach, could be valuable to some.

>  
> 
> Rerouting without extra traffic (protection type 0x02) involves
> pre-establishment of the alternate LSP using a disjoint path, with no
> sharing of resources.
> 
>  
> 
> We also found that section 12 on reversion describes how reversion is
> supported for 1+1 bidirectional protection, 1:n protection with extra
> traffic, and rerouting without extra traffic, but has no description for
> reversion for the full LSP rerouting case. 
> 

Again, I can't speak for the authors, but my guess is that they made a
choice to not put requirements on the LSP Rerouting case.

If we were to add such constraints, I suspect the change is little more
than (in Section 12):
	s/For "Rerouting/For "(Full) LSP Rerouting" and "Rerouting/

>  
> 
> Is there a procedure that would support the kind of rerouting with
> reversion above that we may have missed 

The only think you have missed is the perspective that most of the
(G)MPLS specs provide tools for a toolbox, and it is often up to the
implementer to choose how to implement a particular solution.

As I mentioned above, I believe that an implementation can use existing
specs to implement this solution.

> or does a procedure might need
> to be added to the specifications for this?  

This is a question of perspectives, if you just want everyone to
interoperate -- this can be supported today.  On the other hand, if your
objective is for all to implement this function in the same way, then
more specification is needed.  To me it seems the authors of 4872
desired the former while you want the latter.

> We are preparing a draft
> that would identify the functionality and requirements and it would help
> us to get your input on whether you think this is already supported or
> will need extensions to the specifications (or if you see potential
> problems supporting something like this).

Well it seems to me (as a WG participant) that there may be room for an
informative or, at most, a BCP document, but unless I'm missing
something, don't think there's any new protocol mechanisms to define.

Obviously, specific comments on your draft will need to wait for it to
be published.

Lou

---

From: Francesco Fondelli <[email-masked]>
Date: Thu, 23 Feb 2012 19:03:50 +0100

+1

Just a side note: I think the term "reversion" applies only to
protection (RFC 4427, section 4.11).  "Revertive-ness" in this
case can be signaled with draft-takacs-ccamp-revertive-ps-06.

In case of restoration is... hmmm "I wanna get back to the orig
path as soon as it is in good shape" :-).  Anyway, as Lou said, I
think is a (one of the possible) local policy.

hope this helps
ciao
FF

On Thu, Feb 23, 2012 at 6:47 PM, Lou Berger <[email-masked]> wrote:
>> We would like to be able to ?support of a version of rerouting that has
>> the following characteristics:
>>
>> - ? ? ? ? ?First the original LSP is established on demand.
>>
>> - ? ? ? ? ?Secondly failure of the original LSP causes an alternate LSP
>> - ? ? ? ? ?Finally, traffic reverts to the original LSP path once the
>> failure is repaired.
>>
>
> I see nothing that precludes this in the current specs. ?(I believe
>> We wanted to get the benefit of CCAMP?s expertise and knowledge as to
>> existing recovery specifications or not. ?We have taken a read through
>> some of the specifications and haven?t found an exact fit yet.
>>
>>
>>
> ? ? ? ?s/For "Rerouting/For "(Full) LSP Rerouting" and "Rerouting/
>
>>
>>
> interoperate -- this can be supported today. ?On the other hand, if your
> more specification is needed. ?To me it seems the authors of 4872
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 23 Feb 2012 18:36:56 +0000

Lou.

This someone was me. :=)  We call it dynamic restoration with reversion. When the second LSP is created,  it is done via make-without-break procedure. Once the failure is repaired the second LSP is removed.

Cheers,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Thursday, February 23, 2012 12:47 PM
To: Ong, Lyndon
Cc: CCAMP
Subject: Re: [CCAMP] question on rerouting with reversion

Hi Lyndon,

See below.

> -          Finally, traffic reverts to the original LSP path once the

I see nothing that precludes this in the current specs.  (I believe someone mentioned to me that they support exactly this behavior.) As described, this is largely handled at an application level above signaling.

> We wanted to get the benefit of CCAMP's expertise and knowledge as to 
> whether this combination of reversion and rerouting is supported in 
> the existing recovery specifications or not.  We have taken a read 
> through some of the specifications and haven't found an exact fit yet.
> 
>  
> 

As you note, the make-before-break is listed as an informative option.
Furthermore, the text does no include any required behavior on the alternate LSP. I can't speak for the authors, but I can see why they didn't include required behavior as there is no interoperability issues with several of the different approaches.

That said, I think documenting the options, with or without a recommended approach, could be valuable to some.

> traffic, and rerouting without extra traffic, but has no description 
> for reversion for the full LSP rerouting case.
> 

Again, I can't speak for the authors, but my guess is that they made a choice to not put requirements on the LSP Rerouting case.

If we were to add such constraints, I suspect the change is little more than (in Section 12):
	s/For "Rerouting/For "(Full) LSP Rerouting" and "Rerouting/

> reversion above that we may have missed

The only think you have missed is the perspective that most of the (G)MPLS specs provide tools for a toolbox, and it is often up to the implementer to choose how to implement a particular solution.

As I mentioned above, I believe that an implementation can use existing specs to implement this solution.

> to be added to the specifications for this?  

This is a question of perspectives, if you just want everyone to interoperate -- this can be supported today.  On the other hand, if your objective is for all to implement this function in the same way, then more specification is needed.  To me it seems the authors of 4872 desired the former while you want the latter.

> We are preparing a draft
> that would identify the functionality and requirements and it would 
> help us to get your input on whether you think this is already 
> supported or will need extensions to the specifications (or if you see 
> potential problems supporting something like this).

Well it seems to me (as a WG participant) that there may be room for an informative or, at most, a BCP document, but unless I'm missing something, don't think there's any new protocol mechanisms to define.

Obviously, specific comments on your draft will need to wait for it to be published.

Lou

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 23 Feb 2012 21:38:38 +0000

Hi Lyndon,
(Chair hat off/co-author hat on)

I don't think there was any intentional preclusion of reversion support for LSP rerouting. As described in RFC4428, reversion was considered a generic operation, one of the recovery phrases for use with any of the recovery mechanisms (depending on recovery domain policy). The same treatment was done for RFC4872, keeping it as a separate section. The sequence may not have been detailed in Section 12 (probably due to author interest), but there is nothing precluding use with LSP rerouting. And as described in Section 11 on LSP rerouting, there is no (RFC2119) requirement that the old LSP must be torn down.

If you want to use full LSP rerouting, you may want to look at RFC3209 on SE, as it describes in Section 2.5 rerouting with reversion as this is the reference for this recovery mechanism. So it is supported. Alternatively, the Resource Sharing Association Type defined in RFC4783 can be used (which can be viewed as running segment recovery where the segment end-points are aligned with LSP end-points).

And, if you want to do pre-plan for these options, it's not precluded (refer to RFC4872 section 11.1).

As Lou suggests, you could clarify by doing an errata. If need more clarification, an informational.

Regards,
Deborah

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Thursday, February 23, 2012 12:47 PM
To: Ong, Lyndon
Cc: CCAMP; BRUNGARD, DEBORAH A
Subject: Re: question on rerouting with reversion

Hi Lyndon,

See below.

> some of the specifications and haven't found an exact fit yet.
> 
>  
> 

Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 24 Feb 2012 10:48:35 +0100

So do we, but in a slightly different fashion. MBB plus keeping the nominal path rerources reserveed (this might allow for reuse of part of them from other LSPs with lower priority). In case the work Lyndon is proposing is progressed, both options might be reflected.

In reply to Francesco and Lou, i agree with you on the fact that it is a local policy, but local policies are not always manually configured, there are two cases that they are not:

1. SC (swtched connections). In this case the node asking the ingress for a connection should be able to ask for a "revertive" restoration or not (revertive term not properly used, but "i wanna get back to the orig path as soos as it is in good shape" was too long)

2. Segment recovery. In this case the policy is not local but remote. The ingress should be able to tell the LSR performing the segment recovery whether to go back to the nominal path or not (couldn't find anything on this in RFC4873).

BR
Daniele

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Igor Bryskin
>Sent: giovedì 23 febbraio 2012 19.37
>To: Lou Berger; Ong, Lyndon
>Cc: CCAMP
>This someone was me. :=)  We call it dynamic restoration with 
>reversion. When the second LSP is created,  it is done via 
>make-without-break procedure. Once the failure is repaired the 
>second LSP is removed.
>
>Cheers,
>Igor
>
>I see nothing that precludes this in the current specs.  (I 
>believe someone mentioned to me that they support exactly this 
>behavior.) As described, this is largely handled at an 
>application level above signaling.
>
>Furthermore, the text does no include any required behavior on 
>the alternate LSP. I can't speak for the authors, but I can 
>see why they didn't include required behavior as there is no 
>interoperability issues with several of the different approaches.
>
>Again, I can't speak for the authors, but my guess is that 
>they made a choice to not put requirements on the LSP Rerouting case.
>
>The only think you have missed is the perspective that most of 
>the (G)MPLS specs provide tools for a toolbox, and it is often 
>up to the implementer to choose how to implement a particular solution.
>
>As I mentioned above, I believe that an implementation can use 
>existing specs to implement this solution.
>
>This is a question of perspectives, if you just want everyone 
>to interoperate -- this can be supported today.  On the other 
>hand, if your objective is for all to implement this function 
>in the same way, then more specification is needed.  To me it 
>seems the authors of 4872 desired the former while you want the latter.
>
>> We are preparing a draft
>Well it seems to me (as a WG participant) that there may be 
>room for an informative or, at most, a BCP document, but 
>unless I'm missing something, don't think there's any new 
>protocol mechanisms to define.
>

---

From: Oscar González de Dios <[email-masked]>
Date: Fri, 24 Feb 2012 11:20:45 +0100

+1 to Daniele's approach.

We keep the nominal path resources reserved, as a way to guarantee the reversion. Otherwise, there is no such guarantee, any new incoming LSP may have used part of the resources of the original route.

Óscar

>-----Mensaje original-----
>De: [email-masked] [mailto:[email-masked]] En nombre de
>Daniele Ceccarelli
>Enviado el: viernes, 24 de febrero de 2012 10:49
>Para: Igor Bryskin; Lou Berger; Ong, Lyndon
>CC: CCAMP
>Asunto: Re: [CCAMP] question on rerouting with reversion
>
>So do we, but in a slightly different fashion. MBB plus keeping the nominal
>path rerources reserveed (this might allow for reuse of part of them from
>other LSPs with lower priority). In case the work Lyndon is proposing is
>progressed, both options might be reflected.
>
>In reply to Francesco and Lou, i agree with you on the fact that it is a local
>policy, but local policies are not always manually configured, there are two
>cases that they are not:
>
>1. SC (swtched connections). In this case the node asking the ingress for a
>connection should be able to ask for a "revertive" restoration or not (revertive
>term not properly used, but "i wanna get back to the orig path as soos as it is
>in good shape" was too long)
>
>2. Segment recovery. In this case the policy is not local but remote. The
>ingress should be able to tell the LSR performing the segment recovery
>whether to go back to the nominal path or not (couldn't find anything on this
>in RFC4873).
>
>BR
>Daniele
>
>
>
>>From: [email-masked] [mailto:[email-masked]] On Behalf
>>Of Igor Bryskin
>>make-without-break procedure. Once the failure is repaired the second
>>LSP is removed.
>>
>>Cheers,
>>Igor
>>
>>someone mentioned to me that they support exactly this
>>behavior.) As described, this is largely handled at an application
>>level above signaling.
>>
>>interoperate -- this can be supported today.  On the other hand, if
>>your objective is for all to implement this function in the same way,
>>then more specification is needed.  To me it seems the authors of 4872

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Fri, 24 Feb 2012 16:14:18 +0000

Hi Francesco,

Thanks for the input.

Section 4.11 is part of Section 4: "Recovery Terminology Common to Protection and Restoration". So 4.11, "revertive recovery operation" refers to both protection and restoration.

You gave a good reminder with Attila's draft (which has expired). Maybe it will be of more interest at this time (and it's similar to Attila's OAM configuration documents). Maybe a MIBs would be helpful for folks interested in configuration.

Ciao,
Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Francesco Fondelli
Sent: Thursday, February 23, 2012 1:04 PM
To: Lou Berger
Cc: CCAMP
Subject: Re: [CCAMP] question on rerouting with reversion

+1

hope this helps
ciao
FF

---

From: Francesco Fondelli <[email-masked]>
Date: Fri, 24 Feb 2012 18:48:41 +0100

> Hi Francesco,

Hi Deborah,

> Section 4.11 is part of Section 4: "Recovery Terminology Common to Protection and Restoration". So 4.11, "revertive recovery operation" refers to both protection and restoration.

I see, statements like "switching operation" and "switch-over requests"
make me think at protection rather than restoration.  Anyway, you are right.

> You gave a good reminder with Attila's draft (which has expired).
> Maybe it will be of more interest at this time (and it's similar
> to Attila's OAM

yep!  I agree.

>configuration documents). Maybe a MIBs would be helpful for folks interested in configuration.

> Deborah

thanks
Ciao
FF