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

[Gyan Mishra <[e-mail]>]

Hi Oliver

I believe the goal here is as the subject states is to investigate an
alternative to BGP-LS to avoid overloading of BGP so BGP remains clean for
internet routing functions only.

Regarding new IGP extensions to be encoded for stateful PCE that come up,
all solutions end up requiring a separate parser for OSPF and ISIS as the
TLVs are different.  So you are in the same boat regardless of if it’s
BGP-LS, PCEP-LS, IGP of Yang.

I think it’s a good idea to have multiple alternative to BGP-LS for
operators.

One major advantage of PCEP-LS is that if you already have a Centralized
PCE/SDN controller deployed you already have a PCEP session NBI to all the
nodes in each domain across H-PCE parents and child PCEs, do to the PCEP
infrastructure beong already present and now can be reused for PCEP-LS
instead of BGP-LS.

Thanks

Gyan

On Thu, Jun 30, 2022 at 6:13 AM <[e-mail]> wrote:

> 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.
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*