basic RSVP Traffic Engineering P-Router

[blakedot]

Would love to see a very simple "minimum viable product" transit-only RSVP​-TE/IS-IS P-router implementation. No originating/terminating LSPs, just a basic aggregation box.

Please contact me for more details.

[odd22]

Hi,

Up to know, both OSPF and IS-IS support Traffic Engineering. You could configure TE link parameters and then they are advertise by the routing protocol. This is the base for an implementation of RSVP-TE. But, currently there is no implementation of RSVP-TE in FRR. We have on-going code to implement Segment Routing (I hope to publish it soon).

If I correctly understand, you would have an FRR instance acting as a P router, performing transit-only process of RSVP-TE signalling. The LER (i.e. tail and head of the LSP tunnel) will be provided by other routers (e.g. Cisco, Juniper, Nokia ...).

Can you elaborate a bit more ? or confirm what I think ?

Regards

Olivier

[louberger]

Open sourcing our RSVP-TE implementation (which is used in production) is on our wish list.
Contact me directly ([email protected]) if interested in discussing.

Lou

[blakedot]

@odd22 that's right. The basic goal is to be able to use a white-box switch as a P-router in an existing RSVP-TE network (which uses IS-IS as its IGP).

[TekunoKage]

Is any progress on this? RSVP could be key for scale deployments... @louberger any luck to move your implementation to open source?

[eqvinox]

moved to https://github.com/FRRouting/frr/wiki/Feature-Requests

[nancy-crypto]

Not sure where to ask this question, so I am adding to this 'closed' issue. Please advise if there is another way.

I have a request from a customer asking about RSVP-TE. We are currently running FRR stable 7.5. My reading the FRR docs online, FRR does not support a complete RSVP-TE solution. I see that it is on the features_requested list. Is there still plans to implement this? or is there more information about what part of RSVP-TE solution is supported in FRR?