[Pce] Comments about the LSP Object Flag field

<xiong.quan@zte.com.cn> Mon, 16 September 2019 08:42 UTC

Return-Path: <xiong.quan@zte.com.cn>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF1712002E; Mon, 16 Sep 2019 01:42:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.58
X-Spam-Level:
X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 6IEa3lNbDV7u; Mon, 16 Sep 2019 01:42:28 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 952FE12003F; Mon, 16 Sep 2019 01:42:28 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.164.217]) by Forcepoint Email with ESMTPS id 7F7499747E0E7AAC4D96; Mon, 16 Sep 2019 16:42:26 +0800 (CST)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 5E10DC0CE415935C5DF4; Mon, 16 Sep 2019 16:42:26 +0800 (CST)
Received: from njxapp05.zte.com.cn ([10.41.132.204]) by mse-fl2.zte.com.cn with SMTP id x8G8gA13077894; Mon, 16 Sep 2019 16:42:10 +0800 (GMT-8) (envelope-from xiong.quan@zte.com.cn)
Received: from mapi (njxapp05[null]) by mapi (Zmail) with MAPI id mid201; Mon, 16 Sep 2019 16:42:10 +0800 (CST)
Date: Mon, 16 Sep 2019 16:42:10 +0800
X-Zmail-TransId: 2afd5d7f4ae2eeccff67
X-Mailer: Zmail v1.0
Message-ID: <201909161642099990442@zte.com.cn>
Mime-Version: 1.0
From: xiong.quan@zte.com.cn
To: pce@ietf.org
Cc: pce-chairs@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn x8G8gA13077894
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/Mdkt9knRNZOjHNZCTSKUwPIRmIM>
Subject: [Pce] Comments about the LSP Object Flag field
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 08:42:31 -0000

Hi all,




As defined in [RFC8231], the length of LSP Object Flag field is 12 bits and it defined the value from bit 5 to bit 11.  

The bits from 1 to 3 are defined in [RFC8623] and the bit value 4 is used in [RFC8281]. So all bits of the flag has been occupied as the following shown.









I noticed many other drafts have extended the flag, for example, draft-li-pce-sr-path-segment defined a new P bit.

But no unused bit can be assigned for it. So I propoese  a new LSP-EXTENDED-FLAG TLV for LSP object to extend the

 length of the flag as the following shown.

        0                            1                            2                           3

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                    Type=TBD             |                    Length                   |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                                    Extended Flag                                         |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




What is ypur opnion? Do you have other suggestions?





Thanks,

Quan