Re: [Pals] Shepherds review of draft-ietf-pals-status-reduction-00

Stewart Bryant <stewart.bryant@gmail.com> Tue, 28 June 2016 11:06 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: pals@ietfa.amsl.com
Delivered-To: pals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9540912D0E1 for <pals@ietfa.amsl.com>; Tue, 28 Jun 2016 04:06:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VYeRgohZ4Dd for <pals@ietfa.amsl.com>; Tue, 28 Jun 2016 04:06:42 -0700 (PDT)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B924B12D0DB for <pals@ietf.org>; Tue, 28 Jun 2016 04:06:38 -0700 (PDT)
Received: by mail-wm0-x22e.google.com with SMTP id f126so135054424wma.1 for <pals@ietf.org>; Tue, 28 Jun 2016 04:06:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=VcVSTBhZfFK1EMcV5eYFMOlcZTsKofWRfLMhrQokYiY=; b=guNpos4RWQOFXyFRPWKn71qdXGEnYn+We0qX3z5kqjR7JQOLUd0zGKDf45rsZSs9QT kof+kSamS0nIwPkcKj5VKeQr9plAeVLbmgfTxoq11tneuX5I1K//+gAnCTA8TViK+MGV 2D1Z8JMWM4GnrG5RTKOHOXQzpT6+DgCB/iWDy353U6SCvsuxs74y0gwXs5c/Zeoh7eUc Dkv2o5b9yQ4ESHiFX7GTTTOueUVZ0y6te4DApqjy/0q4d62NBZdh5sw5fEitjr69hbEz YrUX2cLjlQY9hqAmpiN5FeB2zkqeriL2AYVGkgCzkASC5/nNiN4JB5T5j71c9YxbWGr6 17XQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=VcVSTBhZfFK1EMcV5eYFMOlcZTsKofWRfLMhrQokYiY=; b=Q9tpIKTK6JsPK93KxMDA/InCqiAf7boXHJwAFj1MHrDyZAQFqUAk2Mi4qGnk6oEmbh Q2ArrNaPAUfxtvxwd1BapEM2hrqPXApWY1hJ+2XTOwbOWBYK++rimiMJ8/7GEjFAfwbq VFVpYP/Sm+8Rp4XP7KlIITOMj3XisU4fuFjZCwmwhYm0Tkzy9cgSTNhyTMJDtmD8H2at M282eG3M51LM5R6n/ug3xkCQTbQZeGe5uA/zq7eVur0fB/v4gcrflJ9mu/raqoWwkcXw PeWnLlCGIAz0aS8f5WuTZ/Hdb2UP2Ajgogu6NI0NNm7lxWczWGARQkBFdHPUDBrZY+py Wsog==
X-Gm-Message-State: ALyK8tLlTylUZb5toSmYeJCK9C1b9VMeZ7wnDDX0Jr5v5kvZj7XNwi6Ud8I06GZNcOgnOg==
X-Received: by 10.28.176.129 with SMTP id z123mr14462063wme.99.1467111997119; Tue, 28 Jun 2016 04:06:37 -0700 (PDT)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id bf5sm6055570wjc.12.2016.06.28.04.06.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jun 2016 04:06:36 -0700 (PDT)
To: Luca Martini <lmartini@cisco.com>, draft-ietf-pals-status-reduction@tools.ietf.org
References: <6cdf6691-e5ce-434c-edbe-4ad999b7aa5a@gmail.com> <576427F9.2030704@cisco.com> <69c9d897-3f45-12e3-4567-3cc9ebcdec6d@gmail.com> <5768298D.3060005@cisco.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <d21487b8-78b0-ce14-e646-40a205637b60@gmail.com>
Date: Tue, 28 Jun 2016 12:06:36 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <5768298D.3060005@cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/pals/h25N3usvCg7wMLdJqcK7k4EaT2Y>
Cc: Elisa Bellagamba <elisa.bellagamba@gmail.com>, "pals-chairs@tools.ietf.org" <pals-chairs@tools.ietf.org>, "pals@ietf.org" <pals@ietf.org>
Subject: Re: [Pals] Shepherds review of draft-ietf-pals-status-reduction-00
X-BeenThere: pals@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Pseudowire And LDP-enabled Services dicussion list." <pals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pals>, <mailto:pals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pals/>
List-Post: <mailto:pals@ietf.org>
List-Help: <mailto:pals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pals>, <mailto:pals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jun 2016 11:06:46 -0000

======
>>>>
>>>>
>>>>        * Session ID
>>>>
>>>>          A non-zero, locally selected session number that is not
>>>> preserved
>>>>          if the local PE restarts.
>>>>
>>>>          In order to get a locally unique session ID, the recommended
>>>>          choice is to perform a CRC-16 giving as input the following
>>>> data
>>>>
>>>>          |Y|Y|M|M|D|D|H|H|M|M|S|S|L|L|L|
>>>>
>>>>          Where:  YY: are the decimal two last digit of the current year
>>>>          MM: are the decimal two digit of the current month DD: are the
>>>>          decimal two digit of the current day HHMMSSLLL: are the decimal
>>>>          digits of the current time expressed in (hour, minutes,
>>>> seconds,
>>>>          milliseconds)
>>>>
>>>> SB> What happens if there is a hash collision?
>>> ok, I'll take care of this by just adding 1 to the number until it is
>>> locally unique.
>>> ( unless you have a better suggestion ? )
>>> I will add the following:
>>>
>>> If the calculation results in an already existing session ID, a unique
>>> session ID can be generated by adding 1 to the result until the session
>>> ID is unique.
>>> Any other method to generate a locally unique session ID is also
>>> acceptable.
>> That would work, or you could say any use any method you like so long
>> as you
>> search for  value that is unique amongst the currently known Session IDs.
>>
>> Is there any reason no to preserve the number? Surely it make n/w mgt
>> easier?
>>
> I did not see a reason to force any implementation to preserve the
> number. It certainly is not necessary for inter-operation of PEs.
> Since the number is only unique to a PE , I would expect it to not be
> used to identify links on it's own.
>
>

You are correct in terms of interoperability. I am not sure what view 
the OPs folks
will take.

Why don't we leave it as non-preserving then and see what they say.

Stewart