Hi @Renato Westphal "https://github.com/opensourcerouting/frr/wiki/Architecture " Can this not be used to manage, configure and get updates from the FRR routing daemons by an external NETCONF device, say an SDN controller ? Like ODL has a south bound Netconf - https://docs.opendaylight.org/en/stable-oxygen/user-guide/netconf-user-guide... So by using this I think ODL would be able to configure and get prefix updates from the signalling daemons in FRR. Correct me if I am wrong here. Thanks
Hi Anzal, I agree with your proposal, with some concerns however. I presented a few weeks ago at FRR weekly meetings, some slides about what would be the mechanisms involved for an SDN controller to be able to use FRR as BGP speaker. ODL can be the target, obviously. See in [0] The yang solution applied to BGP northbound API has been proposed. However, there were two remarks: - on the data exchanged between SDN and FRR. What was ok was for configuration ( BGP, VPN, BGP peers, ...), since it fits well with BGP NB API. However, at one moment, SDN had to populate the IPs information coming from its VMs. The best solution was to use an other API plugged into ZEBRA ( and not BGP), so that this IP information could be seen as a remote dataplane. Here, the API is not well defined yet. Should this API be equipped with Yang too? - on the constraints between SDN and FRR. Some API require performance. For instance, will yang fit well when SDN retrieves thousands of prefix entries ? Remember that if you use a netconf server like netopeer, the data flow will look like the below: odl client <---> netopeer server <---> sysrepo server <---> bgp/zebra server which may not be the optimised path when you want to retrieve a lot of prefix entries. to be confirmed. There is an alternative. From document [1], figure 2 depicts a new NB API that bypasses sysrepo, and relies on scripts (it looks like a data format ( gRPC with protoBuf) carried close to sysrepo bgp data exchanges ( using protobuf) could be used to exchange with routing daemons. Because that path would bypass netopeer and sysrepo, while keeping a data format close to what is done with netconf ( though not all would be possible), retrieving prefix entries ( and why not configuration too) could be optimised. Here too, that path has to be confirmed. Which technology could suit well with FRR (also from licensing point of view..). Philippe [0] https://docs.google.com/presentation/d/194vUFaWxmhfTpHyANHsP66Ffw0BQuJ9sI0ir... [1] https://github.com/opensourcerouting/frr/wiki/Architecture On Thu, Nov 15, 2018 at 1:59 PM anzal <mohammedanz@gmail.com> wrote:
Hi
@Renato Westphal "https://github.com/opensourcerouting/frr/wiki/Architecture"
Can this not be used to manage, configure and get updates from the FRR routing daemons by an external NETCONF device, say an SDN controller ?
Like ODL has a south bound Netconf - https://docs.opendaylight.org/en/stable-oxygen/user-guide/netconf-user-guide...
So by using this I think ODL would be able to configure and get prefix updates from the signalling daemons in FRR. Correct me if I am wrong here.
Thanks
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
Hi Philippe, Thanks a lot for your insights. I happened to glance over a report regarding the performance of the ODL southbound netconf interface. Please see https://wiki.opendaylight.org/view/NETCONF:Testing#NETCONF_southbound_perfor... I do understand that optimizations will be needed in the path you referred odl client <---> netopeer server <---> sysrepo server <---> bgp/zebra server But wouldn't this report justify that a yang based model can help with cases of handling 10K prefix updates. What are your thoughts. Regards Anzal On Sat, Nov 17, 2018 at 1:56 PM Philippe Guibert <philippe.guibert@6wind.com> wrote:
Hi Anzal,
I agree with your proposal, with some concerns however.
I presented a few weeks ago at FRR weekly meetings, some slides about what would be the mechanisms involved for an SDN controller to be able to use FRR as BGP speaker. ODL can be the target, obviously. See in [0]
The yang solution applied to BGP northbound API has been proposed.
However, there were two remarks: - on the data exchanged between SDN and FRR. What was ok was for configuration ( BGP, VPN, BGP peers, ...), since it fits well with BGP NB API.
However, at one moment, SDN had to populate the IPs information coming from its VMs. The best solution was to use an other API plugged into ZEBRA ( and not BGP), so that this IP information could be seen as a remote dataplane. Here, the API is not well defined yet. Should this API be equipped with Yang too?
- on the constraints between SDN and FRR. Some API require performance. For instance, will yang fit well when SDN retrieves thousands of prefix entries ?
Remember that if you use a netconf server like netopeer, the data flow will look like the below: odl client <---> netopeer server <---> sysrepo server <---> bgp/zebra server
which may not be the optimised path when you want to retrieve a lot of prefix entries. to be confirmed.
There is an alternative. From document [1], figure 2 depicts a new NB API that bypasses sysrepo, and relies on scripts (it looks like a data format ( gRPC with protoBuf) carried close to sysrepo bgp data exchanges ( using protobuf) could be used to exchange with routing daemons. Because that path would bypass netopeer and sysrepo, while keeping a data format close to what is done with netconf ( though not all would be possible), retrieving prefix entries ( and why not configuration too) could be optimised. Here too, that path has to be confirmed. Which technology could suit well with FRR (also from licensing point of view..).
Philippe
[0] https://docs.google.com/presentation/d/194vUFaWxmhfTpHyANHsP66Ffw0BQuJ9sI0ir... [1] https://github.com/opensourcerouting/frr/wiki/Architecture On Thu, Nov 15, 2018 at 1:59 PM anzal <mohammedanz@gmail.com> wrote:
Hi
@Renato Westphal "
https://github.com/opensourcerouting/frr/wiki/Architecture"
Can this not be used to manage, configure and get updates from the FRR
routing daemons by an external NETCONF device, say an SDN controller ?
Like ODL has a south bound Netconf -
https://docs.opendaylight.org/en/stable-oxygen/user-guide/netconf-user-guide...
So by using this I think ODL would be able to configure and get prefix
updates from the signalling daemons in FRR. Correct me if I am wrong here.
Thanks
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
Hi
Thanks a lot for your insights.
I happened to glance over a report regarding the performance of the ODL southbound netconf interface. Please see
https://wiki.opendaylight.org/view/NETCONF:Testing#NETCONF_southbound_perfor...
I do understand that optimizations will be needed in the path you referred
odl client <---> netopeer server <---> sysrepo server <---> bgp/zebra server
But wouldn't this report justify that a yang based model can help with cases of handling 10K prefix updates.
What are your thoughts.
Regards
Anzal
On Sat, Nov 17, 2018 at 1:56 PM Philippe Guibert < philippe.guibert@6wind.com> wrote:
Hi Anzal,
I agree with your proposal, with some concerns however.
I presented a few weeks ago at FRR weekly meetings, some slides about what would be the mechanisms involved for an SDN controller to be able to use FRR as BGP speaker. ODL can be the target, obviously. See in [0]
The yang solution applied to BGP northbound API has been proposed.
However, there were two remarks: - on the data exchanged between SDN and FRR. What was ok was for configuration ( BGP, VPN, BGP peers, ...), since it fits well with BGP NB API.
However, at one moment, SDN had to populate the IPs information coming from its VMs. The best solution was to use an other API plugged into ZEBRA ( and not BGP), so that this IP information could be seen as a remote dataplane. Here, the API is not well defined yet. Should this API be equipped with Yang too?
- on the constraints between SDN and FRR. Some API require performance. For instance, will yang fit well when SDN retrieves thousands of prefix entries ?
Remember that if you use a netconf server like netopeer, the data flow will look like the below: odl client <---> netopeer server <---> sysrepo server <---> bgp/zebra server
which may not be the optimised path when you want to retrieve a lot of prefix entries. to be confirmed.
There is an alternative. From document [1], figure 2 depicts a new NB API that bypasses sysrepo, and relies on scripts (it looks like a data format ( gRPC with protoBuf) carried close to sysrepo bgp data exchanges ( using protobuf) could be used to exchange with routing daemons. Because that path would bypass netopeer and sysrepo, while keeping a data format close to what is done with netconf ( though not all would be possible), retrieving prefix entries ( and why not configuration too) could be optimised. Here too, that path has to be confirmed. Which technology could suit well with FRR (also from licensing point of view..).
Philippe
[0] https://docs.google.com/presentation/d/194vUFaWxmhfTpHyANHsP66Ffw0BQuJ9sI0ir... [1] https://github.com/opensourcerouting/frr/wiki/Architecture On Thu, Nov 15, 2018 at 1:59 PM anzal <mohammedanz@gmail.com> wrote:
Hi
@Renato Westphal "
https://github.com/opensourcerouting/frr/wiki/Architecture"
Can this not be used to manage, configure and get updates from the FRR
routing daemons by an external NETCONF device, say an SDN controller ?
Like ODL has a south bound Netconf -
https://docs.opendaylight.org/en/stable-oxygen/user-guide/netconf-user-guide...
So by using this I think ODL would be able to configure and get prefix
updates from the signalling daemons in FRR. Correct me if I am wrong here.
Thanks
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
Hi, Netconf is a configuration protocol and is not particularly suitable for streaming data, one could use YANG-push(https://tools.ietf.org/html/draft-ietf-netconf-yang-push-20), has been implemented in ODL’ Baron release (https://docs.opendaylight.org/en/stable-boron/user-guide/yang-push.html) however - general performance implications apply, gRPC on another hand is de-facto industry standard for streaming telemetry OpenConfig has defined number of frameworks. Specifically for prefix injection, gRIBI (https://github.com/openconfig/gribi/blob/master/doc/motivation.md) could be considered, this what we (IETF) envisioned with I2RS effort but, reality is different. Cheers, Jeff
On Nov 17, 2018, at 12:26 AM, Philippe Guibert <philippe.guibert@6wind.com> wrote:
Hi Anzal,
I agree with your proposal, with some concerns however.
I presented a few weeks ago at FRR weekly meetings, some slides about what would be the mechanisms involved for an SDN controller to be able to use FRR as BGP speaker. ODL can be the target, obviously. See in [0]
The yang solution applied to BGP northbound API has been proposed.
However, there were two remarks: - on the data exchanged between SDN and FRR. What was ok was for configuration ( BGP, VPN, BGP peers, ...), since it fits well with BGP NB API.
However, at one moment, SDN had to populate the IPs information coming from its VMs. The best solution was to use an other API plugged into ZEBRA ( and not BGP), so that this IP information could be seen as a remote dataplane. Here, the API is not well defined yet. Should this API be equipped with Yang too?
- on the constraints between SDN and FRR. Some API require performance. For instance, will yang fit well when SDN retrieves thousands of prefix entries ?
Remember that if you use a netconf server like netopeer, the data flow will look like the below: odl client <---> netopeer server <---> sysrepo server <---> bgp/zebra server
which may not be the optimised path when you want to retrieve a lot of prefix entries. to be confirmed.
There is an alternative. From document [1], figure 2 depicts a new NB API that bypasses sysrepo, and relies on scripts (it looks like a data format ( gRPC with protoBuf) carried close to sysrepo bgp data exchanges ( using protobuf) could be used to exchange with routing daemons. Because that path would bypass netopeer and sysrepo, while keeping a data format close to what is done with netconf ( though not all would be possible), retrieving prefix entries ( and why not configuration too) could be optimised. Here too, that path has to be confirmed. Which technology could suit well with FRR (also from licensing point of view..).
Philippe
[0] https://docs.google.com/presentation/d/194vUFaWxmhfTpHyANHsP66Ffw0BQuJ9sI0ir... [1] https://github.com/opensourcerouting/frr/wiki/Architecture On Thu, Nov 15, 2018 at 1:59 PM anzal <mohammedanz@gmail.com> wrote:
Hi
@Renato Westphal "https://github.com/opensourcerouting/frr/wiki/Architecture"
Can this not be used to manage, configure and get updates from the FRR routing daemons by an external NETCONF device, say an SDN controller ?
Like ODL has a south bound Netconf - https://docs.opendaylight.org/en/stable-oxygen/user-guide/netconf-user-guide...
So by using this I think ODL would be able to configure and get prefix updates from the signalling daemons in FRR. Correct me if I am wrong here.
Thanks
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
Hi Anzal, About your question related to ODL-FRR interaction, may I know if you have a specific ODL service in mind ? I have come up with design proposals on ODL/FRR interaction for L3VPN and L2VPN in ODL service. Main points are: - rely on the new yang NB API ( using GRPc technology). - optional : extend L3VPN/L2VPN to Zebra, via remote dataplane You can find specific proposal in [0] Anzal, or everyone else in the FRR community, your comments are welcome, Thanks, Philippe [0] https://docs.google.com/presentation/d/18LkCGc8HAXto-c5IRT0NUBLmKRBYM6Oq6D5Q... On 11/21/18, Jeff Tantsura <jefftant@gmail.com> wrote:
Hi,
Netconf is a configuration protocol and is not particularly suitable for streaming data, one could use YANG-push(https://tools.ietf.org/html/draft-ietf-netconf-yang-push-20), has been implemented in ODL’ Baron release (https://docs.opendaylight.org/en/stable-boron/user-guide/yang-push.html) however - general performance implications apply, gRPC on another hand is de-facto industry standard for streaming telemetry OpenConfig has defined number of frameworks. Specifically for prefix injection, gRIBI (https://github.com/openconfig/gribi/blob/master/doc/motivation.md) could be considered, this what we (IETF) envisioned with I2RS effort but, reality is different.
Cheers, Jeff
On Nov 17, 2018, at 12:26 AM, Philippe Guibert <philippe.guibert@6wind.com> wrote:
Hi Anzal,
I agree with your proposal, with some concerns however.
I presented a few weeks ago at FRR weekly meetings, some slides about what would be the mechanisms involved for an SDN controller to be able to use FRR as BGP speaker. ODL can be the target, obviously. See in [0]
The yang solution applied to BGP northbound API has been proposed.
However, there were two remarks: - on the data exchanged between SDN and FRR. What was ok was for configuration ( BGP, VPN, BGP peers, ...), since it fits well with BGP NB API.
However, at one moment, SDN had to populate the IPs information coming from its VMs. The best solution was to use an other API plugged into ZEBRA ( and not BGP), so that this IP information could be seen as a remote dataplane. Here, the API is not well defined yet. Should this API be equipped with Yang too?
- on the constraints between SDN and FRR. Some API require performance. For instance, will yang fit well when SDN retrieves thousands of prefix entries ?
Remember that if you use a netconf server like netopeer, the data flow will look like the below: odl client <---> netopeer server <---> sysrepo server <---> bgp/zebra server
which may not be the optimised path when you want to retrieve a lot of prefix entries. to be confirmed.
There is an alternative. From document [1], figure 2 depicts a new NB API that bypasses sysrepo, and relies on scripts (it looks like a data format ( gRPC with protoBuf) carried close to sysrepo bgp data exchanges ( using protobuf) could be used to exchange with routing daemons. Because that path would bypass netopeer and sysrepo, while keeping a data format close to what is done with netconf ( though not all would be possible), retrieving prefix entries ( and why not configuration too) could be optimised. Here too, that path has to be confirmed. Which technology could suit well with FRR (also from licensing point of view..).
Philippe
[0] https://docs.google.com/presentation/d/194vUFaWxmhfTpHyANHsP66Ffw0BQuJ9sI0ir... [1] https://github.com/opensourcerouting/frr/wiki/Architecture On Thu, Nov 15, 2018 at 1:59 PM anzal <mohammedanz@gmail.com> wrote:
Hi
@Renato Westphal "https://github.com/opensourcerouting/frr/wiki/Architecture"
Can this not be used to manage, configure and get updates from the FRR routing daemons by an external NETCONF device, say an SDN controller ?
Like ODL has a south bound Netconf - https://docs.opendaylight.org/en/stable-oxygen/user-guide/netconf-user-guide...
So by using this I think ODL would be able to configure and get prefix updates from the signalling daemons in FRR. Correct me if I am wrong here.
Thanks
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
Hi Philippe, Thanks for your inputs. I am also interested in the use case of L3VPN/L2VPN for ODL-FRR interaction. I would root for the approach mentioned by you in the first slide, of interfacing the zebra daemon for prefix handling, to ODL over gRPC. Meanwhile, when are we planning to start with the bgpd specific north bound API related work ? Is there any planned timeline for this feature request #2585 <https://github.com/FRRouting/frr/issues/2585>- gRPC support for Zebra Thanks Anzal On 19-12-2018 08:34 PM, Philippe Guibert wrote:
Hi Anzal,
About your question related to ODL-FRR interaction, may I know if you have a specific ODL service in mind ?
I have come up with design proposals on ODL/FRR interaction for L3VPN and L2VPN in ODL service. Main points are: - rely on the new yang NB API ( using GRPc technology). - optional : extend L3VPN/L2VPN to Zebra, via remote dataplane
You can find specific proposal in [0]
Anzal, or everyone else in the FRR community, your comments are welcome,
Thanks,
Philippe
[0] https://docs.google.com/presentation/d/18LkCGc8HAXto-c5IRT0NUBLmKRBYM6Oq6D5Q...
On 11/21/18, Jeff Tantsura <jefftant@gmail.com> wrote:
Hi,
Netconf is a configuration protocol and is not particularly suitable for streaming data, one could use YANG-push(https://tools.ietf.org/html/draft-ietf-netconf-yang-push-20), has been implemented in ODL’ Baron release (https://docs.opendaylight.org/en/stable-boron/user-guide/yang-push.html) however - general performance implications apply, gRPC on another hand is de-facto industry standard for streaming telemetry OpenConfig has defined number of frameworks. Specifically for prefix injection, gRIBI (https://github.com/openconfig/gribi/blob/master/doc/motivation.md) could be considered, this what we (IETF) envisioned with I2RS effort but, reality is different.
Cheers, Jeff
On Nov 17, 2018, at 12:26 AM, Philippe Guibert <philippe.guibert@6wind.com> wrote:
Hi Anzal,
I agree with your proposal, with some concerns however.
I presented a few weeks ago at FRR weekly meetings, some slides about what would be the mechanisms involved for an SDN controller to be able to use FRR as BGP speaker. ODL can be the target, obviously. See in [0]
The yang solution applied to BGP northbound API has been proposed.
However, there were two remarks: - on the data exchanged between SDN and FRR. What was ok was for configuration ( BGP, VPN, BGP peers, ...), since it fits well with BGP NB API.
However, at one moment, SDN had to populate the IPs information coming from its VMs. The best solution was to use an other API plugged into ZEBRA ( and not BGP), so that this IP information could be seen as a remote dataplane. Here, the API is not well defined yet. Should this API be equipped with Yang too?
- on the constraints between SDN and FRR. Some API require performance. For instance, will yang fit well when SDN retrieves thousands of prefix entries ?
Remember that if you use a netconf server like netopeer, the data flow will look like the below: odl client <---> netopeer server <---> sysrepo server <---> bgp/zebra server
which may not be the optimised path when you want to retrieve a lot of prefix entries. to be confirmed.
There is an alternative. From document [1], figure 2 depicts a new NB API that bypasses sysrepo, and relies on scripts (it looks like a data format ( gRPC with protoBuf) carried close to sysrepo bgp data exchanges ( using protobuf) could be used to exchange with routing daemons. Because that path would bypass netopeer and sysrepo, while keeping a data format close to what is done with netconf ( though not all would be possible), retrieving prefix entries ( and why not configuration too) could be optimised. Here too, that path has to be confirmed. Which technology could suit well with FRR (also from licensing point of view..).
Philippe
[0] https://docs.google.com/presentation/d/194vUFaWxmhfTpHyANHsP66Ffw0BQuJ9sI0ir... [1] https://github.com/opensourcerouting/frr/wiki/Architecture On Thu, Nov 15, 2018 at 1:59 PM anzal <mohammedanz@gmail.com> wrote:
Hi
@Renato Westphal "https://github.com/opensourcerouting/frr/wiki/Architecture"
Can this not be used to manage, configure and get updates from the FRR routing daemons by an external NETCONF device, say an SDN controller ?
Like ODL has a south bound Netconf - https://docs.opendaylight.org/en/stable-oxygen/user-guide/netconf-user-guide...
So by using this I think ODL would be able to configure and get prefix updates from the signalling daemons in FRR. Correct me if I am wrong here.
Thanks
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
participants (4)
-
anzal -
Jeff Tantsura -
Mohammed Anzal K -
Philippe Guibert