Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

[Greg Shepherd]

So you haven't yet installed your home Holodeck?

On Mon, May 23, 2022 at 12:31 PM David Bass  wrote:

> What is changing in the next 5 years that could possibly require a
> household to need a gig?  That is just ridiculous.
>
> On Mon, May 23, 2022 at 3:15 PM Michael Thomas  wrote:
>
>>
>> On 5/23/22 12:04 PM, Thomas Nadeau wrote:
>> >
>> >
>> >> On May 23, 2022, at 3:00 PM, Michael Thomas  wrote:
>> >>
>> >>
>> >> On 5/23/22 11:49 AM, Aaron Wendel wrote:
>> >>> The Fiber Broadband Association estimates that the average US
>> household will need more than a gig within 5 years.  Why not just jump it
>> to a gig or more?
>> >>
>> >> Really? What is the average household doing to use up a gig worth of
>> bandwidth?
>> >>
>> >> Mike
>> > Thats almost the same question we were asked at BT a dozen years ago
>> when moving from DSL -> FTTC when someone said, “but surely DSL is
>> sufficient because its so much faster than dial.”
>>
>> The two of us survive just fine with 25Mbs even when we have a house
>> full of friends. I mean it would be nice to have 100Mbs so that it's
>> never a problem but the reality is that it just hasn't been a problem in
>> practice. I mean how many 4k streams are running at the same time in the
>> average household? What else besides game downloads are sucking up that
>> much bandwidth all of the time?
>>
>> Mike
>>
>>
>> >
>> > —Tom
>> >
>> >
>> >>>
>> >>> On 5/23/2022 1:40 PM, Sean Donelan wrote:
>> 
>> https://www.fcc.gov/document/fcc-proposes-higher-speed-goals-small-rural-broadband-providers-0
>> 
>>  The Federal Communications Commission voted [May 19, 2022] to seek
>> comment on a proposal to provide additional universal service support to
>> certain rural carriers in exchange for increasing deployment to more
>> locations at higher speeds. The proposal would make changes to the
>> Alternative Connect America Cost Model (A-CAM) program, with the goal of
>> achieving widespread deployment of faster 100/20 Mbps broadband service
>> throughout the rural areas served by rural carriers currently receiving
>> A-CAM support.
>> 
>>
>

Re: IPv6 Multicast Routing

[Greg Shepherd]

Globally unique multicast destination addresses have become
unnecessary since the advent of SSM. If you look at the IPv4 registry,
you'll what was essentially a land-grab of Group D address space back when
global multicast delivery was considered "on the horizon", and ASM was the
only option. Then there was GLOP for automatic assignments based on ASN,
then SSM. I co-authored a draft back in ~2003 (from memory..) to
deprecate global IPv6 ASM, but was over powered by vendor vote-stuffing,
and it was shot down. Nearly two decades later, a similar draft emerged and
is now a BCP: RFC8815

https://tools.ietf.org/html/rfc8815

No more global IPv6 group address assignments required.

- Shep



On Tue, Mar 2, 2021 at 1:36 PM Nicholas Warren 
wrote:

