Subject: RE: [arch-d] Finding a way forward

From: "Azinger, Marla" <[email-masked]>
Date: Thu, 30 Nov 2006 14:13:06 -0500

Hello Ian-

Yes, action is required

Asking for a best guess timefame is opening a can of warms.  You will receive answers ranging from 4 years, 20 years and never.

Lessons learned from the past show us "bandaids" are just that ( they tend to degrade in worth).  Acknowleding this are a number of people looking for a balanced solution that is technically sound and acknowledges time to implementation.   

So you want difinitive answers on solution and time.  This really cant be done.  But what can be done and what several people are attempting to do is accept that we need a solution and that we need it relatively quickly (1-4 years).  Yes, there will always be people that want to debate the method and the timeframe to the third degree.  However, there are also people willing to take the facts from these debates and pick a direction and go with it, and that is when solutions are made.  It will happen.

Thank you for your time
Marla Azinger
Frontier Communications
ARIN AC

-----Original Message-----
From: Ian Peter [mailto:[email-masked]]
Sent: Thursday, November 30, 2006 10:44 AM
To: [email-masked]
Subject: [arch-d] Finding a way forward

Assuming that action is required and this is not just an interesting
discussion -

Can someone give a best guesstimate as regards what timeframe the problem is
likely to severly affect Internet performance - are we talking 3 years or 10
or further?

That should help to indicate whether a bandaid approach is absolutely
necessary or whether a more wholistic approach should be concentrated on.

I certainly suggest you avoid trying to do both on the same list (if both
are necessary)

The next step after this preliminary analysis would be to evaluate
realistically what could be done (that’s means implemented, not just a
standard) in the timeframe in which action is needed.

Ian Peter
Ian Peter and Associates Pty Ltd
PO Box 10670 Adelaide St  Brisbane 4000
Australia
Tel (+614) 1966 7772
www.ianpeter.com
www.internetmark2.org
www.nethistory.info

