Re: [Pce] draft-dhodylee-pce-pcep-ls next steps!

Gyan Mishra <hayabusagsm@gmail.com> Sun, 18 July 2021 14:47 UTC

Return-Path: <hayabusagsm@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 DF4A83A0B91; Sun, 18 Jul 2021 07:47:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 9Zpnorq39d35; Sun, 18 Jul 2021 07:47:22 -0700 (PDT)
Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 15D8F3A0B92; Sun, 18 Jul 2021 07:47:21 -0700 (PDT)
Received: by mail-pj1-x102a.google.com with SMTP id jx7-20020a17090b46c7b02901757deaf2c8so10270693pjb.0; Sun, 18 Jul 2021 07:47:21 -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=IDmcyzXYW/HxCY9pdVsIMNVyLuKpZ4lYYZLwc1Y+ReY=; b=fOgrLCRYGLuv6zeXrU+LoQm2w4X2XQix4JcPVMRAWrqcKZTk1mQFXyI2oFVADMtlkj Zyqp+GWPSUj7n7/nSfueMAQAzqh5CE6mGSSVXv+ER/D6LATmWn9R/AMjt5laoFev69fU HONi6/SjARSXipdudYNbR9Q3VBF1J0gNvAdizHzZKs95O5G8v+SQ/kC4hXY59Js2Fd4U s8X/vf2OVnK9mYmmHVGUCqqNR5cM9tqB+IKlY81GGidHxlNkIIYhxQeT7xm9OMM2HmWt A6mmkwpI8WxDf2dM0WwTQuzvv8Ss+cZiONhlnyz2p+aQzCdElaG7pKt2TBnBwqLx87X0 0arA==
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=IDmcyzXYW/HxCY9pdVsIMNVyLuKpZ4lYYZLwc1Y+ReY=; b=kXi5bVdfCDgoNuAhKV/IeFCIWP9DXUZTbLie9sbXJt4AiHamDwI+cOoA+ILxzyzLTk AzAKdH0nAfqpF9stVh1kdbiAoEs6IndN5Xh+SmqRQCZ/X5BqsbbVITDqOmDZ5zq2+bMR r0L4W5DA1kFhmgdyBCGdQSJhnDmht9fV3ctk8vP60SnEZTUn26B9lmXmJZWd4H9XJrJy RVMnagkKfpOUatSTBuX5LMOXAVyK/fOC52y6BCOh7V0vr40R5DmNeqGhm0v1CO/KVfdq 2XMtnYlQ7RMLOk0A1UBboXnLje4eG+2wgAsKGX5WtuiEhdbpZvbXGjUmhmGfA3QRWz3r Yb0Q==
X-Gm-Message-State: AOAM533NKTXbfhL5rgVtOro+fgpLFwPu2RWvqaqTk4VQ2+0IAC8OSMbv SClGeaB24zaCQ50X8D89z3AJ97Qw+j9Ai0BqJUc=
X-Google-Smtp-Source: ABdhPJzMsHaAkEyF6GuyrzNVkaL8IYWUgB43OIMgYOqqQaRjQXkrYE6yOGfHuMzRJy2FS1jZiOyC0oYyJtkPufyHS5E=
X-Received: by 2002:a17:90a:9914:: with SMTP id b20mr19492993pjp.112.1626619640543; Sun, 18 Jul 2021 07:47:20 -0700 (PDT)
MIME-Version: 1.0
References: <CABNhwV1hby7ap3DWQzxB2aV+ggVCeuDL89SNfaMA6RH0XiC8sQ@mail.gmail.com> <CANJFx2SJYNn9uTdR4KxVnAM=rpygJXVniVeeWdwZp+20+5nQrA@mail.gmail.com>
In-Reply-To: <CANJFx2SJYNn9uTdR4KxVnAM=rpygJXVniVeeWdwZp+20+5nQrA@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sun, 18 Jul 2021 10:47:09 -0400
Message-ID: <CABNhwV3x9kGxuvyw6N8-w5WY4k99PPshTR92w+w0jKeve8NZOQ@mail.gmail.com>
To: Siva Sivabalan <msiva282@gmail.com>
Cc: Adrian Farrel <adrian@olddog.co.uk>, Dhruv Dhody <dd@dhruvdhody.com>, "draft-dhodylee-pce-pcep-ls@ietf.org" <draft-dhodylee-pce-pcep-ls@ietf.org>, pce-chairs <pce-chairs@ietf.org>, "pce@ietf.org" <pce@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000dbfc9905c766e5f3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/agFe7J7g1rdN3QDI6rTic3IM4dg>
Subject: Re: [Pce] draft-dhodylee-pce-pcep-ls next steps!
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: Sun, 18 Jul 2021 14:47:27 -0000

Hi Siva

