PROs/CONs of SIP/PIP/TUBA

[Eric Fleischman <[e-mail]>]

                            Request for Assistance

I am frequently asked by other Boeing employees to explain to them the PROs 
(advantages) and CONs (disadvantages, unknowns, vulnerabilities) of the 
major IPng approaches.  I have constructed the following list of the unique 
elements which form the PROs and CONs of SIP, PIP, and TUBA in order to 
partially satisfy these requests.  However, I have noticed that my own 
understanding of these approaches is imperfect.  This implies that I may have 
inadvertently misrepresented some of the proposals in various ways.  
Unfortunately, I am not usually aware of when I have been inaccurate.  For 
this reason I am sending this note out to the SIP, PIP, and TUBA working 
groups in order to elicit their assistance to more accurately characterize 
these approaches.  I offer my apologies to those people who, like me, belong 
to multiple lists since this will mean that we will be bothered by multiple 
copies of this note.

I would like to request that interested parties read the following lists of 
PROs and CONs in order to enhance the list.  I recognize the possibility 
that differing people may label the same feature differently since there are 
a variety of legitimate and differing perspectives by which the IPng issues 
may be viewed.  For this reason, I would appreciate it if the responders 
would explicitly note the viewpoint of their comments (e.g., network 
providers, university, router vendor, end system vendor, government, 
non-computer-related industry, etc.) together with their sage advice 
as to how this list may be improved/enhanced.  An enhanced version of 
this list may be requested in a week or two once the anticipated 
suggestions have been assimilated.

One more thing:  I have no desire to spark another "whose protocol is best" 
flaming fest by this request (hence I am not sending it to the
big-internet list).  Thus, I suggest that any respondent seriously 
consider not copying the entire list unless the response is deemed to be of 
value to the community as a whole (i.e., accomplishes more than just 
instructing a certain naive yours truly).

In any case, thank you for your attention to this matter.

Sincerely yours,

--Eric Fleischman

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

                                   SIP Pro

1)  As much like the current TCP/IP network layer protocols as possible 
(except for SIP System Discovery which enhances upon the current protocols).  
This leverages off of our current IPv4 knowledge-base for IPng deployments 
(e.g., reduce training costs, etc.).  It also greatly reduces the "risk 
factor" of introducing new technologies.

2)  SIP has fewer options than IPv4 which means that it is even simpler 
than IPv4 to process (e.g., to route).

3)  Theoretically positioned to better support "flows" and other future 
technologies than is the case for IPv4.

4)  Has IPAE and other well-thought-out migration approaches.  [Question 
to the reader:  I suspect that a slightly modified IPAE would also work 
for TUBA and EIPIP has been proposed for PIP.  Thus, is this really an 
advantage of SIP?  Isn't it rather merely a function of the expertise of 
the original SIP designers rather than an inherent advantage of the SIP 
approach?]

                                 SIP Con

1)  Since hierarchical addresses tend to be deployed in a "sparse" manner, 
it unclear whether a 64 bit address space will adequately scale to meet 
every conceivable future addressing scenario. 

2)  No SIP protocol is totally unchanged from its "IPv4" equivalent.  This 
introduces a certain degree of risk in its deployment (i.e., the unknown).

3)  No network provider currently supports SIP.

4)  RFC 1454 stated:  "although there are a few 'reserved' bits in the 
header, the extension of SIP to support new features is not obvious".  
[Question to the reader:  Is this really the case?  Isn't it rather the 
case that new features will be supported by optional header data field 
additions whose existence is signaled by the payload type field?  But then, 
how would this be generally extensible for complex permutations of payload 
types?  If so, then probably the original claim of RFC 1454 has merit.  
Does it?]

--------------------------------------------------------------------------

                              PIP Pro

1.  General routing and addressing without performance hit (i.e., in most 
cases PIP routes faster than IPv4.  Exception is IP cache hit...)   Tangible 
near-term benefit of this generality is provider selection and policy routing 
in general together with potentially simplified address administration.  
Longer term benefit of this generality is ability to evolve to new routing 
and addressing paradigms.

2.  PIP has more features.  These include provider selection, auto host
configuration (address, ID, domain name, and DNS server address, plus 
auto-config of DNS), PDN address discovery, and domain-wide address prefix 
autoconfiguration.

3.  Evolvability.  PIP is architected to be well positioned to support 
"flows" and other future network-layer technologies (e.g., separation of 
routing/identification/handling), plus has explicit evolution mechanisms 
(contents numbers, host version number, fast options handling).  This will 
hopefully enhance the possibility of support for real-time services.

                              PIP Con

1. Complexity. 

2.  PIP is not directly based on existing protocols.  Thus, it represents new 
technologies and it has a new addressing paradigm.  This "newness" implies 
an unknown deployment "risk" factor (i.e., the "unknown").  

3.  Since the PIP approach is novel, it represents a significant "learning 
curve" for deployments with attendant expenses.

4.  No network provider currently supports PIP.

--------------------------------------------------------------------------

                             TUBA Pro

1.  Every TUBA protocol already exists and has experienced some degree of 
actual deployment experience.  TUBA adopts these OSI network layer protocols 
in an unchanged fashion.

2.  Internet currently becoming "bilingual" with IPv4 and CLNP.  Thus, no 
change for many network providers to support TUBA.

3.  Will partially join the TCP/IP and OSI/CCITT communities -- hopefully 
for greater synergy between these communities for those end users which 
currently support both protocol families.  This may translate into reduced 
end user network complexity.  

4.  Has proven auto-configuration (auto-addressing) capabilities.

5.  Is based upon International Standards and government-supported protocols 
which are currently mandated in certain environments.

6.  Integrated IS-IS already exists for mixed IPv4/TUBA deployments.  
Integrated-OSPF (for IPv4/IPng) is yet to be defined.

7.  The 160 bit TUBA address space is well positioned to meet any future 
address scaling requirement.

                                 TUBA Con

1.  Unless a company is already familiar with OSI's connectionless network 
layer protocols, TUBA represents a significant "learning curve" for 
deployments with attendant expenses.

2.  TUBA is no more positioned to support "flows" and other possible future 
technologies than is IPv4.

3.  TUBA supports a 160 bit network address which represents a potentially 
significant overhead penalty for some environments.

4.  TUBA protocols are not "tuned" for maximum routing efficiency (e.g. 
checksum, attention to 32-bit CPU alignment issues).