Re: [Teas] Preemption priority in GMPLS signaling for SMP

Jeong-dong Ryoo <ryoo@etri.re.kr> Thu, 29 October 2020 15:26 UTC

Return-Path: <ryoo@etri.re.kr>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7503A09D9 for <teas@ietfa.amsl.com>; Thu, 29 Oct 2020 08:26:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MISSING_MIMEOLE=1.899, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dooray.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 fIPKsL9lI3d8 for <teas@ietfa.amsl.com>; Thu, 29 Oct 2020 08:26:10 -0700 (PDT)
Received: from mscreen.etri.re.kr (mscreen.etri.re.kr [129.254.9.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5C343A09E8 for <teas@ietf.org>; Thu, 29 Oct 2020 08:26:09 -0700 (PDT)
Received: from unknown (HELO send001-relay.gov-dooray.com) (211.180.235.152) by 129.254.9.16 with ESMTP; 30 Oct 2020 00:26:05 +0900
X-Original-SENDERIP: 211.180.235.152
X-Original-MAILFROM: ryoo@etri.re.kr
X-Original-RCPTTO: teas@ietf.org
Received: from [10.162.225.103] (HELO send001.gov-dooray.com) ([10.162.225.103]) by send001-relay.gov-dooray.com with SMTP id 731d99a95f9adf0e; Fri, 30 Oct 2020 00:26:06 +0900
DKIM-Signature: a=rsa-sha256; b=fx2l8r4yydH+WlGEzexY19K3MO3iq9hUb9Uj9mTbA578gqqaNRArlm15zQhHLcEjpSMuUrk8N+ BgwYWPQ9gsSV+ntiZMXN0draiIc6GS3/nR2PMAeQROljBrIBexeXMM1N5fZnvXNNAoPNkKLmGZ8z M3+PgbYKafkaIhI6iE7V07lq6YxCJKD+1iRi2OqZkymfH0TV/wmzTukOlOCpE5tMFWW+taclI95h hFURFRWVU9Te43w6hRddsl+bVXTCTc9YMvf3s+MxrGKoKT3nS/Hb7hX0ztsQacec4yk2ZPsSClZI HUPexivqCGO9HQbYqth1uVcklPilV4znEwIOsM5g==; c=relaxed/relaxed; s=selector; d=dooray.com; v=1; bh=Nl49nSe9DuagQ1C9NMWAwx0qCjQj2gteGoAnNpm9Sf8=; h=From:To:Subject:Message-ID;
From: Jeong-dong Ryoo <ryoo@etri.re.kr>
To: teas@ietf.org, teas-chairs@ietf.org, adrian@olddog.co.uk
Cc: 'Bin Yeong Yoon' <byyun@etri.re.kr>, "'Hejia (Jia)'" <hejia@huawei.com>, 'Peter Park' <peter.park@kt.com>, 'Italo Busi' <italo.busi@huawei.com>
Message-ID: <lrxy6v4sfexc.lrxy6v4qfwj6.g1@dooray.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_2779_1819004467.1603985164238"
X-Dsn-Request: true
X-Dooray-Agent: mail-api
X-Dooray-Mail-Id: 2866219992831071568
Importance: Normal
X-Priority: Normal
X-MSMail-Priority: Normal
Date: Fri, 30 Oct 2020 00:26:04 +0900
Sender: ryoo@etri.re.kr
References: <lrqnh3lvdj0s.lrqnh3lsvtle.g1@dooray.com> <068a01d6ad6d$3da74060$b8f5c120$@olddog.co.uk>
In-Reply-To: <068a01d6ad6d$3da74060$b8f5c120$@olddog.co.uk>
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Ii3WZC9-pFE9IkPSvGj3n3ZzQqo>
Subject: Re: [Teas] Preemption priority in GMPLS signaling for SMP
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Oct 2020 15:26:12 -0000

Dear Adiran,

Thank you for your email.

When a working LSP or a protecting LSP is configured, SMP can also utilize the Setup and Holding priorities in the SESSION_ATTRIBUTE object. Once the working and protecting LSPs are all configured, SMP will use the preemption priority to resolve the competition for shared resources among multiple protecting LSPs. In SMP, the LSP that is preempted by a higher priority should not be torn down.&nbsp;

Yes, 0 is the highest priority value.

Thank you again for your interest.

Best regards,

Jeong-dong





-----Original Message-----
From: "Adrian Farrel" &lt;adrian@olddog.co.uk&gt;
To: "'Jeong-dong Ryoo'" &lt;ryoo@etri.re.kr&gt;; &lt;teas@ietf.org&gt;; &lt;teas-chairs@ietf.org&gt;;
Cc: "'Bin Yeong Yoon'" &lt;byyun@etri.re.kr&gt;; "'Hejia (Jia)'" &lt;hejia@huawei.com&gt;; "'Peter Park'" &lt;peter.park@kt.com&gt;; "'Italo Busi'" &lt;italo.busi@huawei.com&gt;;
Sent: 2020-10-29 (목) 06:00:06 (UTC+09:00)
Subject: Re: [Teas] Preemption priority in GMPLS signaling for SMP

Hey Jeong-dong,
&nbsp;
Can you clarify (for those who have not been following SMP closely) why existing GMPLS signaling pre-emption priorities (session attribute set-up and hold priorities) don’t provide you with what you need?
&nbsp;
In any case, I would recommend that you use the same order of ranking used for the set-up and hold priorities. That is, 0 is the highest priority. This seems to be what you are suggesting.
&nbsp;
Best,
Adrian
&nbsp;
&nbsp;
&nbsp;
From:&nbsp;Teas &lt;teas-bounces@ietf.org&gt; On Behalf Of&nbsp;Jeong-dong RyooSent: 28 October 2020 14:38To: teas@ietf.org; teas-chairs@ietf.orgCc: Bin Yeong Yoon &lt;byyun@etri.re.kr&gt;; Hejia (Jia) &lt;hejia@huawei.com&gt;; Peter Park &lt;peter.park@kt.com&gt;; Italo Busi &lt;italo.busi@huawei.com&gt;Subject: [Teas] Preemption priority in GMPLS signaling for SMP

&nbsp;
Dear TEAS WG,&nbsp;&nbsp;This email is to solicit your opinion on how to implement the preemption priority for GMPLS signaling extentions for Shared Mesh Protection, draft-ietf-teas-gmpls-signaling-smp-04.&nbsp;&nbsp;As described in draft-ietf-teas-gmpls-signaling-smp-04, the preemption priority is to resolve the competition for shared resources among multiple protecting LSPs, when controlled by the Automatic Protection Switching (APS). &nbsp;&nbsp;&nbsp;The authors of this draft would like to define one octet for the preemption priority values and state that a lower value has a higher priority. And the number of priority levels is up to the network operator. We also want to indicate the preemption priority of a protecting LSP in a new field, by shrinking the size of Reserved field, within the PROTECTION object.&nbsp;&nbsp;We would appreciate if you can provide your feedbacks on our proposal above.&nbsp;&nbsp;Best regards,&nbsp;&nbsp;Jeong-dong (on behalf of co-authors)&nbsp;


&nbsp;

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas