On Mon, Jan 22, 2024 at 1:27 PM Owen DeLong <o...@delong.com> wrote: > > > > On Jan 21, 2024, at 16:10, Christopher Morrow <morrowc.li...@gmail.com> wrote: > > > > > On Sun, Jan 21, 2024, 5:39 PM Owen DeLong <o...@delong.com> wrote: >> >> >> >> On Jan 21, 2024, at 12:07, Christopher Morrow <morrowc.li...@gmail.com> >> wrote: >> >> >> >> >> On Fri, Jan 19, 2024, 4:55 PM Owen DeLong via NANOG <nanog@nanog.org> wrote: >>> >>> Sounds like you’ve got a weird mix of route origination. Why wouldn’t you >>> advertise to Google via BGP and have your prefix originate from your own >>> ASN? >> >> >> >> I think in this case the customer has their own disconnected deployment, and >> they are asking 396982 to announce some subset of their prefixes such that >> gcp gets that traffic. >> >> >> If that’s the case, IMHO, the better solution is to obtain a second ASN and >> announce that to GCP. Create ROAs (if you want to use RPKI) accordingly. > > > That's not the product today, and really this is all accomplished with cloud > goop inside gcp. (aws and azure have similar offerings, I believe) > > > Interesting. It’s what several of my consulting clients are doing. They > simply treat the cloud provider as an upstream peer on their cloud virtual > router and bgp as normal (ish, those cloud virtual routers are pretty > strange). >
yes the 'cloud router' things are strange, and odd and 'not the same' across various product/providers. I know that some offerings permit a more 'direct control' of the bgp conversation betewen customer and cloud provider and internet, but that's not a universal thing :( Sometimes because 'bgp is hard', I imagine the product thought process went.
