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

[Gyan Mishra <[e-mail]>]

Hi Adrian,

In line

Kind Regards

Gyan
On Sun, Nov 15, 2020 at 7:04 AM Adrian Farrel <[e-mail]> 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