Re: [Idr] [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: idr@ietfa.amsl.com
Delivered-To: idr@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/idr/-IHYeagB3p4Cny1XiaKWNRRKI80>
Subject: Re: [Idr] [Bier] PCE Controller & SDN Controller & Netconf/Yang NMS Controller - lines blurred and can the names be used ubiquitously meaning the same
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-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
- [Idr] PCE Controller & SDN Controller & Netconf/Y… Gyan Mishra
- Re: [Idr] PCE Controller & SDN Controller & Netco… Gyan Mishra
- Re: [Idr] [Bier] PCE Controller & SDN Controller … Adrian Farrel
- Re: [Idr] [Bier] PCE Controller & SDN Controller … Gyan Mishra
- Re: [Idr] [Bier] PCE Controller & SDN Controller … Adrian Farrel