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.

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.

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.

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.

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.

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.

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.

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 Abrahamsson email: swmike@swm.pp.se

----- Original Message -----

From: "Mikael Abrahamsson" <swmike@swm.pp.se>

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 jra@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

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.

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.

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.

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 Abrahamsson email: swmike@swm.pp.se

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

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

...

50000 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.

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.

----- Original Message -----

From: "Frank Bulk" <frnkblk@iname.com>

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 jra@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

----- Original Message -----

From: "Mikael Abrahamsson" <swmike@swm.pp.se>

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 jra@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

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.

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 Abrahamsson email: swmike@swm.pp.se

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 Abrahamsson email: swmike@swm.pp.se

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

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

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 Abrahamsson email: swmike@swm.pp.se

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.

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.

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.