Subject: Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP

From: David Meyer <[email-masked]>
Date: Tue, 20 Jan 2009 11:07:44 -0800

Folks,

	The IESG would like to know whether people believe that
	we can go directly to our first LISP WG meeting at the
	next IETF, or if another WG forming BOF is necessary.

	Here are the current facts on the ground:

	o We have fairly mature set of core drafts
	o There are a number of other (non-core) LISP drafts
	o Significant global deployment is underway
	o We have 2 (or more) implementations
	o We have been discussing a draft charter (see update below)

	The question is that I would like folks to respond to is
	 "Should a WG be formed based on the draft agenda
	 (see below), or should we have another BOF?"

	Please give your opinion as soon as possible so we can
	close on these administrative issues. 

	Thanks,

	Dave
--

LISP (Locator/ID Separation Protocol)

Last Modified: 2009-01-20

Chair(s):
 TBD

Internet Area Director(s):
 TBD

Routing Area Advisor:
 TBD

Secretary(ies):
 TBD
 
Mailing Lists:
 General Discussion: [email-masked]

Description of Working Group:

LISP and companion documents (see below) are proposals that
respond to the problems discussed at the IAB's October, 2006
Routing and Addressing Workshop [0]. The purpose of the BOF is to
form a working group whose charter (see below) is to work on the
design on the LISP base protocol [1], the LISP+ALT mapping system
[2], LISP Interworking [4] and LISP multicast [6]. The working
group will encourage and support interoperable LISP
implementations as well as defining requirements for alternate
mapping systems. The Working Group may also create EID-prefix
assignment guidelines for RIRs, as well as security profiles for
the ALT (presumably using technology developed in the SIDR
working group).

Goals and Milestones:

Mar 2010  Submit base LISP specification to the IESG for
          Experimental.

Mar 2010  Submit base ALT specification to the IESG for
          Experimental.

Mar 2010  Submit the LISP Interworking specification to the IESG
	  for Experimental.

June 2010 Submit Recommendations for Allocation and Routing
	  of both EIDs and RLOCs to the IESG for Experimental.

June 2010 Submit Recommendations for Securing the LISP Mapping
	  System to the IESG for Experimental.

July 2010 Submit LISP for Multicast Environments to the IESG for
	  Experimental. 

Aug  2010  Re-charter or close.

Internet-Drafts:
	draft-farinacci-lisp-11.txt
	draft-farinacci-lisp-multicast-01.txt
	draft-fuller-lisp-alt-03.txt
	draft-lewis-lisp-interworking-02.txt

Request For Comments:
	  None

References
----------
[0]     Meyer, D. et. al., "Report from the IAB Workshop on
        Routing and Addressing", RFC 4984.

[1]     Farinacci, D. et. al., "Locator/ID Separation Protocol
        (LISP)", draft-farinacci-lisp-11.txt.

[2]	Fuller, V., et. al., "LISP Alternative Topology
	(LISP-ALT)", draft-fuller-lisp-alt-03.txt

[3]	Iannone, L., and O. Bonaventure, "OpenLISP Implementation
	Report", draft-iannone-openlisp-implementation-00.txt.

[4]	Lewis, D., et. al., "Interworking LISP with IPv4 and
	IPv6", draft-lewis-lisp-interworking-02.txt.

[5]	Mathy, L., et. al., "LISP-DHT: Towards a DHT to map
	identifiers onto locators", draft-mathy-lisp-dht-00.txt.

[6]     Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
	"LISP for Multicast Environments",
	draft-farinacci-lisp-multicast-01.txt.  

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/routing-discussion

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Jan 2009 09:24:51 +1300

Can you give a little more background on these two points,

> 	o We have 2 (or more) implementations

What's the nature of the deployment, and am I correct
in thinking that only one of the implementations is from
a core router vendor?

Those questions being asked and answered, I don't personally
see that another BOF is called for. The IESG just has to make its
normal assessment of whether the support is broad enough.

Thanks

     Brian

---

From: David Meyer <[email-masked]>
Date: Tue, 20 Jan 2009 14:09:55 -0800

---

From: "Soininen, Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 21 Jan 2009 00:15:16 +0200

I am sorry if I'm a bit lost here. Perhaps I just haven't paid enough
attention. Did the RRG conclude and decide to take LISP or is this a
parallel activity? 

If this is a parallel activity what is the intended connection to the RRG
work?

Sorry for the perhaps simple questions and thanks for the answers in
advance!

Cheers,

Jonne.

On 1/20/09 9:07 PM, "ext David Meyer" <[email-masked]> wrote:

> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Jan 2009 01:36:27 +0200

As you recall, a BOF was held on EXPLISP in Dublin. In Minneapolis we 
had a number of WGs and the RRG talk about LISP. Implementation and 
small scale deployment is going on. The RRG is still continuing its 
work, and they are looking at a number of different solutions, including 
map-and-encap, translation, host changes, and combinations thereof. I do 
not want to preempt the RRG's efforts and at this time we are NOT 
considering any IETF standards in this area. We are, however, 
potentially interested in working groups targeting experimental 
specifications so that we can get more experience about the various 
technical solutions, different people can build systems that work 
together, etc. Some of you may be familiar with the HIP effort; they 
also had a working group that produced experimental RFCs to complement 
the more research oriented work in the IRTF HIP group.

My interpretation of the outcome of the first BOF was that the topic was 
very interesting for the people in the room but that at the time they 
felt it was more in research than IETF scope. There were also technical 
debates. That being said, we did not spend enough time on the WG 
formation question. So I did not view the results as final. 
Nevertheless, several attempts were made in the autumn to create some 
form of a subgroup in RRG to do this work. However, the proponents were 
only interested in a working group.

So what is happening now is what we did with many other BOF efforts as 
well. We got feedback in the BOF, there's been further discussion, and 
work on various fronts has progressed. Its time to complete the 
discussion about the fate of this effort. We need to see if additional 
information or further changes can result in a WG proposal that is 
acceptable to the community or not. If we can reach a decision on the 
list, fine, if not I will reserve a second BOF slot for the discussion. 
I am mindful of the fact that the list discussion may not reach quite 
the same crowd as a f2f meeting, so unless we get a fairly strong signal 
in the list we probably need to meet as well.

But back to the proposal. In particular, I would like to know how people 
feel about this work being ready for an (Experimental) IETF WG, what the 
scope should be, whether the charter is reasonable. And if not, what 
would make it so.

Dave, can you post a summary of changes in the proposed charter since 
the first BOF? I see that you have already posted some information on 
what is going on in the implementation front -- that was very useful, 
thanks. Has there been other significant events since last summer?

Jari

P.S. Maybe we should reply on just one list from now on. Please use, 
say, int-area because I do not think everyone's on the lisp list.

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Wed, 21 Jan 2009 11:55:06 +0100

The task consisting in discovering by experimentation architectural fit
(wrt initial objectives) and complement understanding wrt known
challenges (mapping, caching, loc.reachability, impact on traffic
spatio-temporal properties) is very different in nature than ensuring
interoperability among protocols, minimize operational impact, and
facilitate integration/deployability -> so requiring different type of
efforts with different timelines. As a matter of fact, both types of
activities are still required imho. 

So the question - that is not administrative - boils down imho to: can
we exclusively concentrate on the LISP protocol(s) specifics leaving the
issue of our confidence on the Loc/ID split and associated challenges
open. That question deserves imho a specific discussion that should
happen in the context of a BoF. 

Thanks,
-dimitri.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David Meyer
> Sent: Tuesday, January 20, 2009 8:08 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [Int-area] Please respond: Questions from the IESG 
> as to whether aWG forming BOF is necessary for LISP
> 
> 
> 	Folks,
>

---

From: <[email-masked]>
Date: Wed, 21 Jan 2009 13:56:21 +0100

I support Dimitri's position.

Furthermore, sorry in case I missed it but I would really like to have an answer on Jonne's point regarding RRG conclusions and decisions regarding LISP. I would guess that the answer will have links to the points raised by Dimitri and which, IINM, were the controversial part of the last explisp BOF.

--
Greg

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de 
> PAPADIMITRIOU Dimitri
> Envoyé : mercredi 21 janvier 2009 11:55
> À : David Meyer; [email-masked]; [email-masked]
> Cc : [email-masked]
> Objet : RE: [Int-area] Please respond: Questions from the 
> IESG as to whetheraWG forming BOF is necessary for LISP
> 
> Dave,
> 
> The task consisting in discovering by experimentation 
> architectural fit (wrt initial objectives) and complement 
> understanding wrt known challenges (mapping, caching, 
> loc.reachability, impact on traffic spatio-temporal 
> properties) is very different in nature than ensuring 
> interoperability among protocols, minimize operational 
> impact, and facilitate integration/deployability -> so 
> requiring different type of efforts with different timelines. 
> As a matter of fact, both types of activities are still 
> required imho. 
> 
> So the question - that is not administrative - boils down 
> imho to: can we exclusively concentrate on the LISP 
> protocol(s) specifics leaving the issue of our confidence on 
> the Loc/ID split and associated challenges open. That 
> question deserves imho a specific discussion that should 
> > Subject: [Int-area] Please respond: Questions from the IESG as to 
> > whether aWG forming BOF is necessary for LISP
> > 
> > 
> > 	Folks,
> > 
> respond to 
> > the problems discussed at the IAB's October, 2006 Routing and 
> > Addressing Workshop [0]. The purpose of the BOF is to form 
> a working 
> > group whose charter (see below) is to work on the design on 
> the LISP 
> > base protocol [1], the LISP+ALT mapping system [2], LISP 
> Interworking 
> > [4] and LISP multicast [6]. The working group will encourage and 
> > support interoperable LISP implementations as well as defining 
> > requirements for alternate mapping systems. The Working 
> Group may also 
> > create EID-prefix assignment guidelines for RIRs, as well 
> as security 
> > profiles for the ALT (presumably using technology developed in the 
> > SIDR working group).
> > 
> > Goals and Milestones:
> >

---

From: Eliot Lear <[email-masked]>
Date: Wed, 21 Jan 2009 14:02:44 +0100

> happen in the context of a BoF.

I missed the part where anyone said that we should *exclusively* 
concentrate on LISP.  Where/when did that happen?
_______________________________________________
routing-discussion mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/routing-discussion

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Wed, 21 Jan 2009 14:12:54 +0100

> From: Eliot Lear [mailto:[email-masked]] 
> Sent: Wednesday, January 21, 2009 2:03 PM
> To: PAPADIMITRIOU Dimitri
> Cc: David Meyer; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [Int-area] Please respond: Questions from the 
> IESG as to whether aWG forming BOF is necessary for LISP
> 
> 
> > imho to: can we exclusively concentrate on the LISP protocol(s) 
> > specifics leaving the issue of our confidence on the Loc/ID
> > split and associated challenges open. That question deserves 
> > imho a specific discussion that should happen in the context 
> > of a BoF.   
> 

All items in the charter - see below - are exclusively oriented toward
LISP protocols implementation specifics, and interworking:

/Goals and Milestones:
/ 
/Mar 2010  Submit base LISP specification to the IESG for
/          Experimental.
/ 
/Mar 2010  Submit base ALT specification to the IESG for
/          Experimental.
/ 
/Mar 2010  Submit the LISP Interworking specification to the IESG
/          for Experimental.
/
/June 2010 Submit Recommendations for Allocation and Routing
/ 	     of both EIDs and RLOCs to the IESG for Experimental.
/ 
/June 2010 Submit Recommendations for Securing the LISP Mapping
/          System to the IESG for Experimental.
/ 
/July 2010 Submit LISP for Multicast Environments to the IESG for
/ 	     Experimental. 

thanks,
-dimitri.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 21 Jan 2009 14:55:54 +0100

> LISP protocols implementation specifics, and interworking:
Right.  This is a LISP WG.  There is nothing stopping anyone from 
creating another WG, assuming the work warrants it.  And again, the 
output is experimental docs.  No standardization choices are being made.

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Wed, 21 Jan 2009 16:11:29 +0100

Dave asked for opinions on usefulness to lead another BoF. Imho there is
a pending question that deserves discussion and a BoF is one of the
suitable mean to have such discussion and hopefully reach consensus. 

Your answer seems to state that the activities needed to address the
known Loc/ID split challenges would be lead outside LISP WG anyway ...
but this does not answer the initial question. 

Thanks,
-d.

> Sent: Wednesday, January 21, 2009 2:56 PM
> On 1/21/09 2:12 PM, PAPADIMITRIOU Dimitri wrote:

---

From: David Meyer <[email-masked]>
Date: Wed, 21 Jan 2009 08:17:45 -0800

