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

From: "Zhuangyan (Yan)" <[email-masked]>
Date: Fri, 18 Sep 2015 10:26:30 +0000

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-masked]] 代表 Dieter Beller
发送时间: 2015年7月24日 13:47
收件人: Daniele Ceccarelli
抄送: [email-masked]; [email-masked]
主题: 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-masked]] On Behalf Of Adrian Farrel

Sent: giovedì 23 luglio 2015 15:51

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

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-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/teas

_______________________________________________

Teas mailing list

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

https://www.ietf.org/mailman/listinfo/teas