Subject: Re: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt

From: Loa Andersson <[email-masked]>
Date: Wed, 09 Jul 2008 12:01:22 +0200

Attila,

a neat draft that does what it sets out to do. For the moment I've no
actual comments on the draft itself (might have when I'd time to think
about in detail), but more meta-question.

It is not a given that the revertive behavior always is beneficial. In
networks that are very dynamic it might be optional to revert, let the
traffic stay on the protecting path or replace them altogether.

Wouldn't it be interesting to discuss more in detail when a revertive
behavior is needed/wanted and when it is not.

/Loa

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : GMPLS RSVP-TE recovery extension for data plane initiated reversion
> 	Author(s)       : A. Takacs, B. Tremblay
> 	Filename        : draft-takacs-ccamp-revertive-ps-00.txt
> 	Pages           : 11
> 	Date            : 2008-07-06
> 
> RSVP-TE recovery extensions are specified in [RFC4872] and [RFC4873].
> Currently these extensions cannot signal request for revertive
> protection to the remote endpoint.  This document defines a new bit
> to signal this request and a new field to specify a wait-to-restore
> interval.Requirements Language
> 
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-takacs-ccamp-revertive-ps-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

---

From: "Attila Takacs" <[email-masked]>
Date: Wed, 9 Jul 2008 14:34:06 +0200

Hi Loa,

I assume a part of your comment/question relates to problems with
reversion if LSP setup and holding priorities are mismatched. In this
case the worker may be already deleted before the reversion would take
place. This is certainly an interesting question...

...at a first thought an explicit revertive bit may be used to override
the priorities for LSPs with revertive protection.

Best regards,
Attila

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]] 
> Sent: Wednesday, July 09, 2008 12:01 PM
> To: ccamp; Attila Takacs
> Subject: Re: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
> 
> Attila,
> 
> a neat draft that does what it sets out to do. For the moment 
> I've no actual comments on the draft itself (might have when 
> I'd time to think about in detail), but more meta-question.
> 
> It is not a given that the revertive behavior always is 
> beneficial. In networks that are very dynamic it might be 
> optional to revert, let the traffic stay on the protecting 
> path or replace them altogether.
> 
> Wouldn't it be interesting to discuss more in detail when a 
> revertive behavior is needed/wanted and when it is not.
> 
> /Loa
> 
> > protection to the remote endpoint.  This document defines a 
> new bit to 
> > signal this request and a new field to specify a wait-to-restore 
> > Internet-Draft directories: http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> --
> Loa Andersson
>

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Wed, 9 Jul 2008 14:54:47 +0200

attila,

once you are at it, can u explain the following "to properly setup the
remote data plane endpoints" ? what it actually means in the context:

"Such an example is protection switching of bidirectional
 connections in Ethernet PBB-TE [IEEE-PBBTE] (currently under
 standardisation in IEEE).  In this case revertiveness needs to be
 signalled by RSVP-TE during LSP establishment to properly setup the
 remote data plane endpoint."

also do u need a V bit, or isn't the WTR time with a reserved value not
sufficient e.g. 0x0 ? when for inst. the locally configured timer would
be used (no timer signaled).

the revertive operation is associated to LSP right ? why did you pull
this into the 16-bit space for Link specific operation (before link
flags ?)

thx,
-d.
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Attila Takacs
> Sent: Wednesday, July 09, 2008 2:34 PM
> To: Loa Andersson; ccamp
> Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
> 
> Hi Loa,
>

---

From: "Attila Takacs" <[email-masked]>
Date: Wed, 9 Jul 2008 16:11:54 +0200

Hi Dimitri,

Thanks for the comments!
Pease see inline.
Best regards,
Attila 

> From: PAPADIMITRIOU Dimitri 
> [mailto:[email-masked]] 
> Sent: Wednesday, July 09, 2008 2:55 PM
> To: Attila Takacs; Loa Andersson; ccamp
> once you are at it, can u explain the following "to properly 
> setup the remote data plane endpoints" ? what it actually 
> means in the context:
> 
> standardisation in IEEE).  In this case revertiveness needs 
> to be  signalled by RSVP-TE during LSP establishment to 
> properly setup the  remote data plane endpoint."
> 

With regards to PBB-TE, 1:1 bidirectional protection with or without
reversion is supported by the data plane and are executed in data plane
independently of management or external signaling. However, this
requires to configure both endpoints the same way, i.e., protection with
or without reversion. For this RSVP-TE needs to add signaling of the
revertive property.

> also do u need a V bit, or isn't the WTR time with a reserved 
> value not sufficient e.g. 0x0 ? when for inst. the locally 
> configured timer would be used (no timer signaled).
> 

Agreed, we would not need a bit if we had a WTR field with a reserved
value. On the other hand, if the WTR value is not required to change on
a per-LSP basis, which is possibly the general case, we would not need a
WTR field occupying several bits, instead just have single revertive
bit.

> the revertive operation is associated to LSP right ? why did 
> you pull this into the 16-bit space for Link specific 
> operation (before link flags ?)
> 

I think there are options to place this information:

-it could have a dedicated bit (V) as it is in the ID
-alternatively reversion may be added to LSP Flags as a specific
protection type (e.g., adding new types such as Revertive 1:N
Protection, Revertive 1+1 Bidirectional Protection,...)

-you are right about the WTR time, it should go before the LSP Flags 

