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. 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?). 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]; [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] > https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
