[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
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, 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. 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). 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. We would appreciate if you can provide your feedbacks on our proposal above. Best regards, Jeong-dong (on behalf of co-authors)
- [Teas] Preemption priority in GMPLS signaling for… Jeong-dong Ryoo
- Re: [Teas] Preemption priority in GMPLS signaling… Adrian Farrel
- Re: [Teas] Preemption priority in GMPLS signaling… Jeong-dong Ryoo
- Re: [Teas] Preemption priority in GMPLS signaling… Adrian Farrel
- Re: [Teas] Preemption priority in GMPLS signaling… Jeong-dong Ryoo