Re: RINA - scott whaps at the nanog hornets nest :-)

[Mark Smith]

On Sun, 7 Nov 2010 01:07:17 -0700
"George Bonser"  wrote:

> > >
> > > Yes, I really don't understand that either.  You would think that
> the
> > > investment in developing and deploying all that SONET infrastructure
> > > has been paid back by now and they can lower the prices
> dramatically.
> > > One would think the vendors would be practically giving it away,
> > > particularly if people understood the potential improvement in
> > > performance, though the difference between 1500 and 4000 is probably
> > > not all that much except on long distance ( >2000km ) paths.
> > 
> > Careful, you're rapidly working your way up to nanog kook status with
> > these absurd claims based on no logic whatsoever.
> 
> My aploligies.  It just seemed to me that the investment in SONET,
> particularly the lower data rates, should be pretty much paid back by
> now.  How long has OC-12 been around?  I can understand a certain amount
> of premium for something that doesn't sell as much but the difference in
> prices can be quite amazing in some markets. Some differential might be
> justified but why so much?
> 
> An OC-12 SFP optic costs nearly $3,000 from one vendor, list.  Their
> list price for a GigE SFP optical module is about 30% of that.  What is
> it about the optic module that would cause it to be 3 times as expensive
> for an interface with half the bandwidth?  A 4-port OC-12 module is
> 37,500 list.  A 4-port 10G module is $10,000 less for 10x the bandwidth.
> 
> In other words, what is the differential in the manufacturing costs of
> those?  I don't believe it is as much as the differential in the selling
> price.
> 
> 
> 

Once the base manufacturing cost is covered, supply and demand dictate
the price a.k.a. "you charge what the market will bear." While at least
one person/organisation continues to pay sonet/sdh pricing, that's what
will be charged.

Re: RINA - scott whaps at the nanog hornets nest :-)

[Mark Smith]

On Sun, 7 Nov 2010 01:49:20 -0600
Richard A Steenbergen  wrote:

> On Sun, Nov 07, 2010 at 08:02:28AM +0100, Mans Nilsson wrote:
> > 
> > The only reason to use (10)GE for transmission in WAN is the 
> > completely baroque price difference in interface pricing. With todays 
> > line rates, the components and complexity of a line card are pretty 
> > much equal between SDH and GE. There is no reason to overcharge for 
> > the better interface except because they (all vendors do this) can.
> 
> To be fair, there are SOME legitimate reasons for a cost difference. For 
> example, ethernet has very high overhead on small packets and tops out 
> at 14.8Mpps over 10GE, whereas SONET can do 7 bytes of overhead for your 
> PPP/HDLC and FCS etc and easily end up doing well over 40Mpps of IP 
> packets. The cost of the lookup ASIC that only has to support the 
> Ethernet link is going to be a lot cheaper, or let you handle a lot more 
> links on the same chip.
> 
> At this point it's only half price gouging of the silly telco customers 
> with money to blow. There really are significant cost savings for the 
> vendors in using the more popular and commoditized technology, even 
> though it may be technically inferior. Think of it like the old IDE vs 
> SCSI wars, when enough people get onboard with the cheaper interior 
> technology, eventually they start shoehorning on all the features and 
> functionality that you wanted from the other one in the first place. :)
> 

That sounds a lot like the "Worse is Better" argument

The Rise of ``Worse is Better''
http://www.jwz.org/doc/worse-is-better.html

This quote would be quite applicable to Ethernet -

"The lesson to be learned from this is that it is often undesirable to
go for the right thing first. It is better to get half of the right
thing available so that it spreads like a virus. Once people are hooked
on it, take the time to improve it to 90% of the right thing."

I think ethernet gaining OAM would be an example of improving to
90% of the right thing (15 or so years after being invented and
deployed), while those technologies that tried to be right from the
outset (token ring, ATM etc.) have or are disappearing.

Re: RINA - scott whaps at the nanog hornets nest :-)

[Mans Nilsson]

Subject: RE: RINA - scott whaps at the nanog hornets nest :-) Date: Sun, Nov 
07, 2010 at 12:34:56AM -0700 Quoting George Bonser (gbon...@seven.com):
> 
> Yes, I really don't understand that either.  You would think that the
> investment in developing and deploying all that SONET infrastructure
> has been paid back by now and they can lower the prices dramatically.
> One would think the vendors would be practically giving it away,
> particularly if people understood the potential improvement in
> performance, though the difference between 1500 and 4000 is probably
> not all that much except on long distance ( >2000km ) paths.

Even if larger MTUen are interesting (but most of the time not worth
the work) the sole reason I like SDH  as my WAN technology is the
presence of signalling -- so that both ends of a link are aware of its
status near-instantly (via protocol parts like RDI etc). In GE it is
legal to not receive any packets, which means that "oblivious" is a
possible state for such a connection. With associated routing
implications.

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
Is this the line for the latest whimsical YUGOSLAVIAN drama which also
makes you want to CRY and reconsider the VIETNAM WAR?


