[Pce] cursory review of draft-xiong-pce-lsp-flag

Loa Andersson <loa@pi.nu> Wed, 29 July 2020 08:07 UTC

Return-Path: <loa@pi.nu>
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 04B6E3A10A3; Wed, 29 Jul 2020 01:07:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ruYOBeyX7j_S; Wed, 29 Jul 2020 01:07:19 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 014B33A10D1; Wed, 29 Jul 2020 01:07:14 -0700 (PDT)
Received: from [192.168.1.19] (unknown [122.2.101.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id A9B3C326A46; Wed, 29 Jul 2020 10:07:11 +0200 (CEST)
To: draft-xiong-pce-lsp-flag@ietf.org, "pce-chairs@ietf.org" <pce-chairs@ietf.org>
From: Loa Andersson <loa@pi.nu>
Cc: "pce@ietf.org" <pce@ietf.org>
Message-ID: <138eecce-8db7-90da-d6e8-b006ee4ddc8e@pi.nu>
Date: Wed, 29 Jul 2020 16:07:07 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/uN9P0WDkaNTAMiPgd7dWJ6y8o5U>
Subject: [Pce] cursory review of draft-xiong-pce-lsp-flag
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: Wed, 29 Jul 2020 08:07:25 -0000

Quan,

I have not done a comprehensive review of the document, but from what I
see it is a well written and much needed document. I would advice to run 
the working group adoption poll as soon as possible.

I have one comment and one question.

Comment:

5.2.  PCEP-Error Object

    IANA is requested to register the following error types and error
    values within the "PCEP-ERROR Object Error Types and Values"
    subregistry of the "Path Computation Element Protocol (PCEP) Numbers"
    registry:

           +--------------+-------------------------------------+
           |  Error-Type  |  Meaning                            |
           +--------------+-------------------------------------+
           |  6           |  Mandatory Object missing           |
           |              |  Error-value                        |
           |              | TBD2: LSP-EXTENDED-FLAG TLV missing |
           +--------------+-------------------------------------+

                                   Table 2

Both the RTG DIR rules and IANA rules strongly advice against putting
fixed numeric  values into allocation from existing registries. The
reason is obvious, in the time from you put the value in your document
until iet is ready for IESG review (which includes IANA review) someone
else might have been assigned tht value. This has happened and have
caused serious problems.

6 in table 2 hould be replaced with TBA (to be assigned).

Note: If you really want the value 6, we should go for an early
allocation as soon as we have the wg document.

Question:

In section 4 you say:

    The LSP-EXTENDED-FLAG TLV MUST be defined as mandatory when a router
    supporting the LSP Object and needs to use the extended flag field.

I don't really parse; are you saying that if it is present it should be
treated as mandatory?

If that is what you are saying, what does it change?

/Loa


-- 

Loa Andersson                        email: loa@pi.nu
Senior MPLS Expert                          loa.pi.nu@gmail.com
Bronze Dragon Consulting             phone: +46 739 81 21 64