[Teas] Preemption priority in GMPLS signaling for SMP

Jeong-dong Ryoo <ryoo@etri.re.kr> Wed, 28 October 2020 14:37 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 E96C23A09CC for <teas@ietfa.amsl.com>; Wed, 28 Oct 2020 07:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.9
X-Spam-Level: *
X-Spam-Status: No, score=1.9 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 L21HKhdBsxPf for <teas@ietfa.amsl.com>; Wed, 28 Oct 2020 07:37:44 -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 0DF813A09D1 for <teas@ietf.org>; Wed, 28 Oct 2020 07:37:43 -0700 (PDT)
Received: from unknown (HELO send002-relay.gov-dooray.com) (211.180.235.153) by 129.254.9.16 with ESMTP; 28 Oct 2020 23:37:32 +0900
X-Original-SENDERIP: 211.180.235.153
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 send002-relay.gov-dooray.com with SMTP id cc8946fc5f998234; Wed, 28 Oct 2020 23:37:40 +0900
DKIM-Signature: a=rsa-sha256; b=FrE/J8eN6+d97CFNTLBRvFXlb7lUV0U9Ja+NDU8z1aTVQwqZ64Y8an2CTbw8ubE8UQfnCbrf71 9KcN9mEyDZ8YTdgCmV2I4qeZSMr+MW0wx2uT5pMOFRs8eHNhjN6Rm0oCZjBJvsgo2h/eW5nmT4lu VsWEPG4Z0RLz5wI77S5w/wB/Bu904zsQJh3rxz2YtvsqbQbi2A843hMzOJCFhLFy/HO8P2X5F+NZ sPEioAOsvvc6f4kqYv/mg57U7y21meTP+0m5jEmBtTHe4mgm2rHBkLUMLeZ62qOIPcrmZXCDaQ87 rNP+uLHm9hbdIQU1gPz+mgEdWcl8XlRtpB3tIrTQ==; c=relaxed/relaxed; s=selector; d=dooray.com; v=1; bh=RsmLdVLW5nTzK9qZ/07CLu/LL3j5/u4LIpc5AiTXm8s=; h=From:To:Subject:Message-ID;
From: Jeong-dong Ryoo <ryoo@etri.re.kr>
To: teas@ietf.org, teas-chairs@ietf.org
Message-ID: <lrqnh3lvdj0s.lrqnh3lsvtle.g1@dooray.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_272114_1786522244.1603895858973"
X-Dsn-Request: true
X-Dooray-Agent: mail-api
X-Dooray-Mail-Id: 2865478843014186124
Importance: Normal
X-Priority: Normal
X-MSMail-Priority: Normal
Cc: "Hejia (Jia)" <hejia@huawei.com>, Italo Busi <italo.busi@huawei.com>, Peter Park <peter.park@kt.com>, Bin Yeong Yoon <byyun@etri.re.kr>
Date: Wed, 28 Oct 2020 23:37:39 +0900 (KST)
Sender: ryoo@etri.re.kr
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Y62Fd3gaCjF98bU7DeFsK20ydyA>
Subject: [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: Wed, 28 Oct 2020 14:37:46 -0000

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;