pgpKowh41ld3j.pgp
Description: PGP signature

Migrating from PPP to DHCPo82

[MKS]

Hi list

I work for an small ISP, which does traditional xDSL service with PPPoE.
Currently we are in the process of migrating most of our customers to
DHCP (some customers are getting new CPEs and some will be sw upgraded
remotely ). It would be great if someone has the time to share their
experience (on- or offline) from such a migration. Common pitfals and
perhaps what whey would do differently "next time".
I know that every network is different but I believe that there are
some general concerns, specially around security of DHCP and security
features for vendors around DHCP and DHCP snooping etc.

What about 802.1x, is that generally being deployed with option82?

Regards
MKS

Re: RINA - scott whaps at the nanog hornets nest :-)

[Tony Finch]

On Sun, 7 Nov 2010, William Herrin wrote:
>
> > http://www.ionary.com/PSOC-MovingBeyondTCP.pdf
>
> The last time this was discussed in the Routing Research Group, none
> of the proponents were able to adequately describe how to build a
> translation/forwarding table in the routers or whatever passes for
> routers in this design.

I note that he doesn't actually describe how to implement a large-scale
addressing and routing architecture. It's all handwaving.

And he seems to think that core routers can cope with per-flow state.

The only bits he's at all concrete about are the transport protocol, which
isn't really where the unsolved problems are.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

Re: Migrating from PPP to DHCPo82

[Ingo Flaschberger]

Hi,


I work for an small ISP, which does traditional xDSL service with PPPoE.
Currently we are in the process of migrating most of our customers to
DHCP (some customers are getting new CPEs and some will be sw upgraded
remotely ). It would be great if someone has the time to share their
experience (on- or offline) from such a migration. Common pitfals and
perhaps what whey would do differently "next time".
I know that every network is different but I believe that there are
some general concerns, specially around security of DHCP and security
features for vendors around DHCP and DHCP snooping etc.


option82 is great, but differs from vendor to vender - I use always a 
custom string.


a pitfal is, when you try to give a dslam port a static ip with a 
isc-dhcpd, thats not possible. (I have modfied isc-dhcpd to have a fixed 
size option82 hardware type).


also pools and leasetimes could be problematic, when getting low.


What about 802.1x, is that generally being deployed with option82?


more security - but not always supported, I have not yet tested or needed 
this feature.


Kind regards,
Ingo Flaschberger

Re: RINA - scott whaps at the nanog hornets nest :-)

[Eugen Leitl]

On Mon, Nov 08, 2010 at 03:56:17PM +, Tony Finch wrote:

> I note that he doesn't actually describe how to implement a large-scale
> addressing and routing architecture. It's all handwaving.

I'm probably vying for nanog-kook status as well, but in high-dimensional
spaces blocking is arbitrarily improbable. Think of higher-dimensional
analogs of 3d-Bresenham (which is local-knowledge only), then blow away
most of the links. It still works. You have to wire the network appropriately
to loosely follow geography (which is of course currently a show-stopper) 
and label the nodes appropriately -- as a bonus, you can derive node
ID by mutual iterative refinement, pretty much like relativistic time
of flight mutual "triangulation".

Another issue is purely photonic cut-through at very high data rates:
there's not that much time to do a routing decision even if your packet
stuck in molasses as slow light or circulating in a fiber loop FIFO. 
So not only are photonic gates expensive (and conversion to electronics
and back is right out), you might not stack too many individual gate 
delays on top of each other.

Networks are much too smart still, what you need is the barest decoration
upon the raw physics of this universe.
 
> And he seems to think that core routers can cope with per-flow state.
> 
> The only bits he's at all concrete about are the transport protocol, which
> isn't really where the unsolved problems are.

Re: Migrating from PPP to DHCPo82

[Jack Bates]

On 11/8/2010 9:40 AM, MKS wrote:

I work for an small ISP, which does traditional xDSL service with PPPoE.
Currently we are in the process of migrating most of our customers to
DHCP (some customers are getting new CPEs and some will be sw upgraded
remotely ). It would be great if someone has the time to share their
experience (on- or offline) from such a migration. Common pitfals and
perhaps what whey would do differently "next time".
I know that every network is different but I believe that there are
some general concerns, specially around security of DHCP and security
features for vendors around DHCP and DHCP snooping etc.



While I'm looking at running option-82 (have limited support in a few 
places), I generally run q-in-q providing 100% isolation of customer 
ports. This gives me the same protections and tracking that PPPoE or ATM 
give me. This also allows me to turn off the security of the DSLAM and 
handle all security at the router level.


