RE: Xfinity on Campus

[Bryan Ward via NANOG <nanog () lists nanog org>]

I've got one of these circuits too, and it's very strange how they handle them internally.
From Comcast's point of view, these circuits don't even exist!  They're not configured the same way as their 
"customers" circuits are.
That means, calling for support for them is next to impossible...
The goal of the circuit is to just provide IPTV traffic and nothing else.
But, as you've been suggesting, you can adjust the BGP communities to use it for other purposes, such as advertising to 
their customers within their AS or even using the circuit for transit...
I'd caution against this, as the commit rate is fairly low from what I've experienced, but it does work.




--
Bryan Ward
Lead Network Engineer
Dartmouth College Network Services

-----Original Message-----
From: Eric C. Miller via NANOG <nanog () lists nanog org>
Sent: Wednesday, May 14, 2025 4:00 PM
To: North American Network Operators Group <nanog () lists nanog org>
Cc: Stephen Griffin <pktslngr () gmail com>; Eric C. Miller <eric () ericheather com>
Subject: Re: Xfinity on Campus

I think Brian may have touched on this earlier in the thread, but a dirty way to accomplish would be sending to AS7922 
your de-aggregated /24s with the noexport community. Send your aggregates(> /24) to your transit provider(s). If a 
AS7922 customer is default-free, they'd find you through your transit, if they default through AS7922, they reach you 
there. Path asymmetry is still a concern on both sides though.

I concur with the earlier statement about resolving through your customer rep. AS7922+Customers feels more natural 
while still maintaining their ability to later sell you transit.

Eric
________________________________
From: John van Oppen via NANOG <nanog () lists nanog org>
Sent: Wednesday, May 14, 2025 2:24 PM
To: North American Network Operators Group <nanog () lists nanog org>
Cc: Stephen Griffin <pktslngr () gmail com>; John van Oppen <john () vanoppen com>
Subject: RE: Xfinity on Campus

No export is pretty obviously the wrong choice here, what you want is announce to customers only.

-----Original Message-----
From: Christopher Morrow via NANOG <nanog () lists nanog org>
Sent: Wednesday, May 14, 2025 9:41 AM
To: North American Network Operators Group <nanog () lists nanog org>
Cc: Stephen Griffin <pktslngr () gmail com>; Christopher Morrow <morrowc.lists () gmail com>
Subject: Re: Xfinity on Campus

I'd guess that Stephen already checked the looking-glass at:
  ssh rviewsxr () 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:3 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/ST
> GC5JQCQO7R7T7MO3C4WVB57MR2WZMY/
_______________________________________________
NANOG mailing list
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/6KG5YOZNZ6RC7FJH2IUFUHVYDWGIXHZP/
_______________________________________________
NANOG mailing list
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/5JX56YQMCC2KJFM5PJHML4EIALGFKS4D/
_______________________________________________
NANOG mailing list
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/YK4AYYV7KNCWQ6JR4UVBQXEKVVRXIEET/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/26SNFNKCYLWKCANBE34FL7JL6B24H72R/