(sipp) NSAPs in IP6

William Allen Simpson <bill.simpson@um.cc.umich.edu> Wed, 03 August 1994 16:17 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07479; 3 Aug 94 12:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07474; 3 Aug 94 12:17 EDT
Received: from Sun.COM by CNRI.Reston.VA.US id aa09978; 3 Aug 94 12:17 EDT
Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA10378; Wed, 3 Aug 94 09:16:17 PDT
Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA04997; Wed, 3 Aug 94 09:16:24 PDT
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00838; Wed, 3 Aug 94 09:18:21 PDT
Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00820; Wed, 3 Aug 94 09:18:08 PDT
Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA02312; Wed, 3 Aug 94 09:15:40 PDT
Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA10089; Wed, 3 Aug 94 09:15:22 PDT
Received: from pm002-12.dialip.mich.net (pm002-12.dialip.mich.net [35.1.48.93]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA09053 for <sipp@sunroof.eng.sun.com>; Wed, 3 Aug 1994 12:15:19 -0400
Date: Wed, 03 Aug 1994 15:11:14 +0000
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: William Allen Simpson <bill.simpson@um.cc.umich.edu>
Message-Id: <2963.bill.simpson@um.cc.umich.edu>
To: sipp@sunroof.eng.sun.com
Subject: (sipp) NSAPs in IP6
X-Orig-Sender: owner-sipp@sunroof.eng.sun.com
Precedence: bulk
Reply-To: sipp@sunroof.eng.sun.com

> From: jhalpern@Newbridge.COM (Joel Halpern)
> I must object to Bill Simpson's assertion.
>
> There may be good reason's to object to the usage of 1/32 of the address
> space for a portion of the transition plan.  However, the assertion by
> one member of the community that "I object" does not constitute sufficient
> reason to force re-drafting of the plan.

I must object to Joel's uninformed objection to my objection, etc, etc,
ad infinitum.

Moreover, I'm not the only one objecting.


> The proposal had clear text
> indicating the reasons for the support, and the fact that a different
> approach was preferred.  However, unless we are going to pretend that
> the rest of the world does not exist, it is incumbent upon the objector
> to either:
> A) Present an alternative strategy which meets the needs,  or
> B) Provide stronger reasons than his personal objections to the work
> 	going forward.
>
  A) That's odd, I'm sure I presented a strategy (using less space), and
     gave a quantitative measure (a 24-bit prefix).  How much more
     specific do you need, Joel?

     Actually, I'd prefer even less, and have a mechanism in mind to do
     it.  It requires mapping in IDRP.  Since there are so few NSAP
     prefixes in use, mapping should not be a problem.

     But, it's not my problem to find a solution to a useless feature.
     I merely set a constraint.  If that constraint can't be met, it
     should not be done.

  B) I'm quite sure that I listed a reason: NSAPs address fewer nodes
     than IPv4, and therefore should waste proportionately less IP6
     space.

     In the past, I have also listed several other reasons as well,
     including the _FACT_ that there are no deployed nodes running TCP
     over NSAPs, and the _FACT_ that there are no plans for running TPn
     over IP6.

     Therefore, I conclude that there are no uses for NSAP conversion
     to IP6, other than politics.  I am not willing to waste our space
     for politics.

> It is true that IP4 uses only 1e-28 of the address space.  That is because
> the IP4 address are smaller.

Your conclusion is incorrect.  The real reason that IP4 uses only 1e-28
of the address space is that there are less than 4e9 IP4 nodes.

Since there are less NSAP nodes than IP6 nodes, it is clear that there
is no objective reason to allocate more space.

> While the NSAPs are arguably badly
> designed, they are what they are.  Wishing will not make them different.
>
Maybe you are wishing, but I am perfectly willing to throw away a bad design.

That's an engineering conclusion.

Bill.Simpson@um.cc.umich.edu
 ------------------------------------------------------------------------------
IETF SIPP Working Group - Archives:  parcftp.xerox.com:/pub/sipp
Unsubscribe:	unsubscribe sipp		(as message body, not subject)
Direct all administrative requests to majordomo@sunroof.eng.sun.com