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