Re: [Pce] Draft -06 available with most WG LC comments addressed//was: WGLC for draft-ietf-pce-vn-association-05

Adrian Farrel <adrian@olddog.co.uk> Fri, 15 April 2022 11:58 UTC

Return-Path: <adrian@olddog.co.uk>
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 9F8513A0C51; Fri, 15 Apr 2022 04:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.904
X-Spam-Level:
X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MAY_BE_FORGED=1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no 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 h9MzZv4PCJCi; Fri, 15 Apr 2022 04:58:55 -0700 (PDT)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 CB44F3A0C4A; Fri, 15 Apr 2022 04:58:51 -0700 (PDT)
Received: from vs4.iomartmail.com (vs4.iomartmail.com [10.12.10.122]) by mta8.iomartmail.com (8.14.7/8.14.7) with ESMTP id 23FBwYIM030757; Fri, 15 Apr 2022 12:58:34 +0100
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D887D46056; Fri, 15 Apr 2022 12:58:33 +0100 (BST)
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B86E546055; Fri, 15 Apr 2022 12:58:33 +0100 (BST)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs4.iomartmail.com (Postfix) with ESMTPS; Fri, 15 Apr 2022 12:58:33 +0100 (BST)
Received: from LAPTOPK7AS653V (205.197.bbplus.pte-ag1.dyn.plus.net [81.174.197.205] (may be forged)) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.7/8.14.7) with ESMTP id 23FBwWFh014765 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 15 Apr 2022 12:58:33 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Zhenghaomian' <zhenghaomian@huawei.com>, 'Dhruv Dhody' <dd@dhruvdhody.com>, pce@ietf.org
Cc: draft-ietf-pce-vn-association@ietf.org, 'pce-chairs' <pce-chairs@ietf.org>
References: <5d86051467124c5d9729587f121babc5@huawei.com>
In-Reply-To: <5d86051467124c5d9729587f121babc5@huawei.com>
Date: Fri, 15 Apr 2022 12:58:31 +0100
Organization: Old Dog Consulting
Message-ID: <0cc401d850c0$21118990$63349cb0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0CC5_01D850C8.82D6B4E0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFsbMKBJ+3ct3P2RngPOjE4xTfVxa3IoltQ
Content-Language: en-gb
X-Originating-IP: 81.174.197.205
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1000-26834.007
X-TM-AS-Result: No--21.217-10.0-31-10
X-imss-scan-details: No--21.217-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1000-26834.007
X-TMASE-Result: 10--21.217400-10.000000
X-TMASE-MatchedRID: Jm7Yxmmj9OnxIbpQ8BhdbI61Z+HJnvsO09la3X7jaybrwoNVYOVcQESi 2ut9sl808kSl1XXlWGcafQZfvyaD9OMAa/S3g8WLNxqr5qtGGJQz0SQBTPKW4V71b3cyy2BjupC V1Tw0TOmEju6+OLyeK+6cICr3BoHtPlW4iFrgB0mXmVAzMqYX0rY7xfWsbKnB0jCYi98uGi3WnN u2/Oq054jtXTM4ySGxDAH5ixtIA6d/s7IOpKdgt1axq6bEGGO0Y/8hgefJn7BYfsHHDgAMI5/vL k4ECKhoNtrqBJtuOX6I40w6RysGJoc7+Qb8+03p/HTKStsDGMK/d317BwwdBxbM9NvE7tH690ib xL4bz6Auy+d2rXUBkptVVeKU/pCr8IMW9dkWZjJh5IuIaxTO+VTizEWrqKARUJ3tU6BsTei0A4L Cx+k0FC/3/XeSSzXhU9IBYcMFyd1akh0Sg+q4f+JOzIOycbNPtPGelsKOu4hfn9s2ECwbJEHSfN 17gSn6zh9/JTWzqEwUAF4uBmvRkR8TzIzimOwPgxsfzkNRlfIDOZGFGsyhFbDszp3K5gqDAqYBE 3k9Mpw=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/AUV0-XyXIaCrwyU7xESsOVy65C8>
Subject: Re: [Pce] Draft -06 available with most WG LC comments addressed//was: WGLC for draft-ietf-pce-vn-association-05
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: Fri, 15 Apr 2022 11:59:00 -0000

Thanks Haomian,

 

Looking good.

 

Cut down to just a few open points.

 

Best,

Adrian

 

4. (for VIRTUAL-NETWORK-TLV)

 

   Length: Variable Length

 

Length of what and in what units?

Just the Virtual Network Name or the whole TLV?

Probably in octets.

What is the maximum allowed value? Surely not 2^16.

[Haomian]  propose as follow: 

 

OLD: 

Length: Variable Length

 

NEW:

Length: Variable Length, which covers all the Virtual Network Identifiers.

 

END

 

Was hoping for (if I have it right)…

Length: The length in octets of the Virtual Network Identifier, not including the Type or Length field.

 

BTW, is it a MUST to have a maximum value?

 

No, there is no such requirement. However, without setting one, you allow the Virtual Network Identifier to by 2^16 bytes long which would, I think, probably break the PCEP message.

 

Often, fields like this are limited to 255 bytes or something like that. But it can be let completely open so that the implementation can trade this field off against other message fields.

 

---

 

4.

 

How does internationalization work for the Virtual Network Name?

Why is ASCII acceptable?

[Haomian] not changed, looking for future advice. My personal taking is ‘all ASCII should find the same processing rule for internationalization’. 

 

OK. You could send a message to the internationalisation directorate ( <mailto:i18ndir@ietf.org> i18ndir@ietf.org) to ask for advice, or you could leave this as it is and see whether the ADs have any concerns.

 

---

 

4.

 

Does the Virtual Network Name need to be unique across all VNAGs? I

suspect that it doesn't because its use is basically out of scope of

this work.

[Haomian]  propose as follow: 

OLD: 

Virtual Network Name (variable): an unique symbolic name for the VN.

NEW:

Virtual Network Identifier (variable): an symbolic name for the VN that is unique in this TLV.

END

 

OK, that is clear.

s/an/a/