Hi Adrian, In line
Kind Regards Gyan On Sun, Nov 15, 2020 at 7:04 AM Adrian Farrel <adr...@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
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