---

From: Ross Callon <[email-masked]>
Date: Wed, 21 Jan 2009 11:26:58 -0500

scale, we need very good solutions and/or greater understanding to some
hard questions such as what will be the granularity of the mapping
function (how large will the mapping table be and what granularity of
prefix will be in it), how to do the mapping, how to do liveness
detection, what the scaling properties of the mapping and liveness
detection functions is likely to be, and what the manageability,
security, and robustness implications are. I guess that while we are at
it we need to figure out if there are other issues, such as MTU, that
need consideration. 

If you want to do experimentation on a moderate scale, then answers to
these questions are not strictly needed. 

I didn't see any of these "hard issues" explicitly mentioned in the
proposed charter (although there is mention of "the LISP+ALT mapping
system"). Is this because the effort is intended to be focused on the
shorter term experimentation efforts (including experimental protocol
specs that allow the immediate experiments to occur), for which these
hard issues do not need to be answered? 

Thanks, Ross

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Eliot Lear
Sent: 21 January 2009 08:56
To: PAPADIMITRIOU Dimitri
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG
as to whether aWG forming BOF is necessary for LISP

lisp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lisp

---

From: Joe Touch <[email-masked]>
Date: Wed, 21 Jan 2009 08:41:56 -0800

Ross Callon wrote:
> In order to make an ID/Loc split work on an Internet-wide ubiquitous

I could not agree more, but, as others have noted, the LISP WG's purpose
is to split out the work of documenting the LISP protocols as
experimental. This does not preclude the needed research above from
happening in the IRTF.

A note on these issues might be useful to include in the LISP documents
under 'deployment considerations' or 'open issues'.

Joe

---

From: David Meyer <[email-masked]>
Date: Wed, 21 Jan 2009 10:16:52 -0800

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Wed, 21 Jan 2009 19:20:12 +0100

> 	It would seem that one could apply the same argument to
> 	SHIM6, HIP, SCTP, and several other protocols that have
> 	been or are being standardized.
> 
> 	So my question to you is:
> 
> 	(i).	Given your argument above, do you believe that
> 		say, the SHIM6 WG should not have been chartered
> 		(or perhaps that the SIGTRAN WG, which produced
> 		RFCs 4960 and 3286) should not have been
> 		chartered?  Clearly they did not have such an
> 		analysis, or we wouldn't be talking about doing
> 		it now (and again, that is not to say there isn't
> 		a ton of literature on loc/id split).
>
> 	(ii).	If on the other hand you believe that, say SHIM6
> 		should have been chartered, the question is why
> 		(again, given your argument above)? 

Applying that approach (SCTP had foundations coming from outside IETF)
may work with relatively simpler problems/protocols. The level of
complexity of the task to reach a certain objective drives the approach.

In the present case, some of the main challenges are known beforehand
and they are certainly not limited yet to protocol implementation
specific aspects. One may certainly initiate a cycle of experiments
using experimental protocol specs together with a specific set of
eval.objective and criteria. This said, the approach in spiral
(LISPv1->experiment->analysis->LISPv2->  ...) works iff
proto-development takes these elements into account (otherwise any
experimentation is hardly useful as it will not deliver the expected
outcomes in order to make real progress) and outcomes/analysis are
documented accordingly before moving to the next iteration. 

Here, the problem in understanding stems because: LISP WG focus on
experimental specification to resolve only protocol engineering problems
leaving actual challenges outside of its own protocol work but at the
same time acknowledges that such experimentation are complementary to
achieve real progress on its own protocols. However, at this point in
time, I do not see how the protocol engineering problem can be decoupled
from the purpose of the experimental effort in spiral.

Hope this clarifies my concern,
-dimitri.

> From: David Meyer [mailto:[email-masked]] 
> Sent: Wednesday, January 21, 2009 5:18 PM
> Cc: [email-masked]; [email-masked]; [email-masked]
> IESG as towhether aWG forming BOF is necessary for LISP
> 
> 	Dimitri,
> 
> architectural fit
> imho to: can
> 	The purpose of this WG would be to take the *LISP*
> 	documents to EXPERIMENTAL. That is what I had in mind
> 	when I wrote the charter, and I believe that it is pretty
> 	clear on this point. That is not to say it the charter
> 	can't be further tightened (I'm sure it can).
> 
> 	A you know, WGs need to be tightly focused, especially in
> 	the case of protocol groups. I'll grant you that my
> 	experience with WGs in the OPs area are somewhat more
> 	open-ended (at least mine have been), but it seems
> 	unlikely that an IETF WG could successfully produce both
> 	tight protocol specs and broad architectural surveys and
> 	analyzes. In fact, I can't think of a case in which this
> 	has been done in the IETF (perhaps there is one, but it
> 	doesn't readily come to mind). Add to that that LISP is
> 	clearly in an engineering and deployment phase, coupled
> 	with the fact that producing engineering specs what the
> 	IETF is good at (well, that is the IETF does), and one
> 	sees that finishing up the LISP specs in the IETF seems
> 	only natural.
> 
> 	That said, it is a fine thing for the RRG to continue to
> 	do what its doing, and further, the document you've been
> 	describing on the RRG list should continue to progress
> 	(IMO of course). In fact, these activities are completely
> 	complementary. So keep up the good work.
> 
> 	Just one point on your argument:
> 
> imho to: can
> 	It would seem that one could apply the same argument to
> 	SHIM6, HIP, SCTP, and several other protocols that have
> 	been or are being standardized.
> 
> 	So my question to you is:
> 
> 	(i).	Given your argument above, do you believe that
> 		say, the SHIM6 WG should not have been chartered
> 		(or perhaps that the SIGTRAN WG, which produced
> 		RFCs 4960 and 3286) should not have been
> 		chartered?  Clearly they did not have such an
> 		analysis, or we wouldn't be talking about doing
> 		it now (and again, that is not to say there isn't
> 		a ton of literature on loc/id split).
> 
> 	(ii).	If on the other hand you believe that, say SHIM6
> 		should have been chartered, the question is why
> 		(again, given your argument above)? 
> 
> 
> 	Note that I'm not taking a stand on this either
> 	way. Rather, I'm just following the logic of your
> 	argument. 
> 
> 	Dave
> 
> 
> 
>

---

From: David Meyer <[email-masked]>
Date: Wed, 21 Jan 2009 10:54:31 -0800

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 22 Jan 2009 00:48:46 +0100

> 	Agreed that its complex, though you dismiss SCTP without
> 	explanation. 

I mean for SCTP the base work was already done when protocol was
translated in the IP world. SCTP follows the path described by D.Thaler
in the IAB doc. "What Makes For a Successful Protocol?"
 
>     In addition, I don't see the relevance of
> 	SCTP coming from outside the IETF. In any event, you
> 	might make the same claim for LISP (that its coming from
> 	outside the IETF).
>
> 	Not really. First, you didn't answer my question. 

Your question is: does one size (of approach) fits all and the answer is
no. Indeed, these situations can not be compared (SHIM6 is a WG whereas
HIP is a WG and a RG) but none did intend to address the Internet
routing system scalability. If my answer yes they should have been
chartered it does not provide any element for answering the present
question.

>     Second,
> 	what you are arguing can be applied to say, OSPF (v1-n),
> 	EGP->BGP, ..... Essentially any protocol that has ever
> 	been rev'ed.

Indeed. This is what i had in mind as example but there is a main
difference: BGPv1 has been released in 1989 and progressed together with
the growth of the Internet until reaching BGPv4. The
conditions/environment is thus different but one thing remains multiple
iterations will be needed.

> 	Just to be clear: I understand the concern to further
> 	understand the properties of loc/id split. If fact, to
> 	the best of my knowledge no one in the current RRG cycle
> 	has written about this except for me and Darrel
> 	(draft-meyer-loc-id-implications-00.txt). That, however,
> 	shouldn't stop us from developing protocols. If it did,
> 	we'd never develop any protocol (since obviously the set
> 	of such questions is clearly *not* recursively
> 	enumerable). 

Work on cache-based mapping is ongoing, and there is still open work for
mapping system itself (any reason for instance why you consider ALT as
the only mapping distribution technique ?) to a name a few whereas there
is no outcome yet for what it concerns impact on spatio-temporal traffic
properties. All these "uncertainties" are left outside the design space
- at least as the charter translates it -   

> 	Finally, what happens if the properties you want to study
> 	are in some sense "emergent" (e.g., the Internet's
> 	heavy-tailed robustness-complexity curve). The point here
> 	is that you won't see those properties until you have a
> 	system to study, so in our case (the Internet) the
> 	approach you are advocating would not have revealed the
> 	deepest and most fundamental (and hence most interesting)
> 	properties of "the architecture" (check out 
> 	
> http://www.cds.caltech.edu/~doyle/SFI_robustness/rigor_robust.htm
> 	or any of Doyle's work on this topic).

Uncertainties are intrinsically part of the experimental work: this
reference states "robust to known and designed-for uncertainties".
Paraphrasing that statement it seems the LISP charter does not leave
room for addressing uncertainties (e.g. mapping system consider only ALT
so only ALT could be experimented) - a BoF session should clarify why
this is the case -

Thanks,
-dimitri.

---

From: David Meyer <[email-masked]>
Date: Wed, 21 Jan 2009 16:02:20 -0800

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 22 Jan 2009 01:57:06 +0100

> Sent: Thursday, January 22, 2009 1:02 AM
> IESG astowhetheraWG forming BOF is necessary for LISP
> 
> 	Hey Dimitri,
> 
> 	Right, this is RYF (Robust Yet Fragile) behavior...see
> 	the second Eugene NANOG t-shirt (the black one) :-) 
>
> 	Not sure I follow. Of course we want to wind up with a
> 	solid ALT spec, but the charter states that "The working
> 	implementations as well as defining requirements for
> 	alternate mapping systems." IMO this admits the
> 	specification for other mapping systems. Good ideas
> 	always welcome.
>
> 	In any event, Brian really summed it up quite nicely:
>  
>           ...  
> 	  But I don't see the point in a second BOF; the idea
> 	  that a BOF could resolve in a couple of hours the
> 	  issues that the RRG has been discussing since early
> 	  2007 seems unlikely.

No one stated that the BoF will resolve the issues/challenges themselves
- a BoF is the place to discuss what the charter can include as work
items to achieve objectives (that are not limited to the design of the
protocol specifics). 

These items are centered around the initial design goals that lead to
this effort and how LISP after experimental work will address them. I
suggest to have at least an item in the LISP charter that takes the RRG
design goals as outline and for each of the goals documents how LISP
protocol addresses them.

Thanks,
-dimitri.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Jan 2009 10:18:30 +1300

It seems to me that you and Dimitri are talking about things that
the RRG should be doing as it moves towards conclusions. I don't see
why they would be in scope for an IETF LISP WG, where we would ask
for a tight and achievable focus.

Obviously there's a risk in chartering a LISP WG now: that the RRG will
come out with a significantly different recommendation at some date
in the future. The IESG can decide to take that risk if it likes.
But I don't see the point in a second BOF; the idea that a BOF could
resolve in a couple of hours the issues that the RRG has been discussing
since early 2007 seems unlikely.

   Brian

---

From: David Conrad <[email-masked]>
Date: Wed, 21 Jan 2009 16:43:59 -0800

Sorry for being a bit late to this discussion (day job and other  
realities intruding), but having had a small role in the Dublin BOF, I  
don't think it likely (in the extreme) there would be significant  
benefit from having a second BOF.  I'd like to second Dave's seconding  
of Brain's statement:

> 	  issues that the RRG has been discussing since early

I'd actually go a bit further and suggest that any attempt by any  
group to resolve the issues the RRG has been discussing (or any of the  
various other discussions that occurred prior to RRG taking this on)  
as a pre-requisite for creating a working group to standardize an  
experimental protocol in this space would be equivalent to declaring  
no protocol in this space will _ever_ be standardized.

LISP is _an_ approach towards routing scalability.  It is not the only  
one.  Standardizing the experimental protocol would allow folks  
interested in routing scalability to explore one or two axes of the  
possible solution space.  To be honest, I'm unclear as to why there is  
even a question as to whether a WG should be created...

Regards,
-drc

---

From: Eliot Lear <[email-masked]>
Date: Thu, 22 Jan 2009 08:09:59 +0100

> routing system scalability.

It's not entirely so.  The routing system was clearly in peoples' minds 
when HIP was in its early stages.  Bob Moskowitz was involved in the 
Name Space Research Group (NSRG) back when it existed, and as a co-chair 
of that group I was asked to comment on the chartering on both HIP 
groups.  The NSRG looked at HIP in the light of route scalability.  This 
was one reason that Mike O'Dell (author of 8+8) was interested.