There are a few deployments we have where q-in-q isn't possible (poor 
dslam implementations), and we have utilized dslam security (dhcp 
snooping, but currently security breaks IPv6 til the DSLAM gets a future 
code update) + option 82 in those cases. A few don't support option-82 
or q-in-q, and those generally are static assignments in a CPE.


The only benefit I've ever seen for PPPoE/A is dslam agnostics and 
uniform support across all vendors. It has the downside of having to 
terminate PPPoE/A on a cpe device. DHCP requires a plan with DLSAM and 
router support.


Cisco simple (ip unnumbered vlan feature w/ q-in-q, 1 subint per 
customer, snmp probe every 5 minutes for the routing table to store 
IP->MAC->subint in a database). The only reason I've considered adding 
option 82 is to reduce the waste caused by probing (ie, an IP won't 
change without the DHCP request, so option 82 lets me get more granular 
and not probe).



Jack

Re: RINA - scott whaps at the nanog hornets nest :-)

[Jack Bates]

On 11/8/2010 9:56 AM, Tony Finch wrote:


I note that he doesn't actually describe how to implement a large-scale
addressing and routing architecture. It's all handwaving.



That's an extremely hard to address problem. While there are many 
proposals, they usually do away with features which we utilize. I'm 
looking at a graph on the noc screen right now which shows how grotesque 
natural load balancing can be between 3 AS interconnects. I have enough 
free overhead to allow this, but eventually I will have to start 
applying policies to balance better. This implies that I'll eventually 
have to advertise sub-aggregate v6 prefixes to balance as well (perhaps 
some /31 or /32 announcements overlaying the /27).


The problem with most of the other methods are they ignore policies and 
the desired route to reach a network, and instead rely on any way to get 
there. But let's be honest, the current problems tend to be memory 
problems, not performance problems. It annoys me that vendors did this 
last increment in such a small scale guaranteeing we'll be buying new 
hardware again soon.


Jack

Re: Migrating from PPP to DHCPo82

[Mike]

MKS wrote:

Hi list

I work for an small ISP, which does traditional xDSL service with PPPoE.
Currently we are in the process of migrating most of our customers to
DHCP (some customers are getting new CPEs and some will be sw upgraded
remotely ). It would be great if someone has the time to share their
experience (on- or offline) from such a migration. Common pitfals and
perhaps what whey would do differently "next time".
I know that every network is different but I believe that there are
some general concerns, specially around security of DHCP and security
features for vendors around DHCP and DHCP snooping etc.

  


We run PPPoE for the reasons that it's easier to manage and account for 
and does not rely on the middle layer for any security (implemented at 
the pppoe concentrator). There are also technical features we like, such 
as being able to route subnets easilly, and per-user filtering rules if 
necessary, as well as a high level of integration with radius that 
really makes things sing along.


A downside is rampant poor, non-compliant and downright buggy pppoe 
client implementations. It's gotten better over the years with more 
linux replacing other embedded development tool sets but still, it's 
downright criminal sometimes what that lower end consumer junk does in 
the field - and ALWAYS, being resolved by pulling the power and cycling 
it... 


I've recently implemented PPPoE Intermediate agent support as a patch 
against the opensource RP-PPPOE server software, along with 
documentation on integrating it with freeradius, and this enables you to 
ditch completely the username / password and just go with DSLAM port-id 
based authentication, reducing the strain on your support staff as end 
users forget or lose this otherwise most critical information. For 
anyone who cares, the code is on sourceforge -


http://ilc-ppp.sourceforge.net


Mike-

RE: RINA - scott whaps at the nanog hornets nest :-)

[George Bonser]

> 
> Even if larger MTUen are interesting (but most of the time not worth
> the work) the sole reason I like SDH  as my WAN technology is the
> presence of signalling -- so that both ends of a link are aware of its
> status near-instantly (via protocol parts like RDI etc). In GE it is
> legal to not receive any packets, which means that "oblivious" is a
> possible state for such a connection. With associated routing
> implications.

I wasn't talking about changing anything at any of the edges.  The idea was 
just to get the "middle" portion of the internet, the peering points to a place 
that would support frames larger than 1500.  It is practically impossible for 
anyone to send such a packet off-net until that happens.

There was nothing that said everyone should change to a higher MTU.  I was 
saying that there are cases where it can be useful for certain types of 
transfers but the state of today's internet is that you can't do it even if you 
want to except by special arrangement.  Considering the state of today's modern 
hardware, there isn't a technical reason why those points can't be set to 
handle larger packets should one come along.  That's all.  I wasn't suggesting 
everyone set their home system for a larger MTU, I was suggesting that the 
peering points be able to handle them should one pass through.