> Does IANA (
> https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml#variable)
> run the registry for IPv6 Multicast groups? “We do not make allocations
> directly to ISPs or end users except in specific circumstances, such as
> allocations of multicast addresses"
>
>
>
> There are only 112 registered multicast addresses? That seems low.
>
>
>
> Are some IPv6 multicast packets globally routable? Wikipedia says both yes
> and no.
>
> Should we be allowing packets with multicast addresses in/out of our
> network?
>

Re: SRv6

[Greg Shepherd]

Call me old, but I miss the days when this thread was still on the SRv6 rails. 
Can we get back the proper bashing to match this thread title? 

-Shep


> On Sep 21, 2020, at 13:54, James Bensley  wrote:
> 
> 
> 
> On 19 September 2020 03:23:15 BST, Randy Bush  wrote:
>>> Information can be in plaintext and private
>> 
>> Three can keep a secret, if two of them are dead.  -- franklin
>> 
>> i know you truely believe the tunnel k00laid.  the security
>> community does not.
> 
> Hi Randy,
> 
> I'm not sure what you're saying here, I never said MPLS VPNs are secure, only 
> private. I hope others recognise that they are different concepts.
> 
> Cheers,
> James.

Re: Multicast traffic % in enterprise network ?

[Greg Shepherd]

On Thu, Aug 9, 2018 at 11:41 AM, Curtis, Bruce 
wrote:

>
> Multicast was also required for earlier versions of VXLAN.  But later
> versions or VXLAN only require unicast.
>
> For the far future it seems like Named Data Neworking, Content Centric
> Networking, Information Centric Networking, Data Centric Networking etc all
> list multicast as a requirement or fundamental part of their architecture.


And they would all be better served by using BIER.

Greg


> > On Aug 8, 2018, at 4:15 PM, Greg Shepherd  wrote:
> >
> > Financial exchanges around the world use multicast.
> >
> > On Wed, Aug 8, 2018 at 1:31 PM, Stan Barber  wrote:
> >
> >> As someone else remarked, part of this will depend on the type of
> network
> >> you are profiling. One enterprise networking may have critical internal
> >> applications that depend on multicast to work and others may have
> nothing
> >> but the basic requirements of the network itself (e.g. IPv6 uses
> multicast
> >> instead of broadcast for some network control information distribution).
> >>
> >> On Wed, Aug 8, 2018 at 11:49 AM, Mankamana Mishra (mankamis) via NANOG <
> >> nanog@nanog.org> wrote:
> >>
> >>> Hi Every one,
> >>> Recently we had good discussion over multicast uses in public internet.
> >>> From discussion, it was pointed out uses of multicast is more with in
> >>> enterprise.  Wanted to understand how much % multicast traffic present
> in
> >>> network
> >>>
> >>>  *   If there is any data which can provide what % of traffic is
> >>> multicast traffic. And if multicast is removed, how much unicast
> traffic
> >> it
> >>> would add up?
> >>>  *   Since this forum has people from deployment area, I would love to
> >>> know if there is real deployment problems or its pain to deploy
> >> multicast.
> >>>
> >>>
> >>> These questions is to work / discussion in IETF to see what is pain
> >> points
> >>> for multicast, and how can we simplify it.
> >>>
> >>>
> >>>
> >>> Thanks
> >>> Mankamana
> >>>
> >>>
> >>
>
>
> ---
> Bruce Curtis bruce.cur...@ndsu.edu
> Certified NetAnalyst II701-231-8527
> North Dakota State University
>
>

Re: Multicast traffic % in enterprise network ?

[Greg Shepherd]

Financial exchanges around the world use multicast.

On Wed, Aug 8, 2018 at 1:31 PM, Stan Barber  wrote:

> As someone else remarked, part of this will depend on the type of network
> you are profiling. One enterprise networking may have critical internal
> applications that depend on multicast to work and others may have nothing
> but the basic requirements of the network itself (e.g. IPv6 uses multicast
> instead of broadcast for some network control information distribution).
>
> On Wed, Aug 8, 2018 at 11:49 AM, Mankamana Mishra (mankamis) via NANOG <
> nanog@nanog.org> wrote:
>
> > Hi Every one,
> > Recently we had good discussion over multicast uses in public internet.
> > From discussion, it was pointed out uses of multicast is more with in
> > enterprise.  Wanted to understand how much % multicast traffic present in
> > network
> >
> >   *   If there is any data which can provide what % of traffic is
> > multicast traffic. And if multicast is removed, how much unicast traffic
> it
> > would add up?
> >   *   Since this forum has people from deployment area, I would love to
> > know if there is real deployment problems or its pain to deploy
> multicast.
> >
> >
> > These questions is to work / discussion in IETF to see what is pain
> points
> > for multicast, and how can we simplify it.
> >
> >
> >
> > Thanks
> > Mankamana
> >
> >
>

Re: Broadcast television in an IP world

[Greg Shepherd]

Multicast is not PIM. PIM is dead.

https://datatracker.ietf.org/doc/rfc8279/

Significantly reduces the cost and complexity of network replication. Soon
to be on the standards track. What can't BIER do?

-shep

On Tue, Nov 21, 2017 at 8:58 AM, Mike Hammett  wrote:

> of the TV they use... through you. That doesn't count OTA, cable,
> satellite, etc.
>
> It won't change significantly any time soon. I know things are changing,
> but it'll still take five or ten years for those changes to significantly
> change traffic patterns.
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> - Original Message -
>
> From: "Baldur Norddahl" 
> To: nanog@nanog.org
> Sent: Tuesday, November 21, 2017 10:52:09 AM
> Subject: Re: Broadcast television in an IP world
>
> Den 21. nov. 2017 16.20 skrev "Mike Hammett" :
>
> Unicasting what everyone watches live on a random evening would use
> significantly more bandwidth than Game of Thrones or whatever OTT drop.
> Magnitudes more. It wouldn't even be in the same ballpark.
>
>
>
> I agree as of this moment however that will change. Also note that our
> customers do 100% of their TV as unicast OTT because that is the only thing
> we offer. This does not cause nearly as much problems as you would expect.
>
>

Re: Multicast Internet Route table.

[Greg Shepherd]

I'll try to be brief-ish..

Interdomain Multicast suffered from three fundamental problems:

1) Deering's original use cases are far different from what it's used for
today. His original intent was to create a broadcast domain overlay over an
L3 topology. With this came reqs which today are largely nothing more than
unnecessary complexity with limited security and stability. The primary bit
of baggage is network based source discovery - the idea that anyone can
send and everyone will get those packets. Today all we want are explicit
trees. SSM solves these issues, but requires IP stacks, apps, and networks
to all support SSM. BUT, the one bit that Deering got right which the
community ditched was overlay. He knew not all boxes would support it so
DVMRP included tunneling (which I think is the first RFC to use overlay
encapsulation, but I'm willing to be wrong here.) When PIM replaced DVMRP
we unfortunately retained network based source discovery (RPs, MSDP, etc..)
but ditched encapsulation. This caused number 2 below.

2) Everyone must enable it or nobody can really benefit from it. The push
for native multicast (PIM) at the end of the last century was well
intended, but failed. If we had made IGMP multi-hop or something similar to
provide jumping over unicast-only networks we may be in a different place
today. But today we do have AMT which is trying to solve this problem. Some
venders do support it and some networks have already rolled it out in
trials. This may have some hope in changing the game.

