Subject: [Pce] Architectural question about resource-scheduled LSPs

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 23 Jul 2015 14:50:43 +0100

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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 23 Jul 2015 14:13:09 +0000

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-masked]] On Behalf Of Adrian Farrel
> Sent: giovedì 23 luglio 2015 15:51
> To: [email-masked]; [email-masked]
> Subject: [Teas] Architectural question about resource-scheduled LSPs
> 
> Hi,
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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-masked]
> https://www.ietf.org/mailman/listinfo/teas

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 24 Jul 2015 07:54:04 +0000

Hi Dieter,

In line.

BR
Daniele

From: Dieter Beller [mailto:[email-masked]]
Sent: venerdì 24 luglio 2015 07:47
To: Daniele Ceccarelli
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [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,

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.

[DanCe] no I meant RSVP-TE. One option is IGP flooding, the other one is to make the reservation on the nodes (via signaling) for a future time interval. In any case both options are not even comparable in terms of complexity and scalability (and openness to other control mechanisms) compared to PCEP notifications to all the other PCEs.

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.
[DanCe] what if such PCE is not reachable for a while? How do the other PCEs know which is the master PCE for the each given LSP to be? Storing this info on the nodes in the most reliable solution IMHO.

 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-----

To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi,

on the same page.

also MPLS.

data held?"

The options are:

future reservations.

messages.

are trying to build.

Thanks for listening,

Adrian

Teas mailing list

[email-masked]<mailto:[email-masked]>

Teas mailing list

[email-masked]<mailto:[email-masked]>

---

From: Dieter Beller <[email-masked]>
Date: Fri, 24 Jul 2015 07:47:09 +0200

Hi Daniele,

Thanks,

Dieter

On 23.07.2015 16:13, Daniele Ceccarelli
wrote:

Hi Adrian,

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.

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.

Cheers,
Daniele

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: giovedì 23 luglio 2015 15:51
To: [email-masked]; [email-masked]
Subject: [Teas] Architectural question about resource-scheduled LSPs

Hi,

The options are:

Thanks for listening,
Adrian