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

["Attila Takacs" <[e-mail]>]

Hi Dimitri,
Please see inline! 
Attila

> -----Original Message-----
> From: PAPADIMITRIOU Dimitri 
> [mailto:[e-mail]] 
> Sent: Wednesday, July 09, 2008 4:39 PM
> To: Attila Takacs; Loa Andersson; ccamp
> Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
> 
>  
> hi - see inline:
> > -----Original Message-----
> > From: Attila Takacs [mailto:[e-mail]]
> > Sent: Wednesday, July 09, 2008 4:12 PM
> > To: PAPADIMITRIOU Dimitri; Loa Andersson; ccamp
> > Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
> > 
> > Hi Dimitri,
> > 
> > Thanks for the comments!
> > Pease see inline.
> > Best regards,
> > Attila
> > 
> > > -----Original Message-----
> > > From: PAPADIMITRIOU Dimitri
> > > [mailto:[e-mail]]
> > > Sent: Wednesday, July 09, 2008 2:55 PM
> > > To: Attila Takacs; Loa Andersson; ccamp
> > > Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
> > > 
> > > 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."
> > > 
> > 
> > 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.
> 
> 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 ?
> 

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).
> > 
> > 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.
> 
> 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.

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 ?)
> > > 
> > 
> > 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
> > 
> > 
> > 
> > 
> > > thx,
> > > -d.
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]] 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,
> > > > 
> > > > 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:[e-mail]]
> > > > > 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
> > > > > 
> > > > > [e-mail] 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
> > > > > > [e-mail]
> > > > > > 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:  [phone]
> > > > > Isafjordsgatan 22                  mobile: [phone]
> > > > > Kista, Sweden                      email:  
> > [e-mail]
> > > > >                                             [e-mail]
> > > > > 
> > > > 
> > > > 
> > > 
> > 
>