Re: [Lsr] [Bier] PCE Controller & SDN Controller & Netconf/Yang NMS Controller - lines blurred and can the names be used ubiquitously meaning the same

Gyan Mishra <hayabusagsm@gmail.com> Fri, 20 November 2020 21:10 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6933A03FA; Fri, 20 Nov 2020 13:10:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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_MESSAGE=0.001, 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 OMKalITUndVT; Fri, 20 Nov 2020 13:10:44 -0800 (PST)
Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 15F5B3A03F8; Fri, 20 Nov 2020 13:10:43 -0800 (PST)
Received: by mail-pg1-x535.google.com with SMTP id t37so8288433pga.7; Fri, 20 Nov 2020 13:10:43 -0800 (PST)
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=HVqPPl4GuzSQxU7gwyD0TqLs2eYORVqviHayiFj0arY=; b=ZvFfHichZ+LAoNwtkXuT2vfjPEHWZPHCosuDJyXeQZQZP0g5dNRxQnCmK4bU5pcQIy +N7aM10+5a6mBIpWgPaNhL8pfyQgIxiG3yNQF/Pv3uwaubEFR+br+DKO5Bjt6nWkpFcG 0IwWfZ/vxuIBvujmwHWam0md2zy8yPAOvEMbubqn77V+ExyoH4U6VA0vVcnNBcVFexcE dttpjp4z9EhOMX5YbL93tArm+7KxB+nCUc4O3yYrXaaT3mqLGG9899zDW3sOfwXSt1/N u6xIxoPkcuN0VCcj2RiUmFsgB1I4ulmeDv7IV4KeAiJMwUj60xq6/0DbqiyqZeCLlDR1 KhFA==
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=HVqPPl4GuzSQxU7gwyD0TqLs2eYORVqviHayiFj0arY=; b=gtLzEDwYJdrwVY8S9MSdaTNxONzrdstxkAle9pCvp+vXvhNlh6JWQ+TbgmFPyXem0E vBBS+ACs13i1YmZfBoEnfJW9SKUFbw7Wqx6P1SvO1ABb/V2g0293gQ1PWYqJaOqP3+DG sxs4nIdRYyC1LxXcHOTINZi5Pb5rfImkTfz1KrneoBd36X10glhKB3rnpOh0saS0pOHH nnxkxxL18flNcmqMSfhNtCZjbr8K4KzLXG3fSQ+jD7F3aLXB3dMc/Z8Cq1cvaGXCxme9 ioSsR2kwo4B18VQs+R03AzawQEbf+3iUNO4iiJOs3Xuf8TkrnUhts1U3f8nXCsGM26hq QTcg==
X-Gm-Message-State: AOAM531DmGVjWmp/KAO6HtOcAP4Jn9VBXiy0q2p6vNguPR7GQUyZRgJf ThaAU9UOGjROpuKygdqopMb/ODZaM3xxsUeovyNqmQCZwNk=
X-Google-Smtp-Source: ABdhPJzwwWXkS/rFf4J7op5wJTVaMEuWkqOiHnwKeT7TGJ7y8e2meuT9G8SMb/AbeNls1rACgw1goGDcVdfL/wIZITQ=
X-Received: by 2002:a65:56c8:: with SMTP id w8mr18687502pgs.383.1605906643271; Fri, 20 Nov 2020 13:10:43 -0800 (PST)
MIME-Version: 1.0
References: <CABNhwV2hACuvVJxQVihP2ejfq1NHKOwxHLCq=_o9DgoWBZag=w@mail.gmail.com> <00d501d6bb47$7ee160a0$7ca421e0$@olddog.co.uk>
In-Reply-To: <00d501d6bb47$7ee160a0$7ca421e0$@olddog.co.uk>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Fri, 20 Nov 2020 16:10:32 -0500
Message-ID: <CABNhwV03n0F2bSpZWfSVhgRnTjSd=drEfrhiP+v2orpsaiKT3w@mail.gmail.com>
To: adrian@olddog.co.uk
Cc: BESS <bess@ietf.org>, BIER WG <bier@ietf.org>, IDR List <idr@ietf.org>, SPRING WG <spring@ietf.org>, TEAS WG <teas@ietf.org>, lsr <lsr@ietf.org>, pce@ietf.org
Content-Type: multipart/alternative; boundary="00000000000003c42c05b490476d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/jioNIkc22eDsQfE_d6hJmd6KRME>
Subject: Re: [Lsr] [Bier] PCE Controller & SDN Controller & Netconf/Yang NMS Controller - lines blurred and can the names be used ubiquitously meaning the same
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Nov 2020 21:10:47 -0000

Hi Adrian,

In line

Kind Regards

Gyan
On Sun, Nov 15, 2020 at 7:04 AM Adrian Farrel <adrian@olddog.co.uk> wrote:

