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.
>
>
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, an
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 defau
msson
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 wi
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?
B
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?
(s
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 contai
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 CP
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 DH
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.
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 wan
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
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 solut
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.
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 m
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 DHC
- 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
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.
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,
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 t
t (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:
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
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 th
- 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
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 anyon
- 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
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 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 t
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 w
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
> ar
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 i
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 on
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
dep
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 hav
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 simpl
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
>
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
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 sc
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 t
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
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 (
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 bun
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.
--
Mika
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
> crede
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
syst
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 b
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.
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
> traf
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 g
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
Descripti
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 reason
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 th
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
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
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
55 matches
Mail list logo
