On Tue, 22 Dec 2009, Leo Vegoda wrote:
ASSIGNED PA: This address space has been assigned to an End User for use
with services provided by the issuing LIR. It cannot be kept when
terminating services provided by the LIR.
My interpretation of the above is ASSIGNED PA is the equivalent of my
Hello Stephane - if you search google for VRF aware IPSEC you will find
links and relevant information and configs.
I did this on older hardware by creating an IPSEC tunnel between 2 routeable
loopbacks and creating a GRE tunnel that used the loopbacks and tunnel
source and destination. Then plac
> I'm more persistent than smart, and I tell ya, if you prep well
> enough, you can hand your checklist to a stoned intern and you'll
> have no worries at all.
this works in a tech culture where folk follow mops obsessively. my
experience is that most north american engineers are too smart to do
On Dec 24, 2009, at 9:51 AM, Randy Bush wrote:
>> I'm more persistent than smart, and I tell ya, if you prep well
>> enough, you can hand your checklist to a stoned intern and you'll
>> have no worries at all.
>
> this works in a tech culture where folk follow mops obsessively. my
> experience i
> I _do_ create action plans and _do_ quarterback each step and _do_
> slap down any attempt to deviate.
imagine a network engineering culture where the concept of 'attempt to
deviate' just does not occur.
randy
On Dec 24, 2009, at 10:09 AM, Randy Bush wrote:
>> I _do_ create action plans and _do_ quarterback each step and _do_
>> slap down any attempt to deviate.
>
> imagine a network engineering culture where the concept of 'attempt to
> deviate' just does not occur.
>
> randy
=]
The networking gro
Eddy Martinez wrote:
On Dec 24, 2009, at 10:09 AM, Randy Bush wrote:
I _do_ create action plans and _do_ quarterback each step and _do_
slap down any attempt to deviate.
imagine a network engineering culture where the concept of 'attempt to
deviate' just does not occur.
I find the thought of
On Dec 24, 2009, at 1:09 PM, Randy Bush wrote:
>> I _do_ create action plans and _do_ quarterback each step and _do_
>> slap down any attempt to deviate.
>
> imagine a network engineering culture where the concept of 'attempt to
> deviate' just does not occur.
Are you trying to suggest that this
>> imagine a network engineering culture where the concept of 'attempt to
>> deviate' just does not occur.
>
> Are you trying to suggest that this is something horrible, or that
> it's the future of network engineering? :)
neither. it is one [type of] ops engineering culture, and a very
successf
I _do_ create action plans and _do_ quarterback each step and _do_
slap down any attempt to deviate.
imagine a network engineering culture where the concept of 'attempt to
deviate' just does not occur.
Are you trying to suggest that this is something horrible, or that it's the
fu
Wouldn't that be kind of pointless? ARIN policies are proposed by the
public, not ARIN staff or board members.
https://www.arin.net/policy/pdp.html
Policy proposals may be submitted by anyone in the global Internet
community except for members of the ARIN Board of Trustees or the ARIN
staff
: this works in a tech culture where folk follow mops obsessively. my
: experience is that most north americam engineers are too smart to do
: that, and take shoprtcuts
> and _do_ slap down any attempt to deviate
: imagine a network engineering culture where the concept of 'attempt to
: deviate
On 12/23/2009 12:31 AM, George Bonser wrote:
Apologies in advance for the top post.
Likewise. These are general comments, though, so I don't feel too
badly... :-)
It sounds like you're on the right track. You discovered the 2009-5
Multiple Discrete Networks draft policy, which should
:-)
:mops work.
It depends on who wrote it and the experience the person has (on the particular
network) who generated it..
scott
Hi all,
On the 7th of next month I'll be participating in an ICANN
consultation on the proposed draft registry agreement, and the number
of "nines" that have crept into it, relative to what was expected of
new registry operators a decade ago, is one of the hidden cost
increases I will discuss
> -Original Message-
> From: Scott Leibrand
>
> It sounds like you're on the right track. You discovered the 2009-5
> Multiple Discrete Networks draft policy, which should allow you a
> separate /48 for each discrete network. That is somewhat orthogonal to
> the question of whether you s
>> imagine a network engineering culture where the concept of 'attempt to
>> deviate' just does not occur.
>
> Are you trying to suggest that this is something horrible, or that it's the
> future of network engineering? :)
The model of network engineering that grew up during the 1990s is
forever
> I can't in good conscience justify a /32. That is just too much space.
Then you need to go back to IPv6 101.
> I believe I can, however, justify a separate /48 in Europe and APAC with
> my various offices and data centers in that region coming from the /48
> for that region.
A /48 is for a si
On Dec 24, 2009, at 8:59 AM, Jon Lewis wrote:
[…]
>> I am sure that your interpretation was the original intent of the policy
>> text. However, the wording could also be read in a way that allows an LIR to
>> just provide registry services, without providing any connectivity services.
>
> That's
> -Original Message-
> From: Michael Dillon [mailto:wavetos...@googlemail.com]
> Sent: Thursday, December 24, 2009 4:11 PM
> To: nanog@nanog.org
> Subject: Re: IPv6 allocations, deaggregation, etc.
>
> > I can't in good conscience justify a /32. That is just too much
> space.
>
> Then
On Dec 25, 2009, at 7:01 AM, Michael Dillon wrote:
> It would be interesting to see what others have to say about this answer.
I think it's a pretty accurate summation of how these things work in a lot of
big organizations, all over the world.
There's a detrimental side to it, in that in the e
> -Original Message-
> From: Dobbins, Roland
>
> On Dec 25, 2009, at 7:01 AM, Michael Dillon wrote:
>
> > It would be interesting to see what others have to say about this
> answer.
>
> I think it's a pretty accurate summation of how these things work in a
> lot of big organizations, al
On Dec 25, 2009, at 9:27 AM, George Bonser wrote:
> Capt. Sullenberger did not need to fill out an incident
> report, bring up a conference bridge, and give a detailed description of
> what was happening with his plane, the status of all subsystems, and his
> proposed plan of action (subject to c
On Thu, Dec 24, 2009 at 6:27 PM, George Bonser wrote:
> So you can put a lot of process around changes in advance but there
> isn't quite as much to manage incidents that strike out of the clear
> blue. Too much process at that point could impede progress in clearing
> the issue. Capt. Sullenbe
24 matches
Mail list logo