-----Original Message-----
From: John Day [mailto:[email-masked]] 
Sent: 01 December 2006 02:51
To: Bound, Jim; John Day; John Leslie
Cc: [email-masked]
Subject: RE: [arch-d] On identifiers: what is virtual and what is global
(wasRe: thou...

I believe that a week or so ago a list was created to address the 
problem you describe.  As I understand it, this list was created to 
address the fact that for the past 30 years the Internet has shirked 
its responsibility to do the work necessary to provide a complete and 
well thought out architecture.

As was expressed at the beginning of this discussion a few weeks ago, 
we have to give up this constant band-aid approach.  We have to find 
the *solutions.*  Then we can trade our band-aids in for steps toward 
an answer.

As for transport, yes, we do have a number of bad examples in the data.

At 3:38 -0500 2006/11/30, Bound, Jim wrote:
>I am working here on engineering (not a computer science research
>project) for an architecture that will assist routing, but alleviating
>the business problem for operators that are not just network providers
>from the multihoming problem to some degree permits us more time to
>resolve the architecture issue at hand for routing.  If the transport
>layer, which does rely on IPvN addresses in any implementation code I
>have ever seen for lookups etc., can be made to not be dependent on IPvN
>addresses, that will permit aggregation of IPvN addresses for some time
>to avoid the collision presented by the IAB at San Diego potentially.
>Thus it is important and I don't agree with John Day.
>
>Best,
>/jim
>
>>  -----Original Message-----
>>  From: John Day [mailto:[email-masked]]
>>  Sent: Wednesday, November 29, 2006 9:14 PM
>>  To: Bound, Jim; John Leslie
>>  Cc: [email-masked]
>>  Subject: RE: [arch-d] On identifiers: what is virtual and
>>  what is global (wasRe: thou...
>>
>>  Not quite.  Sooner or later you are going to realize that
>>  that there are no such thing as Transport Addresses.  In
>>  fact, transport is sort of a minor layer at best.  As far as
>>  this problem is concerned, Transport is irrelevant to the solution.
>>
>>  Transport has no effect on the routing and its components and
>>  doesn't constrain its possibilities in the least.
>>
>>  QED
>>
>>  At 20:49 -0500 2006/11/29, Bound, Jim wrote:
>>  >agree again.  also no attachment to src addresses at my end.
>>   agree on
>>  >identifying transport points of the protocols to the
>>  architecture but
>>  >want to go offline with Pekka N. on that one and can do as I
>>  can around
>>  >the day job of course.  the reason to do this arch exercise is the
>>  >potential of freeing the transport layer from IPvN layer and
>>  >components, which affords routing more freedom in thinking
>>  models.  but
>>  >to note both
>>  >shim6 and hip have done this and some implementation exists.
>>  >
>>  >Best,
>>  >/jim
>>  >
>>  >
>>  >
>>  >>  -----Original Message-----
>>  >>  From: John Leslie [mailto:[email-masked]]
>>  >>  Sent: Wednesday, November 29, 2006 4:52 PM
>>  >>  To: Bound, Jim
>>  >>  Cc: [email-masked]
>>  >>  Subject: Re: [arch-d] On identifiers: what is virtual and
>>   what is
>>  >> global (wasRe: thou...
>>  >>
>>  >>  Bound, Jim <[email-masked]> wrote:
>>  >>  >> From: John Leslie [mailto:[email-masked]]  >>  >> I strongly
>>  >> recommend that we call the "thing" that sits in
>>  >>   the IPv4
>>  >>  >>header as destination address an "IPv4 destination 
>>  address", and
>>  >> the  >>"thing" that sits in the IPv6 header as a 
>>  destination address
>>  >> an
>>  >>  >>"IPv6 destination address".
>>  >>  >>...
>>  >>  >> (The actual parameters passed to operating systems to
>>  open  TCP 
>>  >> >>sockets and connections are _also_ something else  >>
>>  entirely: we
>>  >> must not confuse TCP endpoints with IPvN  destination
>>  >>  >>addresses.)
>>  >>  >
>>  >>  > Two points I do want to note for discussion are  >  > what is
>>  >> passed to transport connections are end-to-end 
>>  identifiers in  > my
>>  >> view and should not be exposed in the IPvN headers or used for  >
>>  >> loc+id.
>>  >>
>>  >>     I agree they are end-to-end identifiers, even if they look 
>  > >> exactly like IPvN addresses.
>>  >>
>>  >>     That they currently are exposed in IPvN headers is an
>>  accident of
>>  >>  history: TCP never defined a standard for exchanging
>>  anything  else
>>  >> as endpoint identifiers. (Clearly, both ends of a TCP  connection
>>  >> need to agree how to distinguish that a packet  belongs to that
>>  >>  connection: IPvN addresses have worked OK for that purpose.
>>  >>  Endpoint identifiers _could_ be something else entirely;
>>  and  need
>>  >> not be visible at all to the IPvN layer.)
>>  >>
>>  >>     We must allow _something_ to be used for loc+id within
>>   IPvN; but
>>  >> it'd be fine if, for example, the application  passed FQDNs as the
>>  >> endpoint IDs and the operating system did  a DNS-like
>>  query to find 
>>  >> loc+id.
>>  >>
>>  >>  > Also on source addresses my pain has been if they get  altered
>>  >> then I  > am unclear how I respond back at the OS transport end.
>>  >>
>>  >>     This is indeed a mess right now. NAT boxes routinely
>>  alter  these
>>  >> and "try" to maintain enough state to alter them back. :*(
>>  >>
>>  >>  > But if I am no longer using the notion of a current source 
>>  >> address at  > the transport end I don't care about that
>>  anymore and
>>  >> if that is  > possible that is a good thing.
>>  >>
>>  >>     IPvN source addresses are used to report routing problems:
>>  >>  other than that, they can mostly be ignored. (Indeed, they  can't
>>  >> even be trusted for that much: the less we depend on  them, the
>>  >> better.)
>>  >>
>>  >>     (There was a time when we believed routing based on source 
>>  >> address would help. Most of us would like to bury that idea...)
>>  >>
>>  >>  > I believe shim6 and hip get us very close to this model
>>  for the  >
>>  >> transport with current architecturs and specifications.
>>  >>
>>  >>     I must admit that I view both shim6 and hip as moving  targets
>>  >> trying to be too many things to too many people. I 
>>  suspect I'm not
>>  >> alone. In any case, both of those are  engineering, not
>>  architecture;
>>  >> for purposes of this list I
>>  >  > suggest explaining which features of them you'd like to
>>  >>  compare, rather than just naming a protocol.
>>  >>
>>  >>  --
>>  >>  John Leslie <[email-masked]>
>>  >>
>>  >
>>  >_______________________________________________
>>  >Architecture-discuss mailing list
>>  >[email-masked]
>>  >https://www1.ietf.org/mailman/listinfo/architecture-discuss
>>
>>

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.15.0/557 - Release Date: 29/11/2006

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.15.0/557 - Release Date: 29/11/2006

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: "Ian Peter" <[email-masked]>
Date: Fri, 1 Dec 2006 06:24:08 +1100

Thanks Marla

I think I hear you say that a solution is needed in 1-4 years

Ian Peter

-----Original Message-----
From: Azinger, Marla [mailto:[email-masked]] 
Sent: 01 December 2006 06:13
To: Ian Peter; [email-masked]
Subject: RE: [arch-d] Finding a way forward

Hello Ian-

Yes, action is required

Asking for a best guess timefame is opening a can of warms.  You will
receive answers ranging from 4 years, 20 years and never.

Lessons learned from the past show us "bandaids" are just that ( they tend
to degrade in worth).  Acknowleding this are a number of people looking for
a balanced solution that is technically sound and acknowledges time to
implementation.   

So you want difinitive answers on solution and time.  This really cant be
done.  But what can be done and what several people are attempting to do is
accept that we need a solution and that we need it relatively quickly (1-4
years).  Yes, there will always be people that want to debate the method and
the timeframe to the third degree.  However, there are also people willing
to take the facts from these debates and pick a direction and go with it,
and that is when solutions are made.  It will happen.

Thank you for your time
Marla Azinger
Frontier Communications
ARIN AC

-----Original Message-----
From: Ian Peter [mailto:[email-masked]]
Sent: Thursday, November 30, 2006 10:44 AM
To: [email-masked]
Subject: [arch-d] Finding a way forward

Ian Peter

-----Original Message-----
From: John Day [mailto:[email-masked]] 
Sent: 01 December 2006 02:51
To: Bound, Jim; John Day; John Leslie
Cc: [email-masked]
Subject: RE: [arch-d] On identifiers: what is virtual and what is global
(wasRe: thou...