[dev] Request for a BGP-LS development branch

Donald Sharp sharpd at cumulusnetworks.com
Tue Nov 5 06:59:25 EST 2019


Olivier -

Sounds like a great idea.  Let's discuss this during the technical
meeting today.

donald

On Tue, Nov 5, 2019 at 5:47 AM Jeff Tantsura <jefftant at gmail.com> wrote:
>
> Please note, RFC7752 has a number of inconsistencies and is being updated, as well as implementations based on it.
> New document is - draft-ietf-idr-rfc7752bis-02
>
> Cheers,
> Jeff
>
> On Nov 5, 2019, at 11:41 AM, <olivier.dugeon at orange.com> <olivier.dugeon at orange.com> wrote:
>
> Dear all,
>
> I got request from FRR developers to share our respective work on BGP Link State (BGP-LS a.k.a RFC7752)
>
> This new functionality has been identify in the feature request list (see
> https://github.com/FRRouting/frr/wiki/Feature-Requests) following issue 3520
> (see https://github.com/FRRouting/frr/issues/3520).
>
> The development branch is necessary as:
>  - No one have a complete solution and we would build a global solution without redeveloping everything
>    from scratch: we have parser & serializer, others have integration in latest FRR version ...
>  - This is a complex feature which re-use BGP as transport protocol, but which is completely new in FRR
>    and need large amount of work
>  - BGP-LS needs to collect Link State information from OSPF or IS-IS. For that purpose, new Traffic
>    Engineering Database will be introduce in lib directory. This TED will be fulfil by OSPF or IS-IS and
>    modification sent to BGP through new ZAPI message. This method will avoid to code an OSPF parser and
>    an IS-IS parser inside BGP-LS code and reduce the amount of data that transit through zebra layer.
>
> Please inform me once the branch created.
>
> Regards
>
> Olivier
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> dev mailing list
> dev at lists.frrouting.org
> https://lists.frrouting.org/listinfo/dev
>
>
> _______________________________________________
> dev mailing list
> dev at lists.frrouting.org
> https://lists.frrouting.org/listinfo/dev



More information about the dev mailing list