Now I agree, on an existing exchange having a "flag day" for everyone to change 
might not be worthwhile but on a new exchange where you have a green field, 
there is no reason to limit the MTU at that point to 1500.  Having a larger MTU 
in the middle of the path does not introduce PMTUD issues. PMTUD issues are 
introduced by having a smaller MTU somewhere in the middle of the path.  The 
conversation was quickly dragged into areas other than what the suggestion was 
about.

What was interesting was the email I got from people who need to move a lot of 
science and engineering data on a daily basis who said their networking people 
didn't "get it" either and it is causing them problems.  Not everyone is going 
to need to use large frames.  But people who do need them can't use them and 
there really isn't a technical reason for that.  That specific portion of the 
Internet, the peering points between networks, carries traffic from all sorts 
of users, not just people at home with their twitter app open.  Enabling the 
passage of larger packets doesn't mean advocating that everyone use them or 
changing anyone's customer edge configuration.

It wouldn't change anyone's routing, wouldn't impact anyone's PMTUD problems.  
I don't believe that is "kooky". A lot of other people have been calling for 
the same thing for quite some time. But making a network "jumbo clean" doesn't 
do a lot of good if the peering points are the bottleneck. That's all.  
Removing that bottleneck is all that the suggestion was about.

Re: RINA - scott whaps at the nanog hornets nest :-)

[Mans Nilsson]

Subject: RE: RINA - scott whaps at the nanog hornets nest :-) Date: Mon, Nov 
08, 2010 at 08:53:47AM -0800 Quoting George Bonser (gbon...@seven.com):
> > 
> > Even if larger MTUen are interesting (but most of the time not worth
> > the work) the sole reason I like SDH  as my WAN technology is the
> > presence of signalling -- so that both ends of a link are aware of its
> > status near-instantly (via protocol parts like RDI etc). In GE it is
> > legal to not receive any packets, which means that "oblivious" is a
> > possible state for such a connection. With associated routing
> > implications.
> 
> I wasn't talking about changing anything at any of the edges.  The idea was 
> just to get the "middle" portion of the internet, the peering points to a 
> place that would support frames larger than 1500.  It is practically 
> impossible for anyone to send such a packet off-net until that happens.

Know what? We have not one, but five or so Internet Exchange points in
Sweden, where there are 802.1q VLANS setup for higher MTU (4470 for
hysterical raisins) . My impression is that people use them, but I'm
also being informed by statistics that there is a _very_ steep drop in
packet count vs size once 1500 is reached. It is setup, but the edge is
where packets are made, not the core. Thus, noone can send large
packets. Anyway. 

I'd concur that links where routers exchange very large routing tables
benefit from PMTUD (most) and larger MTU (to some degree), but I'd
argue that most IXPen see few prefixes per peering, up to a few
thousand max. The large tables run via PNI and paid transit, as well as
iBGP. There, I've seen drastical improvements in convergence time once
PMTUD was introduced and arcane MSS defaults dealt with. MTU mattered
not much.

Given this empirical data, clearly pointing to the fact that It Does
Not Matter, I think we can stop this nonsense now.

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
I was making donuts and now I'm on a bus!


pgp3C76fClvkv.pgp
Description: PGP signature

Re: GRE Tunnels and MPLS

[Rettke, Brian]

This seems to be working now with the 'mls mpls tunnel-recir' command entered. 
There are some potential downsides, but this should get things up and running 
until I create the new backup tunnels (GRE over IPSec) on a connected router 
that is not MPLS-enabled. Thanks!

Sincerely,

Brian A . Rettke
RHCT, CCDP, CCNP, CCIP
Network Engineer, CableONE Internet Services


--

Message: 6
Date: Thu, 04 Nov 2010 16:49:55 -0400
From: Shimol Shah 
Subject: Re: GRE Tunnels and MPLS
To: nanog@nanog.org
Message-ID: <4cd31c73.80...@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Do you have recir enabled ? If not, good one to enable and check for
status of issue.

http://www.cisco.com/en/US/docs/ios/mpls/command/reference/mp_m1.html#wp1012208

"If you do not enable tunnel-MPLS recirculation, the IPv4 and
IPv4-tunneled packets that need to be labeled (for example, the packets
that are encapsulated with an MPLS header) will be corrupted when they
are transmitted from the Cisco 7600 series router."

Shimol