Many thanks for your support and responding to WG poll sent for interest in
progressing research and development efforts of this work as as an
experimental draft.

Yes that is one of the main R=0 goals and use cases to be able to reuse the
existing PCECC CCI object SDN (SDN-like) SBI session for PCEP-LS, thereby
eliminating the needs for another protocol in this case BGP-LS NBI for that
purpose.  That is the main goal and use case and very nicely pointed out
Siva.

This draft does provide the nice flexibility as well if operators are not
yet using PCECC for R=1, to allow for mixed environments and cater to the
operators needs and requirements.  We want to emphasize that we are not
trying to by any means compete with the other existing solutions but rather
provide operators another valuable tool in the operators toolbox.

As part of the next steps in building the framework for the scope of the
experiments performed the to prove out any scalability concerns and impact
to other protocols namely the reuse aspect of the SBI.

We would like to prove out that this solution is solid and viable in the
tests and that the reuse of the SBI in fact provides improves scalability
rather than diminishing scalability by leveraging the R=0 existing sessions
between all nodes versus PCEP PCE R=1.  We would also like to prove out in
the experiment that we are in fact not overloading the SBI by the reuse for
PCEP-LS and in no way impacting the existing SBI PCECC PCE session.

We would like to address in the experiment any and all scalability,
overload, collateral damage related issues  or any fear or issues anyone
has to prove that this is a solid and viable solution on par with the other
existing solutions as an extra tool in the operators toolbox.


Kind Regards

Gyan

On Sun, Jul 18, 2021 at 8:43 AM Siva Sivabalan <msiva282@gmail.com> wrote:

> Hi Gyan,
>
> I support this experimental work. If a router communicates with PCE over
> PCEP for path computation purpose, it might as well propagate topology via
> PCEP eliminating the need for another protocol for that purpose. The lesser
> the number of protocols, the better for simplifying network operation.
>
> Thanks,
> Siva
>
>
> On Mon, Jul 5, 2021 at 2:43 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:
>
>>
>> Dear PCE WG,
>>
>>
>> We presented the PCEP-LS [1] I-D [2] in the IETF 110 with a quick recap
>> and a summary of past discussions. Some new scenarios such as PCECC, H-PCE
>> were highlighted where the PCEP session could be reused.
>>
>>
>> This is an experimental I-D with the aim to progress research and
>> development efforts. This work is not a replacement for any of the existing
>> mechanisms. There are specific scenarios highlighted where the reuse of
>> PCEP sessions for this information is deemed useful. To make progress, it
>> may not be useful to rehash the beauty context between everyone's favorite
>> protocol :). What would be useful would be - finding out if there is still
>> interest in this experimental work by some in the WG; are there strong
>> technical objections for the experiment in its limited scope etc...
>>
>>
>> As a next step, it would be good to define the scope of the experiments
>> and expected output especially targeting the scalability concerns as well
>> as impact in other protocols and the network, etc.
>>
>>
>> From the last query on this draft March 18th we received positive
>> feedback from Aijun Wang with China Telecom mentioned that as a telco are
>> interest in deploying in their network PCEP-LS once the Huawei
>> implementation is ready.  Aijun pointed out in the thread that using this
>> draft simplifies the implementation of SDN controller.  One question asked
>> by Aijun was related to section 9.2.1 LS Capability TLV R=1 remote allowed
>> meaning hybrid mode to provide flexibility for operators not yet using SDN
>> (SDN-like) SBI.  For any operators already using PCEP as SDN (SDN-like)
>> SBI, a direct PCEP session already exist between all the nodes in the
>> network and the PCE which would be the PCECV SDN scenario in which case the
>> R flag in the open message is set to 0.
>>
>>
>> We also received positive feedback from Peter Park with telco KT
>> regarding interest in PCEP-LS.
>>
>>
>> We also had feedback from Bin as they have implemented PCEP and have
>> interest in this experimental implementation of this work.
>>
>>
>> I would like to poll the WG again for interest in progressing research
>> and development efforts of this draft as experimental.
>>
>>
>> As stated in the last WG poll, I would like get feedback from the WG on
>> scope of experiments especially related to scalability concerns and impact
>> to other protocols on the network.
>>
>>
>> Thanks!
>>
>> Gyan (on behalf of co-authors)
>>
>>
>> [1]
>> https://datatracker.ietf.org/meeting/110/materials/slides-110-pce-42-pcep-ls-00.pdf
>>
>> [2] https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/
>>
>> ==
>>
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions Architect *
>>
>> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>>
>> *M 301 502-1347*
>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>>
>>
>>
>> *M 301 502-1347*
>>
>> _______________________________________________
>> Pce mailing list
>> Pce@ietf.org
>> https://www.ietf.org/mailman/listinfo/pce
>>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*



*M 301 502-1347*