3) Multicast is UDP. Many of the multicast problems people have stated
here on the list can more accurately be classified as UDP problems. When
using UDP rather than TCP, congestion control and reliability need to be
addressed at the application layer. Some solutions have capitalized on this
requirement by engineering solutions for each independently rather than
being stuck trying to game TCP (see unicast ABR).

So, with SSM only, an overlay layer like AMT, and a resilient application
layer CC and reliability we may have the right tools to see a larger global
multicast footprint. Or we may have figured all this out a bit too late.

Greg


On Tue, Sep 2, 2014 at 9:48 AM, Dale W. Carder dwcar...@wisc.edu wrote:

 Thus spake Mikael Abrahamsson (swm...@swm.pp.se) on Tue, Sep 02, 2014 at
 06:05:42PM +0200:
  On Tue, 2 Sep 2014, Octavio Alvarez wrote:
 
  I have never used interdomain multicast but I imagine the global
 m-routing
  table would quickly become large.
 
  I have set up interdomain routing connecting both to a few peers and a
 Tier1
  transit provider. Not many non-research networks to be seen.
 
  Also, since we didn't use it it kept breaking and I had to fix it every
 two
  years or so, where it probably had been down for months.
 
  I don't believe in Internet-wide multicast happening in current
 incarnation,
  it's just too fragile and too few people are using it. It wouldn't scale
  either due to all the state that needs to be kept.

 Inter-domain multicast was largely replaced in practice by CDN's.

 In addition to scale issues in keeping state, large wireless L1
 environments
 are hostile to functioning multicast.

 Dale

CenturyLink Engineering contact?

[Greg Shepherd]

Is there someone on the list in CenturyLink Engineering involved in the
pacific north west? Please contact me off list.

Thanks,
Greg

Re: abha ahuja

[Greg Shepherd]

Deeply missed. I can't believe it's been that long.


On Sat, Oct 19, 2013 at 3:36 PM, Randy Bush ra...@psg.com wrote:

 abha ahuja, researcher and operator, died this day in 2001 at a
 tragically early age.  if you did not know her, search a bit.
 she did a lot, and with an open mind and heart.

 randy

Re: Comcast vs. Verizon for repair methodologies

[Greg Shepherd]

Oh to have choices... I'm still hanging on the end of a dedicated T1
and paying through the nose. I'm nearly convinced that the monthly
income from my circuit has prevented Qwest, and now Century Link from
building out DSL.

Greg

On Mon, Aug 20, 2012 at 4:43 PM, Randy Bush ra...@psg.com wrote:
 on bainbridge, i replaced centurystink dsl (756k/256k for $65/mo) with
 comcast (20m/4m for $50/mo).  the installer was a knarly old dog, and
 damned competent.  he cleaned up old cable on the pole and where it went
 underground to the house.  he cleaned up the box and replaced in-house
 junctions.  then he accidentally left 8m of coax to get from the in-wall
 cable outlet to my 'puter area, and rode off in his white van into the
 sunset.

 now if i could get that kind of professionalism from twt in hawaii ...

 randy

Re: mulcast assignments

[Greg Shepherd]

Sure, but GLOP predated SSM, and was really only an interim fix for
the presumed need of mcast address assignments. GLOP only gives you a
/24 for each ASN where SSM gives you a /8 for every unique unicast
address you have along with vastly superior security and network
simplicity.

Greg