Was there was any alternative propose to HIP at the host level as a 
layer 3.5 mechanism?   That is really where SHIM6 comes in, which as I 
recall was an outgrowth of MULTI6 and Tony Li's early proposal on NOID.  
Bob Braden, John Wrocklawski (?), et al argued at one point (and I'm 
sorry I don't have the cite) that we have all the names we need in the 
IP stack.  Both NOID and SHIM6 were, at least in part, evolutions on 
that notion, and a nameless (stack-wise) alternative to HIP.

And so while I agree with your high level point that one size does not 
fit all, I would say that the policy here as I understand it from Jari 
is simply that he will not favor one proposal over another and he will 
not short circuit the RRG process, while at the same time he will 
provide a venue for work where there is sufficient interest to mature 
the specifications through community involvement.

Eliot

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 22 Jan 2009 10:52:37 +0100

> LISP is _an_ approach towards routing scalability.

providing it does not transpose the scalability problem at another level
e.g mapping system (including at the edge TR), this point is related to
the granularity of the mapping function and the EID/RLOC space ratio.
also, the data-driven behaviour of LISP - its dynamics is driven by the
spatio-temporal characteristics of the traffic and not only the prefix
reachability (as in existing routing system) - adds dependencies to the
"equation" of routing system design.   

=> i would be less affirmative in making such statement -a priori-. in
order to consolidate our understanding, the charter should include an
item on how LISP addresses routing scalability and other design goals
(at least as much as the experiment result allows). this would at the
same time close the loop with part of the RRG work. 

thanks,
-dimitri.

> [mailto:[email-masked]] On Behalf Of David Conrad
> Sent: Thursday, January 22, 2009 1:44 AM
> To: David Meyer
> IESGastowhether aWG forming BOF is necessary for LISP
> 
> Hi,
>

---

From: David Meyer <[email-masked]>
Date: Thu, 22 Jan 2009 08:12:19 -0800

---

From: Joe Touch <[email-masked]>
Date: Thu, 22 Jan 2009 08:34:58 -0800

you want to add the generation of such a document, that seems fair.

Joe

David Meyer wrote:
> 	This is the second or third time you've said this, so I
> 	feel the need to respond. 
> 
> 	So here's how I would like to see this go (i.e., here's
> 	the rule I want for these cases):
> 
> 	Rule:	Anyone suggesting a charter milestone item must
> 		agree to the the following conditions:   
> 
> 		(i).   You (or your agent) must commit to write the
> 		       document that fulfils the proposed
> 		       milestone, and 
> 
> 		(ii).  If you (or your agent) defaults on the
> 		       commitment described in (i). above, that
> 		       is, if the document is not delivered in a
> 		       timely fashion (where timely is defined by
> 		       the charter milestone), the charter
> 		       milestone will be removed and rechartering
> 		       the WG is *not* necessary, and   
> 
> 	        (iii). The authorative AD(s) must also agree to
> 		       these conditions.  
> 
> 	Now, I don't know if a WG/BOF/proposer/chair can
> 	articulate such a rule, but then, in the IETF rules are
> 	made up as we go along, so why not (its not as if the
> 	IETF is a legal (or even quasi-legal) system after all)?
> 	In any event, I will say that without such a rule,
> 	arbitrary milestones (constructed for whatever reason)
> 	can be injected into the charter, and clearly, no one
> 	wants that.
> 
> 	In the case of the document you are proposing (I think
> 	its a document, correct me if I'm wrong), if you (or your
> 	agent) commit to the above conditions, and if the
> 	document you propose does not hold up/gate any other WG
> 	document (i.e., no other WG document can have a normative
> 	reference to this this document), I see no reason not to
> 	add such an item. Otherwise, I would be reluctant to add
> 	such a milestone.
> 
> 	Dave
> 
> 
> ------------------------------------------------------------------------
>

---

From: David Meyer <[email-masked]>
Date: Thu, 22 Jan 2009 09:58:06 -0800

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 22 Jan 2009 15:39:39 -0800

> I wanted to provide some background on this question.
> 

The question to ask is whether LISP is an appropriate solution to
the problems discussed at the IAB's October, 2006 Routing and
Addressing Workshop.

In answering this question we need to keep in mind that such
techniques as (a) caching routing and forwarding information, (b)
use of separate mapping system for Loc/ID mapping, (c) relying on
probing for determining path feasibility are essential/fundamental
to LISP. In other words, these techniques form the foundation of
LISP. Concerns with scaling and operational properties of these
techniques have been raised many times before (both at the previous
BOF, as well as on the RRG mailing list). Yet the LISP proponents
still did not adequately address these concerns.

Unless these concerns are adequately addressed, claiming that LISP
is an appropriate solution to the problems discussed at the IAB's
October 2006 Routing and Addressing Workshop is nothing more than
a proof by an emphatic assertion.

Addressing these concerns does *not* require LISP protocol specs.
Addressing these concerns does *not* require experimentation with
LISP protocols either. Addressing these concerns does *not* require
interoperable LISP implementations. Therefore, forming a WG to "work
on the design on the LISP base protocol , the LISP+ALT mapping
system, LISP Interworking  and LISP multicast", and to "encourage
and support interoperable LISP implementations as well as defining
requirements for alternate mapping systems" (as was proposed in
Dave's e-mail) is *not* going to address these concerns.

Unless the concerns I mentioned above are adequately addressed,
LISP can not be accepted as a feasible/practical approach towards
routing scalability. Therefore, unless and until these concerns are
adequately addressed, it is totally premature to form LISP WG.

Yakov.

---

From: David Meyer <[email-masked]>
Date: Thu, 22 Jan 2009 16:04:52 -0800

---

From: David Meyer <[email-masked]>
Date: Thu, 22 Jan 2009 18:24:30 -0800

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 22 Jan 2009 08:44:46 -0800

Unless we're planning to scuttle the Internet and start from
scratch, IMHO it is inevitable that we will eventually need
some form of map-and-encaps. I don't believe that the solution
necessarily has to be LISP, but that is not intending to make
any statement wrt what you are trying to accomplish here.

Fred
[email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 22 Jan 2009 15:57:15 -0800

> LISP. Concerns with scaling and operational properties of these

Correction. LISP does not use probing. It isn't in the current spec  
and has never been documented. Just want to state the facts.

Dino

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 22 Jan 2009 16:38:35 -0800

> Sent: Thursday, January 22, 2009 4:05 PM
> To: Yakov Rekhter
> Cc: [email-masked]; rrg; [email-masked]
> Subject: Re: [rrg] [Int-area] Please respond: Questions from 
> the IESG asto whether a WG forming BOF is necessary for LISP
> 
> 	Yakov,
> 
> > to LISP.
> 	(c) is clearly not fundemental to LISP. 
> 
> 	What is fundemental (IMO) to any Loc/ID split
> 	architecture is what have what we have termed the Locator
> 	Path Liveness problem. How that problem is solved is a
> 	matter for each architecture to consider. 
> 
> 	In particular, probing is a solution to the Locator Path
> 	Liveness problem, but as we know from shim6 (etc), the
> 	complexity of that isn't pretty. But then either is the
> 	O(n!) complexity of BGP path hunting. In any event, the
> 	space of potential solutions for map-and-encap schemes
> 	such as LISP (or eFIT, Ivip, etc) haven't been throughly
> 	explored. This is part of the reason why we think LISP
> 	should be EXPERIMENTAL.

Not meaning to pick on you, but I don't understand why RANGER
hasn't made it onto the "short list" of proposals yet; maybe
you could answer that for me? AFAICT, RANGER is in the top-two
map/encaps proposals in terms of technical completeness (maybe
even the top-one) so can we have folks add it to their lists?

Thanks - Fred

> > In other words, these techniques form the foundation of
> > LISP.
> 
> 	With respect to LISP and probing, that statement is
> 	incorrect. 
> 
> 	Dave
>

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 22 Jan 2009 21:34:24 -0500

original message :(

On Thu, Jan 22, 2009 at 6:39 PM, Yakov Rekhter <[email-masked]> wrote:
> Jari,

I think having a focused group that can work out some of the large
scale deployment, operations and design issues with this bit of
technology would be helpful. We have spent the better part of 2 years
(we == the community) working in the RRG and in side groups attempting
to design and test a new routing architecture. Putting that work into
an official spot, allowing it to work through issues and determine if
the design/plan will bare fruit, I think is a good thing.

>> debates. That being said, we did not spend enough time on the WG

in every WG meeting that this subject came up in both Dublin and
Minneapolis there was a great deal of interest, discussion and debate.
This, it seems to me, signals that there is interest in seeing how
this technology may work out for the community as a whole. I believe
this shows a WG would be helpful in containing the work and scope so a
result and direction can be determined.

>> scope should be, whether the charter is reasonable. And if not, what

I'd like to see an experimental wg, I think at least the scope could cover:
o fleshing out/finalizing the proposed LISP protocol suite
o working through and documenting some of the use cases and operations of LISP
o characterization of true scalability impact at current traffic rates

I think that 'LISP' is a might narrow though, there are other
map/encap solutions which may work as well. I'd like to see how
something like map/encap works, and if it shows itself to be helpful.

> the problems discussed at the IAB's October, 2006 Routing and

Yakov,
I'm not sure there have been any other credible solutions aside from
'map/encap', this seems promising, though certainly it hasn't been
proven out in the way that v4 routing as we know it today has been.

Certainly there are use cases where there will be issues, certainly
there are ways to deal with these use cases. Without some direct
experimentation, thought about the problems and focus, we won't be
able to address these things. (we == community)

> still did not adequately address these concerns.

I thought they had addressed some of them, both on-list and in-person
at a few of the meetings. Perhaps some details were lacking?

> a proof by an emphatic assertion.

I don't think anyone has said one thing or another is 'the solution',
I think so far 'a solution might be' has been used though. Without
some work, investigation and engineering I don't think we'll be much
further toward a solution in  another 2 years. I think it's important
to gain some experience with the options.

> adequately addressed, it is totally premature to form LISP WG.

we can't know if an approach is feasible/practical until we make an
honest attempt to work through both the engineering issues and the
operational issues... Did you have options we should also discuss?

-Chris

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 22 Jan 2009 22:36:35 -0500

>
>> I think having a focused group that can work out some of the
>> large scale deployment, operations and design issues with
>> this bit of technology would be helpful.
>
> I agree.
>
>> map/encap solutions which may work as well. I'd like to see
>> how something like map/encap works, and if it shows itself to
>> be helpful.
>
> Exactly. The to-be-formed WG should not only focus on LISP, but also focus
> on other map&encap solutions. Just as Yakov etc. pointed out, there are
> still some open issues in LISP need to be answered. If many different
> map&encaps solutions can be explored further simultaneously under this WG
> charter, we may find they are complementary and can be converged finally to
> form a successful short-term solution.

they might also feedback into RRG as inputs useful to the discussion
William's been putting together...
-Chris
_______________________________________________
routing-discussion mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/routing-discussion

---

From: Scott Brim <[email-masked]>
Date: Fri, 23 Jan 2009 10:25:00 -0500

> [email-masked]

To start with, could we pick one list to discuss RANGER on?  How about
RRG?  Fred?

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 23 Jan 2009 09:01:18 -0800

> From: Scott Brim [mailto:[email-masked]] 
> Sent: Friday, January 23, 2009 7:25 AM
> To: Templin, Fred L
> Cc: David Meyer; Yakov Rekhter; rrg; [email-masked]; 
> the IESG astowhether a WG forming BOF is necessary for LISP
> 
> Excerpts from Templin, Fred L on Thu, Jan 22, 2009 04:38:35PM -0800:

My leaning would be toward int-area based on the maturiy of
the specs. I already have a head start on running code:

http://osprey67.com/vet/
http://osprey67.com/seal/

but this is an excellent opportunity for linux, *BSD, etc.
enthusiasts who might be interested in developing independent
implementations (commercial vendor implementations are also
welcome).

Thanks - Fred
fred.l.templin

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 24 Jan 2009 10:26:11 -0800

>   LISP has too many fundamental problems to be considered a
>   potentially practical solution.  Some of these problems require

LISP is not perfect and still evolving but let me point out that every  
design has fundamental problems. At this scale, it's very hard to be  
perfect Robin. And as Noel has stated so many times, the hard  
decisions must be made to incrementally deploy this. So things might  
not look pretty on the surface, but jeez, you got to do what you got  
to do. Else, this will all be academic.

We really want to solve this problem, sincerely. This is not lip  
service, we are not just writing papers, we want to rev the Internet,  
this is serious.

I want to address each of your 7 points below. I have cc'ed the [email-masked] 
  mailing list so the folks who want to focus on details of LISP can  
see this thread.

> 1 - Delays in delivering initial packets in a flow.  This is either
>    due to sending the packets along the ALT network (which takes
>    time and involves sending substantial volumes of data packets
>    over the ALT network, rather than just mapping requests) or to
>    sending mapping requests only, and waiting for the ITR to get a
>    response before it attempts to send traffic packets.

We have a memory/bandwidth tradeoff. So we have to make a hard design  
call. I'd rather have mappings cached and timed out so they can be  
updated when they need to then to hold all the possible mappings for  
the Internet in an ITR.

There is no such thing of a free lunch. You either store all possible  
mappings or you fetch them when you need them.

>    According to: http://www.lisp4.net/docs/lisp-ausnog02.ppt pp 10
>    & 11 the experimental LISP ALT network's ITRs drop initial
>    packets and send brief map request messages.   Even if we think
>    this delay doesn't matter, I am sure enough potential adopters
>    would - and therefore make it difficult or impossible for LISP or
>    any other such solution to be widely enough adopted to solve the
>    routing scaling problem.

Then why was/is ARP deployed in a 10^4 host-based bridged network with  
basically the same properties. First packet loss is not persistent  
when you look at all the traffic that originates from a source site to  
another destination site.

The host vendors are probably thinking, if we do LISP in the host, you  
could wait to send your TCP SYN before the mapping is available. Guess  
what, you don't send that TCP SYN before you get the DNS Reply. ;-) I  
wonder why? Well I'll spell it out. If a host needs an address to make  
the connection, we can say it also needs a locator to make a connection.

The design choice of LISP *is to just change software in CPE devices*  
to get the feature of decoupling rather than changing all the hosts at  
a site. That's a huge deployment advantage. So these CPE devices get  
packets before they have mappings. We don't even want to consider a  
host to CPE router signaling protocol and all it's complexities to  
solve this and to keep the architecture pure, we don't want to snoop  
on DNS, SIP, or any other protocol that can give us a hint on where  
the host is about to send a packet.

So the cost is *either* first packet loss or sending the packet on the  
ALT using it as a request for a mapping.

> 2 - LISP-ALT's long-path problem
>      http://psg.com/lists/rrg/2008/msg01676.html
>      http://www.antd.nist.gov/~ksriram/strong_aggregation.png
>
>      [Fix? Another fundamental problem in the architecture.  Could
>       be partially solved by more meshiness, but that would greatly
>       increase the complexity of the network and so raise more
>       scaling problems.]

Well this I believe is a duplicate of 1 above. So it's not really  
*another* problem.

> 3 - Problems creating a highly aggregated ALT network in order to
>    speed the flow of packets up and down the hierarchy, while also
>    making the network robust against the failure of its routers and
>    tunnels.  This has not been discussed much on the RRG, but it is
>    an obvious problem.

If we can do this with BGP, which we have decades of existence proof  
why can't we do this with a tunnel topology 1) where a tunnel can be  
rehomed much quicker and easily than physical links and boxes we have  
to do with today, allowing aggregation to occur at the edges of the  
ALT network, and 2) these tunnels stay up because there is robust  
connectivity below the tunnel level to keep them up, hence there will  
be less route-flaps for EID-prefixes.

I think it's the complete opposite of what you claim. I think BGP will  
be more stable and scalable then the underlying BGP. Plus, what we  
propose for the use-case of BGP uses quite a few features of it.  
Recall this is eBGP over GRE.

We have an infrastructure where we can 1) ping to see liveness of  
nodes on the ALT. We have traceroute to determine the path a Map- 
Request takes on the ALT. We can ping/traceroute "underneath" so we  
can see the diameter of the tunnel. Not only do we have a solution but  
we use existing rudimentary tools for management.

