Hi, all, We’d like to draw your attention to a new draft based on the discussion on this thread. This draft is about the architecture for Scheduled use of Resources https://datatracker.ietf.org/doc/draft-zhuang-teas-scheduled-resources/ We have posted it to TEAS mailing list: https://mailarchive.ietf.org/arch/msg/teas/zKrO8f0jtDGOfp8GTTJOPxTHRRE
Comments and suggestions are appreciated and warmly welcome. Thanks! Regards, Yan (on behalf of authors) 发件人: Pce [mailto:[email protected]] 代表 Dieter Beller 发送时间: 2015年7月24日 13:47 收件人: Daniele Ceccarelli 抄送: [email protected]; [email protected] 主题: Re: [Pce] [Teas] Architectural question about resource-scheduled LSPs Hi Daniele, please find my comments in-line below. Thanks, Dieter On 23.07.2015 16:13, Daniele Ceccarelli wrote: Hi Adrian, Thanks for the excellent analysis and summary. I think that distributing the time reservation info just to the PCC and then realigning the other PCEs is the best option. Performing a realignment via IGP can cause scalability issues as you said (maybe BGP could be the only appropriate alternative to PCEP). Distributing the info to all the nodes (e.g. via RSVP) is not needed IMO, it's a burden that does not bring any value and is applicable only to RSVP-TE, while keeping the reservation on the PCC could allow for bandwidth scheduling also in other cases like e.g. segment routing. did you mean OSPF and OSPF-TE, respectively? RSVP signaling may only help to update the DBs in the nodes along the path of an LSP. All other nodes do not see these messages. So, the IGP has to be used to accomplish that all DBs are in sync. Sync between PCEs is another opportunity but then we end up in complex synch issues (who's the master? Who is right in case of conflict?). Is this really a difficult problem to solve? One could imagine that the PCE that calculated the path starting from the head node of the LSP is always the master and that this PCE instance syncs all the other PCE instances or a similar rule. If we send the info to the PCC (i.e. the network), the network is always right in case of contentious and the PCEs can align with it. Cheers, Daniele -----Original Message----- From: Teas [mailto:[email protected]] On Behalf Of Adrian Farrel Sent: giovedì 23 luglio 2015 15:51 To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [Teas] Architectural question about resource-scheduled LSPs Hi, Having listened to the two presentations on scheduled LSPs in PCE and one in TEAS I think we need to do some architectural work and make sure we are all on the same page. This work probably needs to be squared off across the two WGs and possibly also MPLS. The architectural question is "Where is future scheduled resource reservation data held?" The options are: i. Solely in a centralised DB ii. In several distributed DBs that might be periodically synchronised iii. Distributed into the network iv. Some combination of the above. In the old world, the management system held all information about connections in the network. Such management systems were able to schedule connection establishment as well since they had a full view of all resources and all connections. In MPLS/GMPLS, the pendulum swung. Connection state was held in the network and not widely known. Only current resource availability was distributed. In such systems, scheduled connections required a management system that could access the current resource availability and plan the scheduled connections. But this approach was vulnerable to connections set up by other entities (in a distributed manner) that might "steal" resources needed for a planned future connection. One of the proposed solutions to this problem is that scheduled state is distributed into the network by signaling. That is, an RSVP Path message includes the timing parameters and the resources can be reserved by the network devices for use at the specified time. The disadvantages of this approach are that the network nodes have to have per-resource time-based databases (which may be quite complex), and that other nodes in the network (such as other head-end nodes, or PCEs) do not know about the future reservations. The answer to the second point is to report the future reservations either in PCEP or in the IGP. Doing it in the IGP means that every node in the network can see the future reservations, but may have an interesting scaling impact. Doing it in PCEP means the PCE is in synch with the network, but doesn't help other LSRs so implies a PCE-controlled scheduling system. At this point we might ask why, if the resource scheduling is controlled by the PCE, we need to distribute the scheduling information in the network. Why not just leave the time-based TED in the PCE? That reduces us to adding time parameters to the PCReq, but no changes to the PCInitiate message. The PCRep might have some time-based stuff for confirmation etc. But, this approach would have no changes to the RSVP messages. The above is me just rambling on the topic a bit, but it seems that we need to get all of this work on the same page and agree the architecture of what we are trying to build. Thanks for listening, Adrian _______________________________________________ Teas mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/teas
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