On 11/4/10 4:00 PM, Rettke, Brian wrote:
> Beginning work on our implementation of MPLS for the backbone network. I've 
> run into difficulty with our GRE tunnels. The GRE Tunnel sits on our co-lo 
> router (a Cisco 7600), and it uses a route-map to push our 10.x modem traffic 
> to our DHCP servers. This is because the backbone is not complete and DHCP 
> traffic needs to traverse the internet. What I have found is that when I 
> enable basic MPLS on the co-location interfaces that head back to the 
> individual systems, DHCP traffic still works, but ICMP and other 10.x traffic 
> dies. There is also an intermittent problem with DHCP when it is enabled, 
> where not all DISCOVERS are answered. I've tried everything I can think of, 
> including adjusting MTU and TCP MSS. It only seems to impact when the 
> co-location router has a GRE tunnel on one buffer, which it terminates, and 
> then it has to encapsulate traffic with an MPLS tag before sending out of the 
> other buffer. Theoretically, it should work, but I can't figure out if there 
> is some prob
lem with MPLS' interaction with the tunnel. Has anyone encountered something 
similar?
>
> Sincerely,
>
> Brian A . Rettke
> RHCT, CCDP, CCNP, CCIP
> Network Engineer, CableONE Internet Services
>
>

Re: GRE Tunnels and MPLS

[Shimol Shah]

Good deal. Sounds like a plan.

Shimol  

On 11/8/10 2:00 PM, Rettke, Brian wrote:

This seems to be working now with the 'mls mpls tunnel-recir' command entered. 
There are some potential downsides, but this should get things up and running 
until I create the new backup tunnels (GRE over IPSec) on a connected router 
that is not MPLS-enabled. Thanks!

Sincerely,

Brian A . Rettke
RHCT, CCDP, CCNP, CCIP
Network Engineer, CableONE Internet Services


--

Message: 6
Date: Thu, 04 Nov 2010 16:49:55 -0400
From: Shimol Shah
Subject: Re: GRE Tunnels and MPLS
To: nanog@nanog.org
Message-ID:<4cd31c73.80...@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Do you have recir enabled ? If not, good one to enable and check for
status of issue.

http://www.cisco.com/en/US/docs/ios/mpls/command/reference/mp_m1.html#wp1012208

"If you do not enable tunnel-MPLS recirculation, the IPv4 and
IPv4-tunneled packets that need to be labeled (for example, the packets
that are encapsulated with an MPLS header) will be corrupted when they
are transmitted from the Cisco 7600 series router."

Shimol

On 11/4/10 4:00 PM, Rettke, Brian wrote:

Beginning work on our implementation of MPLS for the backbone network. I've run 
into difficulty with our GRE tunnels. The GRE Tunnel sits on our co-lo router 
(a Cisco 7600), and it uses a route-map to push our 10.x modem traffic to our 
DHCP servers. This is because the backbone is not complete and DHCP traffic 
needs to traverse the internet. What I have found is that when I enable basic 
MPLS on the co-location interfaces that head back to the individual systems, 
DHCP traffic still works, but ICMP and other 10.x traffic dies. There is also 
an intermittent problem with DHCP when it is enabled, where not all DISCOVERS 
are answered. I've tried everything I can think of, including adjusting MTU and 
TCP MSS. It only seems to impact when the co-location router has a GRE tunnel 
on one buffer, which it terminates, and then it has to encapsulate traffic with 
an MPLS tag before sending out of the other buffer. Theoretically, it should 
work, but I can't figure out if there is some pro

b

lem with MPLS' interaction with the tunnel. Has anyone encountered something 
similar?


Sincerely,

Brian A . Rettke
RHCT, CCDP, CCNP, CCIP
Network Engineer, CableONE Internet Services

Re: RINA - scott whaps at the nanog hornets nest :-)

[Jack Bates]

On 11/8/2010 12:36 PM, Mans Nilsson wrote:

I'd concur that links where routers exchange very large routing tables
benefit from PMTUD (most) and larger MTU (to some degree), but I'd
argue that most IXPen see few prefixes per peering, up to a few
thousand max. The large tables run via PNI and paid transit, as well as
iBGP. There, I've seen drastical improvements in convergence time once
PMTUD was introduced and arcane MSS defaults dealt with. MTU mattered
not much.

Given this empirical data, clearly pointing to the fact that It Does
Not Matter, I think we can stop this nonsense now.



His point wasn't to benefit the BGP routers at the IX, but to support 
those who need to transmit > 1500 size packets and have the ability to 
create them on the edge. In particular, the impact of running long 
distances (high latency) with higher packet drop probability. In such a 
scenario, it does matter.


Even if you don't see that many > 1500 byte packets, doesn't imply that 
it doesn't matter. I have v6 peerings and see very little traffic on 
them compared to v4. Should I then state that v6 doesn't matter? If 
people have an expectation of not making it through core networks at 
>1500, they won't bother trying to send >1500. If the IX doesn't 
support >1500, why would people connecting to the IX care if their 
backbones support >1500?



Jack

Re: [j-nsp] EX4200 JunOS Recommendation

[GIULIANO (UOL)]

We are running 10.2R3 for 10 x EX4200.

Everything is working fine ... from VC to BGP and virtual routers.