And the address allocation hierarchy can map this logical ALT  
topology. And if the Registries are involved in managing part of this  
ALT network (which we hope and think they will), we can keep this  
consistent relationship.

Do you realize the goodness of this? It's huge Robin.

There's more too, you then throw SIDR in the mix and we have secured  
the ALT, we have secured mappings, we created a PKI for routing use.  
In fact, the first SIDR deployment could happen on the ALT to be  
verified/experimented before it goes on the underlying BGP.

And note, that the infrastructure will/does carry exactly 2 address- 
families. So we can do 6-to-6-over-4 with this approach. That means we  
can get two site to be *IPv6-only* and be able to talk to each other.

If you are a IPv6-only site now or a dual-stack site, you could talk  
to the new IPv6 Google services. I think this is a pretty huge feature.

This is clean and architecturally pure, no double NATs, no CGNS, and  
no applications breaking.

> 4 - LISP-ALT's Aggregation implies provider dependence.
>    This is Christian Vogt's critique:
>    http://psg.com/lists/rrg/2008/msg00259.html

Not true. Aggregation here is for the EID-prefix. Service providers do  
not carry EID-prefixes in their cores so you don't depend on them. The  
decoupling of the address creates this. The dependence is now on the  
ALT. And if your site resides in a specific region of the world, you  
get your EID-prefixes from that registry. So readdressing your domain  
would only occur if you moved it from one region to another (let's  
leave mobile ASes out of this for now).

> 5 - Path MTU Discovery problems.  Despite Fred Templin, myself and
>    others discussing the inherent PMTUD problems in any map-encap
>    proposal, there has been nothing from the LISP team to indicate
>    they have a solution.  They seem to think there is no problem.

In section 5.4 of draft-farinacci-lisp-11.txt we describe two proposed  
solutions, one is stateless, and the other is stateful. The stateful  
creates no new table data structures but requires storing an addition  
2-bytes of effective-MTU state per mapping.

> 6 - Lack of business case for LISP's Proxy Tunnel Routers:
>    http://psg.com/lists/rrg/2008/msg02021.html

You cannot fault a technical design for a business case. A PTR is  
solving a technical problem. And if we want to *truly* keep lots of PI  
type routes out of the core *and* avoid NAT solutions which are just  
way too high in opex, the PTR is the only solution we have to turn to.

And on the contrary, I do believe service providers, interconnect  
providers, registries, third-parties and even governments will provide  
PTR services. Will they make a ton of money out of it, well that  
remains to be seen.

> 7 - The scaling problems of potentially thousands of ITRs each
>    probing reachability to one ETR, and likewise, one ITR probing
>    reachability to many ETRs - this is one view of the "Locator Path
>    Liveness Problem" of draft-meyer-loc-id-implications-00.
>    http://www.irtf.org/pipermail/rrg/2009-January/000809.html

That is not in the LISP design. Everyone just thinks it is.  ;-)

Dave and Darrel's draft is providing a warning about how bad probing  
can be. They do not take a position whether it should go into any  
proposal. They are just saying, beware of the Frankenstein that may  
result and can be an interpretation to not do probing at all.

Like I mentioned in a previous RRG email message, one has to ask the  
question if an ITR *should* switch from one RLOC to another when there  
*may* be a path failure *somewhere in the middle of the network*.  
Please note my very fine qualifications.

If we want to solve this problem, we could do this today by having a  
host switch it's TCP connection to another A record. This doesn't  
happen today because people deal with packet loss, since it doesn't  
last long *and* rerouting actually works quite well.

Van Jacobson always made this comment and I'll never forget it, "The  
fact that the Internet drops packets is it's greatest feature".

What else can either an xTR or TCP host do when sending ICMP  
Unreachables are off by default in most modern routers, or they are  
filtered by firewalls, and route aggregation hides failures close to  
packet sources.

> I agree entirely.
> I believe the LISP team could have made much better use of the RRG -
> by participating fully in the debates resulting from these critiques.

We were asked to do research in RRG. That was a reasonable request. So  
the research stuff in LISP has been and will continue to be presented  
in RRG.

As for the engineering issues, the real details and bits and bytes, we  
want a forum to discuss and work out issues in an open forum. I've  
been going to IETF for 20 years now, that forum is called a working  
group.

The working group doesn't have to standardize what it is working on.  
And the charter and the numerous requests we have made requests *for  
an experimental working group*.

> Experiments won't help solve most of these problems.  I am not
> against experimentation and I think it is great that there is a LISP
> experimental network.
>
> However, I would never have taken a proposal to the point of writing
> code, running a network and inviting others to write compatible
> implementations when the proposal had so many fundamental problems.

There is constant implementation feedback back into the design.  
Experienced engineers know how this cycle works. You start with  
something you think can hold together, you try things out, you refine,  
you revisit design, you go forward with implementation. That's the  
process of *detailed* engineering.

For the old timers, that was the difference between TCP/IP and OSI.

Sorry for the long email,
Dino

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 23 Jan 2009 11:29:49 +0800

I agree.

Xiaohu

---

From: Robin Whittle <[email-masked]>
Date: Sun, 25 Jan 2009 01:02:34 +1100

I am responding to Yakov Rekhter, Christopher Morrow and Xu Xiaohu.

Short version:

   I think it is still early days for routing scaling solutions.

   LISP has too many fundamental problems to be considered a
   potentially practical solution.  Some of these problems require
   design changes and others are probably solvable via extensions
   to the current design.  These problems are well documented.
   Running more experiments, writing interoperable implementations
   etc. will not help solve these problems.

   The other core-edge separation schemes (APT, Ivip, TRRP and
   Six/One Router) need a lot more development before a sufficient
   number of people in this field would agree that it was a (or
   "the") promising solution.

   Whether in a WG or independent of the IETF, I think each
   proposal should be developed vigorously - but with all
   developers taking a keen interest in the other proposals and
   responding fully in a public discussion list (their own, or
   the RRG) to those who make constructive critiques of their
   proposals.

> still did not adequately address these concerns.

