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

From: Scott Brim <[email-masked]>
Date: Tue, 11 Mar 2008 17:05:32 -0400

Attached is the list of criteria from this morning, modulo a little 
editing.  This is not complete.  Please add *and* delete and clarify.

My own comments will follow.

Scott
Support for other network needs
-------------------------------

- Mobility.
  - Impact on preferences for mobility approaches
  - Does it meet mobility requirements
- Emergency services.

Delay and/or Drop of initial packets
------------------------------------

- Whether there will be any delay at all (might even get there
  faster).
- Number of packets that might be delayed, dropped.
- Between sites and/or hosts.
- Trade off determinism of delay/drop versus agility & light weight.
  Analyze based on how bad it would be.
- Effect on transport layer, session.
- Ultimately only end user experience is visible.
- Possibility of difference classes of service?

Push, Poll, Hybrids
-------------------

- Possibly proactive, dynamic adjustment of behavior.
  - By src/dst (site)
  - Responsiveness
  - Other parameters?

Security considerations
-----------------------

- Interactions with drop/delay.  (Eliot Lear -- needs clarification
  please).
- Authorization: Don't take requestors down garden path.  Don't give
  them information they aren't authorized to actually use.
- Security of mapping system itself: updates authenticated .
- Authentication of map replies.
- Interactions between security of mapping system and security of core
  routing.

Granularity
-----------

- What level of specificity?
- Ability to operate at multiple levels of granularity simultaneously.

Churn
-----

- How system responds with rate of intentional changes.

Mapping points
--------------

- Flexibility in mapping points: end system, domain border, in
  between.  
- Placement of mapping points: those that own the mappings, those that
  use them, or in a third party
- Who is authoritative for the mapping.  Owner, holder, user.

Interaction between rate, state, and delay
--------------------------------------

- Interaction between rate, state, and delay.

Deployability (Incremental)
---------------------------

- Interworking with existing deployments.
- How soon are benefits seen?
- Who gains.  Is it the one doing the deployment?
- Does a deployment require more than one party, coordinated?
- Easing v4=>v6 is not an issue.

Flexibility
-----------

- Possibility for hierarchy
- Ability to express preferences (policy)

Failure modes
-------------

- How does mapping system adapt to unintentional changes in reachability (if at
  all).
- Dependence on something not on the data path (-> uncontrolled  weaknesses).
- Resilience of mapping system.

---

From: dimitri papadimitriou <[email-masked]>
Date: Sat, 15 Mar 2008 20:35:26 +0100

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

-> also consider mapping entries change/variation for ongoing traffic
flows and the side effect with corrupted entries

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

in "Push, Poll, Hybrids"

-> distinguish communication between MP and communication between TRs and MP

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

editorials

"Push, Poll, Hybrids"

-> replace by "Push, Pull, Hybrids"

-- i suppose this list is going to be translated into a document that
proposals making use of mapping system will consider and address.

thanks,
-d.

--
to unsubscribe send a message to [email-masked] 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

---

From: "Tony Li" <[email-masked]>
Date: Sat, 15 Mar 2008 21:19:30 -0700

Hi Dimitri,

Thanks for the comments.

|-- i suppose this list is going to be translated into a document that
|proposals making use of mapping system will consider and address.

Hopefully this list will be the basis for our discussion about the
properties of the mapping subsystem.  As we reach consensus on the issues in
this discussion list, we should end up with a complete characterization of
the mapping component.  This would in turn become part of our final
recommendation, assuming that we opt for an approach that requires mapping.

Tony

---

From: Scott Brim <[email-masked]>
Date: Tue, 18 Mar 2008 16:41:44 -0400

Hi Dimitri.

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

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

> -> for the transport layer (e.g. flow and congestion control)

Done

> -> distinguish communication between MP and communication between TRs 

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?

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

> -> replace by "Push, Pull, Hybrids"

Done.

I'm attaching the updates I've done, and a diff.

Scott

- Mobility.

Differential Delay and/or Drop of initial packets
-------------------------------------------------

- Whether there will be any delay at all (might even get there
  faster).
- Number of packets that might be delayed, dropped.
- Between sites and/or hosts.
- Trade off determinism of delay/drop versus agility & light weight.
  Analyze based on how bad it would be.
- Effect on transport/session layers (e.g. congestion control).
- Effect on short elastic and long bulk flows.
- Ultimately only end user experience is visible.
- Possibility of difference classes of service?

Push, Pull, Hybrids
-------------------

Security considerations
-----------------------

Granularity
-----------

Churn
-----

- How system responds with change in rate of intentional changes.
- Effect of changes to mappings on established flows.

Mapping points
--------------

Flexibility
-----------

Failure modes
-------------

*** /Users/sbrim/working/routing/mappingCriteria_080312.txt	Wed Mar 12 10:10:15 2008
--- /Users/sbrim/working/routing/mappingCriteria.txt	Tue Mar 18 16:38:02 2008
***************
*** 7,14 ****
  - Emergency services.

! Delay and/or Drop of initial packets
! ------------------------------------
  
--- 7,14 ----
  - Emergency services.

! Differential Delay and/or Drop of initial packets
! -------------------------------------------------
  
***************
*** 16,27 ****
! - Effect on transport layer, session.

! Push, Poll, Hybrids
  -------------------
  
  - Possibly proactive, dynamic adjustment of behavior.
--- 16,28 ----
  - Between sites and/or hosts.
  - Trade off determinism of delay/drop versus agility & light weight.
    Analyze based on how bad it would be.
! - Effect on transport/session layers (e.g. congestion control).
! - Effect on short elastic and long bulk flows.
  - Ultimately only end user experience is visible.
  - Possibility of difference classes of service?

! Push, Pull, Hybrids
  -------------------
  
***************
*** 52,59 ****
  Churn
  -----
  
! - How system responds with rate of intentional changes.
! 
  
  Mapping points
  --------------
--- 53,60 ----
  Churn
  -----
  
! - How system responds with change in rate of intentional changes.
! - Effect of changes to mappings on established flows.
  
  Mapping points
  --------------

Diff finished.  Tue Mar 18 16:38:52 2008

---

From: dimitri papadimitriou <[email-masked]>
Date: Wed, 19 Mar 2008 09:10:30 +0100

hi scott

> established flows immediately after mapping entries change -- is that 

yes.

> line under "churn" for intentional changes.

ok.

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

> Is MP a Mapping Point?  

yes.

> Do you mean the source of mapping information 

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.

>> longest match-prefix lookup as performed today)

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

> I can't find any of this in what I sent out.  Could you send me what you 

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.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Mar 2008 15:23:32 +1300

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