Re: [Pce] Comments about the LSP Object Flag field

Dhruv Dhody <dhruv.ietf@gmail.com> Mon, 16 September 2019 09:37 UTC

Return-Path: <dhruv.ietf@gmail.com>
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 6943C120810; Mon, 16 Sep 2019 02:37:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 vCUGJGtkhzPq; Mon, 16 Sep 2019 02:37:12 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1CF8120019; Mon, 16 Sep 2019 02:37:12 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id r26so76935569ioh.8; Mon, 16 Sep 2019 02:37:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N3rMwk0zXUUZyJtV3fb0tCSlXgb1lDKppYWmQi0HUTc=; b=M4dHSQeFgKoZmYyGXZ0mN6OCLfmX+JpSMxXsKzJEKTCFlMPSrjkB4/H6pf53gfiK0M zQ/LHIhXotZR1G5vfY1Q7yopI0GfdILtZqX2LeRF7GtaeuobryFxaQt+TDUlm4L9uLyH RuNZoYkT9ws1CDPdjRawCe6UGM+mej2zkdCnkzbhFcPY9C/2ypiY9DWrkP+we3Nw97ec auSdMvEL6/vTIXWCbT+2BYDT3nC0iBLzAW9zBTRNtrhkZ8g1AfwpwfzpAqQd9+yIo8N5 yG41Pimdx3Kp5x9VicNJIwwVC8bgXhQQ7g3FcHR2cP79a7Xo8v3gTTRQ4zrjHeqGRPEZ fgGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N3rMwk0zXUUZyJtV3fb0tCSlXgb1lDKppYWmQi0HUTc=; b=Fje3Ypm1TPnafzzhu+/C/MIvxpVQmhfQLN2hapsKa5yJP9d24g2TRnHzVy8LgM3clp 5Il+LNfOHqNt4JopmpJOqLTc096DDE1LBFggnmZQLw1f0S7f6WjQyYXxZbsutvu2bYsa A5aIiuydABGq5PD9SflfXOnt11CnBdaMod4JeYzJEFDNEtvEbAw+rctfTAgharXhFXHr QoW9Mhvwvher3ksTAmUeK0o0AMWrjc88N55nbH7VgOTb+hVVFOB7h+TMuvgtUWUO5ypg HGAWwgWvenePbbpFcrxp/YSDiz5xPwSvyHPJlw4HF0oN9j02sfnRlvvpVHDaRwBjb4VA w4bA==
X-Gm-Message-State: APjAAAV2dYwTq4WuReMnPhaJiG9IC1U8ofo8v5+XcDlWyEWViie+gDEj n/c1v9U9RqIrDgrcultUYHZFjRshAalVLqSEz4s=
X-Google-Smtp-Source: APXvYqxPJYtYSVW6l+AukhkWvZ+V9+pYLhNYiwBIQdsI2twxtYgsOjFY4DQvOqgfPYcqWfNs//3Xjmm13iMWmfzIWh8=
X-Received: by 2002:a6b:c38f:: with SMTP id t137mr15951781iof.137.1568626631726; Mon, 16 Sep 2019 02:37:11 -0700 (PDT)
MIME-Version: 1.0
References: <201909161642099990442@zte.com.cn>
In-Reply-To: <201909161642099990442@zte.com.cn>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Mon, 16 Sep 2019 15:06:35 +0530
Message-ID: <CAB75xn5oNhRTvJTApZUfQeSb=n=W2bbOXqRfuV5oJeiGb9pu8A@mail.gmail.com>
To: xiong.quan@zte.com.cn
Cc: pce@ietf.org, pce-chairs <pce-chairs@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/QVomd2NJyRn842ZwKLdescQZsPA>
Subject: Re: [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 09:37:15 -0000

Hi Quan,

Thanks for bringing this up.

Hi WG,

I see these options -

1) Leave the last bit in flag field in LSP object as unassigned and
all future allocations in 'LSP-EXTENDED-FLAG TLV'.
2) Mark the last bit as Extended (X) which directs the implementation
to parse the 'LSP-EXTENDED-FLAG TLV'. And all future allocations in
'LSP-EXTENDED-FLAG TLV'.
3) Allocate the last flag in LSP object to the first request and any
other future allocations in 'LSP-EXTENDED-FLAG TLV'.

Thoughts?

The 'LSP-EXTENDED-FLAG TLV' and the associated registry can be created
in an independent document or the first document that is progressed in
the WG that requires the flag.

Thanks!
Dhruv


On Mon, Sep 16, 2019 at 2:12 PM <xiong.quan@zte.com.cn> wrote:
>
>
> 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.
>

I think the path segment is the only one


> 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
>
>