Re: [Pce] WG adoption poll for draft-sivabalan-pce-binding-label-sid-07

Khasanov Boris <khasanov.boris@huawei.com> Wed, 21 August 2019 07:10 UTC

Return-Path: <khasanov.boris@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 7F64A120220; Wed, 21 Aug 2019 00:10:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 x3Z2OIBYutRY; Wed, 21 Aug 2019 00:10:00 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 09705120122; Wed, 21 Aug 2019 00:10:00 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id ED141CA01CDD63F06AA1; Wed, 21 Aug 2019 08:09:57 +0100 (IST)
Received: from LHREML505-MBS.china.huawei.com ([169.254.1.179]) by lhreml705-cah.china.huawei.com ([10.201.108.46]) with mapi id 14.03.0415.000; Wed, 21 Aug 2019 08:09:53 +0100
From: Khasanov Boris <khasanov.boris@huawei.com>
To: Dhruv Dhody <dhruv.ietf@gmail.com>, "pce@ietf.org" <pce@ietf.org>
CC: pce-chairs <pce-chairs@ietf.org>
Thread-Topic: [Pce] WG adoption poll for draft-sivabalan-pce-binding-label-sid-07
Thread-Index: AQHVV39E7J1jXgmla0qLHENd0HUg0KcFKKzw
Date: Wed, 21 Aug 2019 07:09:52 +0000
Message-ID: <C7794D4A32C7D046B93DBCF0FA202C182E823A7E@lhreml505-mbs.china.huawei.com>
References: <CAB75xn44Q8Y_eeGDfV+ecojJt0gKd9zHU4B7V0Xn_PYneCQAeg@mail.gmail.com>
In-Reply-To: <CAB75xn44Q8Y_eeGDfV+ecojJt0gKd9zHU4B7V0Xn_PYneCQAeg@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.198.247.151]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/pPxxZmqYyiCLw2lJAhVDT9M8K_w>
Subject: Re: [Pce] WG adoption poll for draft-sivabalan-pce-binding-label-sid-07
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, 21 Aug 2019 07:10:03 -0000

Hi Dhruv and all,

Yes, I personally support the adoption of this draft.

Additionally to a pre-adoption review, few questions to authors for a thinking during next version preparation (sorry if I missed earlier discussion about this).

The draft says:
" A PCC could report the binding label/SID allocated by it to the
   stateful PCE via Path Computation State Report (PCRpt) message.  It
   is also possible for a stateful PCE to request a PCC to allocate a
   specific binding label/SID by sending an Path Computation Update
   Request (PCUpd) message.
...
Additionally, to support the PCE based central controller [RFC8283]
   operation where the PCE would take responsibility for managing some
   part of the MPLS label space for each of the routers that it
   controls, the PCE could directly make the binding label/SID
   allocation and inform the PCC."

In case of PCE based central controller {RFC8283] when PCECC is responsible for label allocation it is quite clear - how we could optimally use a Binding SID, PCE knows everything and knows where to use Binding SID so it can 'force' needed PCCs to allocate it via PCUpd  as it is mentioned in the draft. or provision a  Binding SID in centralized mode.

But what about our traditional distributed case, for example, how Gateway Node 1 (Fig.1 in the draft) would understand that he should allocate a Binding SID towards PCE?
What will trigger that ? 
Should Gateway Node 1 analyze capabilities of Access node (Maximum SID depth) and make an assumption that it could need a Binding SID?

IMO, we should think and try to propose some mechanism (besides relying on PCE central controller)  for distributed case to let PCC know that he should create Binding SID and report it to PCE.

Thank you.

SY,
Boris

 -----Original Message-----
From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Dhruv Dhody
Sent: Tuesday, August 20, 2019 8:45 PM
To: pce@ietf.org
Cc: pce-chairs <pce-chairs@ietf.org>
Subject: [Pce] WG adoption poll for draft-sivabalan-pce-binding-label-sid-07

Hi WG,

This email begins the WG adoption poll for
draft-sivabalan-pce-binding-label-sid-07 [1].

Should this draft be adopted by the PCE WG? Please state your reasons - Why / Why not? What needs to be fixed before or after adoption? Are you willing to work on this draft? Review comments should be posted to the list.

One of the chairs did a pre-adoption review [2] and authors posted a new revision. Note that there are known implementations.

This adoption poll will end on 6th September 2019.

Thanks!
Dhruv (for the chairs)


[1] https://tools.ietf.org/html/draft-sivabalan-pce-binding-label-sid-07
[2] https://mailarchive.ietf.org/arch/msg/pce/oaBIRA9FnNsV6-JrKKRCdwtLysk

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