Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304)

Rajan Rao <rrao@infinera.com> Thu, 02 August 2012 17:18 UTC

Return-Path: <rrao@infinera.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF5D11E8174 for <ccamp@ietfa.amsl.com>; Thu, 2 Aug 2012 10:18:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level:
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_21=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbDNJG+boLdq for <ccamp@ietfa.amsl.com>; Thu, 2 Aug 2012 10:18:48 -0700 (PDT)
Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 886BA11E8170 for <ccamp@ietf.org>; Thu, 2 Aug 2012 10:18:47 -0700 (PDT)
Received: from SV-EXDB-PROD2.infinera.com ([fe80::1d05:1822:aaea:ff52]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.02.0283.003; Thu, 2 Aug 2012 10:18:46 -0700
From: Rajan Rao <rrao@infinera.com>
To: John E Drake <jdrake@juniper.net>, "Zafar Ali (zali)" <zali@cisco.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "'Ong, Lyndon'" <Lyong@ciena.com>, "ccamp@ietf.org" <ccamp@ietf.org>
Thread-Topic: [CCAMP] [Technical Errata Reported] RFC4872 (3304)
Thread-Index: AQHNb+xRzb87U2dmuEW4nUyID8ipJZdFtPGAgABhDQCAABB8AIAAAagAgACMARCAAAd3wIAAB6hw
Date: Thu, 02 Aug 2012 17:18:45 +0000
Message-ID: <650AA355E323C34D9D4AAEED952E053D347EE4F1@SV-EXDB-PROD2.infinera.com>
References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <A0B4FC0A5EFBD44585414760DB4FD2749F1BB256@MDWEXGMB02.ciena.com> <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> <5E893DB832F57341992548CDBB333163A5A8E93302@EMBX01-HQ.jnpr.net> <B6585D85A128FD47857D0FD58D8120D39E9064@xmb-rcd-x14.cisco.com> <5E893DB832F57341992548CDBB333163A5A8E9337E@EMBX01-HQ.jnpr.net> <650AA355E323C34D9D4AAEED952E053D347EE404@SV-EXDB-PROD2.infinera.com> <5E893DB832F57341992548CDBB333163A5A8E93642@EMBX01-HQ.jnpr.net>
In-Reply-To: <5E893DB832F57341992548CDBB333163A5A8E93642@EMBX01-HQ.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.100.156.118]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "jplang@ieee.org" <jplang@ieee.org>, "dimitri.papadimitriou@alcatel-lucent.be" <dimitri.papadimitriou@alcatel-lucent.be>, "dbrungard@att.com" <dbrungard@att.com>
Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304)
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Aug 2012 17:18:50 -0000

John,

I too agree that existing text from Section-12 (see below) is sufficient as pointed by Zafar.  The text below should also clarify your questions.   
"
For "Rerouting without Extra-traffic" (including the shared recovery
   case), reversion implies that the formerly working LSP has not been
   torn down by the head-end node upon PathErr message reception, i.e.,
   the head-end node kept refreshing the working LSP under failure
   condition.  This ensures that the exact same resources are retrieved
   after reversion switching (except if the working LSP required re-
   signaling).
"

Thanks
Rajan


-----Original Message-----
From: John E Drake [mailto:jdrake@juniper.net] 
Sent: Thursday, August 02, 2012 9:52 AM
To: Rajan Rao; Zafar Ali (zali); adrian@olddog.co.uk; 'Ong, Lyndon'; ccamp@ietf.org
Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; dbrungard@att.com
Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304)

Rajan,

Due to link and/or node failure the resources of a failed LSP may not be maintained.  Further, at any time a higher priority LSP may be established that pre-empts the resources of a failed LSP.  This is sort of basic.

Also, because of this, I am not sure what the phrase 'continuous monitoring of failed path is necessary' means or how you intend to accomplish this other than by attempting to re-establish the failed LSP along its original path.

Finally, and most importantly, as I indicated yesterday, I don't see anything wrong with the existing text.

Thanks,

John

Sent from my iPhone

