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

["PAPADIMITRIOU Dimitri" <[e-mail]>]

 
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 ?

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