[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
Hi Dimitri,
Please see inline!
Attila
> -----Original Message-----
> From: PAPADIMITRIOU Dimitri
> [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]
> 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:Attila.Takacs@ericsson.com]
> > 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:Dimitri.Papadimitriou@alcatel-lucent.be]
> > > 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: owner-ccamp@ops.ietf.org
> > > > [mailto:owner-ccamp@ops.ietf.org] 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:loa@pi.nu]
> > > > > 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
> > > > >
> > > > > Internet-Drafts@ietf.org 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
> > > > > > I-D-Announce@ietf.org
> > > > > > 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:
> > loa.andersson@acreo.se
> > > > > loa@pi.nu
> > > > >
> > > >
> > > >
> > >
> >
>