Some LISP problems which I think are unresolved include the
following, many of which are mentioned in the critiques section of:

  http://www.firstpr.com.au/ip/ivip/lisp-links/

      [Fix?  This seems to be inherent in the ALT architecture.
       There's no obvious fix by caching in the ALT network and
       with millions of nodes (ITRs and ETRs) in the ALT network,
       there are going to be multiple hops in the network which
       result in inherent delays which would affect all session
       establishment, and even single byte communications such
       as ping, some DNS queries and responses etc.]

      {Experiments?  The problem won't show up in any experimental
       network - only in real use with tens or hundreds of thousands
       of ALT routers.}

      {Experiments?  As for 1 above.}

      [Fix?  Again, only by making it meshier, which detracts from
       the ALT network's primary design goal - of being highly
       aggregated to enhance efficiency and to minimise scaling
       problems.]

      {Experiments?  As for 1 above.)

      [Fix?  Seems to be a fundamental problem, but every core-edge
       separation scheme involves supplying stable EID, micronet etc.
       address space to end-user networks, so there must be some
       kind of dependence on some organisation - though not
       necessarily an ISP.]

      {Experiments?  There's no need for experiment - problems such
       as this can be clearly foreseen.}

      [Fix?  Add some arrangements such as I propose:
       http://www.firstpr.com.au/ip/ivip/pmtud-frag/ or maybe
       like something Fred proposes.]

      {Experiments?  Experiment with such a fix, but the real
       test only comes with many years of full deployment, with a
       rich mix of jumboframe compatible edge networks and DFZ paths,
       and with 1500 byte and slightly smaller MTU links still being
       used in some or many places.}

      [Fix: Develop a detailed proposal for how end-users would
       gain their EID address space in a way in which some
       organisation would have a financial incentive to build
       and run a set of PTRs all round the world which would
       advertise a single prefix in the DFZ which would cover
       the EID space of many (thousands or more) end-user
       networks.  AFAIK LISP could adopt something similar to
       Ivip's arrangements:
       http://psg.com/lists/rrg/2008/msg01158.html ]

     {Experiments?  This is not amenable to experiment - there
      needs to be a good proposal which can only be tested in the
      commercial reality of widespread deployment.  In other words:
      there will be no widespread deployment of any proposal until
      the proposal is found to be attractive by the end-user networks
      which we need to adopt the scalable routing proposal -
      essentially all of them.  That will only happen if the proposal
      fully supports multihoming etc. of packets sent by hosts in
      non-upgraded networks.  Ivip's OITRDs and LISP's PTRs are the
      only ways to do this.  (APT has an arrangement with some
      similar business case difficulties as LISP's and TRRP's
      solution involves a worrying number of carrots and sticks.)
      So there needs to be an attractive business case for these
      OITRDs or PTRs.}

      [Fix?   The problems of ITRs having to determine reachability
       and make decisions about which ETR to use seem to be
       fundamental to LISP, APT, TRRP or to any other core-edge
       elimination scheme which does not have a real-time mapping
       distribution system.]

      {Experiments?  Not useful at all - this problem won't show up
       in an experimental network, but can be clearly foreseen in
       a full-scale deployment scenario.}

I agree entirely.

I would have worked first to resolve the problems - and if they could
not be resolved, I would have abandoned the proposal.  LISP's
problems are generally not amenable to solution by experiment.

I think that a proposal should proceed to experiment once the
fundamental problems (which are not amenable to experimental
solution) are either resolved, or well on the way to being resolved.

The starting point for solving LISP's problems would be admitting
them as problems and then discussing them.

draft-meyer-loc-id-implications is a step in the right direction, but
the problems of having large numbers of ITRs probing large numbers of
ETRs, making their own decisions etc. has been obvious since the
inception of LISP and APT two years ago.

> interoperable LISP implementations. Therefore, forming a WG to work
> routing scalability.

I agree entirely.

> Therefore, unless and until these concerns are adequately
> addressed, it is totally premature to form LISP WG.

Is the criteria for forming a WG is that the proposal is either "the"
solution to the given problem or one of a few such proposals which
show sufficient promise to warrant serious effort to develop into a
full set of technical specifications?

If so, then I don't think LISP is anywhere near the mark, due to the
large number of fundamental problems which are nowhere near being solved.

> proven out in the way that v4 routing as we know it today has been.

I would agree with a reworded version of the above, replacing
'map/encap' with:

   core-edge separation schemes (all of which - apart from Six/One
   Router - started as map-encap)

Although I haven't read draft-templin-ranger, I think it is fair to
say there are no Core-Edge Elimination proposals (inherently
host-based, and limited to IPv6) which are developed to the level of
the three most developed core-edge separation schemes:

  LISP (ALT and NERD, which is widely regarded as unscalable)
  APT
  Ivip

    (Six/One Router is IPv6-only, and needs to steal a bit from the
     IPv6 header - which I think would require DFZ router upgrades,
     which may well be practical.  See my critiques:

       http://psg.com/lists/rrg/2008/msg02034.html
       http://psg.com/lists/rrg/2008/msg02218.html )

LISP and APT are purely map-encap.

Ivip in the longer term, or ideally from the start, is intended to
use modified DFZ (and other) routers so some or all of the ETR
address can be encoded into a modified version of the IPv4 or IPv6
header.  This removes the encapsulation overhead efficiency problem
and more importantly involves no PMTUD problems.  Ideally, Ivip
wouldn't use map-encap at all, but it could use map-encap initially.

> able to address these things. (we == community)

I disagree.  The most pressing problems with LISP can be clearly
foreseen and do not need any illumination from experimentation.  Most
of them need to be solved by changing the architecture, though the
PMTUD and PTR business case models could be solved by adding to the
current architecture.  If they can't be solved clearly by changing
the design, then it needs to be recognised that these fundamental
problems are a strong argument against adopting any such proposal as
the solution to the routing scaling problem.

Xu Xiaohu wrote:

> Exactly. The to-be-formed WG should not only focus on LISP, but
> also focus on other map&encap solutions.

I think it is widely agreed that each WG should have a single,
concrete, focus.

I think the best way forward, in addition to the RRG discussions
(which I guess will continue after we make our recommendation at the
end of March) is for the most promising proposals to be developed as
vigorously as possible, while learning from and cross-fertilising the
other proposals.

I think each such proposal should have its own, potentially private,
mailing list so the people concerned can work together in whatever
way suits them best.

There is now a LISP-Interest mailing list - but my impression is that
LISP development to date has been based on private communications
between the largely Cisco-based developers.

> Just as Yakov etc. pointed out, there are still some open issues in
> LISP need to be answered. If many different map&encaps solutions
> can be explored further simultaneously under this WG charter, we
> may find they are complementary and can be converged finally to

I think the best way to develop a proposal is a dedicated project -
but one in which the developers take a keen interest in critiques of
their work, and in the work of other comparable projects.

My impression of LISP development to date is that it has been far too
 insular - uninterested in critiques or on how other proposals work.

I think the developers of APT, TRRP and Six/One Router have been much
more responsive to critiques.

There's no way of forcing the LISP developers to take a greater
interest in these things.

What would be the purpose of giving the LISP team their own IETF WG?

It doesn't allow them to develop anything they can't develop on their
own, with their own private or public mailing list, meetings etc.

If creating a LISP WG carries some implication that LISP, or anything
resembling it, is "nearly ready for widespread adoption" or similar,
then I think it would be a mistake.

However, if (like HIP and probably many other protocols IETF WGs
eventually produce full, interoperable, specifications for) LISP is
regarded as being worth working on for experimental purposes AND it
is thought that the best way to do this is to form a WG, then a LISP
WG would be a good idea.

However, I think it is mistaken to believe that writing code, running
an experimental network and writing interoperable implementations
will solve LISP's fundamental problems.

Ideally, after 2 years of developing various proposals and discussing
this stuff on the RAM and then the RRG lists, the RRG would be in a
position to say something like:

  This exact proposal, or an architecture with these principles and
  characteristics, is both a promising way to solve the routing
  scaling problem and by far the most promising solution.  Therefore,
  we recommend the IETF form a WG to develop this proposal /
  architecture into a fully fledged specification, with the intention
  that it be ready for widespread adoption by ISPs and end-user
   networks by the middle of the next decade.

However, I think the RRG is not ready to do this.  Despite this
problem having been foreseen since the early 1990s, it is still early
days in terms of developing the most promising solution.

LISP has too many problems, with no obvious solutions in sight and
with an apparent reluctance of the developers to discuss many of
these problems in public.

APT is the work of a smaller group than LISP.  It doesn't have LISP's
problem with delaying initial packets.  The hybrid push-pull mapping
system with local full-database query servers solves the delay
problem, removes the need for a global query server system (LISP ALT
and TRRP) and uses a slow mapping distribution system which doesn't
raise any obvious scaling problems.  But without running code and a
demo system, would the RRG be able to say for sure this might be a
practical solution, or the best possible solution?  I think not.

Ivip has a smaller team still - so far just me, with the help of
Steve Russert.  Ivip is more ambitious than LISP and APT in some
ways, but simpler in others.  It will be two years at least before
there is running code (but I hope to have a complete set of I-Ds
before March).  I like to think the RRG would see the promise of Ivip
and recommend it to the IETF . . . but it is early days yet for all
these proposals.

I think the most likely outcome of these last two years is that we
agree that a solution needs to be developed by about 2014 which we
can be confident will be very widely adopted for IPv4 - with
something cooking for IPv6 too.

I think we can rule out host-based core-edge elimination schemes on
grounds of excessive complexity in all hosts, excessive management
traffic to and from hosts - and also in terms of such changes (host
changes, probably including major changes to applications) being at
odds with the need to have the solution voluntarily adopted by the
great majority of end-user networks.

That leaves the core-edge separation schemes.

There is a big distinction between those which integrate reachability
probing and decision making into the ITRs and the architecture itself
(LISP, APT, TRRP and the IPv6-only Six/One Router) and those (only
one so far - Ivip) which use a real-time mapping system so the
reachability testing and "which ETR to use" decision making is under
the direct control of each end-user network, and modularly separated
from the scheme itself.

There is also a big distinction between those schemes (LISP, APT and
TRRP) which would forever be stuck with encapsulation overheads and
having to solve the PMTUD problems inherent in map-encap, and those
(so far Ivip and Six/One Router) which will get the packets across
the core without overheads or PMTUD problems.

I don't think any of these are developed enough to warrant the IETF
developing just one as "the" solution.

  - Robin           http://www.firstpr.com.au/ip/ivip/

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 26 Jan 2009 08:51:26 -0800

Here is some follow-up on Dino's message wrt RANGER
and LISP comparisons:

> From: Dino Farinacci [mailto:[email-masked]] 
> Sent: Saturday, January 24, 2009 10:26 AM
> To: Robin Whittle
> Cc: rrg RG; [email-masked]; [email-masked]; 
> Subject: Re: [Int-area] [rrg] Please respond: Questions from 
> the IESG as towhether a WG forming BOF is necessary for LISP
> 

RANGER is following the eFIT/APT model (and perhaps ALT
also?). It allows some stretch for initial packets then
route-optimized paths for the rest, i.e., intial packets
are forwarded; not dropped.
 
> verified/experimented before it goes on the underlying BGP.

I think RANGER could potentially benefit from SIDR too,
but RANGER has a means for ingress filtering even on
networks where spoofing is possible. The philosophy in
RANGER is that sites guard their *own* borders even when
there is expectation that other sites will behave in a
trustworthy fashion.

> no applications breaking.

You are describing here the exact use case that RANGER
was designed to accommodate. IPv6 over IPv4 across one or
several recursive enterprise-within-enterprise nestings
gives IPv6 end-to-end with no NATting. 
 
> leave mobile ASes out of this for now).

RANGER supports true PI prefix delegation such that
readdressing is not needed when the site moves. End
systems that move from site to site may incur readdressing
and need a mobility handling mechanism like HIP or MIP,
but that is an end system mobility consideration and
not a site mobility consideration.

> 2-bytes of effective-MTU state per mapping.

In the "stateless" case, having the LISP ITR return
packet-too-bigs with degenerate MTUs (i.e., MTUs less
than 1500) is going to leave source hosts with an
unsatisfactory experience that they would not incur
without an ITR/ETR in the middle.

In the stateful case, LISP relies on a brittle mechanism
that has known vulnerabilities (e.g., [RFC2923]) and can
easily be spoofed by off-path attackers.

RANGER/SEAL fixes both of these problems and much more.  

> Please note my very fine qualifications.

Fine qualifications noted (I think). About the LISP
locator reachability bits, that seems like a lot of
overhead to carry on each and every packet, and it
also seems to assume symmetric paths. RANGER assumes
unidirectional tunnels and path asymmetry, i.e., if
Site 1's packets use ITR A and go through ETR B at
Site 2, the return traffic could actually come through
Site 2's ITR C. In the LISP locator reachability case,
how does C know anything about the reachability of A?

Although RANGER could send locator reachability bits
in control messages as an optimization, its primary
mechanism is through having the ITR probe the forward
path to the ITR. Probing is by setting an "ack request"
bit on every Nth data packet (+/- some delta if
randomization is desired) and then observing whether
a steady stream of ACKs comes back.

LISP also doesn't seem to take into account that a multi-
homed site can partition, such that locator reachability
does not necessarily imply end system reachability via
specific locators. Nor does it provide a means for an ETR
(A) to inform the ITR of a better ETR (B) when paths get
stretched. RANGER has a means to accommodate this.

> filtered by firewalls, and route aggregation hides failures close to  

RANGER can listen for ICMP unreachables coming from network
middleboxes that it can verify as on-path by checking the
SEAL_ID. In a RANGER world, network middleboxes would be
encouraged to turn the ICMPs back on because site border
xTRs will have a means to detect spoofing (i.e., the SEAL_ID).
But, this is an optimization only; nothing in RANGER depends
on getting the ICMPs from middleboxes.

That's all for now.

Fred

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 26 Jan 2009 12:12:29 -0800

> without an ITR/ETR in the middle.

Ah, then that motivates to upgrade MTUs.

> easily be spoofed by off-path attackers.

Are you saying MTU Discovery is flawed?

> RANGER/SEAL fixes both of these problems and much more.

With a lot more machinery and state. Let's not start this conversation  
again.

> overhead to carry on each and every packet, and it

4 bytes per packet? Sorry, I don't think so.

> how does C know anything about the reachability of A?

It can send a Map-Request. But active-active on ingress and egress  
will be the norm.

> a steady stream of ACKs comes back.

This doesn't work because if you are going to claim liveness through a  
protocol, you have to send control packets all the time from M ITRs to  
N ETRs. If you claim liveness, you have to do this before you send  
packets. So putting the probe in data packets is not sufficient.

And if you send probes all the time from M ITRs to N ETRs, you have a  
huge scaling problem.

> stretched. RANGER has a means to accommodate this.

Can you state some disadvantages of RANGER? There is no such thing as  
a free lunch, so your design has to make tradeoffs, but you seem to  
never state them.

> middleboxes that it can verify as on-path by checking the

Non-starter, you will not get ICMP unreachables, period. So if you  
solely depend on it, the solution is a non-starter.

> on getting the ICMPs from middleboxes.

You have to turn it on in all transit routers. You will get objection  
to this. It will never happen and if you think it could possibly  
happen, it will take forever.

Dino

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 26 Jan 2009 20:16:55 -0800

Hi Dino, 

> Sent: Monday, January 26, 2009 12:12 PM
> To: Templin, Fred L
> Cc: Robin Whittle; rrg RG; [email-masked]; [email-masked]; 

Upgrading to large MTUs everywhere is the desired
end-state goal. But, if you are talking about the LISP
"stateless" case, you would have no way of knowing when
all links everywhere have been updated such that you
can safely set the static value to something larger
than 1500.

> Are you saying MTU Discovery is flawed?

You as much as said it yourself below...

> With a lot more machinery and state. Let's not start this 

I'm not sure we finished the conversation last time,
and I know it wasn't conducted on the wider list
distributions that we are posting to here.

> 4 bytes per packet? Sorry, I don't think so.

I was counting the UDP header as overhead, too.

> packets. So putting the probe in data packets is not sufficient.

The RANGER model sends initial packets through a default
mapper, which returns an ICMP redirect; that is not really
a "protocol", but rather an alternate means of establishing
a FIB entry in the ITR.

Once the FIB entry is established, ITR->ETR liveness
testing is piggybacked on top of ordinary data packets.
That is 1x1; not MxN.

> And if you send probes all the time from M ITRs to N ETRs, 

RANGER piggybacks liveness testing on top of every Nth
(+/- delta) ordinary data packet that flows from one ITR
to one ETR. While packets are flowing, probing continues;
when no packets are flowing, probing ceases.

> a free lunch, so your design has to make tradeoffs, but you seem to  

Forgive me, and I will try to take a more balanced
consideration from now on.

For one thing, RANGER requires a means for
synchronization of a very large distributed mapping
database between a limited number of nodes; that is
probably also the case for other map/encaps systems
too. This may be tenable if the number of nodes
participating in the protocol and the frequency
of updates is kept relatively small, but I have no
quantitative basis for the claim.

> solely depend on it, the solution is a non-starter.

...there - you said it yourself!

> happen, it will take forever.

Well, I did say "optimization only"; the ICMPs would be
nice to have, but RANGER can live without them.

Thanks - Fred

---

From: Robin Whittle <[email-masked]>
Date: Tue, 27 Jan 2009 18:17:36 +1100

Short version:   Responding to Dino's reply to my critiques of LISP.

                 The LISP team should do detailed critiques of APT
                 and Ivip as part of convincing IETF folks of the
                 merits of LISP-ALT.

                 Will it be possible to do firmware upgrades so all
                 DFZ routers ca. 2014 will handle packets with
                 modified IPv4 and IPv6 headers, to forward the
                 packets the ISP network of the ETR, without
                 encapsulation, its overheads and PMTUD problems?

                 If so, then maybe we could go straight to this
                 approach and forget about encapsulation and all
                 its complexities.

Hi Dino,

> Sorry for the long email,

We are attempting to re-engineer one of humanity's most excellent and
important communication networks.  Long detailed messages are often
appropriate.

> LISP is not perfect and still evolving but let me point out that
> every design has fundamental problems. At this scale, it's very
> hard to be perfect Robin. And as Noel has stated so many times, the
> hard decisions must be made to incrementally deploy this. So things
> might not look pretty on the surface, but jeez, you got to do what
> you got to do. Else, this will all be academic.

I wasn't suggesting a proposal should be perfect.  I pointed out
problems which I consider to be fundamental - not "on the surface".
Some can be fixed by adding new design elements, but I think the
others are only fixable by radically altering the current design.

I stand corrected about LISP's approach to PMTUD - the latest draft
does include an outline of a workable solution.

> service, we are not just writing papers, we want to rev the
> Internet, this is serious.

I have always known you and the other LISP folks really care for the
Net and are working hard to devise the best possible improvements.

Despite it only having had broad-based commercial, political and
inter-personal impact in the last 15 years, the Internet is a
momentous development in human relations.  We all want to see changes
which will enable it to remain technically viable - and hopefully
elegant - for the long-term future.

However, I think you jumped straight into some seemingly attractive
approaches which turn out to have problems I consider to be serious.

It seems that you and the APT folks thought for a few moments about a
real-time mapping system and figured it was out of the question.  I
think it is not at all out of the question - and when you have
real-time mapping distribution, you can do some elegant and valuable
things:

1 - Separate out reachability testing and ETR choice mechanisms and
    let (actually require) the end-user networks to do it themselves
    - or pay someone else to do it for them.

2 - Enable the end-user networks to do real-time incoming TE control.

3 - Send the mapping update stream to local query servers, so there
    is reliable and very fast responses to mapping requests - and
    therefore no need to delay or drop initial packets.

4 - Charge a small fee per update to pay for most of the mapping
    distribution system.

5 - Provide much better support for the TTR approach to mobility:

      http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf

I think the ALT system is a lot niftier than CONS, but still, you are
delaying initial packets (APT and Ivip are not), forcing every ITR to
do its own reachability testing and monolithically integrating those
testing and ETR choice mechanisms into the core-edge separation
scheme itself.

I don't think we should be rushed into thinking we can't possibly
have local full-database query servers in ISPs and larger end-user
networks, or that it is impossible to push the mapping to them in a
few seconds (real-time).  One advantage of the real-time approach
over LISP-ALT, APT's approach or the TRRP DNS-like global query
server approach is that it is streamlined and includes multiple
mapping changes (dozens or perhaps a hundred IPv4 mapping changes) in
a single packet.

> I want to address each of your 7 points below. I have cc'ed the
> [email-masked] mailing list so the folks who want to focus on details of
> LISP can see this thread.

OK, we are also transmitting to [email-masked] and
[email-masked] .

> updated when they need to then to hold all the possible mappings for the
> Internet in an ITR.
> 

That is the dichotomy between LISP-CONS/ALT and LISP-NERD.  However
there is another approach (APT and Ivip): full push to local query
servers.

RAM and hard drive space is very cheap.  The query servers don't need
to be Cisco-style routers.  They can be COTS or high-reliability
rack-mount PCs - with gigabytes of RAM and terabytes of hard disk
storage.

In Ivip, IPv4 mapping consists of 12 bytes:

  Start of the micronet  (32 bits)
  Length of the micronet (32 bits, but typically 16 or less)
  ETR address            (32 bits)

So if you have a COTS server with 16GB of RAM (this will no-doubt be
the common amount of RAM in PCs by the time a core-edge separation
scheme is deployed) then you can easily dedicate 12GB for mapping
information.  That is a billion micronets (more or less, depending on
the storage format), which will do the trick for many years to come.
 (IPv6 mapping is more bloated, but there is a longer time-frame for
implementing millions or billions of IPv6 micronets - time for RAM to
get cheaper still).

I think you - and the designers of APT and TRRP - have been somewhat
captive to established ways of thinking about how to solve a
"routing" problem: with more "routing" style structures.  This means
more routers, more messages and replies zipping around the world etc.
 It doesn't have to be like this.

I need to do more work on the fast-push system of Ivip - but you are
welcome to critique it in its current form:

  http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-00

If your design choice with LISP is optimal, or the only one you think
is available, then you should be able to point out why it is
impractical or undesirable to use an approach such as Ivip's:
real-time fast push on a global basis to local query servers, with
local pull from there to ITRs, followed by pushed updates from the
query server to the ITRs if a micronet's mapping changes within the
caching time of the mapping reply.

Likewise, you presumably have a critique about the practicality or
desirability of APT: slow push to local query servers (Default
Mappers) in each ISP, local pull from ITRs querying the Default
Mappers, local push of mapping updates from DMs to those ITRs which
need it (I think) and (again, my recollection) the Default Mappers,
rather than the ITRs, doing reachability testing and choosing which
ITR address an ITR uses.

The Net will soon be delivering gigabytes of video data to homes, in
near-real-time, for a few dollars.  Generally, a packet can be sent
from any host to any other host in 0.2 seconds or less.

In this scenario, why do you think global push to local query servers
- including high-speed, real-time push - is impractical or
undesirable?

> basically the same properties. First packet loss is not persistent when
> you look at all the traffic that originates from a source site to

This doesn't apply to small end-user networks.  If there are to be
hundreds of millions of these sites, meaning hundreds of millions of
EIDs or (Ivip) micronets - then these are mainly going to be small
"sites", such as home offices, or more likely mobile devices.  The
initial packet delay will directly impact usability, since there may
only be one human user at each such "site".

If many small "sites" use a common ITRs in a large ISP, there will be
less trouble with this, since it will be more common for one site to
generate a packet to some EID/micronet which the ITR has mapping
from, due to another "site" sending a packet there too.  However, the
frequent delay of initial packets (actually, it seems you are
planning to drop all initial packets) will still be a problem.

If LISP is not meant to scale to a hundred million or a billion or
whatever "sites", then by whatever same smaller target number of
EIDs, micronets or whatever, this would make alternative approaches
such as Ivip or APT even more immune from whatever scalability
critiques you might make of them.

> could wait to send your TCP SYN before the mapping is available. 

On IPv4, with most human-used hosts behind NAT, you can't put a LISP
ITR in the sending host, because the map reply won't come back to the
host.

In a scenario in which LISP is widely - ubiquitously - deployed, many
DNS servers are going to be on EID space.  This means the ITR will
often need to do a mapping lookup before it can send a DNS request.
The sending host will be on EID space and so the DNS server's ITR
will need to do a mapping lookup too before it can send the return
packet.  This will suck to a high degree in the current arrangement
where the DNS server sends a single packet.  The ITR of the DNS
server will drop that packet and send a mapping request for the
original sending host's EID.  Then, after a while, the sending host
will realise it got no DNS response.  If it sends the same request to
the same DNS server, it will get a response back quickly, since now,
the DNS server's ITR has the sending host's mapping in its cache.

But what if the sending hosts does it it might reasonably do: send
the request to a different DNS server?  Then the same pattern as
above occurs again.

> Guess

So you are proposing that every DNS reply also include full LISP
mapping for every one or more EIDs of the one or more IP addresses
returned?  I doubt if that will always fit in one packet.

> The design choice of LISP *is to just change software in CPE devices* to
> get the feature of decoupling rather than changing all the hosts at a
> site. 

OK . . . LISP mutates again!   I have been following LISP intently
since about March 2007 and I don't recall any mention of changes to
hosts or to CPE - by which I guess you mean DSL, cable and fibre
router/firewalls.

Do you propose putting the ITR function in the DSL
modem-router-firewall?  That is not such a bad idea, since it has
(presumably) a public IP address and so can receive the map reply
message from the globally distant query server (in the case of LISP,
the mapping queries are typically answered by the destination
end-user network's ETR).

Ivip has the option for putting ITR functions in a sending host which
has a public address, or in a device such as a
DSL-modem-router-firewall.  It would not be out of the question to
put an ITR function in the sending host behind NAT, but then the
sending host would need to build a persistent tunnel through NAT to
the one or more local query servers - in order to receive mapping
updates from those query servers.  That is possible, but not part of
the current plan.

> That's a huge deployment advantage.

I don't see any advantage in terms of deployment, since it involves
changes to more and more equipment, including customer equipment.
Ivip's ITFH (ITR Function in Host) is optional - if it is cheap and
convenient to do this for servers or devices like DSL-routers, then
by all means do so.  It only makes sense when the device is
well-connected.  It would be a bad idea to put an ITR function in a
host or router at the edge of the network connected by a slow,
expensive or unreliable link such as a wireless link.

> So these CPE devices get packets before they have mappings.

OK - for instance, the ITR function is in a DSL-modem-router-firewall
device.

> We don't even want to consider a host
> to CPE router signaling protocol and all it's complexities to solve this
> and to keep the architecture pure, we don't want to snoop on DNS, SIP,
> or any other protocol that can give us a hint on where the host is about
> to send a packet.

I agree.

> ALT using it as a request for a mapping.

These are not the only choices.

Another choice is to using a different architecture with local query
servers - as does APT and Ivip.   I think you have approached this
without thinking widely enough about the alternative ways of doing
things which are different from traditional approaches like routers
and DNS.

If you send the packet on the ALT network (for the purposes of
delivering it to the ETR ASAP, as well as to elicit a mapping reply
from that ETR) then you are going to greatly increase the volume of
traffic on the ALT network.  Many of these packets will be short -
but what if someone sends a 1500 or 9000 byte packet?

If you don't send the packet via the ALT network, then you either
drop it, or delay it until the mapping arrives.  But that could be
longer than 0.5 or 1.0 seconds, considering how many ALT routers the
mapping request packet needs to go through to get to the ETR, how
these ALT routers could be all over the world, and how the ETR could
be on the other side of the world anyway.  This is a lot slower than
the current system which usually takes 0.2 seconds or less to
delivers packet anywhere in the world.  (The round trip from
Melbourne Australia to Latvia is about 400ms.)

> Well this I believe is a duplicate of 1 above. So it's not really

In terms of delaying packets, I agree.  Do you agree the long-path
critique is valid?

The long path involves more than delay.  It involves traffic flowing
(often) all around the world due to the fact that the highly
aggregated structure of the ALT network will frequently result in
different levels of the ALT hierarchy of routers being distributed
all around the globe, since the physical location of organisations
who are responsible for various parts of the address space does not
correlate very strongly with geography or the topology of the Net.

This is a traffic burden, particularly if you are sending initial
packets on the ALT network for ASAP delivery to the ETR, rather than
just map requests.  (However, Ivip involves pumping mapping
information around the globe anyway, and if your ALT network only
handles requests, not traffic packets, the actual volume of traffic
should not be too much of a problem.)

Each operator of each ALT router needs to have a commercial
relationship with those other ALT routers they connect with.
Otherwise, why would they accept the traffic?  I haven't seen any
business plan for the commercial relationships which pay for the ALT
routers and their traffic.

Ivip's fast push system involves a charge per update, which will
finance the construction and running costs of most of the fast-push
system, which will be run collectively by the various RUAS (Root
Update Authorisation System) companies, each of which generates the
real-time mapping changes for multiple MABs (Mapped Address Blocks -
BGP-advertised prefixes encompassing thousands, or hundreds of
thousands of micronets).

> If we can do this with BGP, which we have decades of existence proof why
> can't we do this with a tunnel topology 1) where a tunnel can be rehomed
> much quicker and easily than physical links and boxes we have to do with
> today, allowing aggregation to occur at the edges of the ALT network,
> and 2) these tunnels stay up because there is robust connectivity below
> the tunnel level to keep them up, hence there will be less route-flaps
> for EID-prefixes.

I don't recall any prior mention of rapidly reconstructing tunnels to
maintain the ALT topology.  I agree with your point 2 that the
tunnels will be reasonably robust due to relying on existing
connectivity which is generally ensured by BGP.

But what happens when two ALT routers loose their connection for a
moment?  Do they try to set up one or more tunnels with the same role
in the ALT topology as the one which just died?  This is your point
1.  It could get messy, but I guess it could be done, by using other
interfaces which, for some reason (I guess) have connectivity while
the interfaces used for the first tunnel don't.  But that is the sort
of situation which I think BGP would naturally resolve, generally in
a few seconds or less.

My concern is more about what happens if an ALT router dies.   In
your highly aggregated hierarchy, a mid-level ALT router is a single
point of failure for sending mapping requests to all the ETRs in the
branch below this router and from all the ITRs in that branch to ETRs
outside the branch.

When a mid-level router dies, you can't just re-establish tunnels -
it is dead.  The routers below need to establish tunnels to another
ALT router which can take the dead one's place.

How is this going to work?  Say one lower-level router finds it can't
reach the mid-level router in question, it is going to assume the
mid-level router is dead.  So the lower-level router tries to set up
a tunnel to the one or more backups.  If it does so, either this
won't work at all, or the next level up will have to adapt to the
original mid-level router having routes for most of its patch of the
ALT address space, but with the backup having the router for the
smaller patch of space handled by the lower-level router which just
made a tunnel to the backup mid-level router.

> be more stable and scalable then the underlying BGP. 

I assume you mean that the BGP of the ALT network, operating over
tunnels, will be more stable than the BGP of the Internet.  This is
your point 2, and I largely agree.  But what if an ALT router dies?

> Plus, what we
> propose for the use-case of BGP uses quite a few features of it. Recall
> this is eBGP over GRE.
> 
> We have an infrastructure where we can 1) ping to see liveness of nodes
> on the ALT. We have traceroute to determine the path a Map-Request takes
> on the ALT. We can ping/traceroute "underneath" so we can see the
> diameter of the tunnel. 

