[OSPF] FW: [Teas] Architectural question about resource-scheduled LSPs

["Acee Lindem (acee)" <[e-mail]>]

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"
<[e-mail] on behalf of [e-mail]> 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/teas