FYI - with respect to yesterday’s OSPF presentation on TE advertisement of time-based bandwidth, the work in MPLS and TEAS would need to precede it. Thanks, Acee
On 7/23/15, 3:50 PM, "Teas on behalf of Adrian Farrel" <teas-boun...@ietf.org on behalf of adr...@olddog.co.uk> wrote: >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 >t...@ietf.org >https://www.ietf.org/mailman/listinfo/teas _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