I don't understand "diameter" in this context.

> Not only do we have a solution but we use
> existing rudimentary tools for management.
> 
> And the address allocation hierarchy can map this logical ALT topology.
> And if the Registries are involved in managing part of this ALT network
> (which we hope and think they will), we can keep this consistent
> relationship.
> 

I am sure you can make the ALT network reasonably robust, at a cost
of complexity and with a loss of the original attractive design goal:
a very high degree of aggregation.

I imagine you can reduce the excessively long paths by collapsing the
network as much as possible to reduce the number of levels a packet
typically has to ascend and descend.  This will reduce the
"long-path" problem significantly.  But then, each participating
mid-level ALT router (there are fewer of them) covers a larger part
of the address space, and my concerns above become more acute, when
such a router fails or becomes really unreachable.

I imagine you can reduce the geographical scatter component of the
long-path problem by centralizing the ALT routers geographically.
However, that privileges some operators and creates costs and
difficulties for others.

I still think it is fundamentally wrong to have a global query server
network for any system like this, where waiting for mapping replies
involves delaying or dropping traffic packets.

I think a much better solution is to push the mapping to local query
servers in each ISP (APT and Ivip) - and into any larger end-user
networks which want to run their own local query servers (Ivip) so
their ITRs can get marginally faster, more reliable, responses than
by using the query servers of their ISPs.

