Re: [CCAMP] New Version Notification for draft-gandhi-ccamp-gmpls-restoration-lsp-04.txt

["Rakesh Gandhi (rgandhi)" <[e-mail]>]

Hi CCAMP WG and Chairs,

We have updated the text in the draft to reflect the Informational status
as per discussions at the last IETF.

We believe the draft is ready for the WG adoption, there was a good
support in the meeting for this draft.

Please let us know your review comments.

Thanks,
Rakesh 

P.S. Minutes from IETF-89
--------------------------
Draft:
          
http://tools.ietf.org/html/draft-gandhi-ccamp-gmpls-restoration-lsp-02

Presenter:     Zafar Ali
          http://tools.ietf.org/agenda/89/slides/slides-89-ccamp-26.pdf

          Lou Berger: There is inconsistency between the document and the
intended status (informational) as it changes procedures. Either you make
it
          standard track or change the text and make it informational.

          [poll] how many are interested in having it informational? [good
support]

          Lou Berger: The document needs to be made consistent before we
can discuss it further. I suggest making the document informational to be
          consistent with the slides.





On 2014-04-23 10:37 AM, "[e-mail]"
<[e-mail]> wrote:

>
>A new version of I-D, draft-gandhi-ccamp-gmpls-restoration-lsp-04.txt
>has been successfully submitted by Rakesh Gandhi and posted to the
>IETF repository.
>
>Name:		draft-gandhi-ccamp-gmpls-restoration-lsp
>Revision:	04
>Title:		RSVP-TE Signaling For GMPLS Restoration LSP
>Document date:	2014-04-23
>Group:		Individual Submission
>Pages:		7
>URL:            
>http://www.ietf.org/internet-drafts/draft-gandhi-ccamp-gmpls-restoration-l
>sp-04.txt
>Status:         
>https://datatracker.ietf.org/doc/draft-gandhi-ccamp-gmpls-restoration-lsp/
>Htmlized:       
>http://tools.ietf.org/html/draft-gandhi-ccamp-gmpls-restoration-lsp-04
>Diff:           
>http://www.ietf.org/rfcdiff?url2=draft-gandhi-ccamp-gmpls-restoration-lsp-
>04
>
>Abstract:
>   In transport networks, there are requirements where Generalized
>   Multi-Protocol Label Switching (GMPLS) end-to-end recovery scheme
>   needs to employ restoration Label Switched Path (LSP) while keeping
>   resources for the working and/or protecting LSPs reserved in the
>   network after the failure.
>
>   This document reviews how the LSP association is to be provided using
>   Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
>   signaling in the context of GMPLS end-to-end recovery when using
>   restoration LSP where failed LSP is not torn down.  No new procedures
>   or mechanisms are defined by this document, and it is strictly
>   informative in nature.
>
>
>                  
>        
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>