> On Mon, Nov 8, 2010 at 2:59 PM, Richard A Steenbergen 
> wrote:
> 
>> On Mon, Nov 08, 2010 at 11:43:55AM -0800, Mehmet Akcin wrote:
>>> Hi Keegan,
>>>
>>> I always try to go with
>>>
>>>
>> https://www.juniper.net/customers/csc/software/junos_software_versions.jsp
>>
>> Based on past experience, I find this list to be a giant load of horse
>> shit. You'd have better luck picking good versions of code with a magic
>> 8ball.
> 
> 
> hahahahah  For one, I don't think I would have taken that quite as seriously
> coming from anyone else.  Secondly I'm new here, but it's better than NANOG.
> 
> 
>> Unfortunately I can't tell you specifically what works best for
>> L2 on EX4200 because we use none of the first and very little of the
>> second, but I can give you a very very long list of reasons why 10.2R3
>> is (at this exact moment) the best choice for EX8200 doing routing.
>>
> 
> We use the big cats for this but this may help someone I know.  Thanks.
> 
>>
>> --
>> Richard A Steenbergenhttp://www.e-gerbil.net/ras
>> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
>>
>>
>>
> ___
> juniper-nsp mailing list juniper-...@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 

Re: RINA - scott whaps at the nanog hornets nest :-)

[Valdis . Kletnieks]

On Mon, 08 Nov 2010 19:36:49 +0100, Mans Nilsson said:

> Given this empirical data, clearly pointing to the fact that It Does
> Not Matter, I think we can stop this nonsense now.

That's right up there with the sites that blackhole their abuse@
address, and then claim they never actually see any complaints.
Or forcing NAT at the edge, and saying "The fact we get no complaints
means It Does Not Matter", ignoring SCTP and similar use cases where
it *does* matter.

If in fact It Does Not Matter, why did the Internet2 folks make any
effort to support 9000 end-to-end?

http://proj.sunet.se/LSR2/index.html says they used an MTU of 4470.. and then
add "and we used only about half the MTU size (which generates heavier CPU-load
on the end-hosts)", which pretty much implies the previous record was at 9000 or
so.

So there's empirical data that It Does Indeed Matter (at least to some
people).  



pgp77N4B5YvB0.pgp
Description: PGP signature

Re: RINA - scott whaps at the nanog hornets nest :-)

[Nick Hilliard]

On 08/11/2010 21:51, valdis.kletni...@vt.edu wrote:
> So there's empirical data that It Does Indeed Matter (at least to some
> people).  

It certainly does.  However, there is lots more empirical data to suggest
that It Does Not Matter to most service providers.  We tried introducing it
to INEX several years ago.  Of 40-something connected parties, only one was
really interested enough to do something about it.  Another indicated
interest but then pulled back when they realised a) the amount of work it
would take to support it across their network, b) the scope for painful
breakage if they accidentally got something wrong somewhere and c) the
benefit they would get from it.

Probably most interesting aspect was the cost / benefit analysis.  One the
one hand, there was little to no benefit for end-users and hosted services
on the commercial ISP that showed interest.  However, the NREN which was
interested could have made real use out of it, in terms of dealing with
very speed single-stream data transfers.

Anyway, all of the arguments for it, both pro and con, have been rehashed
on this thread.  The bottom line is that for most companies, it simply
isn't worth the effort, but that for some NRENs, it is.

Let's move on now.

Nick

Re: RINA - scott whaps at the nanog hornets nest :-)

[Chris Adams]

Once upon a time, valdis.kletni...@vt.edu  said:
> That's right up there with the sites that blackhole their abuse@
> address, and then claim they never actually see any complaints.

What about telcos that disable error counters and then say "we don't see
any errors"?
-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: RINA - scott whaps at the nanog hornets nest :-)

[Scott Weeks]

Been unexpectedly gone for the weekend, apologies for the delay.  Wow, can 
subjects get hijacked quickly here.  I think it happened within one or two 
emails.  It was just for weekend fun anyway...


--- b...@herrin.us wrote:
From: William Herrin 

> And so, "...the first principle of our proposed new network architecture: 
> Layers are recursive."

: Anyone who has bridged an ethernet via a TCP based
: IPSec tunnel understands that layers are recursive.

WRT the paper I'm having trouble correlating what you say with their notion of 
recursive layer network communications.  It seems apples and oranges, but maybe 
I have Monday-its.  It's only a little after noon here.




> http://www.ionary.com/PSOC-MovingBeyondTCP.pdf

: John Day has been chasing this notion long enough to write three
: network stacks. If it works and isn't obviously inferior in its
: operational resource consumption, where's the proof-of-concept code?

Not having read the following enough, being in operations and not in the 
research areas as much as others on this list I don my flameproof underpants 
and post this:

