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
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