> -----Original Message-----
> From: Rajan Rao [mailto:rrao@infinera.com]
> Sent: Thursday, August 02, 2012 9:21 AM
> To: John E Drake; Zafar Ali (zali); adrian@olddog.co.uk; 'Ong, 
> Lyndon'; ccamp@ietf.org
> Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be;
> dbrungard@att.com
> Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304)
>
> John,
>
> Revertive restoration requires keeping original path  because 
> continuous monitoring of failed path is necessary for revertive 
> operation upon recovery.
>
> Thanks
> Rajan
>
> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf 
> Of John E Drake
> Sent: Wednesday, August 01, 2012 5:54 PM
> To: Zafar Ali (zali); adrian@olddog.co.uk; 'Ong, Lyndon'; 
> ccamp@ietf.org
> Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be;
> dbrungard@att.com
> Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304)
>
> You can't keep the original, broken LSP around because it no longer 
> has e2e committed resources.  The best you can do is clean it up and 
> try to re-instantiate it on its original path.
>
> Sent from my iPhone
>
> > -----Original Message-----
> > From: Zafar Ali (zali) [mailto:zali@cisco.com]
> > Sent: Wednesday, August 01, 2012 5:48 PM
> > To: John E Drake; adrian@olddog.co.uk; 'Ong, Lyndon'; ccamp@ietf.org
> > Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be;
> > dbrungard@att.com
> > Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304)
> >
> > Hi John-
> >
> > Please see my response to Adrian's email for the use case for 
> > keeping the original LSP around during failure.
> >
> > Thanks
> >
> > Regards ... Zafar
> >
> >
> > > -----Original Message-----
> > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
> > Behalf
> > > Of John E Drake
> > > Sent: Wednesday, August 01, 2012 7:49 PM
> > > To: adrian@olddog.co.uk; 'Ong, Lyndon'; ccamp@ietf.org
> > > Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be;
> > > dbrungard@att.com
> > > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304)
> > >
> > > Is it not the case that the old LSP is broken?  In which case it
> > needs
> > > to be cleaned up and re-signaled.
> > >
> > > Sent from my iPhone
> > >
> > >
> > > > -----Original Message-----
> > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On 
> > > > Behalf Of Adrian Farrel
> > > > Sent: Wednesday, August 01, 2012 11:02 AM
> > > > To: 'Ong, Lyndon'; ccamp@ietf.org
> > > > Cc: dimitri.papadimitriou@alcatel-lucent.be; jplang@ieee.org; 
> > > > dbrungard@att.com
> > > > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304)
> > > >
> > > > Hello again,
> > > >
> > > > > Thank you for the fast evaluation of the errata.  It sounds
> like
> > > > > the
> > > > correction that I
> > > > > suggested has ended up overspecifying the method to do
> reversion
> > > with
> > > > > full rerouting when it is very possible to support a form of
> > > > reversion
> > > > > that doesn't involve maintaining the old LSP.
> > > >
> > > > Right, I understand that you want to allow the option of
> retaining
> > > > the old working LSP. Also that you have no intention to remove
> the
> > > > option of removing the old working LSP.
> > > >
> > > > > From your response I believe that you do agree that it was not
> > the
> > > > > intent of
> > > > the
> > > > > original specification text to imply that reversion with full 
> > > > > rerouting is not
> > > > allowed
> > > >
> > > > Definitely not the intent to imply that reversion with full 
> > > > rerouting is not allowed.
> > > > Does the text say or even imply this?
> > > >
> > > > > (or to require that the old LSP always be torn down in full
> > > > rerouting)
> > > >
> > > > Also no intention to *require* the old LSP to be torn down.
> > > > My view is that the text is fully conformant with that.
> > > > I understand that the text does not make an explicit statement 
> > > > of
> > > this.
> > > >
> > > > > so hopefully
> > > > > with some more discussion we can determine if there is 
> > > > > anything that could be done to make that clearer.
> > > >
> > > > There is, of course, a lot that could be done to make it clearer.
> > > > But is there really a need? We discussed the point. We agreed it 
> > > > is not prohibited in the RFC. Can we not just move on?
> > > >
> > > > Cheers,
> > > > Adrian
> > > > > -----Original Message-----
> > > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> > > > > Sent: Tuesday, July 31, 2012 6:28 PM
> > > > > To: ccamp@ietf.org
> > > > > Cc: jplang@ieee.org; yakov@juniper.net;
> > > > dimitri.papadimitriou@alcatel-
> > > > > lucent.be; stbryant@cisco.com; lberger@labn.net; 
> > > > > dbrungard@att.com; Ong, Lyndon
> > > > > Subject: RE: [Technical Errata Reported] RFC4872 (3304)
> > > > >
> > > > > Hi CCAMP,
> > > > >
> > > > > I find that this erratum is raised against two sections one of 
> > > > > which
> > > > I
> > > > supplied text
> > > > > for. If this get contentious, I will call on Stewart to call
> > > > consensus
> > > > > and
> > > > handle the
> > > > > Erratum in the system.
> > > > >
> > > > > In my opinion, this proposal goes further than the intention 
> > > > > of the authors/WG
> > > > in
> > > > > publishing 4872.
> > > > >
> > > > > With regard to the proposed addition to section 11...
> > > > > The use of mb4b is already in scope. The existing text says
> "The
> > > > > new LSP resources can be established using the make-before-
> break
> > > > > mechanism," so there is no need to re-state "The new LSP can 
> > > > > be established without tearing down
> > > > the
> > > > > old LSP".
> > > > >
> > > > > I think your concern here is whether the old LSP is ever torn
> > down.
> > > I
> > > > > think
> > > > that
> > > > > you are worried that if the old LSP is torn down, it might be 
> > > > > impossible to
> > > > perform
> > > > > reversion because, after repair, an attempt to revert (also 
> > > > > using
> > > > > mb4b) might
> > > > find
> > > > > that key resources have been "stolen" by some other LSP. I
> don't
> > > > > see this as
> > > > at all
> > > > > different from the issue of the protection LSP itself. That 
> > > > > is,
> > it
> > > is
> > > > > of the
> > > > nature of
> > > > > LSP Rerouting as a protection mechanism that:
> > > > > a. protection may fail because of lack of resources b.
> reversion
> > > > > may fail
> > > > because
> > > > > of lack of resources
> > > > >
> > > > > *If* reversion is so important, I don't quite see why
> protection
> > > > > is not
> > > > important.
> > > > > If protection is important then you should be using a proper 
> > > > > protection mechanism and not waiting for post facto rerouting.
> > > > > Furthermore, if you
> > > > require
> > > > > that the LSP be retained for restoration, why are you not 
> > > > > using a protection mechanism?
> > > > >
> > > > > But the general paradigm here is that you are willing to use
> the
> > > best
> > > > available LSP
> > > > > when it is set up in the first place, the best available LSP 
> > > > > when
> > > you
> > > > > re-route
> > > > after
> > > > > failure, and the best available LSP when you "revert".
> > > > >
> > > > > Lastly, it *does* remain an _option_ to retain the failed LSP
> in
> > > > order
> > > > > to
> > > > switch
> > > > > back. Nothing in the old text precludes that, although I 
> > > > > understand that there
> > > > is
> > > > > an implication that it might be expected to be torn down.
> > > > >
> > > > > So I conclude that the proposed addition to section 12 is not
> > what
> > > > the
> > > > > authors/WG intended.
> > > > >
> > > > > We should discuss further.
> > > > >
> > > > > Adrian
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]
> > > > > > Sent: 31 July 2012 17:39
> > > > > > To: jplang@ieee.org; yakov@juniper.net;
> > > > > > dimitri.papadimitriou@alcatel- lucent.be; 
> > > > > > stbryant@cisco.com; adrian@olddog.co.uk; lberger@labn.net; 
> > > > > > dbrungard@att.com
> > > > > > Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc-
> editor.org
> > > > > > Subject: [Technical Errata Reported] RFC4872 (3304)
> > > > > >
> > > > > >
> > > > > > The following errata report has been submitted for RFC4872,
> > > > > > "RSVP-
> > > > TE
> > > > > > Extensions in Support of End-to-End Generalized Multi-
> Protocol
> > > > Label
> > > > > > Switching (GMPLS) Recovery".
> > > > > >
> > > > > > --------------------------------------
> > > > > > You may review the report below and at:
> > > > > > http://www.rfc-editor.org/errata_search.php?rfc=4872&eid=330
> > > > > > 4
> > > > > >
> > > > > > --------------------------------------
> > > > > > Type: Technical
> > > > > > Reported by: Lyndon Ong <lyong@ciena.com>
> > > > > >
> > > > > > Section: 11 & 12
> > > > > >
> > > > > > Original Text
> > > > > > -------------
> > > > > > Section 11 says:
> > > > > >
> > > > > >
> > > > > >    (Full) LSP rerouting will be initiated by the head-end
> node
> > > that
> > > > has
> > > > > >    either detected the LSP failure or received a Notify 
> > > > > > message
> > > > and/or a
> > > > > >    PathErr message with the new error code/sub-code "Notify
> > > > Error/LSP
> > > > > >    Locally Failed" for this LSP.  The new LSP resources can
> be
> > > > > >    established using the make-before-break mechanism, where 
> > > > > > the
> > > new
> > > > LSP
> > > > > >    is set up before the old LSP is torn down.  This is done
> by
> > > > using the
> > > > > >    mechanisms of the SESSION_ATTRIBUTE object and the 
> > > > > > Shared-
> > > > Explicit
> > > > > >    (SE) reservation style (see [RFC3209]).  Both the new and
> > old
> > > > LSPs
> > > > > >    can share resources at common nodes.
> > > > > >
> > > > > > Section 12 says:
> > > > > >
> > > > > >    [No text on reversion for (full) LSP Rerouting.]
> > > > > >
> > > > > > Corrected Text
> > > > > > --------------
> > > > > > Section 11 should say:
> > > > > >
> > > > > >
> > > > > >    (Full) LSP rerouting will be initiated by the head-end
> node
> > > that
> > > > has
> > > > > >    either detected the LSP failure or received a Notify 
> > > > > > message
> > > > and/or a
> > > > > >    PathErr message with the new error code/sub-code "Notify
> > > > Error/LSP
> > > > > >    Locally Failed" for this LSP.  The new LSP resources can
> be
> > > > > >    established using the make-before-break mechanism, where 
> > > > > > the
> > > new
> > > > LSP
> > > > > >    is set up before the old LSP is torn down.  This is done
> by
> > > > using the
> > > > > >    mechanisms of the SESSION_ATTRIBUTE object and the 
> > > > > > Shared-
> > > > Explicit
> > > > > >    (SE) reservation style (see [RFC3209]).  Both the new and
> > old
> > > > LSPs
> > > > > >    can share resources at common nodes.  The new LSP can be
> > > > established
> > > > > >    without tearing down the old LSP in case of reversion 
> > > > > > (see
> > > > section 12).
> > > > > >
> > > > > > Section 12 should say:
> > > > > >
> > > > > >    For "(full) LSP Rerouting", reversion implies that the 
> > > > > > old LSP
> > > > is not
> > > > > >    torn down by the head-end node after the new LSP is
> > > established.
> > > > For
> > > > > >    reversion, the head-end node re-activates the old LSP
> after
> > > this
> > > > has
> > > > > >    recovered.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Notes
> > > > > > -----
> > > > > > Current text in RFC 4872 describes reversion in the cases of
> > 1+1
> > > > > > bidirectional Protection, 1:N Protection with Extra Traffic 
> > > > > > and Rerouting Without Extra
> > > > > Traffic,
> > > > > > however it has no description of reversion with (Full) LSP
> > > > Rerouting.
> > > > > > For (full) LSP Rerouting, the description in Section 11 
> > > > > > instead implies that
> > > > > the old
> > > > > > LSP is torn down. This has led to some confusion as to
> whether
> > > > > > reversion with
> > > > > > (full) LSP Rerouting is allowed or not allowed by the RFC. 
> > > > > > We believe this was
> > > > > not
> > > > > > intentional. The additions would make it clear that 
> > > > > > reversion can
> > > > be
> > > > > > supported with (Full) LSP Rerouting.
> > > > > >
> > > > > > Instructions:
> > > > > > -------------
> > > > > > This errata is currently posted as "Reported". If necessary,
> > > please
> > > > > > use "Reply All" to discuss whether it should be verified or
> > > > rejected.
> > > > > > When a decision is reached, the verifying party (IESG) can
> log
> > > > > > in
> > > > to
> > > > > > change the status and edit the report, if necessary.
> > > > > >
> > > > > > --------------------------------------
> > > > > > RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04)
> > > > > > --------------------------------------
> > > > > > Title               : RSVP-TE Extensions in Support of End-
> to-
> > End
> > > > Generalized
> > > > > Multi-
> > > > > > Protocol Label Switching (GMPLS) Recovery
> > > > > > Publication Date    : May 2007
> > > > > > Author(s)           : J.P. Lang, Ed., Y. Rekhter, Ed., D.
> > > > Papadimitriou, Ed.
> > > > > > Category            : PROPOSED STANDARD
> > > > > > Source              : Common Control and Measurement Plane
> > > > > > Area                : Routing
> > > > > > Stream              : IETF
> > > > > > Verifying Party     : IESG
> > > >
> > > > _______________________________________________
> > > > CCAMP mailing list
> > > > CCAMP@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/ccamp
> > > _______________________________________________
> > > CCAMP mailing list
> > > CCAMP@ietf.org
> > > https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp