Re: [RRG] RRG process clarification

[Robert Bonomi <bonomi@mail.r-bonomi.com>]

> From: Scott Brim <swb@employees.org>
> Date: Tue, 6 May 2008 15:52:52 -0400
> Subject: Re: [RRG] RRG process clarification
>
> On 5/2/08 12:47 PM, Tony Li allegedly wrote:
> > It should be noted that some folks come at things with an alternate
> > branching structure:
> > 
> > 	- Map-n-encap
> > 	- Translation
> > 	- Transport
>
> I would go with this conceptual framework, but not call it "transport",
> since that can be confusing.  The point is that the solution is in the
> endpoints (i.e. transport layer) not in the network.  Perhaps just say
> "endpoint-based".

Looking strictly at methodologies for change, the available options are:

   1) 'Replacement.'  Tear out the old-style infrastructure and replace it 
      "in toto".  This requires the origin point to do things the 'new way',
      the destination point to do things the 'new way', and requires` all 
      intermediate points to do things the 'new way', as well.

      NOTE:  It may be possible for old-style and new-style protocols to 
      co-exist on the wire, but there is -no- inter-operation between the 
      new-style and old-style nodes.

      Anything/everything 'new style' operates exclusively in the new-style
      domain.  Everything old-style operates exclusively in the old-style
      domain.  If an end-point wishes to be present in both domains, that
      _end-point_ must implement both protocols itself.

      Advantages: option for 'clean slate' design; no 'historical baggage'
      to deal with; single, uniform methodology end-to-end; any device and/or
      application works 'anywhere'.

      Disadvantages:  either/or solution; requires a 'flag day' cut-over;
      chicken and egg acceptance problem; reaching critical mass; possible 
      balkanization, etc.  

   2) 'Translation.'  Allows old-style end-points to communicate with new-
      style end-points *IF* a suitable 'gateway' is interposed "somewhere.
      "Network" elements can be either old-style or new-style depending on 
      which side of the translation gateway they are on.  In fact they _must_ 
      be either old-style or new-style on the appropriate sides of the gateway.
      multiple translations can occur on a path.  "old->new-old" is lossless,
      "new->old->new" _can_ result in partial loss of functionality.

      Functional requirements:
	 (1) Anything attempting to communicate with an 'old-style' system 
	     must not rely on any 'features' of the new-style protocol that 
	     cannot be 'back-mapped' into the old-style communication.
         (2) An "old->new->old" double-translation must be lossless. i.e.,
	     as if there had been no translation at all.

      Advantages:   "mixed-mode" operation possible. "anything can talk to
      anything", as long as there is _a_ path with required translation 
      capabilities between the two end-points.  Network infrastructure
      can move  more-and-more to 'new style' (from center outwards), by 
      simply moving the translation points closer to the end-users.

      Disadvantages: "Translation" devices require a fairly intimate knowledge
      of both new-style and old-style protocols, and there are far too many
      opportunities for Murphy to stick his oar in when _exact_ equivalence 
      between old- and new-style functionality doesn't exist.

   3) 'Encapsulation.'  Implement an arbitrary new-style layer 'underneath'
      what the end-users see.  This preserves/presents the 'appearance' of
      the old-style protocol to the outside world, _while_ being free to
      do  "whatever seems appropriate" in the infrastructure, *without* any
      visible impact (except possibly indirectly, in a performance change)
      to external users.
      
      Functional requirement:
	 (1) a method of determining which new-style device at the far edge
	     of the new-style network should recieve packs for old-style
	     address '0xDEADBEEF'. This requires an information flow _from_
	     the old-style domain _into_ the new-style one.  Since the
	     infrastructyre layer is normally 'utterly invisible' to the
	     end-user layer, this requires the addition of specialty devices
	     that have conscious visibility at both layers.


      Advantages: complete decoupling of end-user requirements from the infra-
      structure.  ANY/ALL future infrastructure changes are essentially 
      invisible to the end user.  "Virtual" clean-slate to design on, any/all
      'historical baggage' is simply data to the new-style infrastructure.
      _CAN_ be rolled out incrementally although the main benefits occur only
      when (at least near-) "universal" adoption has occured.  "Encapsulation"
      is easy to do.

      Disadvantages:  must now maintain tables of 'mapping' information not
      formerly needed.  Possible additional latency on connection initiation
      depending on how this 'mapping' information is (a) organized, and 
      (b) disseminated.  Additional hardware required to perform the 
      encapsulation and mapping. "Mapping" is is a -hard- issu issue.



--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg