IETF Logo Mail Archive

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

Adrian Farrel <adrian@olddog.co.uk> Wed, 28 October 2020 20:59 UTC

Return-Path: <adrian@olddog.co.uk>
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 EC9623A03F2; Wed, 28 Oct 2020 13:59:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 GJ5YX2kAQ6Nl; Wed, 28 Oct 2020 13:59:50 -0700 (PDT)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E36203A011B; Wed, 28 Oct 2020 13:59:48 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 09SKxZod028628; Wed, 28 Oct 2020 20:59:35 GMT
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4F5662203A; Wed, 28 Oct 2020 20:59:35 +0000 (GMT)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS id 3990F22032; Wed, 28 Oct 2020 20:59:35 +0000 (GMT)
Received: from LAPTOPK7AS653V (81-174-211-216.pth-as4.dial.plus.net [81.174.211.216]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 09SKxXP4011438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 28 Oct 2020 20:59:34 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Jeong-dong Ryoo' <ryoo@etri.re.kr>, teas@ietf.org, teas-chairs@ietf.org
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>
References: <lrqnh3lvdj0s.lrqnh3lsvtle.g1@dooray.com>
In-Reply-To: <lrqnh3lvdj0s.lrqnh3lsvtle.g1@dooray.com>
Date: Wed, 28 Oct 2020 20:59:34 -0000
Organization: Old Dog Consulting
Message-ID: <068a01d6ad6d$3da74060$b8f5c120$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_068B_01D6AD6D.3DA7DCA0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKgdNtYyppxsbrff5h/ThSlSWAtsagZ71JA
Content-Language: en-gb
X-Originating-IP: 81.174.211.216
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25754.002
X-TM-AS-Result: No--26.051-10.0-31-10
X-imss-scan-details: No--26.051-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25754.002
X-TMASE-Result: 10--26.051400-10.000000
X-TMASE-MatchedRID: HLMPCFyIyBPxIbpQ8BhdbGyGdbpKa3Zsqb3/o5s+OcO9K1jOJyKSa8Y3 yfovp2x0dsMzI991nVNBi6woqdJeivVZEoTxkSletKV49RpAH3t4PXLLrqnAoBdj6A1O5s5AtlQ oKcURlm5QEui0XhcW/peKYk3RPxO68eA/CsXTGsuJ8gcTogWcPlG+BHSGRsbg2+Avsq/zL0E2SE Ea6XGfm1J5R3CC0+bWCNO4jCWnm2xc2mxBgRVxqWbkaV5im3ecBnIRIVcCWN9Gpg/nZAuJ/R/16 4dzHy5iqiZ5g+lHKlDWfeshm/rRpYsCIQRLajognMQdNQ64xffT1G7ME+dqdEdmDSBYfnJRKy5g TtsBLaT2O7FCVNcUTnHEJ1xSA8bd3HON1VLzA8DvVbHa5Rs8t0OvwxWboMrdu/zUE1SNSPnMRUM adz4R8pqEb+LwlrVjt1gVV8hFpdKcw7JdiVDKn6ygL0j4rnch6qG5M9QNAO3Nyg/q1m6rcUk+6z qv9h+6W3I0dGGaO1+JcVxfW4YddSxLt17m0r0BMTTrAcDX5/5dxx6WRf+5sCcFM9Xjxbz/UdfEK c10rU75B8XGyV5ZNyqFmu/h/tw77k0KvrVDNPCVUcz8XpiS9CXdp9l6EkRZ55TSoW/nwH4yBdbG TflgF1UUXBciUoEBzqrIDMjfu3uFZ5NatKgouF67ppG3mtjJGEfoClqBl84452hx28rHFQpACfG toeF/EoVm8wZnvfQMW4XCGtaGVNLvsKjhs0lda9+JVKonO7cESmAu8to/E7WEKBcHbEMfBEAUhu 52t8h/A75FGmxK1XkguuQorcgMVlb4rbylyLK+2ljjg1v2iDPSYP4R2MVL8nUtssavzvV+3Bndf XUhXQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/CdtWw9zAsieyOeK1Ob11LJmcp_0>
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: Wed, 28 Oct 2020 20:59:53 -0000

Hey Jeong-dong,

 

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?

 

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.

 

Best,

Adrian

 

 

 

From: Teas <teas-bounces@ietf.org> On Behalf Of Jeong-dong Ryoo
Sent: 28 October 2020 14:38
To: teas@ietf.org; teas-chairs@ietf.org
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>
Subject: [Teas] Preemption priority in GMPLS signaling for SMP

 

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)

v2.30.2 | Report a Bug | By Email | System Status