On Thu, May 3, 2012 at 12:53 PM, Quentin Carpent
quentin.carp...@vtx-telecom.ch wrote:
 You can also use the glop IP addressing:
 http://tools.ietf.org/html/rfc3180

 Quentin

 -Original Message-
 From: Greg Shepherd [mailto:gjs...@gmail.com]
 Sent: Thu 5/3/2012 9:35 PM
 To: Philip Lavine
 Cc: NANOG list
 Subject: Re: mulcast assignments

 Why do you think you need an assigned mcast block? All inter domain
 mcast uses source trees only, so just use SSM and you don't need
 address assignments.

 Greg

 On Thu, May 3, 2012 at 12:24 PM, Philip Lavine source_ro...@yahoo.com wrote:
    How do I get a registered multicast block?

Re: mulcast assignments

[Greg Shepherd]

On Thu, May 3, 2012 at 1:19 PM, Owen DeLong o...@delong.com wrote:
 Simpler solution... Just set the P flag and use your unicast prefix as part 
 of the group ID.

 For example, if your unicast prefix is 2001:db8:f00d::/48, you could use:

 ff4e:2001:db8:f00d::group number

 Where group number is any number of your choosing up to 64 bits, but 
 recommended
 to be ≤32 bits.

 Make sense?

Sure, for v6. :)

Greg

 Owen

 On May 3, 2012, at 1:00 PM, Greg Shepherd wrote:

 Sure, but GLOP predated SSM, and was really only an interim fix for
 the presumed need of mcast address assignments. GLOP only gives you a
 /24 for each ASN where SSM gives you a /8 for every unique unicast
 address you have along with vastly superior security and network
 simplicity.

 Greg

 On Thu, May 3, 2012 at 12:53 PM, Quentin Carpent
 quentin.carp...@vtx-telecom.ch wrote:
 You can also use the glop IP addressing:
 http://tools.ietf.org/html/rfc3180

 Quentin

 -Original Message-
 From: Greg Shepherd [mailto:gjs...@gmail.com]
 Sent: Thu 5/3/2012 9:35 PM
 To: Philip Lavine
 Cc: NANOG list
 Subject: Re: mulcast assignments

 Why do you think you need an assigned mcast block? All inter domain
 mcast uses source trees only, so just use SSM and you don't need
 address assignments.

 Greg

 On Thu, May 3, 2012 at 12:24 PM, Philip Lavine source_ro...@yahoo.com 
 wrote:
    How do I get a registered multicast block?

Re: mulcast assignments

[Greg Shepherd]

On Thu, May 3, 2012 at 1:42 PM,  valdis.kletni...@vt.edu wrote:
 On Thu, 03 May 2012 13:38:14 -0700, Greg Shepherd said:
  Make sense?

 Sure, for v6. :)

 Does it make sense to be planning new deployments for anythign else? ;)

 (Hint - if your reaction is but we're not v6-capable, who's fault is that?)

The original question was not from me. :)

But even for IPv6 I would avoid embedded addressing and just use SSM.
With SSM there's no need for embedded addressing and again you get all
the security and network simplicity.

 FF3x::/96

Greg

Re: mulcast assignments

[Greg Shepherd]

On Thu, May 3, 2012 at 3:32 PM, Nick Hilliard n...@foobar.org wrote:
 On 03/05/2012 21:00, Greg Shepherd wrote:
 Sure, but GLOP predated SSM, and was really only an interim fix for
 the presumed need of mcast address assignments. GLOP only gives you a
 /24 for each ASN where SSM gives you a /8 for every unique unicast
 address you have along with vastly superior security and network
 simplicity.

 SSM is indeed a lot simpler and better than GLOP in every conceivable way -
 except vendor support.  It needs igmpv3 on all intermediate devices and SSM
 support on the client device.  All major desktop operating systems now have
 SSM support (OS/X since 10.7/Lion), but there is still lots of older
 hardware which either doesn't support igmpv3 or else only supports it in a
 very primitive fashion.  This can lead to Unexpected Behaviour in naive
 roll-outs.

I haven't seen a piece of network gear without SSM support in a very
long time. The weak link is the applications. It was the OS stacks but
that's finally caught up - it only took it 10 years...

The weakest link is simply multicast deployment - if it's not
everywhere it has little use. That's what AMT is promising to fix. And
with AMT comes the opportunity to bring SSM to non-SSM-capable apps if
it is implemented correctly.

Greg

 Nick

Re: last mile, regulatory incentives, etc (was: att fiber, et al)

[Greg Shepherd]

On Thu, Mar 22, 2012 at 3:11 PM,  valdis.kletni...@vt.edu wrote:
 On Thu, 22 Mar 2012 13:40:27 -0700, Owen DeLong said:
 Yes, I find it quite amusing that I am paying additional fees on all
 of my telecommunications services to subsidize high speed PON networks
 in rural bumf*ck while I can't get anything like it in San Jose, California.

 That's OK, you're all in the same boat - the subsidized users can't get it 
 either. :)

So where are these subsidies going? I live in rural BFE where most
of my neighbors are still dialing in, and the local providers have no
$$ incentive to build out here.

Greg