pouzinsociety.org gives: 
-
"The TSSG developed CBA prototype, which consists of a fully functional 
componentised network stack and the ancillary supporting infrastructure, has 
been contributed to the Pouzin Society as the TINOS project.

TINOS will provide the underlying platform and execution environment upon which 
a RINA prototype can be developed.

The TSSG and i2CAT will be joining forces with the Pouzin Society to contribute 
to the development of a RINA prototype based on the TINOS platform.

The TINOS code is freely available under the LGPL license."
-


the "CBA prototype" link being: 
http://www.tssg.org/4WARD/2010/07/component_based_architecture_n.html

Seemingly unfortunate (to me) is: "...an open-source project to create a Java 
platform operating system."




: The last time this was discussed in the Routing Research Group, none
: of the proponents were able to adequately describe how to build a
: translation/forwarding table in the routers or whatever passes for
: routers in this design.

When I asked on RRG I was told by the chairs, privately, that no open-slate 
designs would be considered.  No RINA proponents are participating in the list, 
as well.

WRT RRG I had assumed various proposals would be considered with equal respect 
and dignity, the basic components described, a 'winner' selected and then the 
engineering details designed.  Watching the list has been an experience in 
reality (it's not all peace, love and happiness out there :-) and I now more 
clearly understand the comments made by others on this list about the process.  
Since it wasn't allowed on RRG, I hoped to spur discussion here between those 
who spend more cycles in research and learn from that discussion.  It didn't 
happen yet...  ;-)

scott

ps.  Thanks for the response.  I am really curious about the approach.  It 
would seem to weed out a lot of redundant things that various layers repeat.

Re: RINA - scott whaps at the nanog hornets nest :-)

[Jack Bates]

On 11/8/2010 4:08 PM, Nick Hilliard wrote:

Anyway, all of the arguments for it, both pro and con, have been rehashed
on this thread.  The bottom line is that for most companies, it simply
isn't worth the effort, but that for some NRENs, it is.



I think a lot of that is misinformation and confusion. A company looks 
at it and thinks of the issues deploying it to end users, and misses the 
benefits of deploying it at the core only handling special requests. 
This is especially true for hosting companies, where a majority of 
connections to servers need to stay at low MTU to keep things 
streamlined, but for specific cases could increase MTU for things such 
as cross country backups. Many servers can handle these dual MTU setups.


Larger MTU is beneficial when someone controls the 2 endpoints and has 
use for it. They can request for the larger MTU connection with their 
providers/datacenters, but if the core systems aren't supporting it, 
they'll die miserably.



Jack

RE: RINA - scott whaps at the nanog hornets nest :-)

[Nathan Eisenberg]

> Been unexpectedly gone for the weekend, apologies for the delay.  Wow,
> can subjects get hijacked quickly here.  I think it happened within one or two
> emails.  It was just for weekend fun anyway...

So... You tossed a cow into a pool (that you knew was) filled with piranhas, 
waited a few days, and now you want to know where the cow went?

-Nathan

Re: RINA - scott whaps at the nanog hornets nest :-)

[Scott Weeks]

--- d...@dotat.at wrote:
From: Tony Finch 

: I note that he doesn't actually describe how to implement 
: a large-scale addressing and routing architecture. It's all 
: handwaving.

There is more discussed in the book.  The paper was written by another person 
and had to only hit the highlights, or it'd be too long for folks to want to 
read.  I'd imagine you can get a copy of the book in a university library.



:And he seems to think that core routers can cope with per-flow state.

Can you elaborate for me?



: The only bits he's at all concrete about are the transport
: protocol, which isn't really where the unsolved problems are.

It wasn't about just solving problems.  It seems to me to be about if you could 
clean-slate design, what would you do?  AFAICT the RRG folks are specifically 
focused on fixing problems: map-n-encap and tunneling being the most liked 
solutions.

One similar thing to other proposals on that list, though, that has me 
wondering is the use of a 'server' in the middle to keep track of everything.


scott

Re: RINA - scott whaps at the nanog hornets nest :-)

[Mans Nilsson]

Subject: Re: RINA - scott whaps at the nanog hornets nest :-) Date: Mon, Nov 
08, 2010 at 10:08:53PM + Quoting Nick Hilliard (n...@foobar.org):
> On 08/11/2010 21:51, valdis.kletni...@vt.edu wrote:
> > So there's empirical data that It Does Indeed Matter (at least to some
> > people).  
 
> Anyway, all of the arguments for it, both pro and con, have been rehashed
> on this thread.  The bottom line is that for most companies, it simply
> isn't worth the effort, but that for some NRENs, it is.

And NREN-NREN traffic typically does not traverse commercial IXen.
(Even though ISTR Sunet and Nordunet having peerings configured on
Netnod).  Instead, from empire-building reasons or job security or "No
research project is complete unless the professor gets a new laptop and
a wavelength to CERN (or in USA, pick a DoE site) from the project
money", NRENs build their own...  I am convinced that some applications
actually benefit from this, though.
 
