Re: Progress?

"Paul Francis (formerly Paul Tsuchiya" <francis@thumper.bellcore.com> Tue, 08 June 1993 21:29 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11052; 8 Jun 93 17:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11048; 8 Jun 93 17:29 EDT
Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa25294; 8 Jun 93 17:29 EDT
Received: by thumper.bellcore.com (4.1/4.7) id <AA13857> for ietf-archive@nri.reston.va.us; Tue, 8 Jun 93 17:29:05 EDT
Received: from tsuchiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id <AA13850> for /usr/lib/sendmail -oi -fowner-pip X-pip; Tue, 8 Jun 93 17:29:04 EDT
Received: by tsuchiya.bellcore.com (4.1/4.7) id <AA03811> for pip@thumper.bellcore.com; Tue, 8 Jun 93 17:29:02 EDT
Date: Tue, 8 Jun 93 17:29:02 EDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Paul Francis (formerly Paul Tsuchiya" <francis@thumper.bellcore.com>
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Message-Id: <9306082129.AA03811@tsuchiya.bellcore.com>
To: Garrett.Wollman@uvm.edu, pip@thumper.bellcore.com
Subject: Re: Progress?

>  
>  This list has been very quiet recently.  Would anyone (Paul?) care to
>  make a summary of what has transpired in the last few months?
>  

Yes, it has been quiet.  I've been meaning to put out
a progress report, but have been negligent....


We're continuing to work on specs and implementation, and
we're starting to put together the pBone....

Spec-wise, I'm just finishing up revision of the ID and
architecture specs.  I'm also just finishing up new specs
that discuss host operation and addressing conventions.
The latter is quite interesting, in part because I introduce
a new address type, something I'm calling "nearcast".  
Nearcast is sending a packet to the "nearest" of a set
of systems.  Kind of a cross between multicast and unicast.
It is useful for various kinds of discovery.  (We'll be
using it for auto-configuration for Pip, though I guess
there will be many uses for it.)

These specs will be out by the end of the week.

Bala Rajagopolan is working on Pip routing.  We are tying
the routing protocol to IDRP, and he has been looking over
existing IDRP code to add Pip to it.  

The Bellcore implementors, Sue Thomson and Ramesh Govindan,
have been continuing various things.
The DNS implementation is being improved to deal with various
transition scenarios, including translating between IP DNS
requests and Pip DNS requests.  They have added some PCMP messages
to the router implementation, including router discovery, 
ping, and trace route.  We'll be demoing this stuff in Amsterdam
(if the IESG approves demos).  They've done more to the host code,
generalizing it somewhat for address selection.  Also, we have
completed the code that allows for static configuration of a
Pip network.  We'll use this to experiment with Pip and transition
while the routing algorithm is being developed and tested.


We're putting together an initial testbed now.  This will be
up before Amsterdam, and will consist of about 10 nodes around
the world.  You'll be able to ping and trace-route these machines
from Amsterdam.  After we work out any kinks that come up from
this limited pBone, we will open up participation to anyone who
wants to get involved.


A couple of issues have come up.  One has to do with transition.
I'm finding that the "IPAE" style of putting a valid IP address
in the packet header (in this case, the Pip ID) constrains Pip.
For instance, mobility is constrained because, if the host moves,
then it gets a new IP address, which means a new Pip ID, which
blows Pip's mobility mechanism.  So, I'm seriously thinking of
a new transition scheme that completely divorces Pip from IP.
This requires a more sophisticated Pip/IP translation scheme,
but so far appears workable.

The other issue has to do with the format of IDs.  I'm beginning
to think that putting any kind of hierarchy in the ID is not
good.  I think it might be best to just keep the ID flat.  This
makes a lot of things simpler, auto-configuration being just one.