I think there are much misunderstanding on what PCEP-LS is. Adrian pointed out an accurate assessment of what PCEP-LS is doing with TE information:
>> In this network, the question to address is "How does the PCE learn the >> topology of the TE network?" I believe that at least some of the proponents >> of PCEP-LS are suggesting that *each* NE can have a PCEP session that is >> used not only for programming the NE for forwarding, but also for reporting >> a fragment of the topology. In other words, PCEP-LS would be used by *each* >> NE to report its local links. (Whether this assumes that the NEs are running >> some form of discovery/verification protocol such as LMP is maybe something >> we should also be talking about.) >> So maybe what is needed to make this clear is a tiny little architecture >> statement? That way people hearing "PCEP-LS" will not think "dump the whole >> topology from a single node in the network" the way that we have become >> accustomed to thinking with BGP-LS, but will see the picture being solved >> and will understand the flow of information. Regards, Young From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, July 25, 2017 5:59 AM To: 'Daniele Ceccarelli' <daniele.ceccare...@ericsson.com>; 'Julien Meuric' <julien.meu...@orange.com>; pce@ietf.org Cc: pce-cha...@ietf.org Subject: Re: [Pce] PCEP as an SDN controller protocol? I think it is all slightly a distraction :-) It is possible to run an MCN without a routing protocol depending on the topology of the MCN. Many MCNs can be achieved with relatively simple static routes. Statements (Haomian) that optical devices cannot run BGP-LS seem to me to be an exaggeration. I understand why they choose to not do it. The use of BGP-LS or PCEP-LS in a network where an IGP-TE is running may be excessive since making a PCE a passive partner in an IGP is very cheap and easy. All of these things are an aside to the deployment models being discussed. Those models are more closely SDN-based, and that fact may be missing from the conversation. Consider a network that runs without a horizontal control plane (i.e., no IGP-TE and no signaling protocol). In this mode, devices are individually provisioned from a controller using a protocol such as PCEP in a PCE-CC mode. The controller-device communications run through an MCN, but that network could be fairly simply constructed of P2P forwarding paths or (in the case of an in-fiber MCN) by taking advantage of default static routes. In this network, the question to address is "How does the PCE learn the topology of the TE network?" I believe that at least some of the proponents of PCEP-LS are suggesting that *each* NE can have a PCEP session that is used not only for programming the NE for forwarding, but also for reporting a fragment of the topology. In other words, PCEP-LS would be used by *each* NE to report its local links. (Whether this assumes that the NEs are running some form of discovery/verification protocol such as LMP is maybe something we should also be talking about.) I find myself asking, "How does an individual NE know its configuration? What identities does it give to links? Where do those links connect to?" If that information is pushed by configuration, couldn't that configuration station push that information to the PCE as well. So maybe what is needed to make this clear is a tiny little architecture statement? That way people hearing "PCEP-LS" will not think "dump the whole topology from a single node in the network" the way that we have become accustomed to thinking with BGP-LS, but will see the picture being solved and will understand the flow of information. Thanks, Adrian From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Daniele Ceccarelli Sent: 25 July 2017 11:27 To: Julien Meuric; pce@ietf.org<mailto:pce@ietf.org> Cc: pce-cha...@ietf.org<mailto:pce-cha...@ietf.org> Subject: Re: [Pce] PCEP as an SDN controller protocol? HI Julien, your correction is…correct 😊 You’re referring to the protocols running on the DCN, or more appropriately on the MCN, right? The IGP is usually non TE and just providing reachability info…but as PCEP can be modified for other purposes, they can be modified as well. On this I agree with you. Cheers Daniele From: Julien Meuric [mailto:julien.meu...@orange.com] Sent: martedì 25 luglio 2017 11:36 To: Daniele Ceccarelli <daniele.ceccare...@ericsson.com<mailto:daniele.ceccare...@ericsson.com>>; pce@ietf.org<mailto:pce@ietf.org> Cc: Jonathan Hardwick <jonathan.hardw...@metaswitch.com<mailto:jonathan.hardw...@metaswitch.com>>; pce-cha...@ietf.org<mailto:pce-cha...@ietf.org> Subject: Re: PCEP as an SDN controller protocol? Hi Daniele, [Operator hat on.] I agree on several things you wrote, starting from the answer to Jon's rhetorical question, which cares more about how much (at least I've never noticed my co-chair has a short memory). Nevertheless the sentence below needs to be corrected, because it happens to be wrong: "optical networks with no control plane" is as inaccurate as "a fuel car with no battery". Not relying on the high-end version of this mean to realize the core task of an equipment must not hide that most (even those Sonet/SDH ADMs) of the deployed optical devices do (mostly for management traffic, whose fate PCEP may share)...: - perform IP forwarding, - have a routing table, - run an IGP to populate that routing table, - run an IGP to advertise their attached addresses, - support a large set of (IP-based) protocols for various purposes (e.g., ICMP, DHCP, SSH, SMTP), i.e. squeezing many roles within a single protocol is a non-goal. A possible rephrasing could be "networks where the control plane is limited to background tasks", which reminds that operators deploy "fully packaged cars", not just "raw wheels with a motor" according to the misleading scope assumed in the current discussion. Thanks, Julien Jul. 24, 2017 - daniele.ceccare...@ericsson.com<mailto:daniele.ceccare...@ericsson.com>: • It could be the SBI solution for those networks where there is no control plane (e.g. many NMS driven optical networks)
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
