Re: [CCAMP] Comment on compatibility in draft-takacs-ccamp-revertive-ps
Francesco Fondelli <francesco.fondelli@gmail.com> Thu, 14 November 2013 08:31 UTC
Return-Path: <francesco.fondelli@gmail.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 1CBDE21E8088 for <ccamp@ietfa.amsl.com>; Thu, 14 Nov 2013 00:31:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 F+qs8hnQ62Px for <ccamp@ietfa.amsl.com>; Thu, 14 Nov 2013 00:31:35 -0800 (PST)
Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7BE21E8087 for <ccamp@ietf.org>; Thu, 14 Nov 2013 00:31:34 -0800 (PST)
Received: by mail-qe0-f48.google.com with SMTP id a11so1042428qen.35 for <ccamp@ietf.org>; Thu, 14 Nov 2013 00:31:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=L5kL8IsJ1yrWpoBGRHqXJ3TOGMZ5lIdvtQO0ku270ts=; b=IFIFtMEtZXu057BasWibGWHklcsEu1uqhh6LeiZq7wnUv2+ndbzFRnlPl3SZZIzhza USU33VnSIPDyzBiX+RBRerWQ9UFhSq3VVvTys8gj8UiBHSRa70t76tHJAaddFGRiQzai /V+VjxY6EmlhvGBTdT6qSJEfQJrwLOH0mVYAfU5gjiL4tyrZLZt0mTokEZd+fwh2Lq7A IF2NOdcJcgVJm5wir4XgT15v94OVWN5Vp1Zu94eWq+pw4dyeTd1TkF3jAbY7IiOYaBy/ n1MKUpgr6nY7WYxDk7M28/aTcDBOoeMeBkHu9D/SiGSlrshsFJLQvQzFUrNRT2hRo5Tw hUmg==
MIME-Version: 1.0
X-Received: by 10.49.62.167 with SMTP id z7mr179640qer.67.1384417888582; Thu, 14 Nov 2013 00:31:28 -0800 (PST)
Received: by 10.224.37.198 with HTTP; Thu, 14 Nov 2013 00:31:28 -0800 (PST)
In-Reply-To: <5283EAB2.1090609@gmail.com>
References: <CEA7E0C8.82EA8%zali@cisco.com> <5283E6B0.7030607@gmail.com> <3ff1a569966142cbb120eeecbb6b9530@BY2PR05MB142.namprd05.prod.outlook.com> <5283EAB2.1090609@gmail.com>
Date: Thu, 14 Nov 2013 09:31:28 +0100
Message-ID: <CABP12Jz-tFTPhER==WndJCez1SxrC2rBbqrD_V7dwafRh8eL6A@mail.gmail.com>
From: Francesco Fondelli <francesco.fondelli@gmail.com>
To: "ccamp@ietf.org" <ccamp@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [CCAMP] Comment on compatibility in draft-takacs-ccamp-revertive-ps
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, 14 Nov 2013 08:31:36 -0000
Hi, > They will provision default values per layer in the network. Many years ago we had a request (for a gmpls-controlled sdh network) to control hoff on a per connection basis. Some connections were supporting a form of protection switching at upper layer. Other connections (at the same layer) were supported by a form of protection switching in the lower layer. They wanted different hold off timers (default was 100ms if I am not wrong). They also pointed me to "Hold-off times are useful for interworking of protection schemes. The objective is that these times should be provisionable on an individual VC basis" [G.841]. No idea what OTN or WDM recommendations say about this point. > A nice note. Dou you think this draft is gilding the lily? I do not know, it might. All I know is that during the past 5 years I sporadically receive the request described above. I typically reply with a link to this draft. thanks ciao fra On Wed, Nov 13, 2013 at 10:10 PM, Huub van Helvoort <huubatwork@gmail.com> wrote: > Hello John, > > You replied: > >> A nice note. Dou you think this draft is gilding the lily? > > > Yes, indeed. > > Regards, Huub. > > > >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >>> Of Huub van Helvoort >>> Sent: Wednesday, November 13, 2013 12:53 PM >>> To: ccamp@ietf.org >>> Subject: Re: [CCAMP] Comment on compatibility in draft-takacs-ccamp- >>> revertive-ps >>> >>> Hello Zafar, >>> >>> You wrote: >>> >>> > The default parameter value in data plan is deficient for the > >>> following >>> reasons: >>>> >>>> >>>> 1. We cannot differentiate between revertive and non-revertive >>>> behavior >>>> using default value of wait-to-restore timer. >>> >>> >>> The value of the WTR timer should not determine the (non-)revertive >>> behavior. >>> The (non-)revertive behaviour should be explicitly provisioned. >>> >>>> E.g., as far >>>> as I remember default value for WRT is 0, which means protection >>>> is non-revertive. >>> >>> >>> The typical default value for WTR is 5 minutes to provide a hysteresis, >>> it can be >>> overruled by a higher priority event like Sf or SD. >>> Setting the value of WTR to 0 does not mean protection is non-revertive. >>> >>>> So this default does not work for revertive >>>> protection. I.e., the data plan default cannot cover both revertive >>>> and non-revertive cases. >>> >>> >>> Again: the WTR value should not be used to indicate (non-)revertive >>> behavior. >>> >>>> 2. Correct setting for wait-to-restore and hold-off timers need to >>>> account for differential delays between working and protection >>>> paths. >>> >>> >>> No, WTR accounts for repair of the failed path and to encertain that the >>> repair >>> can be trusted. >>> Hold-off timers are used to allow protection switching in layers closer >>> to the >>> physical layer to complete before protection switching in the affected >>> layer. >>> >>>> In summary, default values cannot cover all use cases. Hence, SP >>>> typically wants to set revertive vs. non-revertive behavior, >>>> wait-to-restore and hold-off timers on per connection basis. >>> >>> >>> They will provision default values per layer in the network. >>> >>> Regards, Huub. >>> >>> =========== >>>> >>>> From: Dieter Beller <Dieter.Beller@alcatel-lucent.com >>>> <mailto:Dieter.Beller@alcatel-lucent.com>> >>>> Organization: Alcatel-Lucent >>>> Date: Sunday, November 10, 2013 9:07 AM >>>> To: zali <zali@cisco.com <mailto:zali@cisco.com>> >>>> Cc: "lberger@labn.net <mailto:lberger@labn.net>" <lberger@labn.net >>>> <mailto:lberger@labn.net>>, "ccamp@ietf.org <mailto:ccamp@ietf.org>" >>>> <ccamp@ietf.org <mailto:ccamp@ietf.org>> >>>> Subject: Re: [CCAMP] Comment on compatibility in >>>> draft-takacs-ccamp-revertive-ps >>>> >>>> Hi Zafar, >>>> >>>> this draft is defining signaling extensions for the hold-off time >>>> as >>>> well as the wait-to-restore time for protected LSPs >>>> where applicable. >>>> >>>> There are default values set for these timers in the data plane and >>>> signaling them in the control plane makes only >>>> sense if the timer values shall differ from the default values. Do >>>> you see a need for that? IMO, operators typically >>>> use the defaults and do not set these values on a per connection >>>> basis. >>>> >>>> >>>> Thanks, >>>> Dieter >>>> >>>> >>>> On 08.11.2013 22:11, Zafar Ali (zali) wrote: >>>>> >>>>> Hi Lou- >>>>> >>>>> You are right, the ctype is TBD, like I mentioned during the >>>>> meeting that >>>>> we are using different ctype. >>>>> >>>>> We would like to take this opportunity to solicit comments from >>>>> the WG >>> >>> on >>>>> >>>>> this draft. >>>>> >>>>> Thanks >>>>> >>>>> Regards Š Zafar >>>>> >>>>> -----Original Message----- >>>>> From:"lberger@labn.net" <lberger@labn.net> >>>>> Date: Thursday, November 7, 2013 6:17 PM >>>>> To: zali<zali@cisco.com>,"ccamp@ietf.org" <ccamp@ietf.org> >>>>> Subject: Comment on compatibility in >>>>> draft-takacs-ccamp-revertive-ps >>>>> >>>>>> Zafar, >>>>>> My comment in today's session was that you are redefining the >>>>>> format >>> >>> of >>>>>> >>>>>> an existing object (by adding TLVs) this breaks compatibility. >>>>>> You >>>>>> stated that this wasn't the case. >>>>>> >>>>>> FWIW: >>>>>> >>>>>> Your document says: >>>>>> >>>>>> 0 1 2 3 >>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 >>>>>> 1 >>>>>> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | Length | Class-Num(37) | C-Type(2) >>>>>> | >>>>>> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> |S|P|N|O| Reserved | LSP Flags | Reserved | Link >>>>>> Flags| >>>>>> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> |I|R| Reserved | Seg.Flags | Reserved >>>>>> | >>>>>> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | >>>>>> | >>>>>> ~ sub-TLVs >>>>>> ~ >>>>>> | >>>>>> | >>>>>> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> >>>>>> >>>>>> RFC4872 says >>>>>> 0 1 2 >>>>>> 3 >>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 >>>>>> 0 1 >>>>>> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | Length | Class-Num(37) | C-Type (2) >>>>>> | >>>>>> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> |S|P|N|O| Reserved | LSP Flags | Reserved | Link >>>>>> Flags| >>>>>> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | Reserved >>>>>> | >>>>>> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> >>>>>> Perhaps you meant C-Type(TBD). You should address compatibility >>>>>> explicitly in any case. >>>>>> >>>>>> Lou >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.orghttps://www.ietf.org/mailman/listinfo/ccamp >>>> >>>> > > > -- > ***************************************************************** > 请记住,你是独一无二的,就像其他每一个人一样 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp
- [CCAMP] Comment on compatibility in draft-takacs-… Lou Berger
- Re: [CCAMP] Comment on compatibility in draft-tak… Zafar Ali (zali)
- Re: [CCAMP] Comment on compatibility in draft-tak… Lou Berger
- Re: [CCAMP] Comment on compatibility in draft-tak… Dieter Beller
- Re: [CCAMP] Comment on compatibility in draft-tak… Fatai Zhang
- Re: [CCAMP] Comment on compatibility in draft-tak… Zafar Ali (zali)
- Re: [CCAMP] Comment on compatibility in draft-tak… Zafar Ali (zali)
- Re: [CCAMP] Comment on compatibility in draft-tak… Fatai Zhang
- Re: [CCAMP] Comment on compatibility in draft-tak… Zafar Ali (zali)
- Re: [CCAMP] Comment on compatibility in draft-tak… Zafar Ali (zali)
- Re: [CCAMP] Comment on compatibility in draft-tak… Fatai Zhang
- Re: [CCAMP] Comment on compatibility in draft-tak… Huub van Helvoort
- Re: [CCAMP] Comment on compatibility in draft-tak… John E Drake
- Re: [CCAMP] Comment on compatibility in draft-tak… Huub van Helvoort
- Re: [CCAMP] Comment on compatibility in draft-tak… John E Drake
- Re: [CCAMP] Comment on compatibility in draft-tak… Acee Lindem
- Re: [CCAMP] Comment on compatibility in draft-tak… Francesco Fondelli
- Re: [CCAMP] Comment on compatibility in draft-tak… Rajan Rao