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

[dimitri papadimitriou <dpapadimitriou@psg.com>]

hi scott

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?

yes.

> Unintentional changes are covered under "Failure Modes".  I'll add a 
> line under "churn" for intentional changes.

ok.

> (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.)

this is why i proposed here below

"-> in-band/user-driven trigger impact for mapping resolution (more than
longest match-prefix lookup as performed today)" you could instead refer 
to effect/impact of dynamic population of the mapping entries at TRs

indeed, the event is the reception of a packet for which a mapping is 
absent in addition to the fwd'ing decision towards next hop.

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

yes.

> Do you mean the source of mapping information 
> for the tunnel routers?  Can you expand on this one a little?

the communication/exchange between routers making use of mapping and the 
mapping repository (could be at the lowest level of decomposition 
completely distributed) is of different nature than the exchange between 
repositories.

> > -> in-band/user-driven trigger impact for mapping resolution (more than
> > longest match-prefix lookup as performed today)

i don't see this one in the new version.

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

it is a "new" topic that i consider as important due to the timeframe 
and uncertainty on sizing the system will have to cope with. so, the 
issue of evolvability of the system shall be taken into account. i have 
tried to provide for the elements that would need to be taken into to 
enable for mapping system evolvability.

> > editorials
> >
> > "Push, Poll, Hybrids"
> >
> > -> replace by "Push, Pull, Hybrids"
>
> Done.
>
> I'm attaching the updates I've done, and a diff.

ok. thanks. looking at the next iteration. it would be appropriate at 
some point in time (after list is completed) to translate bullet points 
into short explanatory paragraphs.

thanks,
-d.

> 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