[ppml] "Recommended Practices" procedure

[Owen DeLong]

--On May 1, 2006 9:49:36 AM -0700 "Azinger, Marla" <marla_azinger at eli.net>
wrote:

> Michel-  Thank you for taking the time and writing those responses.
> 
> Michel wrote:
> <c) and d) are structural design issues that are deliberate design
> <choices. No changes to shim6 can make operators happy with TE issues
> <neither could they convince enterprises that multiple PA addresses per
> <host is a supportable solution.
> 
> I am curious though.  The way you view Shim 6 and its creations/workings
> is very dire.  I confess I dont know the people who actually work on the
> Shim 6 creation.  Do they feel it is as hopeless as your view?  Any
> chance you know a few of them and could get them to post their view on
> ppml?  If Shim 6 is this hopeless then it seems the only solution left in
> our hands is to use V6 as is like we need.  
> 
Shim6 is the wrong answer to the wrong question.  The question we should
be asking is "How do we build a scalable IDR[1] architecture?"  What
shim6 answers "Given that we won't build a scalable IDR architecture,
how can we hack in enough support for multihoming that we can hope
nobody insists on solving the other problems created by a PA-only
world?"

Yes, it is pretty dire, actually.  However, there are other solutions.
We need to go back and re-examine true ID/LOC splits.  This can be
done either by the use of extension headers, or, through the
reservation of some high-order bits for a routing LOC and some
modifications to routers to perform replacements on the LOC portions
of the packet.

Doing it with the high-order bits would be more of a flag-day kind
of change, but, there are probably some clever tricks that can be
done to mitigate this.  Doing it with an extension header would be
harder on the silicon engineers, but, would preserve complete backwards
compatibility and not require any sort of flag-day changes.

Anyone who wants a more detailed description of my thinking on this,
send me a note OFF LIST and I'll forward you the details.

> Michel wrote:
> <The way out of this mess is a BGP replacement that could handle
> <large-scale PI.
> 
> This suggestion only addresses PI.  Why is everyone stuck on PI?  There
> are large networks that need these capabilities (multihoming) as well.
> We need solutions that enable Upstream Providers to employ multihomig as
> well.
> 
Marla, by definition, blocks ALLOCATED to LIRs are PI space to begin with.
Large networks fall into one of two categories... LIRs (as I think you
are describing) who were always able to get PI space, and, End Sites
who cannot get PI space until 2005-1 becomes policy.  In the latter
case, this covers any organization which does not sell transit and has
more than about 500 hosts and multihomes (2002-3).

> First, thank you for the laugh.  I never thought the IETF as an evil
> empire.  But the "perseption" that I am left with over the years is that
> the IETF seems a bit unreachable.  Yes, this is partly because I have not
> had the money or priviledge to attend an IETF conference and make the
> face to face contact.  And for the past several years kept "hoping in
> vein" that some majic liason person from IETF would come to an ARIN
> conference and take down our concerns and suggestions and then return
> later with a response from IETF or something to that effect.  I pulled my
> head out of the sand this time however, and came to realize that lack of
> action and response on my part was also the problem.  So to hear you say
> they dont need my reminder or theory of motivation is disheartening, but
> from where I sit my perception is that they do.  If anything, to at least
> get a response and answer of help with the situation.  We need to take
> action now, not sit in silence hoping this nightmare passe  s us by.  
> 
FWIW, Tony Hain, Tomas Narten, and many others who were at ARIN in Montreal
are active in IETF.  Being active in IETF does not require attendance at
the IETF meetings. Most of the IETF work is done on the mailing lists and
all you really need to do is allocate a bunch of time and join one or more
of the mailing lists.

> Also, fortunatley  Thomas Narten who is involved with IETF has responded
> to this string and has expressed a willingness to help with this.  So I
> dont think my "reminder or motivation" was useless.  I get your point
> that the IETF may not be ignorant to this issue at hand, but the
> communication and lack of action gives a different perception to the
> masses.
> 
IETF is definitely not ignorant, but, it is overweighted with vendors, large
ISPs, and Academia and underweighted with operators and end-users.  This
creates an interesting polity in the IETF which does not lead to the most
universal solutions being able to gain traction.

Owen

-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20060501/e2533bee/attachment.sig>