RE: [RRG] LISP next steps

["Tony Li" <tony.li@tony.li>]

Hi guys,

|> > My understanding/summary of what I heard this week
|> > (Tuesday, IIRC) is that the RRG will *not* recommend any
|> > of the proposed solutions (or any other?) but rather will
|> > recommend "concepts". What exactly constitutes a
|> > "concept" wasn't clear (at least to me), even though it
|> > was briefly discussed. 
|> 
|> OK - I haven't yet listened to the earlier part of the Tuesday
|> meeting, or the Friday meeting.
|> 
|> I guess the RRG would recommend development of a set of technical
|> concepts which would (ideally) fit together to create the complete
|> solution, or perhaps recommend some parts of the solution for
|> engineering development while leaving other parts up for further
|> research and discussion.
|
|	I think I understand what you're saying, Check me on
|	this: So the RRG should recommend a sort of
|	meta-recommendation, i.e., that the IETF should develop
|	"a set of technical concepts" that others (the IESG?)
|	would use to what, evaluate proposed working group
|	charters for WGs that do the protocol development for
|	some proposal that fits the "set of technical concepts"?
|	Is that close?   


Close, but one level off.  Again, we are chartered to deliver an
architecture.  Not do protocol development work.  Our job is to look at the
full broad solution space and attempt to narrow it down, starting from the
top and understand the full spectrum that is available.  Then to look at the
different segments within the solution space and continue to whittle those
down until we can partition the solution into particular functions and
describe the properties of those functions.  Thus, it's up to the RRG to
deliver "a set of technical concepts" that, integrated, form the
architecture.

In essence, we should be staying at a level of abstraction well above the
protocol work, where we are effectively providing a functional specification
of the various protocols, but not fill in the bits and bytes.  We should
stop entirely when we have an adequate definiton of the functionality.

Now, Dino will immediately respond that "the devil is in the details".  ;-)
This is certainly true.  However, this does NOT imply that we necessarily
need to work out all of the details to provide the functional specification.
In particular, where there is some question about the feasibility or
tractability of a particular approach, we should certainly be willing to go
off and perform some experiments (possibly even coding) to determine
tractability.  That does NOT mean that we need to fully flesh out a
prototype of all parts of our recommendation.


|	Do you envision these principles as being at the level
|	like "It is recommended that the IETF develop protocols
|	based on Locator/ID split", or more fine-grained like "It is
|	recommend that the IETF develop protocols based on
|	address rewriting"? Or something even more fine-grained? 


It should definitely get more fine-grained.  Again, it should be specific
enough, with enough rationale so that a set of WG's in the IETF can simply
sit down with it as their problem statement and quickly and directly sit
down to the task of protocol design.  They shouldn't have to ask how the big
pieces fit together or what it is that their particular function should do.
Again, please refer to the list of properties that we put together this week
for the mapping function.  We should be able to characterize all of these
down to some reasonable extent.

Exactly how much detail is necessary?  To borrow some legalese, someone
"skilled in the art" should have no problem sitting down and cranking out
something that just works, assuming that they do a reasonable job meeting
the specific recommendations and functional requirements.  At the same time,
the implementor shouldn't feel overly constrained.  Again, folks who are
practiced in writing software functional specifications should have a fair
understanding of the feel of this level of detail.


|	Also, do you envision that a recommendation could be
|	something unrelated to what the RRG has been focusing on,
|	say, like "It is recommended that the IETF develop
|	protocols based on the NIMROD architecture"?


It's certainly possible that we might turn up a new sector in the solution
space in our discussions.  Handley's proposal, for example, was a segment
that was not previously discussed.  I would not discount that there are
other segments that are unexplored -- we have not made a systematic search
of the solution space.

However, making a recommendation of NIMROD would be precisely what I'm
suggesting that we don't do: refer to a specific proposal.


|> > The LISP BOF proposal has nothing to do with any other
|> > proposal.


Moreover, the BOF proposal is outside of the scope of the RRG and is,
frankly, off topic for the mailing list.  I do realize that there is some
commonality of interest in the audience, but holding the BOF is *not*
forwarding our work within the RRG, and discussing holding the BOF is simply
a level of indirection on a tangential subject.


Tony


--
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