Re: [RRG] mapping "issues" list from this morning

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

Scott,

Many moons ago I posted
http://tools.ietf.org/id/draft-carpenter-idloc-map-cons-01.txt

Feel free to adapt/adopt (xml is available if useful). It will
be interesting to see what we've learned.

   Brian

On 2008-03-19 09:41, Scott Brim wrote:
> Hi Dimitri.
> 
> On 3/15/08 3:35 PM, dimitri papadimitriou allegedly wrote:
>> hi - a couple of comments/suggestions here below:
>>
>> "- Whether there will be any delay at all (might even get there
>>   faster)."
>>
>> -> differential delay would better translate this issue
> 
> Good point.  That's what we try to use when we talk about it anyway.
> I'll change the section title.
> 
>> -> also consider mapping entries change/variation for ongoing traffic
>> flows and the side effect with corrupted entries
> 
> To paraphrase: the possibility of additional delay/drop for packets in
> established flows immediately after mapping entries change -- is that
> right?
> 
> Unintentional changes are covered under "Failure Modes".  I'll add a
> line under "churn" for intentional changes.
> 
> (I don't think "delay" should be a major heading of its own, because
> delay is a result, not an event, but I don't know how to organize things
> yet so that the "delay" section goes away.  When someone actually tries
> to use this list, we'll know how to organize it better.)
> 
>> "- Number of packets that might be delayed, dropped."
>>
>> -> add "effect on e.g. short elastic and long bulk flows"
>>
>> "- Effect on transport layer, session."
>>
>> -> for the transport layer (e.g. flow and congestion control)
> 
> Done
> 
>> in "Push, Poll, Hybrids"
>>
>> -> distinguish communication between MP and communication between TRs
>> and MP
> 
> Is MP a Mapping Point?  Do you mean the source of mapping information
> for the tunnel routers?  Can you expand on this one a little?
> 
>> -> in-band/user-driven trigger impact for mapping resolution (more than
>> longest match-prefix lookup as performed today)
>>
>> add in "mapping points"
>>
>> -> distribution of the mapping points vs modes (push, pull, hybrid)
>>
>> -> impact of mapping point failure (for LISP 2 and 3 for inst. a there
>> is no fate sharing this would result in serious impact)
>>
>> add issue of evolvability
>>
>> -> EID allocation and structure (noticing that a 1:1 mapping does not
>> resolve any routing system scalability issue)
>>
>> -> mapping system scalability and complexity
> 
> I can't find any of this in what I sent out.  Could you send me what you
> are quoting from?
> 
>> editorials
>>
>> "Push, Poll, Hybrids"
>>
>> -> replace by "Push, Pull, Hybrids"
> 
> Done.
> 
> I'm attaching the updates I've done, and a diff.
> 
> Scott
> 

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