Hello Robert, I just read the first document, I guess for most people could be "interesting" too see BGP Auto Discovery, I'm not sure yet if I'm in favor or against.
Hope this is not a crazy comment. Well, in the document you (and other co-authors) do not mention much about -any possible- impact this mechanism could have in bgp route selection algorithm (which anyhow is by default managed by vendors and modified by administrators). As far as I could understand from your doc, routers can identify which prefixes were learnt by auto-discovered devices and which were learnt by the "traditional" BGP operation. Am I right? which one would you trust more?, new administrative distance or something like that?. Thanks, Alejandro, On 12/11/19 3:24 PM, Robert Raszuk wrote: > Dear WG, > > We have seen formation of BGP Autodiscovery WG followed by total > silence. Well maybe group is > live just not everyone got onto its private list :) > > Regardless of this I refreshed and resubmitted two proposals in this > very space. > > > 1. BGP Auto Discovery > > > https://tools.ietf.org/html/draft-raszuk-idr-bgp-auto-discovery-06 > > > and > > > 2. BGP Automated Session Setup > > > https://tools.ietf.org/html/draft-raszuk-idr-bgp-auto-session-setup-01 > > *_Ad 1:_* > First document is focused on WAN and IX scenario where establishing > full mesh of IBGP or > selected eBGP peering can automate the operational management tasks or > if run in informational > mode could validate NMS session setup correctness. > Original proposal was presented many years ago in Vienna and at that > point suggested extension to > IGPs to flood discovery information for IBGP auto mesh. Later based on > the input and discussions with > Pedro the proposal got simplified to use classic Route Reflector as > bootstrap node (info broker). > Last input from Jon and Warren added the ability to also automate > setup of eBGP sessions in selected > scenarios. > Since then the document was shelved for some time waiting for IDR WG > turn to deal with discovery topic. > So here we are. > *_Ad 2: _* > The second document first published in July 2018 provides a very > trivial to implement mechanism (without > even changing BGP state machine) to automatically establish common LAN > or p2p interfaces BGP sessions. > Typical use case would be Clos DC fabrics, customer PE-CE LANs, TORs > to Compute Nodes etc ... > Comments, questions, feedback on both proposals all very welcome. > Kind regards, > Robert. > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow
pEpkey.asc
Description: application/pgp-keys
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
