[168906] in North American Network Operators' Group
Re: SIP on FTTH systems
daemon@ATHENA.MIT.EDU (Mark Tinka)
Thu Feb 6 10:32:56 2014
From: Mark Tinka <mark.tinka@seacom.mu>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Date: Thu, 6 Feb 2014 17:32:14 +0200
In-Reply-To: <alpine.DEB.2.02.1402061547240.24915@uplift.swm.pp.se>
Cc: nanog@nanog.org
Reply-To: mark.tinka@seacom.mu
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--nextPart4340113.XUH7Neo0Kg
Content-Type: Text/Plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
On Thursday, February 06, 2014 04:56:15 PM Mikael=20
Abrahamsson wrote:
> Yes, this is for hundreds of thousands of customers. Why
> do you need customer management? You document where a
> certain fiber goes to (what port), and then this port
> goes to a certain customer. That is the only customer
> management you need.
>=20
> So you provision your L3 switch with a protocol based
> 0x86dd vlan per port, put a static /64 L3 subinterface
> into this vlan, then you have a built in DHCPv6(-PD)
> server in the same switch that hands out a static /56 on
> this vlan, plus hands out DNS-resolver etc. No dynamics,
> just static. You provision ACLs to only allow the /56,
> /64 and LL in on the L3 interface. You set ND cache max
> size to 20-50 entries per L3 subinterface to protect the
> 1024-2048 entries or whatever the L3 switch can handle.
> For IPv4 you need to do all the L2/L3-inspection magic
> in a common vlan.
> This is now a standalone unit and you don't need any
> central system to stay up and running in order to move
> IPv6 packets, and you support both directly attached
> computer or a residential gateway that wants PD.
I won't lie, it is impressive that you strung the network=20
this way. I can certainly see how it would work, although=20
I'm not sure how well it would scale if you're diddling=20
about with all sorts of kinky services beyond just access to=20
the Internet (certinaly a concern for me, anyway).
At previous job, we looked at various topologies and=20
deployment techniques for how to support large scale FTTH=20
installations, and one of the key issues is impact on the=20
control plane for locally-ran DHCP servers on the routers,=20
particularly when the same router is providing business=20
services as well. Some vendors have seen the light and are=20
finally running x86-based multi-core 64-bit CPU's for=20
control plane processing, and while this may help, CPU=20
horsepower is finite (although it would, most certainly,=20
scale better than a Layer 3 switch doing the same thing).
When you start to add services like Multicast for IPTv, and=20
depending on whether you run these switches in a ring or=20
not, and whether you're running Rosen MVPN vs. NG-MVPN, you=20
can quickly start to hit platform limits or feature=20
constraints.
> I did this type of DSL deplayment early 2000nds with an
> L3 switch and an ethernet DSLAM as media converter. This
> was obviously IPv4 only, but worked very well. At the
> same time the guys with central DHCP systems had a lot
> of country wide outages when the DHCP system went
> belly-up.
I don't believe in centralized BNG's; mostly because traffic=20
forwarding is not optimal. That and it's too much trust in=20
one device.
I prefer distributed BNG's (much like the topology you=20
describe, only just less your deployment in number given how=20
much you can scale a single Layer 3 switch to act as a=20
service termination device). Along with distributed BNG's,=20
you can also distribute DHCP servers, and multiple DHCP=20
servers can maintain lease state amongst each other to allow=20
for failover in case the primary DHCP server breaks. This is=20
a known design tactic, and helps to take away from the=20
issues of centralized architectures.
> I would never want to have MPLS that far out into the
> network.
This is a different topic, but what we did was deploy MPLS=20
all the way into the Metro-E access using Cisco's ME3600X=20
because there had simply been to much pain doing legacy=20
Layer 2-based Metro-E solutions (stringing VLAN's together=20
between end points, keeping hands away from VTP, e.t.c.).=20
This was in 2010, and by then, there wasn't any decent=20
devices cheap enough with sufficient features to make this=20
possible.
I'd certainly recommend this architecture for Metro-E=20
deployments focused on business-grade services. I don't=20
expect most to follow it given there is a large Layer 2-
based Metro-E installed base, but I think it will grow with=20
time.
Mark.
--nextPart4340113.XUH7Neo0Kg
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
iQIcBAABAgAGBQJS86sBAAoJEGcZuYTeKm+GTtAP/RRJKodmXe5cDTxonD/E2F96
FoENQoX/Q0xasNVpB0ZWLHQ6MWSW8oF2S2zzy4Vd9uYTz7OEYWe5T4PN9N+NZbe8
2M2xk9Zu6CAp1RaXCjcs3TllufRVkYWiW51sPn1NX/lGuRnew/qF4aFnfWyUe3bT
KYukm1EKZEvNyBneuuuyF40ncrHhcnuCSkufP9sDLZOua6F8Uwx5MkMg0Is8zwGU
nlt76AzYuLQbuHmHBZO43bYg3NsbBIeUxbhdZQAKJjd94L9YJW6ALOEC9KVm7Ism
K/Hd97lvI6HdUZMrN8SXNTybPzZMRMmy2hst1aB4x6kV2dYPOpF8e953V23x8Omf
jXRUmWuthovrvO63w2C/Inpp/LS6sqzOXKx9Oslg+AfqEZ6BAiIEiE0J3nNCOl7T
82RNrzBwwnVtI1QVLm9zH1dzJ49idKHB92KeBUYVd/NFh8E+0dfmxKID4/Ggx8CB
G5OaDG5vwJoVuWV/VFZdCyI9roDZPg6FlDObR7nFIufGP8L6hcFebXNJSD1cUF6y
0EgRfd2nBnI8L78iExxSQCncrEZx5fWbtzlNnYoD6LzjkJw4oLESUZTqoAZYBjSg
2+rr9aAIGtRRP3HFOkqNO4/lb7mC9ekzvyQbzV49ieJZeSOnrHT+41b7x5E3UM0Q
rT7WGtKQCt8TOehQFUpA
=yMms
-----END PGP SIGNATURE-----
--nextPart4340113.XUH7Neo0Kg--