> There's more too, you then throw SIDR in the mix and we have secured the
> ALT, we have secured mappings, we created a PKI for routing use. In
> fact, the first SIDR deployment could happen on the ALT to be

PKI is a great idea, but I think most people believe it is highly
desirable to find solutions which do not require it.

> And note, that the infrastructure will/does carry exactly 2
> address-families. So we can do 6-to-6-over-4 with this approach. That
> means we can get two site to be *IPv6-only* and be able to talk to each
> other.
> 
> If you are a IPv6-only site now or a dual-stack site, you could talk to
> the new IPv6 Google services. I think this is a pretty huge feature.
> 
> This is clean and architecturally pure, no double NATs, no CGNS, and no
> applications breaking.

Are you discussing just the mapping queries going over the ALT
network?  Or are you discussing the use of LISP to enable, for
instance, two IPv6 sites to communicate via the IPv4 Internet, while
one or both sites has no native IPv6 connectivity?   A concrete
example would help.

> decoupling of the address creates this. 

Christian's critique is not that an end-user network which has
(permanently, by some arrangement) a slice of EID space is bound to
its current ISP (the one it uses for connectivity).

The critique is on this potentially erroneous basis: that the
end-user network is bound to maintaining connectivity (via a tunnel)
to the ALT router which handles this part of the EID space.  It needs
to do this so mapping queries for its EID space will get to its ETR.

The potentially faulty aspect of this is the assumption that the
end-user network runs its own ETR.

But if its one or more ISPs run the ETR this end-user network uses,
then the end-user network still depends on those ETRs having tunnels
to potentially distant ALT router for its section of the EID space.

I don't know if anyone has considered the scaling problems of a busy
ETR maintaining tunnels to about as many ALT routers as the end-user
networks it handles packets for.

The ALT router for this section of the EID space will, I assume, be
located at some ISP somewhere, or some other commercial organisation
which rents out the EID space to this end-user network.

Maybe that organisation is an RIR.  But when this scales to tens or
hundreds of millions of end-user networks (I assume this is a goal of
LISP - it is of Ivip) I doubt if RIRs will want to be dealing with a
hundred million end-user networks directly, either for address
assignment or for tunnels to receive mapping requests to their ETRs
from the ALT network.

For these large scaling arrangements, there will need to be
potentially multiple levels of address splitting.  Ivip allows for
this, and for multiple levels of companies providing interfaces to
accept mapping changes from end-user networks (or more likely from
reachability testing companies they hire) and funnelling them to the
limited number of RUAS organisations which run the fast-push mapping
distribution system.

Any way you do this core-edge separation business - LISP, APT, Ivip
or TRRP - if the end-user network gets a patch of stable address
space to call their own, year after year, then that network is going
to depend on some company or other organisation for that space.  The
end-user network will need to pay for this, and depend on the
organisation to handle mapping.

In the case of LISP-ALT, the organisation needs to run (or have
someone else run) an ALT router (plus backups) which has a tunnel to
the ETRs in the ISPs which the end-user network is currently using
for access.  If that organisation's ALT routers go down, it is not
the fault of the access ISPs - it is up to the end-user network to
ensure it obtains its EID address from an organisation which provides
a reliable ALT router service.

Also - assuming the space is covered by a PTR in order to provide
100% multihomed service for packets sent from hosts in non-upgraded
networks - this organisation has to run PTRs which covers this
end-user's EID space.  For this to be scalable (not to bloat the DFZ
routing table excessively, as we go to millions of end-user networks
with EID/micronet space), the PTRs needs to advertise a prefix which
covers the EID space of thousands or hundreds of thousands of
separate end-user networks.

Since the sending hosts (in non-upgraded networks) could be anywhere
in the world and since the ISPs used by all these end-user networks
(covered by the one BGP advertised route) could be anywhere in the
world, in order to ensure reasonably direct path for traffic packets,
there needs to be a largish number of PTRs physically all over the
Net.  Then the organisation which runs this PTR system needs to
recover costs from individual end-user networks according to the
traffic the PTRs carry.   (This is the Ivip business model for
OITRDs.  I am stating this as an imperative for LISP, because I can't
imagine any other business model for PTRs.)

In the case of Ivip, the equivalent organisation needs to do the same
as just stated for OITRDs and provide the real-time mapping
distribution service, with a small charge per update.

Either way, the end-user network has a long-term technical and
commercial dependency on whichever organisation supplies its EID
(LISP) or micronet (Ivip) address space.  This is why my message
continued to state that a problem such as this is common to all
core-edge separation schemes:

So while I could take this off the list of "unresolved" problems for
LISP, since other schemes have comparable problems - I think LISP
could be improved by more clearly stating the types of commercial and
technical relationships each participating end-user network will rely
upon.  Also, the physical distance to the ALT router from wherever
the end-user network's ETRs are directly affects the delay
experienced at the start of sessions.  I think that is part of
Christian Vogt's concern.

I think I have done a better job of explaining all this with Ivip's
business model for OITRDs:

  http://psg.com/lists/rrg/2008/msg01158.html

> The dependence is now on the
> ALT. And if your site resides in a specific region of the world, you get
> your EID-prefixes from that registry. So readdressing your domain would
> only occur if you moved it from one region to another (let's leave
> mobile ASes out of this for now).

I think a good core-edge separation scheme should make the EID
(micronet) space entirely portable, with little or no compromise in
performance or costs regarding mapping no matter where the end-user
network chooses to connect its EID space (or some part of it) to the Net.

This is easier for Ivip, since the mapping change command only
involves a few dozen bytes and is made quite infrequently.

For LISP-ALT, the mapping connection is an incoming stream of
requests or initial packets which also function as requests.  It is
time-sensitive, since only when a response arrives at the ITR can
communications without delay begin.  So the physical proximity (delay
and reliability) between the ALT router for this section of the EID
address space and the the ETRs of the ISPs currently used by the
end-user network is really important.  I don't mean San Jose to LA
distances - I mean Australia to the USA, Germany to China etc.

These do seem to be a fundamental difference between LISP-ALT and
Ivip.  However, both systems will only work well with a widespread
set of PTRs/OITRDs.

> 2-bytes of effective-MTU state per mapping.

OK - I apologise for stating that you thought there was no problem.

I haven't considered MTU problems of sending traffic packets along
the ALT network, in its GRE tunnels (which impose their own
encapsulation overhead) - but I understand the current LISP test
network doesn't send traffic packets over ALT.  It is my impression
that your long-term plans are to use the ALT network only for short
map request messages, not go get initial traffic packets to the ETR ASAP.

Version 08 (2008-07-10) introduced a stateless technique and version
11 (2008-12-19) adds a stateful approach, derived from the OpenLISP
project, who regarded the stateless approach as inadequate.

My assessment of both approaches is in a separate message:

  LISP PMTU - 2 methods in draft-farinacci-lisp-11
  http://www.irtf.org/pipermail/rrg/2009-January/000885.html

I think the stateless section is poorly written and ill-conceived.
The stateless approach for IPv4 DF=1 packets and IPv6 packets (that
is, virtually all traffic) would limit traffic packets to 1464 bytes
(IPv4) or 1444 bytes (IPv6).  Only once there was jumboframe links
between every ITR and ETR could L be globally adjusted upwards from
1500 bytes to ~9000 bytes or whatever - but this would not be
possible for a decade or two.  Fred Templin expressed the same
concerns in a recent RRG message.

The Stateful approach, which I understand is derived from OpenLISP,
is similar to Ivip's approach:

  http://www.firstpr.com.au/ip/ivip/pmtud-frag/