> Let's move on now.

Indeed. 

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
Yow!  I want my nose in lights!


pgpD2gcXRIWrL.pgp
Description: PGP signature

Re: RINA - scott whaps at the nanog hornets nest :-)

[Scott Weeks]

--- eu...@leitl.org wrote:
From: Eugen Leitl 

Networks are much too smart still, what you need is the barest decoration
upon the raw physics of this universe.
--

Yes, that's one thing I note.  The mapping server idea that several proposals 
use do not appear to keep the smartness at the edges, rather they seem try to 
make a smarter core network.

scott

Re: RINA - scott whaps at the nanog hornets nest :-)

[Tony Finch]

On Mon, 8 Nov 2010, Scott Weeks wrote:
> From: Tony Finch 
>
> : I note that he doesn't actually describe how to implement
> : a large-scale addressing and routing architecture. It's all
> : handwaving.
>
> There is more discussed in the book.

I have bought and read the book. It's an interesting and entertaining rant
about the protocol wars, but still far too vague about proposing solutions
for our current pain points. Argiung about TCP vs. Delta-T is a very long
way from the problems that need solving.

My comment stands.

> :And he seems to think that core routers can cope with per-flow state.
>
> Can you elaborate for me?

Perhaps I don't understand how connection-oriented networks work. How do
you reserve bandwidth for a connection with guaranteed quality of service
without establishing state on every router in the path? How do you do it
in a network that spans multiple organizations? What connection-oriented
inter-domain protocols have had widespread deployment?

> It wasn't about just solving problems.  It seems to me to be about if
> you could clean-slate design, what would you do?

If your lovely clean architecture can't solve problems why should anyone
pay attention to it? A clean slate architecture needs to synthesize what
we have learned from practical experience and add a dose of cleverness so
that problems can be solved much more easily.

A simple mostly-unrelated example: in the 1980s hypertext systems had
links that were bidirectional and they made an effort to keep them
consistently maintained. This made it impossible to have an inter-domain
hypertext system. The WWW discarded the requirement for consistent
bidirectional links, so it was not "proper hypertext". Even so, because it
does not require co-operation between the ends of the link, it rapidly
outgrew any previous hypertext system.

The point of a clean slate design is to rethink the foundations of your
architecture, and get rid of constraints that set you up to fail.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

Re: RINA - scott whaps at the nanog hornets nest :-)

[Scott Weeks]

--- d...@dotat.at wrote:
The point of a clean slate design is to rethink the foundations of your
architecture, and get rid of constraints that set you up to fail.
--


Yes, and I thought this idea could be the beginning of one way to do that and 
became interested in what others thought.  However, there're not very many 
avenues to ask for competent responses on things like this.  Thanks for the 
responses.  

scott

ps. The "NAT is your friend" part is what I thought would whap at the nest for 
weekend fun...  :-)

Re: RINA - scott whaps at the nanog hornets nest :-)

[William Herrin]

On Mon, Nov 8, 2010 at 6:02 PM, Scott Weeks  wrote:
>> And so, "...the first principle of our proposed new network architecture: 
>> Layers are recursive."
>
> : Anyone who has bridged an ethernet via a TCP based
> : IPSec tunnel understands that layers are recursive.
>
> WRT the paper I'm having trouble correlating what you say with their
> notion of recursive layer network communications.
> It seems apples and oranges

Hi Scott,

Having skimmed the article and some of its predecessors, I find it
hard to determine whether there's any correlation. REALLY hard.


>> http://www.ionary.com/PSOC-MovingBeyondTCP.pdf
>
> : John Day has been chasing this notion long enough to write three
> : network stacks. If it works and isn't obviously inferior in its
> : operational resource consumption, where's the proof-of-concept code?
>
> TINOS will provide the underlying platform and execution
> environment upon which a RINA prototype can be developed.

"will provide"
"can be developed"


> the "CBA prototype" link being:
> http://www.tssg.org/4WARD/2010/07/component_based_architecture_n.html

Described in the videos as a clever modeling tool forked off of JNode
which had a plain old TCP/IP stack written in Java.

But what I'm still missing is use of that modeling system to
demonstrate any concepts in Day's plan.


On Mon, Nov 8, 2010 at 6:14 PM, Scott Weeks  wrote:
> From: Tony Finch 
> : I note that he doesn't actually describe how to implement
> : a large-scale addressing and routing architecture. It's all
> : handwaving.
>
> There is more discussed in the book.

A colleague thoughtfully lent me a copy of the book. I found it more
incondite than recondite.

I'd like there to be some abstruse nugget of insight in there. I
really would. Maybe you can tell me the page number, 'cause I just
can't wade through the rest of it.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004