Dear all, Next Telco meeting is tomorrow Wednesday 10th of June 16h - 17h Paris time. Here it is the agenda. Perhaps we'll not have time to go through all points, but we'll try to do our best. - Status on Segment Routing PR and next steps - Status on Traffic Engineering (TED) - Presentation of Backup Paths (PR 6530) by Mark - Discussion about the new project facilities on GitHub to follow Telco actions (similar to what northbound call do) - Discussion on Pathd & PCELib Regards Olivier
Dear all, Following our last Telco meeting, here it is some answer regarding the PCEP protocol. First, as mention in RFC5440 section 4.2.1 https://tools.ietf.org/html/rfc5440#section-4.2.1 / Only one PCEP session can exist between a pair of PCEP peers at any////one time. Only one TCP connection on the PCEP port can exist between////a pair of PCEP peers at any one time./ It is not authorized to setup more than one PCEP session between a PCC router and a PCE server. Second, regarding SR Policy, this is related to an individual draft (WG adoption is on-going) https://datatracker.ietf.org/doc/draft-barth-pce-segment-routing-policy-cp/ that aims to give the possibility to configure SR Policy defined in Segment Routing Policy Architecture https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ through PCEP protocol. However, this is specific to Segment Routing. Policies are always defined for RSVP-TE and thus part of PCE standards. Of course, name and type of policy differ. Some are implicit due to the signalling nature of RSVP-TE i.e. some parameters of the RSVP-TE tunnel are convey by the RSVP protocol, thus each routers on the RSVP-TE tunnel path are aware about the intrinsic characteristics of the RSVP-TE tunnel. SR Policies have been defined to circumvent the lake of signalling of Segment Routing which of course greatly simplify the architecture, but as a counter part need a centralised server e.g. a PCE server to correctly manage Segment Paths in particular when bandwidth reservations are requested. So, there is no risk to have duplicate code if we go to a clear separation between PCELib and pathd. PCEPLib could serve as the basis of creating a PCCd daemon in charge of the PCEP protocol while pathd remains in charge of Segment Path & Segment Routing Policies. When RSVP-TE daemon will be ready, it could also take benefit of the PCCd daemon to interact with a PCE server. Finally, regarding the new project facilities offered by GitHub platform, I will initialize such project and will try to evaluate the benefit of them. But, instead of Northbound project, I will split our various activities into different project to keep the number of card small per project, and thus improve readability. The list of projects is as follow: * Segment Routing * Traffic Engineering * BGP-LS * Backup Path * PCEP We could create new project when needed as well as close project when there will be finished. Feel free to comment the proposal. Regards Olivier Le 09/06/2020 à 18:41, olivier.dugeon@orange.com a écrit :
Dear all, Next Telco meeting is tomorrow Wednesday 10th of June 16h - 17h Paris time. Here it is the agenda. Perhaps we'll not have time to go through all points, but we'll try to do our best. - Status on Segment Routing PR and next steps - Status on Traffic Engineering (TED) - Presentation of Backup Paths (PR 6530) by Mark - Discussion about the new project facilities on GitHub to follow Telco actions (similar to what northbound call do) - Discussion on Pathd & PCELib Regards Olivier
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev -- Orange logo <http://www.orange.com>
Olivier Dugeon Orange Expert, Future Networks Open Source Referent Orange/IMT/OLN/WTC/IEE/iTeQ fixe : +33 2 96 07 28 80 mobile : +33 6 82 90 37 85 olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com>
Olivier, The main concern I have with making a PCC daemon (PCCd) is the performance impacts involved with the daemon acting as a relay and having to send messages on to another process (zebra) which itself will send them on to the destination process (either pathd or RSVPd). Instead of 1 simple decode if the PCEPlib was included in pathd, now the messages would need to be decoded, encoded again to be sent to zebra, which hopefully wont decode/encode them, then sent on again to the final destination which will need to decode it. Or in other words: 1 decode and no extra hops compared to 2 decodes and 1 encode and 2 extra message hops. Also, what would the format of these messages sent between the PCCd and pathd/RSVPd? Hopefully it would just use the existing PCEP message/object/TLVs struct's already defined in the PCEPlib and not recreate some sub-set of the PCEP protocol. Regarding the excerpt you quoted from the RFC spec: I think that is referring to creating multiple PCEP sessions on the same TCP connection, which is not what I was suggesting. What I was proposing in the meeting last week was for pathd and RVSPd to each link in the PCEPlib, and each open independant TCP connections towards the PCE. As you mentioned in the meeting, this could be a problem to have multiple PCEP connections from the same IP, but that could be easily solved by using different source IPs for the pathd and RSVPd. Regards, Brady On Tue, Jun 16, 2020 at 4:36 PM <olivier.dugeon@orange.com> wrote:
Dear all,
Following our last Telco meeting, here it is some answer regarding the PCEP protocol.
First, as mention in RFC5440 section 4.2.1 https://tools.ietf.org/html/rfc5440#section-4.2.1 * Only one PCEP session can exist between a pair of PCEP peers at any** one time. Only one TCP connection on the PCEP port can exist between** a pair of PCEP peers at any one time.*
It is not authorized to setup more than one PCEP session between a PCC router and a PCE server.
Second, regarding SR Policy, this is related to an individual draft (WG adoption is on-going) https://datatracker.ietf.org/doc/draft-barth-pce-segment-routing-policy-cp/ that aims to give the possibility to configure SR Policy defined in Segment Routing Policy Architecturehttps://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ through PCEP protocol.
However, this is specific to Segment Routing. Policies are always defined for RSVP-TE and thus part of PCE standards. Of course, name and type of policy differ. Some are implicit due to the signalling nature of RSVP-TE i.e. some parameters of the RSVP-TE tunnel are convey by the RSVP protocol, thus each routers on the RSVP-TE tunnel path are aware about the intrinsic characteristics of the RSVP-TE tunnel.
SR Policies have been defined to circumvent the lake of signalling of Segment Routing which of course greatly simplify the architecture, but as a counter part need a centralised server e.g. a PCE server to correctly manage Segment Paths in particular when bandwidth reservations are requested.
So, there is no risk to have duplicate code if we go to a clear separation between PCELib and pathd. PCEPLib could serve as the basis of creating a PCCd daemon in charge of the PCEP protocol while pathd remains in charge of Segment Path & Segment Routing Policies. When RSVP-TE daemon will be ready, it could also take benefit of the PCCd daemon to interact with a PCE server.
Finally, regarding the new project facilities offered by GitHub platform, I will initialize such project and will try to evaluate the benefit of them. But, instead of Northbound project, I will split our various activities into different project to keep the number of card small per project, and thus improve readability. The list of projects is as follow:
* Segment Routing * Traffic Engineering * BGP-LS * Backup Path * PCEP
We could create new project when needed as well as close project when there will be finished.
Feel free to comment the proposal.
Regards
Olivier
Le 09/06/2020 à 18:41, olivier.dugeon@orange.com a écrit :
Dear all,
Next Telco meeting is tomorrow Wednesday 10th of June 16h - 17h Paris time.
Here it is the agenda. Perhaps we'll not have time to go through all points, but we'll try to do our best.
- Status on Segment Routing PR and next steps - Status on Traffic Engineering (TED) - Presentation of Backup Paths (PR 6530) by Mark - Discussion about the new project facilities on GitHub to follow Telco actions (similar to what northbound call do) - Discussion on Pathd & PCELib
Regards
Olivier
_______________________________________________ dev mailing listdev@lists.frrouting.orghttps://lists.frrouting.org/listinfo/dev
-- [image: Orange logo] <http://www.orange.com>
Olivier Dugeon Orange Expert, Future Networks Open Source Referent Orange/IMT/OLN/WTC/IEE/iTeQ
fixe : +33 2 96 07 28 80 mobile : +33 6 82 90 37 85 olivier.dugeon@orange.com _______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
Hello Brady, Answer inline Olivier Le 16/06/2020 à 18:30, Brady Johnson a écrit :
Olivier,
The main concern I have with making a PCC daemon (PCCd) is the performance impacts involved with the daemon acting as a relay and having to send messages on to another process (zebra) which itself will send them on to the destination process (either pathd or RSVPd). Instead of 1 simple decode if the PCEPlib was included in pathd, now the messages would need to be decoded, encoded again to be sent to zebra, which hopefully wont decode/encode them, then sent on again to the final destination which will need to decode it. Or in other words: 1 decode and no extra hops compared to 2 decodes and 1 encode and 2 extra message hops.
[OD] The new ZAPI OPAQUE message proposed by Mark is here to exchange data between daemon without the need to encode/decode data at the Zebra layer. So, the correct estimation from performance issue is 1 decode and no extra hops versus 1 decode and 2 extra message hops.
Also, what would the format of these messages sent between the PCCd and pathd/RSVPd? Hopefully it would just use the existing PCEP message/object/TLVs struct's already defined in the PCEPlib and not recreate some sub-set of the PCEP protocol.
[OD] As the idea is to use the ZAPI OPAQUE message, you are free to send the PCEP request as you want to pathd and/or RSVP-TE. I don't finish to look to the code of pathd and PCEPlib, but from my understanding, PCEPLib and pathd exchange information from dedicated structure and not PCEP message/objects/TLVs ... You could easily reproduced the same behaviour. The main difference is that instead to call directly a pathd function from PCEPLib and reciprocally, you will call a pccd_zebra function that sends the data to the pathd daemon through zebra with the same structure as you defined between PCEPlib and pathd.
Regarding the excerpt you quoted from the RFC spec: I think that is referring to creating multiple PCEP sessions on the same TCP connection, which is not what I was suggesting. What I was proposing in the meeting last week was for pathd and RVSPd to each link in the PCEPlib, and each open independant TCP connections towards the PCE. As you mentioned in the meeting, this could be a problem to have multiple PCEP connections from the same IP, but that could be easily solved by using different source IPs for the pathd and RSVPd.
[OD] Definitely not. I discuss this issue with my colleague Julien Meuric co-chair of the PCE WG at IETF, and we achieved the same conclusion: this is forbidden. All what you propose is feasible, but definitively not in the spirit of RFC5440. So, this is not a viable solution as you will not find a PCE server that supports this option.
Regards,
Brady
On Tue, Jun 16, 2020 at 4:36 PM <olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com>> wrote:
Dear all,
Following our last Telco meeting, here it is some answer regarding the PCEP protocol. First, as mention in RFC5440 section 4.2.1 https://tools.ietf.org/html/rfc5440#section-4.2.1 / Only one PCEP session can exist between a pair of PCEP peers at any////one time. Only one TCP connection on the PCEP port can exist between////a pair of PCEP peers at any one time./ It is not authorized to setup more than one PCEP session between a PCC router and a PCE server. Second, regarding SR Policy, this is related to an individual draft (WG adoption is on-going) https://datatracker.ietf.org/doc/draft-barth-pce-segment-routing-policy-cp/ that aims to give the possibility to configure SR Policy defined in Segment Routing Policy Architecture https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ through PCEP protocol.
However, this is specific to Segment Routing. Policies are always defined for RSVP-TE and thus part of PCE standards. Of course, name and type of policy differ. Some are implicit due to the signalling nature of RSVP-TE i.e. some parameters of the RSVP-TE tunnel are convey by the RSVP protocol, thus each routers on the RSVP-TE tunnel path are aware about the intrinsic characteristics of the RSVP-TE tunnel.
SR Policies have been defined to circumvent the lake of signalling of Segment Routing which of course greatly simplify the architecture, but as a counter part need a centralised server e.g. a PCE server to correctly manage Segment Paths in particular when bandwidth reservations are requested.
So, there is no risk to have duplicate code if we go to a clear separation between PCELib and pathd. PCEPLib could serve as the basis of creating a PCCd daemon in charge of the PCEP protocol while pathd remains in charge of Segment Path & Segment Routing Policies. When RSVP-TE daemon will be ready, it could also take benefit of the PCCd daemon to interact with a PCE server.
Finally, regarding the new project facilities offered by GitHub platform, I will initialize such project and will try to evaluate the benefit of them. But, instead of Northbound project, I will split our various activities into different project to keep the number of card small per project, and thus improve readability. The list of projects is as follow:
* Segment Routing * Traffic Engineering * BGP-LS * Backup Path * PCEP
We could create new project when needed as well as close project when there will be finished.
Feel free to comment the proposal.
Regards
Olivier
Le 09/06/2020 à 18:41, olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com> a écrit :
Dear all, Next Telco meeting is tomorrow Wednesday 10th of June 16h - 17h Paris time. Here it is the agenda. Perhaps we'll not have time to go through all points, but we'll try to do our best. - Status on Segment Routing PR and next steps - Status on Traffic Engineering (TED) - Presentation of Backup Paths (PR 6530) by Mark - Discussion about the new project facilities on GitHub to follow Telco actions (similar to what northbound call do) - Discussion on Pathd & PCELib Regards Olivier
_______________________________________________ dev mailing list dev@lists.frrouting.org <mailto:dev@lists.frrouting.org> https://lists.frrouting.org/listinfo/dev
-- Orange logo <http://www.orange.com>
Olivier Dugeon Orange Expert, Future Networks Open Source Referent Orange/IMT/OLN/WTC/IEE/iTeQ
fixe : +33 2 96 07 28 80 mobile : +33 6 82 90 37 85 olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com> _______________________________________________ dev mailing list dev@lists.frrouting.org <mailto:dev@lists.frrouting.org> https://lists.frrouting.org/listinfo/dev
-- Orange logo <http://www.orange.com> Olivier Dugeon Orange Expert, Future Networks Open Source Referent Orange/IMT/OLN/WTC/IEE/iTeQ fixe : +33 2 96 07 28 80 mobile : +33 6 82 90 37 85 olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com>
Hi, 5440 is specifically talking about mandatory single TCP session between PCC and PCE and consequently disallowing multiplexing PCEP sessions over it. What was the use case for multiple sessions? Cheers, Jeff
On Jun 16, 2020, at 10:11 AM, <olivier.dugeon@orange.com> <olivier.dugeon@orange.com> wrote:
Hello Brady, Answer inline Olivier Le 16/06/2020 à 18:30, Brady Johnson a écrit :
Olivier,
The main concern I have with making a PCC daemon (PCCd) is the performance impacts involved with the daemon acting as a relay and having to send messages on to another process (zebra) which itself will send them on to the destination process (either pathd or RSVPd). Instead of 1 simple decode if the PCEPlib was included in pathd, now the messages would need to be decoded, encoded again to be sent to zebra, which hopefully wont decode/encode them, then sent on again to the final destination which will need to decode it. Or in other words: 1 decode and no extra hops compared to 2 decodes and 1 encode and 2 extra message hops. [OD] The new ZAPI OPAQUE message proposed by Mark is here to exchange data between daemon without the need to encode/decode data at the Zebra layer. So, the correct estimation from performance issue is 1 decode and no extra hops versus 1 decode and 2 extra message hops.
Also, what would the format of these messages sent between the PCCd and pathd/RSVPd? Hopefully it would just use the existing PCEP message/object/TLVs struct's already defined in the PCEPlib and not recreate some sub-set of the PCEP protocol. [OD] As the idea is to use the ZAPI OPAQUE message, you are free to send the PCEP request as you want to pathd and/or RSVP-TE. I don't finish to look to the code of pathd and PCEPlib, but from my understanding, PCEPLib and pathd exchange information from dedicated structure and not PCEP message/objects/TLVs ... You could easily reproduced the same behaviour. The main difference is that instead to call directly a pathd function from PCEPLib and reciprocally, you will call a pccd_zebra function that sends the data to the pathd daemon through zebra with the same structure as you defined between PCEPlib and pathd.
Regarding the excerpt you quoted from the RFC spec: I think that is referring to creating multiple PCEP sessions on the same TCP connection, which is not what I was suggesting. What I was proposing in the meeting last week was for pathd and RVSPd to each link in the PCEPlib, and each open independant TCP connections towards the PCE. As you mentioned in the meeting, this could be a problem to have multiple PCEP connections from the same IP, but that could be easily solved by using different source IPs for the pathd and RSVPd. [OD] Definitely not. I discuss this issue with my colleague Julien Meuric co-chair of the PCE WG at IETF, and we achieved the same conclusion: this is forbidden. All what you propose is feasible, but definitively not in the spirit of RFC5440. So, this is not a viable solution as you will not find a PCE server that supports this option.
Regards,
Brady
On Tue, Jun 16, 2020 at 4:36 PM <olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com>> wrote: Dear all, Following our last Telco meeting, here it is some answer regarding the PCEP protocol.
First, as mention in RFC5440 section 4.2.1 https://tools.ietf.org/html/rfc5440#section-4.2.1 <https://tools.ietf.org/html/rfc5440#section-4.2.1>
Only one PCEP session can exist between a pair of PCEP peers at any one time. Only one TCP connection on the PCEP port can exist between a pair of PCEP peers at any one time.
It is not authorized to setup more than one PCEP session between a PCC router and a PCE server.
Second, regarding SR Policy, this is related to an individual draft (WG adoption is on-going) https://datatracker.ietf.org/doc/draft-barth-pce-segment-routing-policy-cp/ <https://datatracker.ietf.org/doc/draft-barth-pce-segment-routing-policy-cp/> that aims to give the possibility to configure SR Policy defined in Segment Routing Policy Architecture https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ <https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/> through PCEP protocol.
However, this is specific to Segment Routing. Policies are always defined for RSVP-TE and thus part of PCE standards. Of course, name and type of policy differ. Some are implicit due to the signalling nature of RSVP-TE i.e. some parameters of the RSVP-TE tunnel are convey by the RSVP protocol, thus each routers on the RSVP-TE tunnel path are aware about the intrinsic characteristics of the RSVP-TE tunnel.
SR Policies have been defined to circumvent the lake of signalling of Segment Routing which of course greatly simplify the architecture, but as a counter part need a centralised server e.g. a PCE server to correctly manage Segment Paths in particular when bandwidth reservations are requested.
So, there is no risk to have duplicate code if we go to a clear separation between PCELib and pathd. PCEPLib could serve as the basis of creating a PCCd daemon in charge of the PCEP protocol while pathd remains in charge of Segment Path & Segment Routing Policies. When RSVP-TE daemon will be ready, it could also take benefit of the PCCd daemon to interact with a PCE server.
Finally, regarding the new project facilities offered by GitHub platform, I will initialize such project and will try to evaluate the benefit of them. But, instead of Northbound project, I will split our various activities into different project to keep the number of card small per project, and thus improve readability. The list of projects is as follow:
* Segment Routing * Traffic Engineering * BGP-LS * Backup Path * PCEP
We could create new project when needed as well as close project when there will be finished.
Feel free to comment the proposal.
Regards
Olivier
Le 09/06/2020 à 18:41, olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com> a écrit :
Dear all, Next Telco meeting is tomorrow Wednesday 10th of June 16h - 17h Paris time. Here it is the agenda. Perhaps we'll not have time to go through all points, but we'll try to do our best. - Status on Segment Routing PR and next steps - Status on Traffic Engineering (TED) - Presentation of Backup Paths (PR 6530) by Mark - Discussion about the new project facilities on GitHub to follow Telco actions (similar to what northbound call do) - Discussion on Pathd & PCELib Regards Olivier
_______________________________________________ dev mailing list dev@lists.frrouting.org <mailto:dev@lists.frrouting.org> https://lists.frrouting.org/listinfo/dev <https://lists.frrouting.org/listinfo/dev> -- <small_logo.png> <http://www.orange.com/>
Olivier Dugeon Orange Expert, Future Networks Open Source Referent Orange/IMT/OLN/WTC/IEE/iTeQ
fixe : +33 2 96 07 28 80 mobile : +33 6 82 90 37 85 olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com>_______________________________________________ dev mailing list dev@lists.frrouting.org <mailto:dev@lists.frrouting.org> https://lists.frrouting.org/listinfo/dev <https://lists.frrouting.org/listinfo/dev> -- <small_logo.png> <http://www.orange.com/>
Olivier Dugeon Orange Expert, Future Networks Open Source Referent Orange/IMT/OLN/WTC/IEE/iTeQ
fixe : +33 2 96 07 28 80 mobile : +33 6 82 90 37 85 olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com>_______________________________________________ dev mailing list dev@lists.frrouting.org <mailto:dev@lists.frrouting.org> https://lists.frrouting.org/listinfo/dev <https://lists.frrouting.org/listinfo/dev>
Hello Jeff, The use-case I was considering was to have 2 separate processes running on the same router, each with their own source IP, and each of them acting as an individual PCC each with their own TCP connection to the same PCE. I guess it boils down to what is considered a PCC: is it a process running on a router with its own IP, or is it the router itself? @Olivier: Im ok either way, I am just trying to understand what the undesired behaviour is. Regards, Brady On Tue, Jun 16, 2020 at 7:35 PM Jeff Tantsura <jefftant@gmail.com> wrote:
Hi,
5440 is specifically talking about mandatory single TCP session between PCC and PCE and consequently disallowing multiplexing PCEP sessions over it. What was the use case for multiple sessions?
Cheers, Jeff
On Jun 16, 2020, at 10:11 AM, <olivier.dugeon@orange.com> < olivier.dugeon@orange.com> wrote:
Hello Brady,
Answer inline
Olivier
Le 16/06/2020 à 18:30, Brady Johnson a écrit :
Olivier,
The main concern I have with making a PCC daemon (PCCd) is the performance impacts involved with the daemon acting as a relay and having to send messages on to another process (zebra) which itself will send them on to the destination process (either pathd or RSVPd). Instead of 1 simple decode if the PCEPlib was included in pathd, now the messages would need to be decoded, encoded again to be sent to zebra, which hopefully wont decode/encode them, then sent on again to the final destination which will need to decode it. Or in other words: 1 decode and no extra hops compared to 2 decodes and 1 encode and 2 extra message hops.
[OD] The new ZAPI OPAQUE message proposed by Mark is here to exchange data between daemon without the need to encode/decode data at the Zebra layer. So, the correct estimation from performance issue is 1 decode and no extra hops versus 1 decode and 2 extra message hops.
Also, what would the format of these messages sent between the PCCd and pathd/RSVPd? Hopefully it would just use the existing PCEP message/object/TLVs struct's already defined in the PCEPlib and not recreate some sub-set of the PCEP protocol.
[OD] As the idea is to use the ZAPI OPAQUE message, you are free to send the PCEP request as you want to pathd and/or RSVP-TE. I don't finish to look to the code of pathd and PCEPlib, but from my understanding, PCEPLib and pathd exchange information from dedicated structure and not PCEP message/objects/TLVs ... You could easily reproduced the same behaviour. The main difference is that instead to call directly a pathd function from PCEPLib and reciprocally, you will call a pccd_zebra function that sends the data to the pathd daemon through zebra with the same structure as you defined between PCEPlib and pathd.
Regarding the excerpt you quoted from the RFC spec: I think that is referring to creating multiple PCEP sessions on the same TCP connection, which is not what I was suggesting. What I was proposing in the meeting last week was for pathd and RVSPd to each link in the PCEPlib, and each open independant TCP connections towards the PCE. As you mentioned in the meeting, this could be a problem to have multiple PCEP connections from the same IP, but that could be easily solved by using different source IPs for the pathd and RSVPd.
[OD] Definitely not. I discuss this issue with my colleague Julien Meuric co-chair of the PCE WG at IETF, and we achieved the same conclusion: this is forbidden. All what you propose is feasible, but definitively not in the spirit of RFC5440. So, this is not a viable solution as you will not find a PCE server that supports this option.
Regards,
Brady
On Tue, Jun 16, 2020 at 4:36 PM <olivier.dugeon@orange.com> wrote:
Dear all,
Following our last Telco meeting, here it is some answer regarding the PCEP protocol.
First, as mention in RFC5440 section 4.2.1 https://tools.ietf.org/html/rfc5440#section-4.2.1 * Only one PCEP session can exist between a pair of PCEP peers at any** one time. Only one TCP connection on the PCEP port can exist between** a pair of PCEP peers at any one time.*
It is not authorized to setup more than one PCEP session between a PCC router and a PCE server.
Second, regarding SR Policy, this is related to an individual draft (WG adoption is on-going) https://datatracker.ietf.org/doc/draft-barth-pce-segment-routing-policy-cp/ that aims to give the possibility to configure SR Policy defined in Segment Routing Policy Architecturehttps://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ through PCEP protocol.
However, this is specific to Segment Routing. Policies are always defined for RSVP-TE and thus part of PCE standards. Of course, name and type of policy differ. Some are implicit due to the signalling nature of RSVP-TE i.e. some parameters of the RSVP-TE tunnel are convey by the RSVP protocol, thus each routers on the RSVP-TE tunnel path are aware about the intrinsic characteristics of the RSVP-TE tunnel.
SR Policies have been defined to circumvent the lake of signalling of Segment Routing which of course greatly simplify the architecture, but as a counter part need a centralised server e.g. a PCE server to correctly manage Segment Paths in particular when bandwidth reservations are requested.
So, there is no risk to have duplicate code if we go to a clear separation between PCELib and pathd. PCEPLib could serve as the basis of creating a PCCd daemon in charge of the PCEP protocol while pathd remains in charge of Segment Path & Segment Routing Policies. When RSVP-TE daemon will be ready, it could also take benefit of the PCCd daemon to interact with a PCE server.
Finally, regarding the new project facilities offered by GitHub platform, I will initialize such project and will try to evaluate the benefit of them. But, instead of Northbound project, I will split our various activities into different project to keep the number of card small per project, and thus improve readability. The list of projects is as follow:
* Segment Routing * Traffic Engineering * BGP-LS * Backup Path * PCEP
We could create new project when needed as well as close project when there will be finished.
Feel free to comment the proposal.
Regards
Olivier
Le 09/06/2020 à 18:41, olivier.dugeon@orange.com a écrit :
Dear all,
Next Telco meeting is tomorrow Wednesday 10th of June 16h - 17h Paris time.
Here it is the agenda. Perhaps we'll not have time to go through all points, but we'll try to do our best.
- Status on Segment Routing PR and next steps - Status on Traffic Engineering (TED) - Presentation of Backup Paths (PR 6530) by Mark - Discussion about the new project facilities on GitHub to follow Telco actions (similar to what northbound call do) - Discussion on Pathd & PCELib
Regards
Olivier
_______________________________________________ dev mailing listdev@lists.frrouting.orghttps://lists.frrouting.org/listinfo/dev
-- <small_logo.png> <http://www.orange.com/>
Olivier Dugeon Orange Expert, Future Networks Open Source Referent Orange/IMT/OLN/WTC/IEE/iTeQ
fixe : +33 2 96 07 28 80 mobile : +33 6 82 90 37 85 olivier.dugeon@orange.com _______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
-- <small_logo.png> <http://www.orange.com/>
Olivier Dugeon Orange Expert, Future Networks Open Source Referent Orange/IMT/OLN/WTC/IEE/iTeQ
fixe : +33 2 96 07 28 80 mobile : +33 6 82 90 37 85 olivier.dugeon@orange.com _______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
Hello Brady, PCC is a función (client) in PCE architecture and defines the relationship (client->server). In an architecture where full virtualization of a routing context (VR) is supported, nothing should prevent a PCC or PCE instantiated as per VR as long it is a full vertical PCC->TED->(some internal guts)->FIB/LFIB. If TED or any other of the databases is shared (in most systems it is), having more than one input operating at the same level would inevitably creates conflicts, hence the text in 5440. Hope this helps, Jeff
On Jun 16, 2020, at 10:53 AM, Brady Johnson <brady@voltanet.io> wrote:
Hello Jeff,
The use-case I was considering was to have 2 separate processes running on the same router, each with their own source IP, and each of them acting as an individual PCC each with their own TCP connection to the same PCE.
I guess it boils down to what is considered a PCC: is it a process running on a router with its own IP, or is it the router itself?
@Olivier: <> Im ok either way, I am just trying to understand what the undesired behaviour is.
Regards,
Brady
On Tue, Jun 16, 2020 at 7:35 PM Jeff Tantsura <jefftant@gmail.com <mailto:jefftant@gmail.com>> wrote: Hi,
5440 is specifically talking about mandatory single TCP session between PCC and PCE and consequently disallowing multiplexing PCEP sessions over it. What was the use case for multiple sessions?
Cheers, Jeff
On Jun 16, 2020, at 10:11 AM, <olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com>> <olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com>> wrote:
Hello Brady, Answer inline Olivier Le 16/06/2020 à 18:30, Brady Johnson a écrit :
Olivier,
The main concern I have with making a PCC daemon (PCCd) is the performance impacts involved with the daemon acting as a relay and having to send messages on to another process (zebra) which itself will send them on to the destination process (either pathd or RSVPd). Instead of 1 simple decode if the PCEPlib was included in pathd, now the messages would need to be decoded, encoded again to be sent to zebra, which hopefully wont decode/encode them, then sent on again to the final destination which will need to decode it. Or in other words: 1 decode and no extra hops compared to 2 decodes and 1 encode and 2 extra message hops. [OD] The new ZAPI OPAQUE message proposed by Mark is here to exchange data between daemon without the need to encode/decode data at the Zebra layer. So, the correct estimation from performance issue is 1 decode and no extra hops versus 1 decode and 2 extra message hops.
Also, what would the format of these messages sent between the PCCd and pathd/RSVPd? Hopefully it would just use the existing PCEP message/object/TLVs struct's already defined in the PCEPlib and not recreate some sub-set of the PCEP protocol. [OD] As the idea is to use the ZAPI OPAQUE message, you are free to send the PCEP request as you want to pathd and/or RSVP-TE. I don't finish to look to the code of pathd and PCEPlib, but from my understanding, PCEPLib and pathd exchange information from dedicated structure and not PCEP message/objects/TLVs ... You could easily reproduced the same behaviour. The main difference is that instead to call directly a pathd function from PCEPLib and reciprocally, you will call a pccd_zebra function that sends the data to the pathd daemon through zebra with the same structure as you defined between PCEPlib and pathd.
Regarding the excerpt you quoted from the RFC spec: I think that is referring to creating multiple PCEP sessions on the same TCP connection, which is not what I was suggesting. What I was proposing in the meeting last week was for pathd and RVSPd to each link in the PCEPlib, and each open independant TCP connections towards the PCE. As you mentioned in the meeting, this could be a problem to have multiple PCEP connections from the same IP, but that could be easily solved by using different source IPs for the pathd and RSVPd. [OD] Definitely not. I discuss this issue with my colleague Julien Meuric co-chair of the PCE WG at IETF, and we achieved the same conclusion: this is forbidden. All what you propose is feasible, but definitively not in the spirit of RFC5440. So, this is not a viable solution as you will not find a PCE server that supports this option.
Regards,
Brady
On Tue, Jun 16, 2020 at 4:36 PM <olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com>> wrote: Dear all, Following our last Telco meeting, here it is some answer regarding the PCEP protocol.
First, as mention in RFC5440 section 4.2.1 https://tools.ietf.org/html/rfc5440#section-4.2.1 <https://tools.ietf.org/html/rfc5440#section-4.2.1>
Only one PCEP session can exist between a pair of PCEP peers at any one time. Only one TCP connection on the PCEP port can exist between a pair of PCEP peers at any one time.
It is not authorized to setup more than one PCEP session between a PCC router and a PCE server.
Second, regarding SR Policy, this is related to an individual draft (WG adoption is on-going) https://datatracker.ietf.org/doc/draft-barth-pce-segment-routing-policy-cp/ <https://datatracker.ietf.org/doc/draft-barth-pce-segment-routing-policy-cp/> that aims to give the possibility to configure SR Policy defined in Segment Routing Policy Architecture https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ <https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/> through PCEP protocol.
However, this is specific to Segment Routing. Policies are always defined for RSVP-TE and thus part of PCE standards. Of course, name and type of policy differ. Some are implicit due to the signalling nature of RSVP-TE i.e. some parameters of the RSVP-TE tunnel are convey by the RSVP protocol, thus each routers on the RSVP-TE tunnel path are aware about the intrinsic characteristics of the RSVP-TE tunnel.
SR Policies have been defined to circumvent the lake of signalling of Segment Routing which of course greatly simplify the architecture, but as a counter part need a centralised server e.g. a PCE server to correctly manage Segment Paths in particular when bandwidth reservations are requested.
So, there is no risk to have duplicate code if we go to a clear separation between PCELib and pathd. PCEPLib could serve as the basis of creating a PCCd daemon in charge of the PCEP protocol while pathd remains in charge of Segment Path & Segment Routing Policies. When RSVP-TE daemon will be ready, it could also take benefit of the PCCd daemon to interact with a PCE server.
Finally, regarding the new project facilities offered by GitHub platform, I will initialize such project and will try to evaluate the benefit of them. But, instead of Northbound project, I will split our various activities into different project to keep the number of card small per project, and thus improve readability. The list of projects is as follow:
* Segment Routing * Traffic Engineering * BGP-LS * Backup Path * PCEP
We could create new project when needed as well as close project when there will be finished.
Feel free to comment the proposal.
Regards
Olivier
Le 09/06/2020 à 18:41, olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com> a écrit :
Dear all, Next Telco meeting is tomorrow Wednesday 10th of June 16h - 17h Paris time. Here it is the agenda. Perhaps we'll not have time to go through all points, but we'll try to do our best. - Status on Segment Routing PR and next steps - Status on Traffic Engineering (TED) - Presentation of Backup Paths (PR 6530) by Mark - Discussion about the new project facilities on GitHub to follow Telco actions (similar to what northbound call do) - Discussion on Pathd & PCELib Regards Olivier
_______________________________________________ dev mailing list dev@lists.frrouting.org <mailto:dev@lists.frrouting.org> https://lists.frrouting.org/listinfo/dev <https://lists.frrouting.org/listinfo/dev> -- <small_logo.png> <http://www.orange.com/>
Olivier Dugeon Orange Expert, Future Networks Open Source Referent Orange/IMT/OLN/WTC/IEE/iTeQ
fixe : +33 2 96 07 28 80 mobile : +33 6 82 90 37 85 olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com>_______________________________________________ dev mailing list dev@lists.frrouting.org <mailto:dev@lists.frrouting.org> https://lists.frrouting.org/listinfo/dev <https://lists.frrouting.org/listinfo/dev> -- <small_logo.png> <http://www.orange.com/>
Olivier Dugeon Orange Expert, Future Networks Open Source Referent Orange/IMT/OLN/WTC/IEE/iTeQ
fixe : +33 2 96 07 28 80 mobile : +33 6 82 90 37 85 olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com>_______________________________________________ dev mailing list dev@lists.frrouting.org <mailto:dev@lists.frrouting.org> https://lists.frrouting.org/listinfo/dev <https://lists.frrouting.org/listinfo/dev>
participants (3)
-
Brady Johnson -
Jeff Tantsura -
olivier.dugeon＠orange.com