Re: [Idr] BGP-LS alternatives - problems and solutions

[[e-mail]]

Hello Robert, all

Le 30/06/2022 à 10:28, Robert Raszuk a écrit :
> All,
>
> I am very glad we are having this thread.

me too ;-)

>  
>
>     There is also an experimental PCEP-LS: draft-dhodylee-pce-pcep-ls
>
>
> IMO PCEP-LS is falling into the same trap as BGP-LS ended up being caught with. It defines TLVs and sub-TLVs to encode information. That means that any change or extension in the OSPF or ISIS would need to be reflected in the PCEP-LS protocol extension. That does not scale. 
>
> While cherry picking some specific information may be useful it should be backwards compatible - so I would expect any new protocol to reuse already defined encoding for BGP-LS. 
>
> New proposal should also allow a mode of operation where any new protocol extension is synchronized without any new IETF draft or RFC needed. As example OSPF OOB LSDB sync spec meets this criteria well: https://datatracker.ietf.org/doc/html/rfc4811

I agree that PCEP-LS fall into the same problem as BGP-LS regarding IGP protocol extension. But, from a developer point of view, BGP-LS as the great advantage that you need to code, debug and maintain only one parser for the BGP-LS listener. Streaming out of band the contain of LSDB (whatever the protocol will be) means that you must code, debug and maintain one parser per IGP (at least one for OSPF and one for IS-IS) as the TLVs are not the same (at least T & L). If you try to standardized the LSDB e.g. with a yang model, you fall again into the same problem of managing new IGP TLVs extension. Another point not mention in the list of advantage for BGP-LS is the possibility to use a Route Reflector / Cluster architecture. I mean, from an SDN Controller point of view e.g. a PCE server, that you could collect the Link State topology of several IGP domains only with one BGP session to the Route Reflector / Cluster instead of one BGP session for each IGP domains. The BGP Route
Reflector / Cluster architecture provides also security and reliability in case of failure. From an operational point of view, it is very important to keep this feature in mind if the WG decides to go to a new protocol. Best Regards Olivier

>
> I will try to document my proposal and share with the team in the coming weeks. 
>
> Best,
> Robert
>
>
>         Just do routing.
>
>          
>
>         Deficit/Benefit:  
>
>         1. New protocol must be deployed along with
>
>         ISIS, OSPF and BGP. 
>
>         2. Interactions between BGP-LS
>
>          
>
>         Open issues:  What are potential error conditions for
>
>         Protocol interactions (ISIS/OSPF to DROID)?
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
-- 
Olivier Dugeon


_________________________________________________________________________________________________________________________

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.