I need to write this up as an I-D, but it is a more detailed spec
than your LISP approach, with mechanisms for occasionally testing for
MTUs longer than the assumed limit and for strictly minimising the
number of traffic packets which are used to probe the PMTU.  Every
packet whose length, once encapsulated, is in the "zone of
uncertainty" for this ETR is either delivered or rejected with a PTB.
   The former raises the lower limit to the zone and the latter
reduces the upper limit.

> You cannot fault a technical design for a business case. 

A complete solution to the routing scaling problem involves much more
than a technical design.

All the technical stuff (sometimes split into "architecture" vs.
"engineering") needs to facilitate someone wanting to build and run
each part of it - which generally means they (or someone not too far
removed from them) needs to be able to make money from it.

> A PTR is
> type routes out of the core *and* avoid NAT solutions which are just way
> too high in opex, the PTR is the only solution we have to turn to.
> 
> PTR services. Will they make a ton of money out of it, well that remains
> to be seen.

I think my critique is valid - you seem to have no business case for
LISP's Proxy Tunnel Routers.

You are welcome to adopt the Ivip approach for address management and
OITRDs:

  http://psg.com/lists/rrg/2008/msg01158.html

This is directly applicable to LISP and PTRs, as long as you have a
concept of a Mapped Address Block, containing many EIDs.  For that to
be the case, you need to develop business arrangements concerning who
really "owns" the MAB and how they rent this space out as EID space
for thousands of end-user networks.

> Dave and Darrel's draft is providing a warning about how bad probing can
> be. They do not take a position whether it should go into any proposal.
> They are just saying, beware of the Frankenstein that may result and can
> be an interpretation to not do probing at all.

The scaling problem of thousands of ITRs continually test
reachability for one ETR (or to every ETR on the LISP mapping list
for a given EID), plus reachability through each ETR to a given
destination network, or of each ITR having to test reachability to
thousands or tens of thousands of ETRs have been obvious from the
start: early 2007.

This is true of LISP, TRRP and to a somewhat lesser extent APT. (I
haven't read RANGER yet.)

Only Ivip avoids these scaling problems by making the end-user
network responsible for their reachability testing and for deciding
which ETR the packets for each micronet should be tunneled to.

> *may* be a path failure *somewhere in the middle of the network*. Please
> note my very fine qualifications.
> 
> host switch it's TCP connection to another A record. This doesn't happen
> today because people deal with packet loss, since it doesn't last long
> *and* rerouting actually works quite well.
> 

The alternative has been available to you and anyone else since July
2007: Ivip.  A fast-push mapping system to local query servers means
the ITRs don't need to test reachability or make any decisions about
which ETR to use.  The mapping has a single ETR address.

What is wrong with this approach?

> the research stuff in LISP has been and will continue to be presented in
> RRG.

OK.

> want a forum to discuss and work out issues in an open forum. I've been
> going to IETF for 20 years now, that forum is called a working group.
> 
> The working group doesn't have to standardize what it is working on. And
> the charter and the numerous requests we have made requests *for an
> experimental working group*.

I think this is fine.

However, I think there are sufficient fundamental, well known
problems with LISP-ALT that if this was my proposal, I would fix them
before asking people in general to join an IETF WG and help me with
it - or drop the proposal.

> For the old timers, that was the difference between TCP/IP and OSI.

I am all for detailed engineering, running tests etc.  However, the
worst problems I perceive with LISP-ALT will not be illuminated by
any amount of testing, as I explained in the message you are
responding to.

Do you think Ivip is so overblown and over-complex that it warrant's
no serious consideration?

Just because I write stuff in detail doesn't mean the system itself
is over-complex.  Ivip ITRs and ETRs are much simpler than LISP ITRs
and ETRs.

I have been giving your work the honour of detailed critiques for 18
months.  I would appreciate you and your colleagues returning the
favour by reading:

  http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf

  http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-00

  Ivip business models: fast push & OITRDs
  http://psg.com/lists/rrg/2008/msg01158.html

and telling me - and the RRG - what you think.

Also, I am keen to know from you, your Cisco colleagues and from the
folks at Juniper how practical it would be to create firmware
upgrades for all the DFZ routers in use ca. 2014 or whatever -
whenever the routing scaling solution is to be implemented.

I think it is practical and highly desirable to encode the ETR
address in the IPv4 header (actually 30 bits, which is fine) or a 20
bit prefix label in the IPv6 header.  Then, in the longer term, we
don't need encapsulation, its complexity, its overhead and its damn
PMTUD problems.

As far as I know, both these proposals could be implemented as
firmware upgrades, or built-in optional features, in the DFZ routers
which are likely to be in use in 5 years time, but only you guys can
say this is so or not:

  ETR Address Forwarding (EAF) - for IPv4
  http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw-01

  Prefix Label Forwarding (PLF) - for IPv6
  http://www.firstpr.com.au/ip/ivip/ivip6/

Maybe we can do that in time for the introduction of the routing
scaling solution - and thereby completely avoid encapsulation and its
PMTUD complexities.

On mobility - what is your objection to this arrangement?  ETR-like
Translating Tunnel Routers with two-way encrypted tunnels to mobile
nodes.  Mapping only changes to a new TTR when one is really needed 0
which is typically only when the MN moves 1000km or more.  So mapping
changes are not at all frequent and in particular are not needed
every time the MN gets a new CoA:

  http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf

If I was proposing to the IETF that a WG be formed for my project, I
would first want to establish for myself - and for IETF people in
general - that my project was either the best in its class, or one of
the very few with the most promise.

I don't see how you can do that when you fail to read - or at least
fail to discuss in public - alternative schemes to LISP.

Ivip and APT are broadly comparable to LISP - they are all core-edge
elimination schemes for both IPv4 and IPv6.  They are both well
enough documented to be suitable for serious critiques from anyone
who believes LISP's approach is superior.

Just because you have more people - with more experience and
resources - working on LISP and have running code, doesn't mean your
LISP-ALT design is better than APT or Ivip.

  - Robin

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 28 Jan 2009 08:37:20 -0800

Robin, 

> From: Robin Whittle [mailto:[email-masked]] 
> Sent: Monday, January 26, 2009 11:18 PM
> To: RRG
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; Dino Farinacci

I don't know if you were fishing for a response, but the
stateful solution outlined in the latest LISP draft still
has problems. It should also be mentioned that the approach
(drop first; return PTBs for subsequent) is not new and
has been proposed many times over the years.

The approach in the current LISP draft still relies on ICMPs
coming from anonymous network middleboxes (which Dino himself
has said that we cannot depend on), and provides insufficient
means for authenticating any ICMPs that may come. For example,
even if the ICMPs were delivered, and even if they included
the LISP nonce, it would be impractical for the ITR to cache
enough nonces of enough recently-sent packets especially at
high data rates. So, the only option is to ignore ICMPs
(leads to black holes) or honor ICMPs (leads to denial
of large packet service).

I have said this before, but AFAICT DF=1 is busted.

Fred

---

From: Christian Vogt <[email-masked]>
Date: Wed, 28 Jan 2009 15:18:20 -0800

On Jan 24, 2009, Dino Farinacci wrote:

> get

Dino -

There is a tradeoff between EID portability and path stretch along the
ALT topology, and I believe the tradeoff made in LISP/ALT has been
revised a few times.

Portability of EID prefixes requires that the ALT topology follows
EID-addressing.  This leads to potentially longer-than-optimal paths
along the ALT topology.  Vice versa, if path stretch is to be limited,
then portability of EID prefixes must be restricted.

According to your email to Robin, LISP/ALT currently makes the following
tradeoff:  Portability of EID prefixes is limited geographically in
order to curb path stretch along the ALT topology to the maximum that
can happen within a geographical region.

That's possible, of course.  The cost is that networks scattered over
different parts of the world, such as those of enterprises with global
presence, cannot use a continuous address space internally -- even if
they all attach to the same provider.

- Christian

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 28 Jan 2009 17:19:06 -0800

> has said that we cannot depend on), and provides insufficient

I did not say that. I said you cannot depend on ICMP Unreachables. But  
ICMP TooBig and Time-Exceeded message are sent and are more  
dependable. That is, they can get lost when they are transmitted since  
they are single transmitted datagrams. But at least they are sent.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 28 Jan 2009 18:52:04 -0800

> ALT topology, and I believe the tradeoff made in LISP/ALT has been

Yes, but if you are portable within an aggregate boundary, you are okay.

> EID-addressing.  This leads to potentially longer-than-optimal paths

And it does.

> then portability of EID prefixes must be restricted.

I envision the number of hops a Map-Request takes is 4 ALT-router  
hops. I think we can do that with how the aggregation and allocation  
assignment is done on the LISP network now.

Now if the diameter of the tunnels are large, then there will be  
longer delays because the Map-Request will have to travel more  
physical hops.

But I really think you are not going to find a better way.

> can happen within a geographical region.

Right that is the tradeoff, but a site in Europe is not going to move  
to the US. A new site that is added in the US will get EID-prefixes  
from ARIN and terminate it's tunnels to the routers in the allocation  
assignment hierarchy for ARIN.

> they all attach to the same provider.

Christian, when you come to IETF in the US and you use your VPN client  
to connect back home to Finland, and you go to a URL in San Jose (when  
you are at the SF IETF), your packets will to east over the Atlantic  
twice and back to the west coast. That's a delay we all seem to live  
with everyday.

I am not justifying delay and I'm not at all saying this is going to  
happen on the ALT either. Remember this only happens for the first few  
packets to a new site when there is a cache miss from each ITR.

You cannot push around 10^10 entries and store them everywhere. In  
fact there are chances with a push technology that you might have to  
store them in nodes that won't need them for use but will need to  
store them for distribution. That will be a big cost. So then you go  
get them when you need them.

Please recall, for LISP to support such a large database (10^10  
entries), it must be distributed. And you want them to be stored where  
the policy holders are for the mapping and you wan them to reside at  
the site that the mapping describes them.

Dino

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 29 Jan 2009 06:04:55 -0800

> Sent: Wednesday, January 28, 2009 5:19 PM
> To: Templin, Fred L
> Cc: Robin Whittle; RRG; [email-masked]; 

Yes, that is what you said. And, an IPv4 PTB is just an
ICMP unreachable with code=4.
 
> they are single transmitted datagrams. But at least they are sent.

There is evidence (e.g., RFC2923, RFC4821, etc.) that
this is not always true.

Fred

---

From: Joe Touch <[email-masked]>
Date: Thu, 29 Jan 2009 16:14:32 -0800

Dino Farinacci wrote:
> ICMP TooBig and Time-Exceeded message are sent and are more dependable.
> That is, they can get lost when they are transmitted since they are
> single transmitted datagrams. But at least they are sent.

Can you clarify? ICMP unreachables are required sent, just as TooBigs
and Time-Exceededs. They're all blocked by various systems, including
NATs and firewalls, so none can be relied upon.

Joe

---

From: Christian Vogt <[email-masked]>
Date: Sat, 31 Jan 2009 11:49:46 -0800

On Jan 28, 2009, Dino Farinacci wrote:

> You cannot push around 10^10 entries and store them everywhere. [...]

Dino -

I think we should experimentally compare ALT with other mapping systems
before we decide whether pull-based or push-based mapping systems are
better.  Dismissing push-based mapping systems without corroborating
data would be a bit premature in my opinion.

In the absence of experimentation results, I would actually argue in
favor of push-based mapping systems based on some analytical reasoning:
Pull-based mapping systems have two important disadvantages compared to
push-based mapping systems:

- Performance penalty, i.e., additional propagation latencies for some
   packets, and higher loss probabilities for packets that take a sub-
   optimal path

- Robustness penalty due to a new online dependency on components off
   the actual transmission path.  (FWIW: All pull-based mapping systems
   have this penalty.  Mapping requests must be routed via overlay
   infrastructure because the direct route is unknown at that time.)

Furthermore, I do not share your concerns regarding push-based mapping
systems:  BGP is pushing routing data already today, and this works
fine.  Any routing-scalability-related issues with BGP are not due to
BGP being push-based; they are due to frequent updates and a high load
for core routers.  Both of these issues would go away in an address
indirection architecture (be it LISP, Ivip, APT, or Six/One Router),
independent of whether you use a pull- or push-based mapping system.

In conclusion:  The overlay approach of ALT is certainly an interesting
idea.  But I think it would be premature to conclude that it is the only
viable solution before we have more evidence to back this claim.

- Christian

PS:  I admit that I have never been really good in avoiding cross-
posting.  But this is obviously my all-time negative record...