Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

"Chengli (Cheng Li)" <c.l@huawei.com> Sat, 27 March 2021 01:45 UTC

Return-Path: <c.l@huawei.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 B64EA3A19B4; Fri, 26 Mar 2021 18:45:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 lbZxr2senmva; Fri, 26 Mar 2021 18:45:34 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D18953A19B2; Fri, 26 Mar 2021 18:45:33 -0700 (PDT)
Received: from fraeml708-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4F6hJf3tfJz683Yp; Sat, 27 Mar 2021 09:36:34 +0800 (CST)
Received: from dggpemm500003.china.huawei.com (7.185.36.56) by fraeml708-chm.china.huawei.com (10.206.15.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Sat, 27 Mar 2021 02:45:28 +0100
Received: from dggpemm500003.china.huawei.com (7.185.36.56) by dggpemm500003.china.huawei.com (7.185.36.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Sat, 27 Mar 2021 09:45:26 +0800
Received: from dggpemm500003.china.huawei.com ([7.185.36.56]) by dggpemm500003.china.huawei.com ([7.185.36.56]) with mapi id 15.01.2106.013; Sat, 27 Mar 2021 09:45:26 +0800
From: "Chengli (Cheng Li)" <c.l@huawei.com>
To: "Stone, Andrew (Nokia - CA/Ottawa)" <andrew.stone@nokia.com>, "julien.meuric@orange.com" <julien.meuric@orange.com>, "pce@ietf.org" <pce@ietf.org>
CC: "draft-ietf-pce-binding-label-sid@ietf.org" <draft-ietf-pce-binding-label-sid@ietf.org>
Thread-Topic: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)
Thread-Index: AQHXG+caJnUYRqZeiUCqBl16P0lEgaqLPNKAgApf6JCAAITbgIAA/C9w
Date: Sat, 27 Mar 2021 01:45:26 +0000
Message-ID: <be741e7913304da8a3afd9b1f3cbd1fb@huawei.com>
References: <7010_1616065722_605334BA_7010_19_1_3f1d8d24-af98-f962-95ea-0e6ec46b738c@orange.com> <375C800D-2014-4D14-830E-0D15439B9F20@nokia.com> <a2f9686490a34a39af5f977cf59230b7@huawei.com> <B3B06655-1F99-416A-AF8F-9FA53E6DB0BB@nokia.com>
In-Reply-To: <B3B06655-1F99-416A-AF8F-9FA53E6DB0BB@nokia.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.243.130]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/MSehhnENiWuKW2lwgDkZcGebfm0>
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)
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: Sat, 27 Mar 2021 01:45:39 -0000

Thanks again for your help!

Cheng



-----Original Message-----
From: Stone, Andrew (Nokia - CA/Ottawa) [mailto:andrew.stone@nokia.com] 
Sent: Saturday, March 27, 2021 2:42 AM
To: Chengli (Cheng Li) <c.l@huawei.com>om>; julien.meuric@orange.com; pce@ietf.org
Cc: draft-ietf-pce-binding-label-sid@ietf.org
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

Hi Cheng,

Thanks for clarifying the text in the document. Diff content looks good to me, much clearer. Consider my comments resolved.

Thanks!
Andrew

On 2021-03-25, 10:49 PM, "Pce on behalf of Chengli (Cheng Li)" <pce-bounces@ietf.org on behalf of c.l@huawei.com> wrote:

    Hi Andrew, 

    Thanks for your comments, please see my reply inline.

    Also, the diff is attached.

    Respect,
    Cheng




    -----Original Message-----
    From: Stone, Andrew (Nokia - CA/Ottawa) [mailto:andrew.stone@nokia.com] 
    Sent: Saturday, March 20, 2021 4:21 AM
    To: julien.meuric@orange.com; pce@ietf.org
    Cc: draft-ietf-pce-binding-label-sid@ietf.org
    Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

    Hi all,

    Overall Support WGLC. It's an important document in the world of SRTE, and the document goes to good lengths to describe the various scenarios and combinations. 

    Only one question I have for the authors and WG, for any further clarification on the following text (section 4):


      The absence of TE-PATH-BINDING TLV in PCUpd message
       means that the PCE does not specify a binding value in which case the
       binding value allocation is governed by the PCC's local policy.


    I find the "governed by PCC local policy" a bit too vague and could lead to implementation interop differences. Assuming a PCInitiated LSP that been established with a BSID: If the PCE wants to withdraw the binding SID , I interpret the document as the PCE would send a PCUpdate without the TLV, but the behaviour is now up to PCC as per that text. if the PCC local policy/implementation is to do nothing, how can the PCE explicitly force-remove the BSID with a PCUpdate? In a similar manner, If the PCE does not want to change the value but PCC local policy is to treat missing TLV as remove, then PCE should always send the TLV in every PCUpdate (which I'm okay with) which is not stated, otherwise the local policy/implementation may interpret it as a removal compared to an implementation which may interpret it as being okay to not send the TLV on every PCUpdate since there was "no change". 

    In summary: might need a bit of a wording to further detail "PCE wishes to withdraw" case. 

    [Cheng] You are correct, there was some issues with multiple TE-PATH-BINDING TLV. This has been updated. See the diff.

    The above text has been updated to - 

       The absence of TE-PATH-BINDING TLV in PCUpd message means that the
       PCE does not specify a binding value in which case any previous
       allocated binding values are withdraw.

    Further, the PCC's local policy aspect has been seperated out as - 

       In the absence of any instruction from the PCE, the PCC's local
       policy dictates how the binding allocations are made for a given LSP.

    Thanks!


    Thanks! 
    Andrew

    On 2021-03-18, 7:09 AM, "Pce on behalf of julien.meuric@orange.com" <pce-bounces@ietf.org on behalf of julien.meuric@orange.com> wrote:

        Hi all,

        This message initiates a 2-week PCE WG Last Call for
        draft-ietf-pce-binding-label-sid-07. Please review and share your
        feedback, whatever it is, using the PCE mailing list. This WGLC will end
        on Thursday April 1st (no kidding).


        Moreover, we have received a request from the authors for a code point
        allocation to support interoperability testing.

        RFC 7120 requires to meet the following criteria to proceed:

        b. The format, semantics, processing, and other rules related to
        handling the protocol entities defined by the code points
        (henceforth called "specifications") must be adequately described
        in an Internet-Draft.
        c. The specifications of these code points must be stable; i.e., if
        there is a change, implementations based on the earlier and later
        specifications must be seamlessly interoperable.

        If anyone believes that the draft does not meet these criteria, or
        believes that early allocation is not appropriate for any other
        reason, please send an email to the PCE mailing list explaining why. If
        the chairs hear no objections by Thursday, March 25th, we will kick off
        the "early" allocation request.

        Thanks,

        Dhruv & Julien


        _________________________________________________________________________________________________________________________

        Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
        pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
        a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
        Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

        This message and its attachments may contain confidential or privileged information that may be protected by law;
        they should not be distributed, used or copied without authorisation.
        If you have received this email in error, please notify the sender and delete this message and its attachments.
        As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
        Thank you.

        _______________________________________________
        Pce mailing list
        Pce@ietf.org
        https://www.ietf.org/mailman/listinfo/pce