Moin, > It might be good to follow up with RIPE NCC on how exactly they think > they can reliably observe 'multi-homing'. Yes. What also might help would be grabbing a lot more dataset, and seeing whether we could calculate an 'error rate'.
> Please note that "multi-homing" doesn't mean "having multiple transit > providers", as I understand the term multi-homing it simply means > that an AS has multiple adjacencies to other ASes (for example, 1 > upstream and 1 peering partner is multi-homing) Agreed; However, iirc, the NCC mostly interprets this as 'multi- upstream'. (Observational statement, not argument.) > yeah, the "Without exception, an AS must have only one routing > policy." sentence and the practise of using the same ASN in multiple > POPs without backbone seem somewhat at odds with each other. I would argue that, even with a bit of a backbone, PoPs will diverge in routing policies. > "prevalent BYOPIP use-cases also see a lot of single homed ASes"? Can > you point at these prevalent use-cases? I was mostly thinking of: https://docs.aws.amazon.com/vpc/latest/ipam/tutorials-byoasn.html and https://www.vultr.com/features/bgp/ It might be good to go through those cones to take a look at the ASes, though. > In my simple reading of RFC1930 IX Route Servers deployments are > covered in the Section 5.1 "Multi-homed site" category. I would disagree, as an IXes' ASN does not necessarily originate prefixes (the text talks about "the site's prefixes"), and 1930 puts (historically) an emphasis on own prefixes, not really considering transit-only ASes (or rather: Route reflector ASes). With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M [email protected] Pronouns: he/him/his _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