> > ...at a first thought an explicit revertive bit may be used to 
> > override the priorities for LSPs with revertive protection.
> > 
> > Best regards,
> > Attila
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > > a neat draft that does what it sets out to do. For the 
> moment I've 
> > > no actual comments on the draft itself (might have when 
> I'd time to 
> > > think about in detail), but more meta-question.
> > > 
> beneficial. 
> > > In networks that are very dynamic it might be optional to revert, 
> > > let the traffic stay on the protecting path or replace them 
> > > altogether.
> > >

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Wed, 9 Jul 2008 16:39:07 +0200

hi - see inline:
> From: Attila Takacs [mailto:[email-masked]] 
> Sent: Wednesday, July 09, 2008 4:12 PM
> To: PAPADIMITRIOU Dimitri; Loa Andersson; ccamp

it is to be used iff reversion is not governed by control
and setup during provisioning - ok this i understand 

what i do not is the properly catch is this setup of the 
remote data plane endpoint, but which specific config is 
this ? in part in the PBB-TE context ?

> WTR field occupying several bits, instead just have single revertive

you ask for both support and use of the V-bit and WTR timer in the 
doc - right ? the fact the WTR is mandatory removes the needed for
a dedicated bit. you can even have something like:
0b0000 enable (using local configured timer)
0b1111 disable 
0b0001-0b1110 enable with the signaled timer.

this should also solve the below problem entirely assuming the WTR
timer goes before LSP flags.
-d.

---

From: "Attila Takacs" <[email-masked]>
Date: Wed, 9 Jul 2008 17:14:05 +0200

Hi Dimitri,
Please see inline! 
Attila

> Sent: Wednesday, July 09, 2008 4:39 PM
> > > once you are at it, can u explain the following "to 
> properly setup 
> > > the remote data plane endpoints" ? what it actually means in the 
> > > context:
> > > 
> > reversion is supported by the data plane and are executed in data 
> > plane independently of management or external signaling. 
> However, this 
> > requires to configure both endpoints the same way, i.e., protection 
> > with or without reversion. For this RSVP-TE needs to add 
> signaling of 
> > the revertive property.
> 
> it is to be used iff reversion is not governed by control and 
> setup during provisioning - ok this i understand 
> 
> remote data plane endpoint, but which specific config is this 
> ? in part in the PBB-TE context ?
> 

When establishing a protection group with worker and protection PBB-TE
ESPs one needs also to specify if reversion is enabled and if so the WTR
time. In particular a WTR timer needs to be specified, which has a
reserved value that disables reversion.

> > > also do u need a V bit, or isn't the WTR time with a 
> reserved value 
> > > not sufficient e.g. 0x0 ? when for inst. the locally configured 
> > > timer would be used (no timer signaled).
> > 
> > value. On the other hand, if the WTR value is not required 
> to change 
> > on a per-LSP basis, which is possibly the general case, we 
> would not 
> > need a WTR field occupying several bits, instead just have single 
> > revertive bit.
> 
> you ask for both support and use of the V-bit and WTR timer 
> in the doc - right ? the fact the WTR is mandatory removes 
> the needed for a dedicated bit. you can even have something like:
> this should also solve the below problem entirely assuming 
> the WTR timer goes before LSP flags.

Agreed.

> -d.
> > > the revertive operation is associated to LSP right ? why did you 
> > > pull this into the 16-bit space for Link specific 
> operation (before 
> > > link flags ?)
> > > 
> > 
> -alternatively 
> > reversion may be added to LSP Flags as a specific protection type 
> > (e.g., adding new types such as Revertive 1:N Protection, Revertive 
> > 1+1 Bidirectional Protection,...)
> >

---

From: Loa Andersson <[email-masked]>
Date: Fri, 01 Aug 2008 09:34:41 +0200

Attila,

I have planned respond to this for same time, but did not really
had time to get around to it.

Attila Takacs wrote:
> reversion if LSP setup and holding priorities are mismatched.

that would be one case, but not really what i was thinking of

> In this

sure
> the priorities for LSPs with revertive protection.

I've two questions:

1. If revertiveness is the normal procedure, wouldn't it be better to
    let indicate LSPs that *shouldn't* revert?

2. What I really thought about was, how does revertiveness work with
traffic placement policies?

Assume that you have a policy that that says you want to optimize the
chances to successfully set up an LSP that make a maximum share of some
constraints. It could be any constraints, but thinking of it as bw
wouldn't wrong.

Assume also that you have three different routes form A to B, through
C, D and E respectively.

Assume that each of the nodes C, D and E has interfaces with constraint
of 100. This is of course a very simplified model just to illustrate my
point.

In order the follow your policy you place traffic on C and E, and leave
D free, if there is a request for an LSP that requires 100. So the
situation could be:

C = 40 occupied, 60 free
D = 100 free
E = 40 occupied, 60 free

now if C fails it makes sense to move the traffic to E:

C = failed
D = 100 free
E = 80 occupied, 20 free

If the failure takes some time to repair, there might be a request
for a LSP that requires 60, the only possibility is to place on D:

C = failed
D = 60 occupied, 40 free
E = 80 occupied, 20 free

Now C comes back up:

C = 100 free
D = 60 occupied, 40 free
E = 80 occupied, 20 free

This situation is in accordance with your policy, but if you
revert you loose the ability to place any LSPs which requires
more than 60

C = 40 occupied, 60 free
D = 60 occupied, 40 free
E = 40 occupied, 60 free

Why would you want to revert in this case?

Now there might be some optimization program working in the background,
that might move traffic from any of nodes to any of the other, possibly
from C to E.

I seems to me that running an optimization program is more efficient.

/Loa

-- 
Loa Andersson