Re: [Lsr] [Bier] PCE Controller & SDN Controller & Netconf/Yang NMS Controller - lines blurred and can the names be used ubiquitously meaning the same
Hi again Gyan, I think we’re narrowing down and getting somewhat esoteric for the mailing lists we’re spamming. > 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. [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 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] [Bier] PCE Controller & SDN Controller & Netconf/Yang NMS Controller - lines blurred and can the names be used ubiquitously meaning the same
Hi Adrian, In line Kind Regards Gyan On Sun, Nov 15, 2020 at 7:04 AM Adrian Farrel 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
Re: [Lsr] [Bier] PCE Controller & SDN Controller & Netconf/Yang NMS Controller - lines blurred and can the names be used ubiquitously meaning the same
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 ___ Lsr mailing list Lsr@ietf.org
