SIP on FTTH systems
Quick question: I am thinking in a possible wholesale FTTH environment operated by a telco where the end user is connected to ISP-X via PPPoE. ONTs have built-in ATAs that can provide POTS service to a house and do SIP/VoIP over the fibre with QoS system to ensure VoIP traffic gets through. In a scenario where the data PPPoE connection is done by an external router, what are the options to operate the VoIP service so that - VoIP still uses the special lane on the GPON with QoS - VoIP gets IP from ISP-X and traffic flow via ISP-X so that telco is not involved in routing such traffic or allocating an IP address ? Is the only option to program the ONT to establish its own PPPoE session to the ISP that carries only SIP traffic (and can such a setup make use of the special "lane" reserved for VoIP traffic ? on the gPON system ?) What other scenarios exist ? In normal incumbent-only FTTH systems, does the OLT provision a special IP to the ATA via DHCP and intercepts that traffic to hand off to a local SIP server and never touches the internet ? In the USA, do CLECs have access to homes served only by FTTH ? If so, how it is accomplisehd ?
RE: SIP on FTTH systems
In our vendor's implementation, the main access shelf hands out IPs to the "ATAs" integrated in the ONTs over a separate VLAN. No PPPoE required. Frank -Original Message- From: Jean-Francois Mezei [mailto:jfmezei_na...@vaxination.ca] Sent: Wednesday, February 05, 2014 10:53 PM To: nanog@nanog.org Subject: SIP on FTTH systems Quick question: I am thinking in a possible wholesale FTTH environment operated by a telco where the end user is connected to ISP-X via PPPoE. ONTs have built-in ATAs that can provide POTS service to a house and do SIP/VoIP over the fibre with QoS system to ensure VoIP traffic gets through. In a scenario where the data PPPoE connection is done by an external router, what are the options to operate the VoIP service so that - VoIP still uses the special lane on the GPON with QoS - VoIP gets IP from ISP-X and traffic flow via ISP-X so that telco is not involved in routing such traffic or allocating an IP address ? Is the only option to program the ONT to establish its own PPPoE session to the ISP that carries only SIP traffic (and can such a setup make use of the special "lane" reserved for VoIP traffic ? on the gPON system ?) What other scenarios exist ? In normal incumbent-only FTTH systems, does the OLT provision a special IP to the ATA via DHCP and intercepts that traffic to hand off to a local SIP server and never touches the internet ? In the USA, do CLECs have access to homes served only by FTTH ? If so, how it is accomplisehd ?
Re: SIP on FTTH systems
On 14-02-06 00:07, Frank Bulk wrote: > In our vendor's implementation, the main access shelf hands out IPs to the > "ATAs" integrated in the ONTs over a separate VLAN. No PPPoE required. Thanks. This would imply that in a wholesale environment, use of the integrated ATA would have to be charged separatly with the telco then handing off SIP traffic from the OLT to (likely) a nearby CLEC SIP server that is colocated (or pay for transit to internet to reach distant SIP server) I know that in the australian NBN plan, they do charge separatly to access the "dedicated" VoIP service, but this is meant more as a means to access the QoS managed bandwidth than to deal with handoff and IP management service that is performed locally instead of by the ISP.
Re: SIP on FTTH systems
Subject: SIP on FTTH systems Date: Wed, Feb 05, 2014 at 11:52:51PM -0500 Quoting Jean-Francois Mezei (jfmezei_na...@vaxination.ca): > Quick question: > > I am thinking in a possible wholesale FTTH environment operated by a > telco where the end user is connected to ISP-X via PPPoE. > > ONTs have built-in ATAs that can provide POTS service to a house and do > SIP/VoIP over the fibre with QoS system to ensure VoIP traffic gets through. > > In a scenario where the data PPPoE connection is done by an external > router, what are the options to operate the VoIP service so that > > - VoIP still uses the special lane on the GPON with QoS > > - VoIP gets IP from ISP-X and traffic flow via ISP-X so that telco is > not involved in routing such traffic or allocating an IP address ? Or, one could make sure everything has a globally unique IP address and is using reasonably secured communications. The downside is that one then can't defend the existence of those empire-building middleboxes. It is not the telco way, so is of course unthinkable. Like anything beyond WAP was on cell phones a decade ago. Warum soll man es einfach machen, wenn man es so schön komplizieren kann? (Why make things simple when you can build them so beautifully complicated?) -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 We are now enjoying total mutual interaction in an imaginary hot tub ... signature.asc Description: Digital signature
Re: SIP on FTTH systems
On Thursday, February 06, 2014 09:19:59 AM Måns Nilsson wrote: > Or, one could make sure everything has a globally unique > IP address and is using reasonably secured > communications. The downside is that one then can't > defend the existence of those empire-building > middleboxes. It is not the telco way, so is of course > unthinkable. Like anything beyond WAP was on cell phones > a decade ago. There are, typically, three topology models for modern FTTH (wireline, really) networks that a service provider could deploy: 1. SVLAN N:1 model 2. CVLAN 1:1 model 3. Hybrid of both The SVLAN (N:1) model is simple; just have a single VLAN for each service (VLAN 10 for Internet/Unicast, VLAN 20 for VoIP, VLAN 30 for IPTv/Multicast). This is simple and easy to scale, but if one is using relatively "dumb" AN's (like GPON's or MSAN's), it can be difficult to control how much bandwidth customers need, and how they can roam between services in the home (given CPE ties services to ports). The CVLAN (1:1) model is good for identifying services and bandwidth requirements on a per-customer basis. The main problem with this model is that Multicast traffic gets treated like Unicast, because each customer has a unique VLAN for themselves, and as such, the upstream PE router ends up having to replicate the same linear video stream as many times as there are customers down the line. The Hybrid model, where CVLAN's are used for all Unicast traffic (Internet, VoIP and VoD, typically), and a single SVLAN is used for all customers to handle Multicast traffic (so-called MVLAN). The challenge here is if you're the type of operator that likes to have a consistent set of address per VLAN, it can become a little tricky if your VoIP service is a walled-garden running on private IP space, given it shares the same VLAN as Internet and VoD which would normally run on public IP space. The N:1 SVLAN model is quite simple and scalable for wholesale FTTH services. There is product from some vendors, now, that is built with FTTH in mind. 1U, dense switches (Active-E) that support (reasonably) proper QoS and bandwidth management controls on customer- and core-facing ports, at Layer 2. So that offers you a lot more capability at the AN, and you can manage bandwidth as close to the customer as possible, unlike typical GPON deployments which may not have these features, leaving you to apply bandwidth policy at the PE router - much too far up the line. These new products can also support split horizons across bridge domains (which GPON's and DSLAM's do today), meaning that customers can use the same SVLAN's, but can only communicate via the upstream router (Layer 3), eliminating risk associated with Layer 2 visibility between customers connected to the same bridge domain. Cheers, Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
Time for users to consider splitting L2 services from IP ? Christian de Larrinaga > On 6 Feb 2014, at 08:01, Mark Tinka wrote: > > On Thursday, February 06, 2014 09:19:59 AM Måns Nilsson > wrote: > >> Or, one could make sure everything has a globally unique >> IP address and is using reasonably secured >> communications. The downside is that one then can't >> defend the existence of those empire-building >> middleboxes. It is not the telco way, so is of course >> unthinkable. Like anything beyond WAP was on cell phones >> a decade ago. > > There are, typically, three topology models for modern FTTH > (wireline, really) networks that a service provider could > deploy: > >1. SVLAN N:1 model >2. CVLAN 1:1 model >3. Hybrid of both > > The SVLAN (N:1) model is simple; just have a single VLAN for > each service (VLAN 10 for Internet/Unicast, VLAN 20 for > VoIP, VLAN 30 for IPTv/Multicast). This is simple and easy > to scale, but if one is using relatively "dumb" AN's (like > GPON's or MSAN's), it can be difficult to control how much > bandwidth customers need, and how they can roam between > services in the home (given CPE ties services to ports). > > The CVLAN (1:1) model is good for identifying services and > bandwidth requirements on a per-customer basis. The main > problem with this model is that Multicast traffic gets > treated like Unicast, because each customer has a unique > VLAN for themselves, and as such, the upstream PE router > ends up having to replicate the same linear video stream as > many times as there are customers down the line. > > The Hybrid model, where CVLAN's are used for all Unicast > traffic (Internet, VoIP and VoD, typically), and a single > SVLAN is used for all customers to handle Multicast traffic > (so-called MVLAN). The challenge here is if you're the type > of operator that likes to have a consistent set of address > per VLAN, it can become a little tricky if your VoIP service > is a walled-garden running on private IP space, given it > shares the same VLAN as Internet and VoD which would > normally run on public IP space. > > The N:1 SVLAN model is quite simple and scalable for > wholesale FTTH services. > > There is product from some vendors, now, that is built with > FTTH in mind. 1U, dense switches (Active-E) that support > (reasonably) proper QoS and bandwidth management controls on > customer- and core-facing ports, at Layer 2. So that offers > you a lot more capability at the AN, and you can manage > bandwidth as close to the customer as possible, unlike > typical GPON deployments which may not have these features, > leaving you to apply bandwidth policy at the PE router - > much too far up the line. > > These new products can also support split horizons across > bridge domains (which GPON's and DSLAM's do today), meaning > that customers can use the same SVLAN's, but can only > communicate via the upstream router (Layer 3), eliminating > risk associated with Layer 2 visibility between customers > connected to the same bridge domain. > > Cheers, > > Mark.
Re: SIP on FTTH systems
On Thursday, February 06, 2014 11:56:45 AM cdel.firsthand.net wrote: > Time for users to consider splitting L2 services from IP > ? But consumer broadband is all about IP; the Layer 2 is needed to transport that IP, and that's a network problem, not a user one. Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
On Thu, 6 Feb 2014, Mark Tinka wrote: There are, typically, three topology models for modern FTTH (wireline, really) networks that a service provider could deploy: 1. SVLAN N:1 model 2. CVLAN 1:1 model 3. Hybrid of both There are more. There are models where each ISP gets its own customer vlan and L2 equipment do inspection of ARP/ND and does security filtering on L2/L3 using this information. There are also L3 networks where the traffic is source-routed out to the correct ISP, or each ISP gets its own VRF in the equipment and it's VRF a long way out. To the original poster. People using PPPoE for FTTH makes me sad. When someone suggests this, please just say "go back to the drawingboard, redo it right". -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: SIP on FTTH systems
On Thursday, February 06, 2014 02:15:57 PM Mikael Abrahamsson wrote: > There are more. There are models where each ISP gets its > own customer vlan and L2 equipment do inspection of > ARP/ND and does security filtering on L2/L3 using this > information. There are also L3 networks where the > traffic is source-routed out to the correct ISP, or each > ISP gets its own VRF in the equipment and it's VRF a > long way out. Agree. The models I listed are typical to an operator that runs its own infrastructure (including the FTTH last mile), and does not necessarily wholesale out to other operators. I've seen certain countries that have given the incumbents leeway to wholesale at the IP level, which the incumbent likes because they "perceive" more control than if they had to hand-off Layer 2 wholesale. In such cases, VRF's and/or logical routers have been deployed. > To the original poster. People using PPPoE for FTTH makes > me sad. When someone suggests this, please just say "go > back to the drawingboard, redo it right". Agree. DHCP really is the way to go, now. Plus, there is good support for IPv6 with vendors today re: DHCP-based subscriber management. Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
On Thu, 6 Feb 2014, Mark Tinka wrote: The models I listed are typical to an operator that runs its own infrastructure (including the FTTH last mile), and does not necessarily wholesale out to other operators. I disagree on that one as well. It might be in some markets, but it's not in all. I've seen certain countries that have given the incumbents leeway to wholesale at the IP level, which the incumbent likes because they "perceive" more control than if they had to hand-off Layer 2 wholesale. In such cases, VRF's and/or logical routers have been deployed. This wasn't incumbents specifically, but just a different model to achieve the same thing, give end users access to multiple ISPs, multiple "cable TV" vendors, and multiple VOIP providers through a neutral network. Agree. DHCP really is the way to go, now. Plus, there is good support for IPv6 with vendors today re: DHCP-based subscriber management. What do you mean by subscriber management? This worked 10 years ago, what problem are you saying has been solved recently? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: SIP on FTTH systems
On Thursday, February 06, 2014 02:29:40 PM Mikael Abrahamsson wrote: > I disagree on that one as well. It might be in some > markets, but it's not in all. I keep using the word "typical", but not sure if you're missing it. Typical, not limited to, i.e., common, but not the only option. I'm basing this on what I've seen in various countries across a few continents I've worked in. > This wasn't incumbents specifically, but just a different > model to achieve the same thing, give end users access > to multiple ISPs, multiple "cable TV" vendors, and > multiple VOIP providers through a neutral network. Again, just an example I gave, not to say it was the norm. The countries I was referring to is where the incumbents either owned the infrastructure and were reluctant to open it up to competitors, or were awarded national broadband projects to deploy and run the infrastructure but were not specifically governed to how low the OSI Layer they can open up the infrastructure to. In other places, it is a business model, in addition to more traditional ways of unbundling. These tend to be more evolved markets, but again, not limited to. > What do you mean by subscriber management? This worked 10 > years ago, what problem are you saying has been solved > recently? End user authentication and management typically being done via PPPoE because that was the best and most secure way to manage customer connections (for some operators, still is). By DHCP I mean an alternative to PPPoE-based authentication where Option 82 and friends can allow service providers to authenticate customers based on AN port, MAC address, VLAN ID, e.t.c., instead of username/password a la PPPoE. This gets passed as part of initial DHCP transactions. Rethinking your comment (because I thought you meant DHCP as the way to go for subscriber management when you debunked PPPoE) I'm guessing you refer to simply assigning IP addresses to customer interfaces in FTTH scenarios? No? Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
On Thu, 6 Feb 2014, Mark Tinka wrote: End user authentication and management typically being done via PPPoE because that was the best and most secure way to manage customer connections (for some operators, still is). Why do you need to authenticate the customer? Don't your documentation system know the port/subscriber mapping? And why is this secure, instead of being tied to a physical connection the customer can now take the credentials and move? If the credentials are stolen, someone else can impersonate that customer. By DHCP I mean an alternative to PPPoE-based authentication where Option 82 and friends can allow service providers to authenticate customers based on AN port, MAC address, VLAN ID, e.t.c., instead of username/password a la PPPoE. This gets passed as part of initial DHCP transactions. This worked 10 years ago, it's nothing recent. Rethinking your comment (because I thought you meant DHCP as the way to go for subscriber management when you debunked PPPoE) I'm guessing you refer to simply assigning IP addresses to customer interfaces in FTTH scenarios? No? Yes? Since option 82 and friends gives you what port the DHCP request came in on, you now log IP/MAC connected to a port, and since you know to what apartment/house this port is physically connected to, nothing more is needed. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: SIP on FTTH systems
On Thursday, February 06, 2014 02:58:14 PM Mikael Abrahamsson wrote: > Why do you need to authenticate the customer? Don't your > documentation system know the port/subscriber mapping? > And why is this secure, instead of being tied to a > physical connection the customer can now take the > credentials and move? If the credentials are stolen, > someone else can impersonate that customer. Which is why I said DHCP was better than PPPoE. Failing to see where we disagree. > This worked 10 years ago, it's nothing recent. In my previous post, I didn't say it was recent. I said it was better than PPPoE if you're deploying FTTH now. What I said was recent was that DHCP_IA and DHCP_IA_PD implementation has improved significantly both in BNG's as well as CPE. Again, failing to see where we disagree. > Yes? Since option 82 and friends gives you what port the > DHCP request came in on, you now log IP/MAC connected to > a port, and since you know to what apartment/house this > port is physically connected to, nothing more is needed. Again, don't see where we disagree. This is a good thing. Some operators provide services with no subscriber management (i.e., no PPPoE, no DHCP; just a static IP address documented about where it is, what street, what building, what floor, what apartment, what customer), while other service providers have a subscriber management technique, PPPoE or DHCP, to log all the same information in concert with the backend. I'm just saying DHCP is better than PPPoE if you're greenfielding FTTH deployments today, and I'm not sure you entirely disagree. Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
On Thu, 6 Feb 2014, Mark Tinka wrote: I'm just saying DHCP is better than PPPoE if you're greenfielding FTTH deployments today, and I'm not sure you entirely disagree. We're in violent agreement it seems. My only beef was that it seemed like you were implying this was something new. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: SIP on FTTH systems
On 2014-02-06 09:01, Mark Tinka wrote: 1. SVLAN N:1 model The SVLAN (N:1) model is simple; just have a single VLAN for each service (VLAN 10 for Internet/Unicast, VLAN 20 for VoIP, VLAN 30 for IPTv/Multicast). This is a deep hole, and basically does not work with IPv6. You need a bunch of stuff, proxy ND, proxy DAD, DHCPv6 inspection, RA guard and more. One VLAN per customer and a separate multicast is much simpler. Or do something bold, run L3 at the edge :) /Anders
Re: SIP on FTTH systems
On Thursday, February 06, 2014 03:46:54 PM Mikael Abrahamsson wrote: > We're in violent agreement it seems. Tend to agree. > My only beef was > that it seemed like you were implying this was something > new. In most of my travels, there is a healthy amount of resistance toward DHCP from new (but mostly, existing) broadband service providers when choosing between DHCP and PPPoE for Unicast traffic. And the reasons for this vary - we saw the OP is PPPoE-biased, for example. It is better in 2014 than it was in 2011 in those places, but by and large, DHCP adoption for subscriber management is not moving as quickly as one would think, especially when you consider all the FTTH work going on around the world. Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
On Thursday, February 06, 2014 03:51:51 PM Anders Löwinger wrote: > This is a deep hole, and basically does not work with > IPv6. > > You need a bunch of stuff, proxy ND, proxy DAD, DHCPv6 > inspection, RA guard and more. One VLAN per customer and > a separate multicast is much simpler. If you have a reasonably intelligent AN (like some of today's Active-E devices), you can create so-called split horizons on the same bridge domain (VLAN, really) where customers will only communicate via the upstream BNG at Layer 3. At Layer 2, even though they are all sitting on the same VLAN, there is no inter-communication between them. I've also know Huawei OLT's support these split horizons too. > Or do something bold, run L3 at the edge :) BNG's are too big to distributed that deeply, even in distributed BNG designs. This would get costly. Cheap switches that have decent IP/MPLS support are mostly geared toward Metro-E deployments, i.e., business-grade services. So they are quite poor with regard to susbcriber management features and capabilities. Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
On Thu, 6 Feb 2014, Mark Tinka wrote: Or do something bold, run L3 at the edge :) BNG's are too big to distributed that deeply, even in distributed BNG designs. This would get costly. You don't need a BNG. You need an L3 switch as the first hop the customer is talking to. Cheap switches that have decent IP/MPLS support are mostly geared toward Metro-E deployments, i.e., business-grade services. So they are quite poor with regard to susbcriber management features and capabilities. If you have L3-in-vlan-per-customer at the first hop then you don't really need all of that. If you include rudimentary VRF support then you can even support wholesale. /64 per customer, DHCPv6(-PD) server support in the L3 switch and you're good to go. There is equipment that already claim to do this (I never got to test their implementation based on my requirements because I switched jobs, but they claimed to have implemented everything last year). -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: SIP on FTTH systems
On Thursday, February 06, 2014 04:17:42 PM Mikael Abrahamsson wrote: > You don't need a BNG. You need an L3 switch as the first > hop the customer is talking to. Fine for FTTB, but not for FTTH where you're serving tens- to-hundreds-of-thousands of customers. If your FTTH deployments are low scale (measure of low or large scale depends on each operator's point of view), the case for doing without subscriber management technologies can be made. > If you have L3-in-vlan-per-customer at the first hop then > you don't really need all of that. If you include > rudimentary VRF support then you can even support > wholesale. /64 per customer, DHCPv6(-PD) server support > in the L3 switch and you're good to go. I'm curious; in these deployments, what kind of customer scale are you talking about? When someone says FTTH, I'm thinking thousands and thousands of customers, in which case not having a scalable susbcriber management system as well as not having a scalable customer termination topology could be difficult. Unless I misunderstand... > There is > equipment that already claim to do this (I never got to > test their implementation based on my requirements > because I switched jobs, but they claimed to have > implemented everything last year). Modern Metro-E switches that support full IP/MPLS in the Access have a lot of good IPv4 and IPv6 features, including DHCP_IA and DHCP_IA_PD, but again, these are more FTTB- than FTTH-focused, if you're talking about scale. Cheers, Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
On Thu, 6 Feb 2014, Mark Tinka wrote: On Thursday, February 06, 2014 04:17:42 PM Mikael Abrahamsson wrote: You don't need a BNG. You need an L3 switch as the first hop the customer is talking to. Fine for FTTB, but not for FTTH where you're serving tens- to-hundreds-of-thousands of customers. Why? If your FTTH deployments are low scale (measure of low or large scale depends on each operator's point of view), the case for doing without subscriber management technologies can be made. Why is it different? I'm curious; in these deployments, what kind of customer scale are you talking about? When someone says FTTH, I'm thinking thousands and thousands of customers, in which case not having a scalable susbcriber management system as well as not having a scalable customer termination topology could be difficult. Unless I misunderstand... 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. 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 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 only a few years later learnt what an LNS was when I talked to someone else who did more of a "follow-the-whitepaper" deployment of DSL. Modern Metro-E switches that support full IP/MPLS in the Access have a lot of good IPv4 and IPv6 features, including DHCP_IA and DHCP_IA_PD, but again, these are more FTTB- than FTTH-focused, if you're talking about scale. I would never want to have MPLS that far out into the network. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: SIP on FTTH systems
On Thursday, February 06, 2014 04:56:15 PM Mikael 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. > > 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 this way. I can certainly see how it would work, although I'm not sure how well it would scale if you're diddling about with all sorts of kinky services beyond just access to the Internet (certinaly a concern for me, anyway). At previous job, we looked at various topologies and deployment techniques for how to support large scale FTTH installations, and one of the key issues is impact on the control plane for locally-ran DHCP servers on the routers, particularly when the same router is providing business services as well. Some vendors have seen the light and are finally running x86-based multi-core 64-bit CPU's for control plane processing, and while this may help, CPU horsepower is finite (although it would, most certainly, scale better than a Layer 3 switch doing the same thing). When you start to add services like Multicast for IPTv, and depending on whether you run these switches in a ring or not, and whether you're running Rosen MVPN vs. NG-MVPN, you can quickly start to hit platform limits or feature 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 forwarding is not optimal. That and it's too much trust in one device. I prefer distributed BNG's (much like the topology you describe, only just less your deployment in number given how much you can scale a single Layer 3 switch to act as a service termination device). Along with distributed BNG's, you can also distribute DHCP servers, and multiple DHCP servers can maintain lease state amongst each other to allow for failover in case the primary DHCP server breaks. This is a known design tactic, and helps to take away from the 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 all the way into the Metro-E access using Cisco's ME3600X because there had simply been to much pain doing legacy Layer 2-based Metro-E solutions (stringing VLAN's together between end points, keeping hands away from VTP, e.t.c.). This was in 2010, and by then, there wasn't any decent devices cheap enough with sufficient features to make this possible. I'd certainly recommend this architecture for Metro-E deployments focused on business-grade services. I don't expect most to follow it given there is a large Layer 2- based Metro-E installed base, but I think it will grow with time. Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
On 14-02-06 08:06, Mark Tinka wrote: > I'm just saying DHCP is better than PPPoE if you're > greenfielding FTTH deployments today, and I'm not sure you > entirely disagree. When an incumbent already has PPPoE deployed for its DSL, putting FTTH on PPPoE makes it simpler. And PPPoE really simplifies wholesale systems. You do not want the incumbent/wholesaler to perform DHCP. This is a HUGE headache. We have that in Canada for cable wholesale (TPIA). The incumbent has to micromanage each ISPs IP blocks and carve subnets for each CMTS (for cable). For as much as everyone hates PPPoE, it makes for managememnt of a wholesale systems much much easier. Ideally, there would be some protocol where the CPE would setup a layer 2 SVC to the ISP, after which the ISP can provide DHCP services etc.
Re: SIP on FTTH systems
On Thu, 6 Feb 2014, Jean-Francois Mezei wrote: You do not want the incumbent/wholesaler to perform DHCP. This is a HUGE headache. We have that in Canada for cable wholesale (TPIA). The incumbent has to micromanage each ISPs IP blocks and carve subnets for each CMTS (for cable). You could have the wholesaler do DHCP inspection and antispoofing etc based on that, but not actually do the DHCP servering. For as much as everyone hates PPPoE, it makes for managememnt of a wholesale systems much much easier. FTTH is supposed to be for higher speeds, putting PPPoE in there makes it a lot more expensive than it has to be. Ideally, there would be some protocol where the CPE would setup a layer 2 SVC to the ISP, after which the ISP can provide DHCP services etc. I don't see that needed, doesn't the wholesaler already know what port has chosen what ISP and can set up L2 to that ISP? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: SIP on FTTH systems
On Thursday, February 06, 2014 06:38:23 PM Jean-Francois Mezei wrote: > When an incumbent already has PPPoE deployed for its DSL, > putting FTTH on PPPoE makes it simpler. And that is the practical issue I saw (and still see). A lot of operators just continue with it because it is maturely deployed in their networks, and attempting DHCP may not be as easy. Would I recommend trying DHCP, hell yes! > And PPPoE really simplifies wholesale systems. > You do not want the incumbent/wholesaler to perform DHCP. > This is a HUGE headache. We have that in Canada for > cable wholesale (TPIA). The incumbent has to micromanage > each ISPs IP blocks and carve subnets for each CMTS (for > cable). > > For as much as everyone hates PPPoE, it makes for > managememnt of a wholesale systems much much easier. In one country I worked, we pressured the incumbent to offer us Layer 2 backhaul instead of Layer 3, for the very same reasons. Co-managing IP address assignments, e.t.c., was problematic, especially because they were not sure how large their network was going to grow, which presented us with planning challenges in how we pre-assign address space for each of their service PoP's. Of course, because the regulator had done their job re: unbundling the fibre, they didn't care how wholesale services were actually provided over said fibre. And yes, the incumbent jumped at the chance not to offer Layer 2 backhaul, because then they knew everything we were up to (to some degree of measure). > Ideally, there would be some protocol where the CPE would > setup a layer 2 SVC to the ISP, after which the ISP can > provide DHCP services etc. Some of the vendors I've worked with don't support LNS functionality on their current generation BNG's. Just LAC. In this scenario, for PPPoE-centric operators and wholesalers, VPLS has been used to backhaul customer traffic, as opposed to L2TP, and recently, some vendors are now able to do this over EoMPLS pw's instead. If you have some control over the AN's that go into the incumben's/wholesaler's CO, you can get that Layer 2 connection (VPLS or EoMPLS pw) between your backbone and the CPE, that way. Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
On 2014-02-06 15:08, Mark Tinka wrote: You need a bunch of stuff, proxy ND, proxy DAD, DHCPv6 inspection If you have a reasonably intelligent AN (like some of today's Active-E devices), you can create so-called split horizons on the same bridge domain (VLAN, really) where customers will only communicate via the upstream BNG at Layer 3. At Layer 2, even though they are all sitting on the same VLAN, there is no inter-communication between them. Ok, then you have not understood the problem with IPv6 in shared VLANs. You need to allow some communication between the user ports on L2, to get the IPv6 control procotol to work. You do this on IPv4 today, with proxy arp etc. Its much more complex in IPv6. I've also know Huawei OLT's support these split horizons too. Many devices support what Cisco calls Private VLAN or MACFF as specificed in RFC4562. There are IPv4 only implementations today - but not all these protocols are standardized, and are not interoperable between vendors. I have still not heard of any vendor shipping the same functionality to share VLANs with IPv6, in a secure way. Or do something bold, run L3 at the edge :) Cheap switches that have decent IP/MPLS support are mostly geared toward Metro-E deployments, i.e., business-grade services. So they are quite poor with regard to susbcriber management features and capabilities. You need a basic L3 access switch, with some tweaks. I've been working at and designing such devices for seven years at my former employeer PacketFront Networks. Whole bunch of standard protocols. OSPF, PIM-SM, IGMPv2/v3 in the edge, and now with OSPFv3, PIM-SMv6 and MLD/MLDv2. DHCPv4/v6 is relayed to the correct service provider, unless its management traffic and should be handled by the network. Very easy, very few security issues since no L2 is allowed between customers, no strange protocols (ARP inspection, proxy ARP, IP source guard, DHCP Snooping/option82 or their IPv6 counterparts). Open-access is done on the L3 layer, no VLANs. There are free seating in the CPE so all equipment in the home can talk to each other. Important with todays DLNA/TV sets and mobile phones. It is very scalable, since that is how Internet is built :) Of course, it needs a proper management system, so we built one as well. We also pushed Python into the access device, so DHCPv4/DHCPv6, radius, 802.1x functionality and how those are used can easily be adjusted in a script instead of trying to express programming in a CLI. On top of that some simple templates describing the services. The radius server just returns the service name with needed parameters (bandwidth, priority etc) and the python script installs/removes instances of the service as needed. I promise this access device has NO problems with spoofed packets, see the BCP38 discussion :) So, it's a small BNG in the access device. And no, it's not that expensive. We did look at sourcing a L2 switch from Taiwan, we could get the switch with L2 or L3 forwarding in a Broadcom switch ASIC, all the other features was equal. Cost difference was five dollars. (PacketFronts access device uses a NPU, much more flexible) Vendors charging both an arm and a leg for routers are doing that because they can, doing L3 is not more expensive than L2 with todays technology. PacketFront has sold over 1 miljon ports, and the largest installation is >5 ports, both in Sweden, Holland and Dubai. This can easily scale to much bigger networks. The biggest issue with selling L3 to the edge is not technical or economical, its religious - people are just so used to build their networks in a specific way and they don't want to change /Anders
Re: SIP on FTTH systems
On Thu, 6 Feb 2014, Anders Löwinger wrote: Ok, then you have not understood the problem with IPv6 in shared VLANs. You need to allow some communication between the user ports on L2, to get the IPv6 control procotol to work. You do this on IPv4 today, with proxy arp etc. Its much more complex in IPv6. No, you don't. It works perfectly well without direct port-to-port communication, you just have to align L3 configuration with this L2 behavior (which can be done in IPv6 but not in IPv4). IPv6 can be made to work without on-link /64, with only DHCPv6 IA_NA (optional) and only DHCPv6-PD. This means all communication goes via the router which then is perfectly aligned with how the L2 looks like with port isolation/private vlan. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: SIP on FTTH systems
On Thursday, February 06, 2014 07:41:34 PM Anders Löwinger wrote: > Ok, then you have not understood the problem with IPv6 in > shared VLANs. You need to allow some communication > between the user ports on L2, to get the IPv6 control > procotol to work. You do this on IPv4 today, with proxy > arp etc. Its much more complex in IPv6. No, it's not, and no, you don't. Active-E and GPON AN's support split horizons where shared VLAN's allow for simple service delivery to the CPE, but do not permit inter-customer communications at Layer 2. All communications happens upstream at the BNG, which works for IPv4 and IPv6. And no, Proxy ARP is recommended for my competitors. If you're not my competitor, suggest you turn it off if you want happiness. > Many devices support what Cisco calls Private VLAN or > MACFF as specificed in RFC4562. There are IPv4 only > implementations today - but not all these protocols are > standardized, and are not interoperable between vendors. > I have still not heard of any vendor shipping the same > functionality to share VLANs with IPv6, in a secure way. And that is why for modern Active-E kit, I prefer to enable split horizons using split horizon tech. against bridge domains, rather than Private VLAN's. Private VLAN's have lots of restrictions, and on AN's that support EVC (Cisco- style), you can enable split horizons on bridge domains, which works perfectly for Layer 2 and Layer 3 traffic. > PacketFront has sold over 1 miljon ports, and the largest > installation is > > >5 ports, both in Sweden, Holland and Dubai. This > >can easily scale to > > much bigger networks. The system specs. are impressive - basically, a little BNG in a switch, which I can't complain with. I suppose if I'm a business that wants to consolidate BNG and business services on a single platform, the existing routers I pay big money for to enable those business servics can double as BNG's. It's distributed, uniform and a single place where I can offer multiple services to different types of customers. But, if I'm a business with a low start-up budget focused on broadband services, or lots of cash with no plans to break into the enterprise or service provider markets, the PacketFront make sense. My only concern would be NG-MVPN support - does the PacketFront have that? > The biggest issue with selling L3 to the edge is not > technical or economical, its religious - people are just > so used to build their networks in a specific way and > they don't want to change Well: - I support DHCP instead of PPPoE for subscriber management. - I support decentralized rather than centralized BNG's. - I support Active-E rather than GPON. These are all relatively less-than-popular scenarios based on many of the deployments I've seen in previous years. So while I agree that there is a healthy amount of religion to these things, there is also room for change if the reasons are compelling. But yes, it can come down to personal taste by one person in the company. Cheers, Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
On Thursday, February 06, 2014 09:04:40 PM Mikael Abrahamsson wrote: > No, you don't. It works perfectly well without direct > port-to-port communication, you just have to align L3 > configuration with this L2 behavior (which can be done > in IPv6 but not in IPv4). > > IPv6 can be made to work without on-link /64, with only > DHCPv6 IA_NA (optional) and only DHCPv6-PD. This means > all communication goes via the router which then is > perfectly aligned with how the L2 looks like with port > isolation/private vlan. Yep. Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
On Wed, Feb 5, 2014 at 11:52 PM, Jean-Francois Mezei < jfmezei_na...@vaxination.ca> wrote: > Quick question: > > In the USA, do CLECs have access to homes served only by FTTH ? If so, > how it is accomplisehd ? > > In practice CLECs do not have access. The TR order of the last decade mandated that access via FTTH was not a section 251 requirement under the Telco Act of 1996 except for a 64kbs stream which in theory could be used for voice. However, I believe there has been no widescale use of that feature because it is uneconomical compared to "over-the-top" VoIP. -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134
RE: SIP on FTTH systems
And then you need MACFF to overcome the split-horizon to that customers in the same subnet can talk to each other. =) Frank -Original Message- From: Mark Tinka [mailto:mark.ti...@seacom.mu] Sent: Thursday, February 06, 2014 8:09 AM To: nanog@nanog.org Subject: Re: SIP on FTTH systems On Thursday, February 06, 2014 03:51:51 PM Anders Löwinger wrote: > This is a deep hole, and basically does not work with > IPv6. > > You need a bunch of stuff, proxy ND, proxy DAD, DHCPv6 > inspection, RA guard and more. One VLAN per customer and > a separate multicast is much simpler. If you have a reasonably intelligent AN (like some of today's Active-E devices), you can create so-called split horizons on the same bridge domain (VLAN, really) where customers will only communicate via the upstream BNG at Layer 3. At Layer 2, even though they are all sitting on the same VLAN, there is no inter-communication between them. I've also know Huawei OLT's support these split horizons too. > Or do something bold, run L3 at the edge :) BNG's are too big to distributed that deeply, even in distributed BNG designs. This would get costly. Cheap switches that have decent IP/MPLS support are mostly geared toward Metro-E deployments, i.e., business-grade services. So they are quite poor with regard to susbcriber management features and capabilities. Mark.
Re: SIP on FTTH systems
- Original Message - > From: "Frank Bulk" > And then you need MACFF to overcome the split-horizon to that > customers in the same subnet can talk to each other. =) In my not-at-all humble opinion, in an eyeball network, you almost *never* want to make it easier for houses to talk to one another directly; there isn't any "real" traffic there. Just attack traffic. Well, ok; slim chance of P2P, but carriers hate that anyway, right? :-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: SIP on FTTH systems
On Fri, 7 Feb 2014, Jay Ashworth wrote: In my not-at-all humble opinion, in an eyeball network, you almost *never* want to make it easier for houses to talk to one another directly; there isn't any "real" traffic there. Just attack traffic. But creating a solution where you can talk to anyone else on the Internet but not the ones in your own neighborhood is broken, so it needs to be fixed. In IPv4 I've seen this solved with local-proxy-arp within the subnet, and for IPv6 it's easily solvable by not announcing an on-link network so they won't even try to communicate directly with each other but instead everything is routed via the ISP upstream router and then down again to the other customer CPE/computer. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: SIP on FTTH systems
- Original Message - > From: "Mikael Abrahamsson" > On Fri, 7 Feb 2014, Jay Ashworth wrote: > > In my not-at-all humble opinion, in an eyeball network, you almost > > *never* want to make it easier for houses to talk to one another > > directly; there isn't any "real" traffic there. Just attack traffic. > > But creating a solution where you can talk to anyone else on the Internet > but not the ones in your own neighborhood is broken, so it needs to be > fixed. In IPv4 I've seen this solved with local-proxy-arp within the > subnet, and for IPv6 it's easily solvable by not announcing an on-link > network so they won't even try to communicate directly with each other but > instead everything is routed via the ISP upstream router and then down > again to the other customer CPE/computer. I did not show my work. I apologize. I will try again: If I am a commercial customer of an eyeball ISP like Road Runner: *I am entitled to expect that that ISP is technically capable of protecting me from possible attack traffic from that other customer*, who's outside my administrative span of control. If they can send me traffic directly across a local access subnet, that requires a much larger hammer than if such traffic must cross the edge concentrator first, the configuration I assert is a better choice. Does that help? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: SIP on FTTH systems
On Fri, 7 Feb 2014, Jay Ashworth wrote: If I am a commercial customer of an eyeball ISP like Road Runner: *I am entitled to expect that that ISP is technically capable of protecting me from possible attack traffic from that other customer*, who's outside my administrative span of control. If they can send me traffic directly across a local access subnet, that requires a much larger hammer than if such traffic must cross the edge concentrator first, the configuration I assert is a better choice. Does that help? Violent agreement. Customers should not talk L2 directly to each other using local switching, but they should be able to send IP packets to each other. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: SIP on FTTH systems
On Friday, February 07, 2014 09:11:38 AM Mikael Abrahamsson wrote: > Violent agreement. Customers should not talk L2 directly > to each other using local switching, but they should be > able to send IP packets to each other. And in fairness, given the positive security benefits (barring extreme corner cases or hardware/software bugs), the otherwise sub-optimal tromboning between homes via the BNG is an acceptable compromise. Mark. signature.asc Description: This is a digitally signed message part.
RE: SIP on FTTH systems
Rather than assign residential and business customers their own /30, to conserve space we give those customers a /32 out of a /24. But when one of these static IP customers wants to send email to another, or the employee wants to VPN into work, they can't. MACFF is supposed to solve that (we haven't turned it on, yet, because the vendor's implementation requires us to do some work on our provisioning system to make it easier). Frank -Original Message- From: Jay Ashworth [mailto:j...@baylink.com] Sent: Thursday, February 06, 2014 11:59 PM To: NANOG Subject: Re: SIP on FTTH systems - Original Message - > From: "Frank Bulk" > And then you need MACFF to overcome the split-horizon to that > customers in the same subnet can talk to each other. =) In my not-at-all humble opinion, in an eyeball network, you almost *never* want to make it easier for houses to talk to one another directly; there isn't any "real" traffic there. Just attack traffic. Well, ok; slim chance of P2P, but carriers hate that anyway, right? :-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: SIP on FTTH systems
On Friday, February 07, 2014 03:30:08 PM Frank Bulk wrote: > Rather than assign residential and business customers > their own /30, to conserve space we give those customers > a /32 out of a /24. But when one of these static IP > customers wants to send email to another, or the > employee wants to VPN into work, they can't. This is akin to Private VLAN's where ports in a shared VLAN are assigned numbers from the same subnet, but they can only communicate via the BNG rather than directly at the bridge level. I prefer EVC Split Horizon to Private VLAN's, though. Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
I would assume that this whole mostly depends on which particular protocols and approaches your edge equipment can implement most efficiently - efficiently enough, that is, to be able to do it on every single port in a chassis. On February 7, 2014 10:20:08 AM EST, Mark Tinka wrote: >On Friday, February 07, 2014 03:30:08 PM Frank Bulk wrote: > >> Rather than assign residential and business customers >> their own /30, to conserve space we give those customers >> a /32 out of a /24. But when one of these static IP >> customers wants to send email to another, or the >> employee wants to VPN into work, they can't. > >This is akin to Private VLAN's where ports in a shared VLAN >are assigned numbers from the same subnet, but they can only >communicate via the BNG rather than directly at the bridge >level. > >I prefer EVC Split Horizon to Private VLAN's, though. > >Mark. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: SIP on FTTH systems
On Friday, February 07, 2014 05:41:44 PM Jay Ashworth wrote: > I would assume that this whole mostly depends on which > particular protocols and approaches your edge equipment > can implement most efficiently - efficiently enough, > that is, to be able to do it on every single port in a > chassis. Well, Split Horizon would be enabled on all the customer- facing ports. I am not aware of any protocol restrictions when running Split Horizon. I haven't run into any issues yet. Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
- Original Message - > From: "Mikael Abrahamsson" > To the original poster. People using PPPoE for FTTH makes me sad. When > someone suggests this, please just say "go back to the drawingboard, > redo it right". FWIW, when I dug this ground a couple Thanksgivings ago, I was looking at AE over home-run to an MDF; that was 12,000 or so passings in about 3 sqmi, muni. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: SIP on FTTH systems
On 2014-02-06 20:04, Mikael Abrahamsson wrote: No, you don't. It works perfectly well without direct port-to-port communication, you just have to align L3 configuration with this L2 behavior (which can be done in IPv6 but not in IPv4). IPv6 can be made to work without on-link /64, with only DHCPv6 IA_NA (optional) and only DHCPv6-PD. This means all communication goes via the router which then is perfectly aligned with how the L2 looks like with port isolation/private vlan. Yes, you are of course correct. I was thinking about selective filtering information between ports, but that is stupid/way too complex and most hardware cannot do that in a good way. I guess you still need proxy-ND or similar as described in RFC4389, and you don't accept clients with IP addresses not assigned over DHCPv6. Fair tradeoffs, SLAAC does not work with abuse etc. /Anders
Re: SIP on FTTH systems
Active-E and GPON AN's support split horizons where shared VLAN's allow for simple service delivery to the CPE, but do not permit inter-customer communications at Layer 2. Yes. All communications happens upstream at the BNG, which works for IPv4 and IPv6. And no, Proxy ARP is recommended for my competitors. If you're not my competitor, suggest you turn it off if you want happiness. So, as I wrote to Mikael, don't you need to use proxy-ARP or proxy-ND to get devices in same L2 domain to be able to communicate? They are on same subnet so they will ARP/ND for each other. > The system specs. are impressive - basically, a little BNG > in a switch, which I can't complain with. There is no rocket science here. Scripting in routers/switches seems to be more common, Cisco has TCL and some Nexus and Arista boxes do Python. There is only some hooks into the control/forwarding plane needed to do advanced services in access. Forwarding plane is covered mostly by SDN so half the work is done. In a 24/48 port access switch there are few clients, so scripting performance is not a problem. But, if I'm a business with a low start-up budget focused on broadband services, or lots of cash with no plans to break into the enterprise or service provider markets, the PacketFront make sense. My only concern would be NG-MVPN support - does the PacketFront have that? They working on all the MPLS stuff to be able to sell L2 and L3 VPN services. Well: - I support DHCP instead of PPPoE for subscriber management. - I support decentralized rather than centralized BNG's. - I support Active-E rather than GPON. These are all relatively less-than-popular scenarios based on many of the deployments I've seen in previous years. Agree, the above list is music in my ears :) /Anders
Re: SIP on FTTH systems
On 2014-02-07 07:14, Mikael Abrahamsson wrote: and for IPv6 it's easily solvable by not announcing an on-link network so they won't even try to communicate directly with each other but instead everything is routed via the ISP upstream router and then down again to the other customer CPE/computer. I'm curious on the details: 1) Do you give the client 64 bit using RA (with the A and L bit cleared), 64 bit using DHCPv6, then force the traffic through the default since on-link is not set? Has there been any test if modern operating systems honor this? (I've seen some firewalls doing this, not sure it was by design, they changed the default in later code) 2) Do you only use link-local on the customer port, and use a L3 CPE & DHCP-PD? Always a learning experience reading Nanog /Anders
Re: SIP on FTTH systems
On Sat, 8 Feb 2014, Anders Löwinger wrote: I guess you still need proxy-ND or similar as described in RFC4389, and you don't accept clients with IP addresses not assigned over DHCPv6. Fair tradeoffs, SLAAC does not work with abuse etc. No, you don't need to do Proxy-ND either. With this solution there is no need for the users to talk directly to each other, even though they're sitting in the same vlan. They have no clue about each other and don't need to know because they will have a prefix delegated to their LL address and a default gateway, and perhaps an IA_NA if the ISP wants to, but that's it. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: SIP on FTTH systems
On Sat, 8 Feb 2014, Anders Löwinger wrote: I'm curious on the details: 1) Do you give the client 64 bit using RA (with the A and L bit cleared), 64 bit using DHCPv6, then force the traffic through the default since on-link is not set? Correct. Has there been any test if modern operating systems honor this? Well, they would be defective if they didn't. Also, you don't even need to announce the prefix at all, even with L-bit cleared. You can make RAs with M and O bit set that won't contain any prefix at all. Been there, done that. At least linux worked perfectly. Do you only use link-local on the customer port, and use a L3 CPE & DHCP-PD? That's one way of doing it, or you give it an IA_NA as well if you want a WAN address. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: SIP on FTTH systems
On Saturday, February 08, 2014 04:41:55 AM Anders Löwinger wrote: > So, as I wrote to Mikael, don't you need to use proxy-ARP > or proxy-ND to get devices in same L2 domain to be able > to communicate? They are on same subnet so they will > ARP/ND for each other. No, you don't, and you don't want to either. You customers will have visibility to one another at Layer 2 if you don't enable Split Horizon, MAC-FF, Private VLAN's, or whatever implementation your favorite vendor uses to prevent inter-communication between customers in a shared VLAN at the AN/bridge level. While it seems sensible, it normally isn't a good idea. The majority of what will take place between customers at Layer 2 is dirt. Best to run them through a Layer 3 device upstream and apply appropriate filtering. > There is no rocket science here. Scripting in > routers/switches seems to be more common, Cisco has TCL > and some Nexus and Arista boxes do Python. > > There is only some hooks into the control/forwarding > plane needed to do advanced services in access. > Forwarding plane is covered mostly by SDN so half the > work is done. > > In a 24/48 port access switch there are few clients, so > scripting performance is not a problem. I'm more impressed by the braveness of this implementation, than the actual implementation itself, I mean. In our case, given the number of customers in question that would terminate on a BNG (be it a small switch or big router), long term control plane performance is a huge concern, as well as how the hardware handles Multicast and other corner-case services in various topologies. Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
On Saturday, February 08, 2014 06:38:29 AM Mikael Abrahamsson wrote: > That's one way of doing it, or you give it an IA_NA as > well if you want a WAN address. We prefer DHCP_IA_NA to ND/RA. But yes, either option works. Just depends on operator choice as well as BNG and CPE support. Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
On Sat, 8 Feb 2014, Mark Tinka wrote: On Saturday, February 08, 2014 06:38:29 AM Mikael Abrahamsson wrote: That's one way of doing it, or you give it an IA_NA as well if you want a WAN address. We prefer DHCP_IA_NA to ND/RA. I have never heard anyone refer to SLAAC as IA_NA. I meant the DHCP kind. When saying IA_NA and IA_PD, you should take for granted people mean DHCP. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: SIP on FTTH systems
On Saturday, February 08, 2014 09:08:43 AM Mikael Abrahamsson wrote: > I have never heard anyone refer to SLAAC as IA_NA. Because it's not. I said "prefer DHCP_IA_NA to ND/RA". > When saying IA_NA and IA_PD, you should take for granted > people mean DHCP. Anders asked whether ND/RA for the CPE WAN address + DHCP_IA_PD (commonly written as DHCP-PD) is a valid option, to which you replied DHCP_IA_NA can be used for the CPE WAN address as well, to which I added I prefer (over ND/RA, that is). Again, violent agreement, Mikael. Whether I write "DHCP_IA_NA or just IA_NA", "DHCP_IA_PD or just DHCP-PD" it is all implicitly understood to mean "the DHCP kind". Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
On 2014-02-08 05:38, Mikael Abrahamsson wrote: Has there been any test if modern operating systems honor this? Well, they would be defective if they didn't. Also, you don't even need to announce the prefix at all, even with L-bit cleared. You can make RAs with M and O bit set that won't contain any prefix at all. Been there, done that. Pretty clever. Not sure why I missed this it is fairly clear in the RFCs. Is there not an issue with this if the customer is connected directly to the access device over L2? They will not communicate with each other direcly, all traffic will be exchanged through the default gateway? (same as has been seen with proxy-arp in such networks) > At least linux worked perfectly. I think I need to do some experiments here... /Anders
Re: SIP on FTTH systems
On Tue, 11 Feb 2014, Anders Löwinger wrote: Is there not an issue with this if the customer is connected directly to the access device over L2? They will not communicate with each other direcly, all traffic will be exchanged through the default gateway? Yes, what's the problem with that? (same as has been seen with proxy-arp in such networks) Local-proxy-arp, yes. I think I need to do some experiments here... I'd venture to say that any IPv6 implementation that doesn't support this is broken and should be fixed by the implementor. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: SIP on FTTH systems
On 2014-02-11 23:41, Mikael Abrahamsson wrote: Is there not an issue with this if the customer is connected directly to the access device over L2? They will not communicate with each other direcly, all traffic will be exchanged through the default gateway? Yes, what's the problem with that? Bad description by me. I'll try again. If I have two PCs in my home, connected with GE to a L2 switch and I buy 10 Mbit Internet access, I don't want traffic between my two PCs to be exchanged through the default route. They could possible communicate directly using link-local, but I'm not sure how they would find each other? Default gw could send a redirect... I'd venture to say that any IPv6 implementation that doesn't support this is broken and should be fixed by the implementor. Agree. /Anders
RE: SIP on FTTH systems
In the scenario you're describing does each PC get its own /64 (or /56 or /48) directly from the service provider? Or are they in the same netblock? Frank -Original Message- From: Anders Löwinger [mailto:and...@abundo.se] Sent: Tuesday, February 11, 2014 6:33 PM To: Mikael Abrahamsson Cc: nanog@nanog.org Subject: Re: SIP on FTTH systems On 2014-02-11 23:41, Mikael Abrahamsson wrote: >> Is there not an issue with this if the customer is connected directly to the >> access device over L2? They will not communicate with each other direcly, >> all traffic will be exchanged through the default gateway? > > Yes, what's the problem with that? Bad description by me. I'll try again. If I have two PCs in my home, connected with GE to a L2 switch and I buy 10 Mbit Internet access, I don't want traffic between my two PCs to be exchanged through the default route. They could possible communicate directly using link-local, but I'm not sure how they would find each other? Default gw could send a redirect... > I'd venture to say that any IPv6 implementation that doesn't support this is > broken and should be fixed by the implementor. Agree. /Anders
RE: SIP on FTTH systems
On Tue, 11 Feb 2014, Frank Bulk wrote: In the scenario you're describing does each PC get its own /64 (or /56 or /48) directly from the service provider? Or are they in the same netblock? They would each get their own /128 via DHCPv6 IA_NA, and they would end up having this /128 and a default route, nothing else, so all traffic between them on their GUA addresses would go over the ISP connection. Only way to solve this is for the customer to buy a router that uses IA_PD, put the PCs behind it, and then they would be able to communicate directly with each other. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: SIP on FTTH systems
On 2014-02-12 05:47, Frank Bulk wrote: In the scenario you're describing does each PC get its own /64 (or /56 or /48) directly from the service provider? Or are they in the same netblock? They are connected through a L2 switch directly to the access port. Mikael responded in another email, and verified that traffic will be exchanged trough the default gateway even if the PCs are in the same home. If CPE is L3 capable it's not an issue. /Anders
Re: SIP on FTTH systems
On Thursday, February 13, 2014 11:37:54 AM Anders Löwinger wrote: > They are connected through a L2 switch directly to the > access port. > > Mikael responded in another email, and verified that > traffic will be exchanged trough the default gateway > even if the PCs are in the same home. > > If CPE is L3 capable it's not an issue. Ideally, CPE would be Layer 3-capable. I can see situations where providers offer you only one port off their AN into your home. I can also see this further enhanced with permiting only one MAC address on that port. In such a case, a IP-capable CPE device is ideal. Mark. signature.asc Description: This is a digitally signed message part.
