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

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 15 Nov 2020 12:04:38 -0000

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.

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.

> 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

> 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.

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.

> 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.

> 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.

BGP-LS was intended to export routing information “northbound” from the network.

> 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.

> 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?

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”.

Best,

Adrian

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 20 Nov 2020 16:10:32 -0500

Hi Adrian,

In line

Kind Regards

Gyan
On Sun, Nov 15, 2020 at 7:04 AM Adrian Farrel <[email-masked]> wrote:

>  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
>
> 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.
>
> 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.
>
> 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.

>  Gyan> Understood
>  Gyan> Understood
>  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.
>
> 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!

-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 21 Nov 2020 15:46:53 -0000

Hi again Gyan,

I think we’re narrowing down and getting somewhat esoteric for the mailing lists we’re spamming.

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.

[Adrian] I think it depends. The protocols are just tools. You could have a centralised TE system with a PCE to preform computations, but you can use any combinations of protocols to extract information from the network (IGPs, BGP-LS, PCEP-LS, Netconf, …) and any combination of protocols to program the network devices to install TE paths, reserve resources, and configure traffic forwarding rules (PCEP, RSVP-TE, Netconf, …).

Cheers,

Adrian