On Tue, May 20, 2025 at 3:54 PM Stephen Griffin <pktsl...@gmail.com> wrote: > > Hi Chris!
howdy! :) I'm glad to see you (even over email :) ) > > Yes, you are correct, I did look at multiple locations including another > Comcast customer. :) I figured as much... :) > As was mentioned elsewhere, this is only an issue if the advertised routes > are prover-independent aggregates. If the networks are deaggregated, this > becomes less of an issue, but that poses its own challenges, especially if > networks are (effectively) not able to be deaggregated. It is also a bit of > an operational chore, for both sides. > > In any event, I'm talking with 7922 under separate cover, but I wanted to > respond to my esteemed former colleague. :) awesome, I'm glad livinggood / et-al are helping out. Ideally this is making things better for you AND other folks :) -chris > Stephen > > On Wed, May 14, 2025 at 12:40 PM Christopher Morrow <morrowc.li...@gmail.com> > wrote: >> >> I'd guess that Stephen already checked the looking-glass at: >> ssh rview...@route-server.newyork.ny.ibone.comcast.net >> >> and validated that the prefix(s) in question are marked no-export... >> I suspect that a university also brings their own IP and ASN to the party, so >> seeing which prefixes have which communities is also something Stephen's done >> before asking the original question. >> >> yea... we can't (unless we are also comcast-campus-customers) know the >> contract >> particulars, but the question at the end seems reasonable. >> >> I'd suspect the overall assumption in the relationship is that the >> prefixes seen on >> 7922 from the neighbors are equality visible to all folks that default >> to comcast's network? >> perhaps this is a situation where: "access to the comcast eyeball set" >> is the goal of the relationship >> not 'access to ALL comcast customers' ? >> >> -chris >> >> On Wed, May 14, 2025 at 11:31 AM Brian Turnbow via NANOG >> <nanog@lists.nanog.org> wrote: >> > >> > Hi Stephen >> > >> > It really depends on the network you are advertising. >> > Say for example you are advertising a /24 or /48 that is part of a >> > block being advertised directly by 7922, or maybe the university's AS. >> > In this case even without announcing your netblock outside of 7922 they >> > will still be receiving the traffic via their announcement. so no >> > blackholing and traffic would still be coming in from the customers to you. >> > You can check this via looking glasses /route servers etc >> > Your logic would apply only to a unique netblock that is covered by another >> > announcement. >> > >> > HTH >> > Brian >> > >> > >> > >> > Brian Turnbow >> > +39 02 6706800 >> > [image: CDLAN SPA] >> > [image: CDLAN SPA] <https://www.cdlan.it//> | [image: CDLAN SPA - >> > LinkedIn] <https://it.linkedin.com/company/cdlan> >> > >> > >> > >> > Il giorno mer 14 mag 2025 alle ore 17:09 Stephen Griffin via NANOG < >> > nanog@lists.nanog.org> ha scritto: >> > >> > > So, I currently work for a university that offers Xfinity on Campus for >> > > our >> > > students. As part of that, we receive essentially peering.. with a >> > > twist... >> > > it is actually configured more like a normal customer. >> > > >> > > We're required to send 7922:999, which is essentially 7922's no-export. >> > > However, 7922:888 (7922+customers), seems like the better choice, while >> > > still respecting the goal of not providing transit. >> > > >> > > The former makes it such that 7922 doesn't advertise our prefixes to >> > > their >> > > BGP customers, which can lead to blackholes if their customer is >> > > default-free and their other provider(s) have an outage, or if the >> > > customer >> > > is doing link (but not provider) redundancy with BGP. It also means that >> > > billable traffic from xfinity customers to us is actually driven away >> > > from >> > > 7922, which would seem to not be in 7922's best interest (maybe folks no >> > > longer bill on usage?). >> > > >> > > no-export and its ilk just seems like the wrong choice in nearly every >> > > case, but I thought I would check myself with the assembled. >> > > >> > > Cheers, >> > > Stephen Griffin >> > > _______________________________________________ >> > > NANOG mailing list >> > > >> > > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/NBQIF6L6YZEGWGY7WAHJNKQT7ISVTVAJ/ >> > > >> > _______________________________________________ >> > NANOG mailing list >> > https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/STGC5JQCQO7R7T7MO3C4WVB57MR2WZMY/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/RZVR5E7IHTJHQN7IYUMBGJ2PNSIREFZO/