> Hi Gyan,
>
>
>
> Sorry, I missed this (got caught on a filter cos it was a bit spammed to a
> lot of lists :-).
>
>
>
> > I have noticed that after reviewing many drafts across many WGs it seems
> in the
>
> > industry that the lines seem to be blurred between a PCE controller, ODL
> or
>
> > Openflow SDN Controller and a Netconf/Yang NMS Controller ZTP & Day X
>
> > provisioning.
>
>
>
> Yes, blurriness our speciality.
>
>  Gyan> :)
>
> You my find RFC 7491 useful in this respect, although it is a little
> dated. And, of course, RFC 8283 is a good starting point.
>
>  Gyan> Thanks
>
> As this is a software sitting on a server you can have a swiss army knife
> server that
>
> > does everything from PCE path computation to  Netconf/Yang ZTP & Day N
>
> > provisioning as well as any SDN Controller ODL or Openflow controller
> type
>
> > functions as well.
>
>
>
> Yes, and this is one of the risks of PCE as a shiny thing: that it be
> converted from a useful toolkit into some form of god-box. I pontificated
> on this way back in 2014 at http://www.olddog.co.uk/PCEPandOnwards.pdf
>
>  Gyan> My sentiments exactly - With that power at your fingertips comes
> responsibility.
>
> How this comes into play and realization of the lines being blurred is
> the use of
>
> > BGP-LS in building the IGP topological graph of the network which was
> designed
>
> > for PCEP and PCE & PCC active & passive off line path computation for
> both
>
> > RSVP-TE or SR-TE path instantiation.
>
>
>
> In some senses, BGP-LS didn’t add anything because a PCE could have
> snooped on the IGP. But BGP-LS provides an export mechanism and importantly
> adds to that some policy filters to determine what is exported thus giving
> the network some control over what is exported.
>
>  Gyan> Agreed
>
> FWIW, https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/
> proposes using PCEP for the same function. The argument in favor is that a
> PCE has to implement PCEP anyway, so why not include the LS export as well.
> The argument against is that BGP-LS has wider applicability and that it
> will typically be exported from an ASBR which already supports BGP.
>
>  Gyan> Makes sense and in some ways cuts out the middle man BGP-LS
> overloading burden on BGP.  Great idea.  I like it.  Another very valuable
> tool in the operators toolbox.
>
> > However now BGP-LS can also be used for other functions now such as
> usage as
>
> > I am a Shepherd reviewing a draft for BGP-LS usage for BIER to use
> BGP-LS to
>
> > gather the elements internals within BIER using the same BGP-LS data
> structures
>
> > to populate with BIER specific information to graph the BIER topology.
> So here
>
> > we are not doing any path computations as we are using in this use case
> for
>
> > NMS type function to gather data for ZTP & Day N provisioning.
>
> >
>
> > Similarly other use cases such as with TEAS TS-Transport slice and being
> able
>
> > to provision TS and capturing the TS Enhanced VPN RT & resource
> information
>
> > and leveraging BGP-LS to do the same data gathering & ZTP like
> controller style
>
> > provisioning.
>
>
>
> Is there a fundamental difference between ZTP & Day N provisioning and
> path computation for traffic engineering provisioning? It’s all determining
> how to configure the network to best carry traffic.
>
>
>
   Gyan> In my mind the fundamental difference would be TE - control plane
TEDs and forwarding plane routing action path computation and instantiation
of path action as compare to a NMS type Netconf/Yang configuration snippet
push function not routing or TE related.

> > It does seem as though BGP-LS as its a means of "data gathering" "dump
> truck"
>
> > of anything with the kitchen sink included to build any type of
> topological graph
>
> > of literally anything under the sun.
>
>
>
> Remembering Yakov Rekhter saying you could use BGP to transport
> Shakespeare.
>
> This is a tension with any protocol BGP-LS, PCEP, etc., etc. Stuff gets
> added, further use gets made.
>
>  Gyan> Understood
>
> BGP-LS was intended to export routing information “northbound” from the
> network.
>
>  Gyan> Understood
>
> > I see that is a nice to leverage but it does in fact blur the lines of
> NMS Netconf/Yang
>
> > Controller based functionality and  PCE path computation functionality
> and SDN
>
> > controller based ZTP functionality into a single ubiquitous server that
> can do all of
>
> > the above and use BGP-LS to accomplish the "kitchen sink" tasks.  It
> does however
>
> > transform BGP to be an NMS tool but a "tool" and not just the original
> function
>
> > which it was intended NLRI network reachability.
>
>
>
> Not sure that BGP-LS is BGP. But I agree that BGP-LS is “an NMS tool”.
>
> I might argue that BGP distributing policies from installation on PEs is
> an NMS protocol.
>
>  Gyan> Agreed.  One way to look at it is that as BGP primary function is
> routing, however there many code points that are not necessarily routing
> related , and BGP provides the ability to have each code point or SAFI or
> parameters as a discrete container - to be enabled as desired, however with
> that flexibility not all containers have to be used by the operator.  So
> the operator can custom tailor what SAFI, codepoint or parameters are
> required for the implementation per design requirements and only enable
> those that are necessary.  So that would of course be the case for BGP-LS.
> So in that case BGP can be utilized for routing or as an NMS tool extending
> Netconf/Yang via BGP-LS or any other function that requires import of data
> structures.   And that’s Ok.
>
> Am I off base and please let me know as its BGP-LS is being way over
> leveraged.
>
> > There are pros & cons to everything but I thought I would bring up to
> the WG as
>
> > an important discussion point.
>
>
>
> Who are we to argue with real implementations? Assuming that there is a
> push for implementation and deployment, then the thing to look for is
> “harm”. Does this use of BGP-LS cause harm, sow confusion, risk
> destabilising the network? Should it use a different code point to be
> distinguishable?
>
> Gyan> Completely agree.  I agree negative impact if any exist.  See my
> comments above.  As BGP has the ability to compartmentalize SAFI,
> codepoints and parameters into containers to be used discretely for
> specific use cases tailored to the operators need. So it may feel that we
> are throwing the kitchen sink at BGP and as that may not have been the
> intention way back but as BGP is customizable BGP can truly be a ubiquitous
> tool in the operators toolbox.
>
> I think the argument that “there is already another protocol for doing
> this” is worth examining. But we have to be careful that it doesn’t get us
> stuck, or force everyone to do something they don’t want to do. After all,
> we could carry any protocol message using Netconf/YANG, but we don’t do
> “RSVP-TE over Netconf”.
>

   Gyan> Agreed

Many thanks for your feedback!

>
>
> Best,
>
> Adrian
>
>
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD