Subject: [GROW] LISP@GROW

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Sun, 3 Aug 2008 12:18:34 +0200

we did not have had sufficient time to discuss during grow@ietf72 the
operational issues related to the deployment scenario of LISP. i would
have appreciated to discuss the following points together with the
operational community:

a) CE-based vs PE-based xTR -> LISP makes use of the former what is the
operational impact ? is deployability becoming easier vs operational
constraints ?

b) Can operational community afford a one time renumbering (EID)
assumption considered by LISP/is it a realistic assumption ? or is the
alternative consisting in reconnecting sites so as to result into a EID
contiguity a possible/feasible scenario ?

c) LISP-ALT relies on BGP-based overlay mapping system (EID-to-RLOC) ->
as LISP is CE-based isolation from CE instabilities would now impact the
mapping system (note: about 80% of the instabilities result from failure
events on eBGP links and proportionally such events resulting into BGP
instability increases towards the edges). this would result into the
same convergence time issue than actually experienced by the current BGP
RS (note: the number of TR is proportional to the number of customer
sites) ?

-- opinions/thoughts ? --

thanks,
-d.
_______________________________________________
GROW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/grow

---

From: "Tony Li" <[email-masked]>
Date: Sun, 3 Aug 2008 08:57:51 -0700

|b) Can operational community afford a one time renumbering (EID)
|assumption considered by LISP/is it a realistic assumption ? or is the
|alternative consisting in reconnecting sites so as to result into a EID
|contiguity a possible/feasible scenario ?

My $.02: We've done nothing to make renumbering sufficiently pain-free that
the vast majority of sites would be willing to renumber (even once) for the
sake of forestalling routing table growth.

Tony

---

From: Lixia Zhang <[email-masked]>
Date: Sun, 3 Aug 2008 17:35:38 -0700

On Aug 3, 2008, at 3:18 AM, PAPADIMITRIOU Dimitri wrote:

> constraints?

I asked the same question earlier.
Someone told me that (perhaps for small client sites) ISPs could be  
running the CE boxes in behalf of their clients.

> contiguity a possible/feasible scenario ?

It seems to me that the answer to renumbering is either "feasible" or  
"infeasible", as opposed to doing it once or multiple times.

And from what I have heard so far, "infeasible" seems the popular  
answer.

> RS (note: the number of TR is proportional to the number of customer

this is a very good point.
My understanding is that locators are aggregatable/aggregated.  Thus,  
different from losing connectivity to customer ASes (or customer  
prefixes) as in today's BGP routing, hopefully the loss of  
reachability to a single CE locator (using LISP terminology) would not  
trigger eBGP updates, at least not to other ASes.

In this case, it just further underscores the importance of edge  
failure detection and recovery scheme (and potential benefits from the  
multipath-TCP as Mark Handley presented at TSV area meeting, if/once  
it's deployed)

Lixia

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 4 Aug 2008 09:55:14 +0200

> running the CE boxes in behalf of their clients.

While I sam sure that could work in some markets, it certainly would  
not be universally true. In some markets that would be a lock in  
effect that would not fly.

Best regards,

- - kurtis -

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Mon, 4 Aug 2008 01:51:27 -0700

> 
> we did not have had sufficient time to discuss during 
> grow@ietf72 the operational issues related to the deployment 
> scenario of LISP. i would have appreciated to discuss the 
> following points together with the operational community:

Hey Dimitri.  I think if there was a common theme in the Dublin
IETF it was 'we didn't have suvvicient time'... :-)

While I don't speak for the community, I can speak for the
intent of the LISP crew, many of which are ex-operators.

> 
> a) CE-based vs PE-based xTR -> LISP makes use of the former 
> what is the operational impact ? is deployability becoming 
> easier vs. operational constraints ?

LISP's preference for CE based xTRs is based upon a few major
factors.  First the we feel that the PE is already
an overloaded box.  Second, and in my mind more important,
a key benefit of loc-id split is provider independence.

Now provider mobility cuts both ways, it reduces de-facto
lock-in for customers who get PA space from their provider. 
But it also allows for sites to add additional provider
connections much easier.  

Allowing for more sites to have additional connections
without stressing the routing system seems to be a win for
everyone.

> 
> b) Can operational community afford a one time renumbering 
> (EID) assumption considered by LISP/is it a realistic 
> assumption ? or is the alternative consisting in reconnecting 
> sites so as to result into a EID contiguity a 
> possible/feasible scenario ?

If a site has PI space today, its not assumed that they will
have to renumber.  However, the current demand for PI space
seems to indicate that PI is a popular concept.  IMHO
PI space, and what that entails, seems to be a compelling 
benefit to weigh against the cost of one time renumbering.

> 
> c) LISP-ALT relies on BGP-based overlay mapping system 
> (EID-to-RLOC) -> as LISP is CE-based isolation from CE 
> instabilities would now impact the mapping system (note: 
> about 80% of the instabilities result from failure events on 
> eBGP links and proportionally such events resulting into BGP 
> instability increases towards the edges).

The answer to this point is that the ALT is highly aggregated, 
and aggregation dampens instability.  Since the ALT is not 
directly responsible for site/link reachability, we can allow
less dynamicity in the system.  The ALT is responsible for
Subscription time mapping events, not failure time reachability.

> this would result 
> into the same convergence time issue than actually 
> experienced by the current BGP RS (note: the number of TR is 
> proportional to the number of customer
> sites) ?

Thanks for the note!

-Darrel

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Mon, 4 Aug 2008 12:27:28 +0200

One point of clarification here below:

> -----Original Message-----
> From: Lixia Zhang [mailto:[email-masked]] 
> Sent: Monday, August 04, 2008 2:36 AM
> To: PAPADIMITRIOU Dimitri
> Cc: [email-masked]
> Subject: Re: [GROW] LISP@GROW
> 
> grow@ietf72 the
> what is  
> > the
> > alternative consisting in reconnecting sites so as to 
> result into a  
> > EID
> (EID-to-RLOC)  
> > ->
> > as LISP is CE-based isolation from CE instabilities would 
> now impact  
> > the
> > same convergence time issue than actually experienced by 
> the current  
> > BGP

My understanding is that in LISP+ALT, RLOCs are not carried by ALT
routers (ALT does not propagate EID-to-RLOC mappings). But i should ask
for actual confirmation.

If this is the case, traffic-driven MAP-Request/Reply (EID-to-RLOC
resolution) relies on BGP exchanges between ALT routers of the
supposedly aggregatable EID prefixes. There are three main consequences:

a) as you state here below traffic disruption resulting from EID
unavailability must be addressed by a mechanism reactive within a
timeframe shorter than the ALT-BGP recovery time.

b) ALT-BGP failure would disrupt EID reachability even if the RLOC
itself is actually reachable.
 
c) ALT-BGP updates would be now triggered by an information not owned by
the operator itself.

> multipath-TCP as Mark Handley presented at TSV area meeting, if/once  

to address point a) i agree. 

-d.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 4 Aug 2008 03:49:18 -0700

> have appreciated to discuss the following points together with the

Dimitri, let me add to Darrel's comments.

> operational impact ? is deployability becoming easier vs operational

If you put xTRs at the PE, they will never talk to each other when  
deployed in different SPs. And you want them to know about each  
other's reachability so they can set loc-reach-bits for themselves as  
well as each other. That has to happen at the site. Plus it scales  
better there.

And I think you'll find PE-based xTRs as a non-starter. I bet many  
operators would confirm this.

> contiguity a possible/feasible scenario ?

I think they can especially if you tell them it's the last time. They  
already know that today when they go to PI and their service providers  
accept their PI prefixes.

> c) LISP-ALT relies on BGP-based overlay mapping system (EID-to-RLOC)  

I want to make something very clear. The feedback and discussion I  
received at the IETF indicates that people think the BGP ALT "carries  
mappings". This IS NOT TRUE. BGP ALT carries solely EID-prefixes so  
ITRs can find sites that have the mapping data. Then the mapping data  
is returned in Map-Replies.

Dave mentioned in his GROW presentation that no changes were made to  
BGP to make ALT work. That is definitely true. You could put a XORP of  
Juniper box in the middle of the ALT and it would work.

> instability increases towards the edges). this would result into the

This isn't really true Dimitri. If the site is unstable they simply  
can't answer Map-Requests for their site, so it's only connectivity to  
it's site would be impacted, which is to be expected.

With a low-opex xTR, there would be zero instability because the EID- 
prefix is not injected into the ALT by the xTR but by the first access- 
layer ALT router. When the xTR does run BGP to advertise it's own EID- 
prefix, then there would be route flaps.

But I would argue that the BGP ALT *could* run flap-dampening because  
the convergence of the ALT may not be *as* critical as underlying BGP.  
But we have to prove that.

Dino

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 04 Aug 2008 04:42:46 -0700

Hi Dino,

> Dave mentioned in his GROW presentation that no changes were made to BGP 
> to make ALT work. That is definitely true. You could put a XORP of 

Haven't the consideration been made that ALT topology should use new 
SAFI to propagate EID reachability ? Do you really want to mix IPv4 
Internet with ALT by carrying it in AFI 1 / SAFI 1 ?

AFAIK all implementations cisco/juniper/redback by default will install 
all routes to RIB & FIB. If for ALT to goal is to scale to 10^9 it will 
be an interesting experiment indeed :).

> But we have to prove that.

Underlying or co-existent. Or perhas you mean that we install routers 
dedicated for ALT use SAFI 1/1 and just hop that at no point in the 
world someone would not make a typo and all Internet routes will flow to 
ALT ?

IMHO either for ALT or APT we should use a new BGP SAFI.

Cheers,
R.

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 4 Aug 2008 05:33:24 -0700

this is top posting so people don't have to scroll down the screen:)

Dimitri, you are exactly right. I actually realized last night that my  
earlier reply only considered data plane, but forgot the control plane  
(the ALT overlay), which can suffer from unstable edge sites, as you  
pointed out.

Lixia

On Aug 4, 2008, at 3:27 AM, PAPADIMITRIOU Dimitri wrote:

>> ......
>>> mapping system (note: about 80% of the instabilities result from
>>> failure events on eBGP links and proportionally such events  
>>> resulting into BGP instability increases towards the edges). this  
>>> would result into the same convergence time issue than actually  
>>> proportional to the number of customer sites) ?
>>
>> My understanding is that locators are aggregatable/aggregated.   
>> Thus, different from losing connectivity to customer ASes (or  
>> customer prefixes) as in today's BGP routing, hopefully the loss of
>> reachability to a single CE locator (using LISP terminology)
>> would not trigger eBGP updates, at least not to other ASes.
>
> routers (ALT does not propagate EID-to-RLOC mappings). But i should  
> ask for actual confirmation.
>
> c) ALT-BGP updates would be now triggered by an information not  
> owned by the operator itself.
>
>> failure detection and recovery scheme (and potential benefits
>> from the  multipath-TCP as Mark Handley presented at TSV area  
>> meeting, if/once it's deployed)
>

---

From: Scott Brim <[email-masked]>
Date: Mon, 04 Aug 2008 13:36:33 +0100

> it's site would be impacted, which is to be expected.

Dimitri, in addition,

(1) The ALT is not meshy, and is aggregated.  An up/down event at an ETR 
affects its particular advertisement of a prefix, and would make it 
impossible for that ETR to answer a Map-Request, but that would only 
propagate to the next level up in the ALT.  Above that (if there is 
anything above that) an including aggregate is advertised.

(2) If a site is multihomed its ETRs will all connect to the next level 
up ALT router, so even if an ETR link is lost, there will still be a 
path from the next level up ALT router to an ETR that can answer the 
Map-Query, so damping is reasonable.

(3) Finally, if a next-level-up ALT router is unstable, a site's ETRs 
can multihome to redundant next-level-ups.

In all of this, route damping seems worth investigating.

Scott

---

From: Vince Fuller <[email-masked]>
Date: Mon, 4 Aug 2008 05:47:27 -0700

> Internet with ALT by carrying it in AFI 1 / SAFI 1 ?

Hi Robert-

Please see section 7.2 of draft-fuller-lisp-alt-02.txt, which is titled
"Sub-Address Family Identifier (SAFI) for LISP+ALT". It specifically covers
this issue and has been par of the LISP+ALT specification since the first
version of the Internet Draft.

For future reference, here is the current list of LISP documents:

- "core" specifications:
    draft-farinacci-lisp-08.txt
    draft-fuller-lisp-alt-02.txt
    draft-lewis-lisp-interworking-01.txt
    draft-farinacci-lisp-multicast-00.txt
    draft-meyer-lisp-eid-block-01.txt

- areas of further exploration:
    draft-mathy-lisp-dht-00.txt
    draft-iannone-openlisp-implementation-01.txt
    draft-brim-lisp-analysis-00.txt

- ideas that were considered and shelved:
    draft-meyer-lisp-cons-04.txt
    draft-lear-lisp-nerd-04.txt
    draft-curran-lisp-emacs-00.txt

Hope this helps.

	--Vince

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Mon, 4 Aug 2008 14:46:41 +0200

Lewis,

> From: Darrel Lewis (darlewis) [mailto:[email-masked]] 
> Sent: Monday, August 04, 2008 10:51 AM
> To: PAPADIMITRIOU Dimitri; [email-masked]
> Cc: [email-masked]
> Subject: RE: [GROW] LISP@GROW
> 
> 
> > 

Indeed. I hope we can rectify this for the next mtg. Using the mailing
list for now would allow for a broader community to provide for their
opinions. 
 
> a key benefit of loc-id split is provider independence.

Afaik in LISP, the xTR is addressable by an RLOC (taken from PA space)
right ? Does that not result in a dependence ? 

The question is probably which incentive are brought to the client-side
to upgrade their CEs ? or as Lixia mentioned those could be operated by
ISP themselves but is that not going to delay deployment and increase
operational expenses ? It would be interesting to see operators
viewpoint here.

> Subscription time mapping events, not failure time reachability.

Let me add one point raised in addition to my post to Lixia replies: the
BGP-based ALT (used for exchanging EID reachability) and BGP (used for
exchanging RLOC reachability) are not necessarily congruent. The latter
could flap while the former does not or vice versa. The result of this
is that one could reach the mapper but not subsequently the forwarder.
Not reaching the mapper may also be a problem in case of ongoing traffic
disruption.

thanks,
-dimitri.

---

From: David Meyer <[email-masked]>
Date: Mon, 4 Aug 2008 06:00:07 -0700

> right ? Does that not result in a dependence ? 

	It can be, but its only the address of the xTRs. So its
	not the same as renumbering an enterprise. The latter is
	what Vixie termed "CIDR Provider Lock", and it the
	"dependence" (as you put it) that folks are concerned
	about.

> operational expenses ? It would be interesting to see operators

	Managed CE is a great product for SPs (at least it was
	for every SP I worked at). That said (and I'm guessing
	here), managed CEs are likely to be a small fraction of
	the CE population; Kurtis made this exact point somewhere
	earlier in this thread.

> is that one could reach the mapper but not subsequently the forwarder.

	i.e, I query the DNS and get a name, but there is no
	reachability to the IP address that the name resolves to.

> Not reaching the mapper may also be a problem in case of ongoing traffic

	If you're saying "if the mapping system is broken, then
	the mapping system is broken", then I agree with that
	(independent of which mapping system your talking
	about). And The same can be said of the underlying
	connectivity, so I don't really understand your point.

	Dave

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Mon, 4 Aug 2008 17:27:16 +0200

Dino, 

> From: Dino Farinacci [mailto:[email-masked]] 
> Sent: Monday, August 04, 2008 12:49 PM
> > what is the
> other's reachability so they can set loc-reach-bits for 
> themselves as well as each other. 
>
> That has to happen at the site. Plus it scales better there.
> And I think you'll find PE-based xTRs as a non-starter. 
>
> I bet many operators would confirm this.

This is why i asked the question actually. I understand the pro's and
con's of CE-based TRs, i just ask in case of CE-based TRs about the
resulting operational/deployability aspects on the GROW list (which is
the right place to receive such feedback). 

> accept their PI prefixes.

I have heard different opinions during the meeting (also translated by
the replies on this list). I believe GROW is the place where such
assumption can be verified. 

> > failure

As a complement to my answer to Lixia & Darrel here, you have a
combination in the present case of the EID value space variation, and
BGP dynamics. as part of the latter we have BGP ALT (used for exchange
EID reachability), and the underlying BGP (used for exchange of RLOC
reachability) defining an overlay:

i) EID value space variation can result in triggered updates (e.g.
permanently remove a contiguous set [j,..,m] of intermediate EID from an
aggregate [a,..,z] results into two aggregates [a,..,i] and [n,..,z])

ii) with an overlay + out-of-band EID-to-RLOC resolution: the ETR once
receiving a MAP Request  does not check forwarding towards the RLOC it
sends back to the ITR. the ITR once receiving a MAP Reply can not rely
on egress RLOC as distributed by BGP to check its actual reachability.
thus, resulting in false positive and the system will stabilize once the
BGP RLOC will stabilize. As a consequence there is no improvement of the
BGP local stability (assuming RLOC are completely aggregatable) or BGP
global stability (otherwise).

iii) otoh you have the reverse issue, true negative. the BGP ALT is
flapping preventing EID reachability while the RLOC are actually
reachable via the BGP. to solve this BGP ALT must be at least as stable
as the underlying BGP.

Hope this clarifies that issue,
-dimitri.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 04 Aug 2008 08:51:07 -0700

Scott,

> anything above that) an including aggregate is advertised.

ALT uses BGP. What makes you say that removal of the aggregate is local 
to only one level up ?

You must be talking about some sort of EID allocation dream to have 
aggregate EIDs at each ALT box for all subtree ALT routers.

Cheers,
R.

---

From: Scott Brim <[email-masked]>
Date: Mon, 04 Aug 2008 17:01:34 +0100

On 8/4/08 4:51 PM, Robert Raszuk allegedly wrote:
> Scott,
> 
>> (1) The ALT is not meshy, and is aggregated.  An up/down event at an 
>> ETR affects its particular advertisement of a prefix, and would make 
>> it impossible for that ETR to answer a Map-Request, but that would 
>> only propagate to the next level up in the ALT.  Above that (if there 
>> is anything above that) an including aggregate is advertised.
> 

ALT is decoupled from the physical topology.  The BGP peerings are not 
between a router for a site and a router for an upstream or peer 
provider, but between a router responsible for a prefix and a router 
responsible for a shorter, including prefix.  Does that help?

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Mon, 4 Aug 2008 18:03:22 +0200

> From: David Meyer [mailto:[email-masked]] 
> Sent: Monday, August 04, 2008 3:00 PM
> Cc: Darrel Lewis (darlewis); [email-masked]; 
> [email-masked]
> Subject: Re: [lisp-interest] RE: [GROW] LISP@GROW
> 

I understand this: EID-to-RLOC resolution is distinct from RLOC
reachability. And the point raised goes exactly in that direction: BGP
ALT must be at least as stable as the underlying BGP otherwise it will
result in lowering the availability of the global system. OTOH, the
underlying BGP would be now subject to TR instability while it is still
the only reachability information forwarding can rely on. Hence, ISPs
need to cope with the resulting operational aspects.
 
> 	connectivity, so I don't really understand your point.

Not exactly. Assume Site 1 and 2 with ITR_1/ITR_2 and ETR_1/ETR_2 resp
(some of the figures presented at the GROW meeting are explicit on this
architecture). ITR_1->ETR_1 is used as primary. Disruption along the
ITR_1->ETR_1 path requires re-resolution to re-route traffic on
ITR_2->ETR_2 path.

For both these aspects: the question is: are these assumptions
operationally acceptable (so as to pass the deployability requirement).

Thanks,
-dimitri.

---

From: "Tony Li" <[email-masked]>
Date: Mon, 4 Aug 2008 10:00:28 -0700

Hi Darrel, 

|LISP's preference for CE based xTRs is based upon a few major
|factors.  First the we feel that the PE is already
|an overloaded box.  Second, and in my mind more important,
|a key benefit of loc-id split is provider independence.

While I respect the preference, history suggests that functionality will
move about to where economics dictates.  Many end user sites would greatly
prefer to outsource anything technical at all.  Thus, there will be SPs who
offer xTR functionality as an option.  I've seen nothing in the architecture
that prevents this, which is good.

Having the xTR functionality does NOT impair provider independence.  To
change to another provider, one does need to find another provider with xTR
in the PE, or you need to transition to a CE based xTR.  This is still a
level playing field, you're just revisiting your outsourcing decision.

In any case, my main point here is that the discussion is wholly moot, as
the market will decide where the functionality belongs.  Our job should be
to spec the functionality and then watch as things evolve.

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 04 Aug 2008 11:06:32 -0700

Scott,

> responsible for a shorter, including prefix.  Does that help?

I do understand that ALT is based on logical GRE links. But I find it 
hard to believe operationally that EID assignment, building ALT 
topology, strict hierarchy will be so good and as it is require to 
achieve ideal aggregation.

Cheers,
R.

---

From: "Tony Li" <[email-masked]>
Date: Mon, 4 Aug 2008 13:32:14 -0700

Hi Dino,

|If you put xTRs at the PE, they will never talk to each other when  
|deployed in different SPs. And you want them to know about each  
|other's reachability so they can set loc-reach-bits for themselves as  
|well as each other. That has to happen at the site. Plus it scales  
|better there.

This doesn't follow.  One could, for example, have a protocol or
configuration on the xTRs that establishes reachability (from the site side)
of each of the xTRs.  If there was an agent on the site that coordinated
this actively, it would only result in customer-provider interactions, which
could reasonably scale.

Tony

---

From: "Tony Li" <[email-masked]>
Date: Mon, 4 Aug 2008 13:34:39 -0700

|I do understand that ALT is based on logical GRE links. But I find it 
|hard to believe operationally that EID assignment, building ALT 
|topology, strict hierarchy will be so good and as it is require to 
|achieve ideal aggregation.

Moreover, even if it doesn instantaneously achieve ideal aggregation, what
is to prevent future entropy?  If a site wants to change its EIDs, it's
forced to renumber.  If it changes its ISP but doesn't change its EIDs, then
it's still locked into a 'mapping provider'.

It seems to me that this is exactly the same problem that we have today.
True, you've moved the problem from the bandwidth plane to the mapping
plane, but it is the same problem with the same consequences.

Tony

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 4 Aug 2008 16:26:46 -0700

> aggregate [a,..,z] results into two aggregates [a,..,i] and [n,..,z])

Well EID-prefix assignments will be relatively static. So I don't  
think we'll nearly have the flapping as the underlying network. And it  
seems the underlying network holds together fairly well with the issue  
you state above.

> sends back to the ITR. the ITR once receiving a MAP Reply can not rely

Right, it doesn't because it is really hard to do that without  
building a complex system.

> global stability (otherwise).

This is no different than we have today. Are you saying what we have  
today is not sufficient?

> reachable via the BGP. to solve this BGP ALT must be at least as  

The ALT will not flap, I don't know why you think that. We have  
logical tunnels between eBGP peers that are very resilient since there  
is a robust network underneath it.

And since the EID-prefixes are added and deleted based on subscription  
based contracts, the flap rate is more like months and years, then  
what you are thinking.

> Hope this clarifies that issue,

Well, not really.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 4 Aug 2008 16:28:09 -0700

> this actively, it would only result in customer-provider  

There is no chance in hell this will ever get deployed. If it would,  
people would have not objected in using PIM Rendezvous Points in other  
SPs. It's the same issue.

Dino

---

From: "Tony Li" <[email-masked]>
Date: Mon, 4 Aug 2008 16:50:46 -0700

|There is no chance in hell this will ever get deployed. If it would,  
|people would have not objected in using PIM Rendezvous Points 
|in other  
|SPs. It's the same issue.

Sorry, but I'm not following the analogy.  My bad for being peripheral on
PIM.

Did that require SP-SP coordination?  Or only SP-customer coordination?

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 05 Aug 2008 00:26:02 -0700

Hi Dino,

#1

I am afraid that what Tony suggested may be needed regardless ....

Let's imagine I have a site (home/office) with two xTRs xTR1 & xTR2 
connected to the upstream via DSL.

My DSL IP is auto-negotiated every 24h. That set by the provider. Both 
do it asynchronously.

The fact that I loose xTR1-out interface will not trigger the xTR2 to 
set loc-reach-bit indicating that xTR1 is down as from the IGP of my 
home it xTR1 is looking just fine.

    "An LISP+ALT router near the edge learns
    EID prefixes which are originated by authoritative ETRs, either by
    eBGP peering with them or by configuration."

#2

If xTR talks BGP to first ALT how is this less BGP or multihoming 
without BGP ?

#3

If xTR talks BGP to first ALT how are you dealing with my side changing 
it's IP dynamically ? AFAIK BGP would require some IP address to come up.

Or is the LISP/ALT solution only for those who would have static locator 
addresses ? I know that mobility is last on your slide but this is not 
mobility. After all my house does not move that fast :)))

Cheers,
R.

---

From: Scott Brim <[email-masked]>
Date: Tue, 05 Aug 2008 09:14:43 +0100

On 8/4/08 7:06 PM, Robert Raszuk allegedly wrote:
> |I do understand that ALT is based on logical GRE links. But I find
> it |hard to believe operationally that EID assignment, building ALT 

This sentence doesn't parse very well, but I'll guess at what you mean.
  The simple answer is that the ALT topology reflects EID assignment.
There is no question of "achieving ideal aggregation", or conflict
between EID assignment and BGP connectivity, because the BGP
connectivity itself reflects the aggregation.  Perhaps you could be
clearer about what you think the problem would be?

On 8/4/08 9:34 PM, Tony Li allegedly wrote:
> Moreover, even if it doesn instantaneously achieve ideal aggregation,
> what is to prevent future entropy?  

Again this phrase "achieve ideal aggregation".  Topology reflects 
addressing hierarchy, so there is no question.

 > If a site wants to change its
> EIDs, it's forced to renumber.  

That's a tautology.

> If it changes its ISP but doesn't
> change its EIDs, then it's still locked into a 'mapping provider'.

I'm guessing you're concerned about business relationships.  Locked in? 
  First, you are already "locked in", for example to your DNS provider, 
and somehow you survive.  Second, the possibilities for business 
relationships are wide open.  For example the lowest levels of the ALT 
could be provided by small enterprises (like DNS names), and the key 
higher levels by non-profits.  So I think it's wildly premature to 
assume the worst.

swb

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Tue, 5 Aug 2008 15:46:41 +0200

> Sent: Tuesday, August 05, 2008 1:27 AM
> seems the underlying network holds together fairly well with 
> the issue you state above.

"relatively static" is certainly dependent on needs/usage and which
entity will manage the EID space and its associated policy. also, it
suffices that an application requires permanence of the EID across a
sequence of RLOCs to invalidate this assumption.

> > thus, resulting in false positive and the system will 
> stabilize once  
> > the
> > BGP RLOC will stabilize. As a consequence there is no 
> improvement of  
> > the

I just point that no improvement is achieved in contrast to what has
been previously stated (and this because the bottomline is the same.) on
this specific goal.

> > reachable via the BGP. to solve this BGP ALT must be at least as  
> > stable as the underlying BGP.
> 
> logical tunnels between eBGP peers that are very resilient 
> since there is a robust network underneath it.

Even if (logical) links are failure-safe (at least at the extend they
can be recovered within a timeframe that does not impose any
notification/update or their recovery does not impose a topological
change) just think about failures of the leafs of the BGP-based ALT
distribution tree i.e. TR like indicated in response to Dave or root
failure since the ALT topology structure is a tree. 

> based contracts, the flap rate is more like months and years, then  

See above.

Thanks,
-d.

---

From: "tom.petch" <[email-masked]>
Date: Tue, 5 Aug 2008 10:34:17 +0200

----- Original Message -----
From: "Vince Fuller" <[email-masked]>
To: "Robert Raszuk" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 04, 2008 2:47 PM
Subject: Re: [GROW] LISP@GROW

>     draft-mathy-lisp-dht-00.txt

I don't recognise this one nor can I see it in Watersprings or the IETF.  Has it
been published?

Tom Petch

---

From: Vince Fuller <[email-masked]>
Date: Tue, 5 Aug 2008 07:22:03 -0700

> I don't recognise this one nor can I see it in Watersprings or the IETF.
> Has it been published?

Thanks for pointing this out.

It looks like this draft has, in fact, not been formally submitted as an
Internet Draft. A Google Search found it at:

    http://inl.info.ucl.ac.be/system/files/draft-mathy-lisp-dht-00.txt

I don't know what plans (if any) the authors have for submitting this; I
have CC'ed them (or at least the two of them who have email addresses listed
in the above document) on this message so that they can answer for themselves.

	--Vince

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 5 Aug 2008 16:43:22 +0200

Hi,

yes we never officially submitted the draft since we finished it  
after the cut-off date for the Philly meeting.

Since we still work at it, we will submit an improved version, but I  
have yet no estimation on the exact date.

Luigi

> in the above document) on this message so that they can answer for  

Luigi Iannone

[email-masked]

---

From: "Tony Li" <[email-masked]>
Date: Tue, 5 Aug 2008 09:50:50 -0700

| > If a site wants to change its
|> EIDs, it's forced to renumber.  
|
|That's a tautology.

So the implication is that LISP doesn't really protect the end user site
from having to renumber.

Per Lixia's presentation in RRG, she's asserting that protection from
renumbering is a hard requirement, as there has been no forward progress on
getting anyone to renumber in at least 13 years.

|> If it changes its ISP but doesn't
|> change its EIDs, then it's still locked into a 'mapping provider'.
|
|I'm guessing you're concerned about business relationships.  
|Locked in? 
|  First, you are already "locked in", for example to your DNS 
|provider, 
|and somehow you survive.  Second, the possibilities for business 
|relationships are wide open.  For example the lowest levels of the ALT 
|could be provided by small enterprises (like DNS names), and the key 
|higher levels by non-profits.  So I think it's wildly premature to 
|assume the worst.

There are numerous DNS providers, and changing your DNS server is a far less
costly proposition than renumbering by several orders of magnitude.  The
fact of the matter is that today, folks do not feel that DNS creates a
lock-in (there are plenty of registrars), but that addressing is a lock-in,
so they go get PI.

FWIW, I'm not assuming anything, I'm just trying to understand how things
will work if LISP is deployed.  So far, I see a few issues.

Tony

---

From: Scott Brim <[email-masked]>
Date: Tue, 05 Aug 2008 23:08:53 +0100

> So the implication is that LISP doesn't really protect the end user site

If a site wants to change its EIDs it renumbers, by definition.  Under 
what conditions do you believe that "wants to" and "has to" are the 
same?  I don't see any way you can get from the first statement to the 
second.

---

From: "Tony Li" <[email-masked]>
Date: Tue, 5 Aug 2008 15:23:23 -0700

|> | > If a site wants to change its
|> |> EIDs, it's forced to renumber.  
|> |
|> |That's a tautology.
|> 
|> So the implication is that LISP doesn't really protect the 
|end user site
|> from having to renumber.
|
|If a site wants to change its EIDs it renumbers, by definition.  Under 
|what conditions do you believe that "wants to" and "has to" are the 
|same?  I don't see any way you can get from the first statement to the 
|second.

Sorry, I wasn't being that precise.

My understanding is that for a site to have its EIDs aggregate, it must be
part of the virtual topology associated with a given 'mapping provider'.
And if they want to change mapping providers, they would need to change EIDs
and renumber their site.

Is that correct?

Tony

---

From: Scott Brim <[email-masked]>
Date: Wed, 06 Aug 2008 08:18:29 +0100

> And if they want to change mapping providers, they would need to change EIDs

Aha, the 'mapping provider' shibboleth.  I thought we dealt with that 
quite a while ago.  I wouldn't make any of those assumptions.  There are 
no restrictions on the business model for how ALT will be operated.  I 
cannot predict.  One would assume that the higher levels will be run by 
RIRs or something like them, but the lower levels are wide open and I 
expect some kind of small business competition there.
_______________________________________________
GROW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/grow

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 6 Aug 2008 14:06:43 -0700

> My DSL IP is auto-negotiated every 24h. That set by the provider.  
> Both do it asynchronously.
>
> The fact that I loose xTR1-out interface will not trigger the xTR2  
> to set loc-reach-bit indicating that xTR1 is down as from the IGP of  
> my home it xTR1 is looking just fine.

Yes, it will if you run an IGP. Other alternatives is to run HSRP or  
VRRP between them.

>   eBGP peering with them or by configuration."

And what does this reference have to do with your point?

> If xTR talks BGP to first ALT how is this less BGP or multihoming  

It is eBGP only over a GRE tunnel. The configuration is basically a  
neighbor and network command. And in the case of your DSL router, it  
wouldn't run BGP, it would be a low-opex router and the other side of  
the GRE tunnel would be the ALT router that originates your EID-prefix  
into the ALT.

> #3
>
> If xTR talks BGP to first ALT how are you dealing with my side  
> changing it's IP dynamically ? AFAIK BGP would require some IP  
> address to come up.

The eBGP peering session is on the IP address configured on the  
tunnel. That could be a private address. You are just establishing a  
TCP connection from your box to the ALT box on a directly connected  
subnet. The subnet for the GRE tunnel.

The point of LISP is to decouple locators. Those locators which are  
changing will only cause a change to your mapping entry and no other  
configuration.

> Or is the LISP/ALT solution only for those who would have static  
> locator addresses ? I

Absolutely not.

> know that mobility is last on your slide but this is not mobility.  
> After all my house does not move that fast :)))

That is good. Your house, like others, will put less stress on the  
mapping system.

Dino

>> There is no chance in hell this will ever get deployed. If it  
>> would, people would have not objected in using PIM Rendezvous  
>> Points in other SPs. It's the same issue.
>> Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 6 Aug 2008 14:09:46 -0700

> sequence of RLOCs to invalidate this assumption.

The site goes to get one more EID-prefix that is a PI prefix. So it  
will never renumber again. That means it won't ever change. It may get  
more EID-prefixes if the site needs more addresses but that would  
*add* a new prefix to the ALT.

> failure since the ALT topology structure is a tree.

I am saying those GRE tunnels will be more robust than physical links.  
An xTR at a site that loses it's physical connection can still keep  
it's eBGP ALT peering up because the GRE encap'ed packets will follow  
the physical path through the other xTR.

Dino

---

From: "Tony Li" <[email-masked]>
Date: Wed, 6 Aug 2008 14:16:03 -0700

Hi Scott,

|> My understanding is that for a site to have its EIDs 
|aggregate, it must be
|> part of the virtual topology associated with a given 
|'mapping provider'.
|> And if they want to change mapping providers, they would 
|need to change EIDs
|> and renumber their site.
|
|Aha, the 'mapping provider' shibboleth.  I thought we dealt with that 
|quite a while ago.

Sorry, what was the conclusion on that?

|  I wouldn't make any of those assumptions.  
|There are 
|no restrictions on the business model for how ALT will be operated.  I 
|cannot predict.  One would assume that the higher levels will 
|be run by 
|RIRs or something like them, but the lower levels are wide open and I 
|expect some kind of small business competition there.

Ok, but I'm less concerned about the business model than I am about the
eventual need to renumber.  Is that going to be a requirement or not?

Tony

---

From: Scott Brim <[email-masked]>
Date: Thu, 07 Aug 2008 07:23:06 -0400

> eventual need to renumber.  Is that going to be a requirement or not?

I suspect that any 'separation-class' approach (e.g. map-n-encap) 
_lessens_ the requirement for renumbering.
_______________________________________________
GROW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/grow

---

From: "Tony Li" <[email-masked]>
Date: Thu, 7 Aug 2008 09:00:50 -0700

|On 8/6/08 5:16 PM, Tony Li allegedly wrote:
|> Ok, but I'm less concerned about the business model than I 
|am about the
|> eventual need to renumber.  Is that going to be a requirement or not?
|
|I suspect that any 'separation-class' approach (e.g. map-n-encap) 
|_lessens_ the requirement for renumbering.

Agreed.  It shifts the need from being an impediment to changing ISPs to one
of being an impediment to changing mapping providers.  However, there still
seems to be a requirement to eventually renumber, and per Lixia's RRG
presentation, we really haven't found a decent way of renumbering.  Should
we presume that we will?  Or should we give up renumbering as a lost cause?

Tony

---

From: Scott Brim <[email-masked]>
Date: Thu, 07 Aug 2008 15:54:57 -0400

On 8/7/08 12:00 PM, Tony Li allegedly wrote:
> of being an impediment to changing mapping providers.  

Didn't you just say you were less concerned about business models?  But 
I guess you are concerned because you brought them up again.  Here are 
the two responses I gave to your concern about 'lock-in' previously:

On 8/5/08 4:14 AM, Scott Brim allegedly wrote:
>> If it changes its ISP but doesn't change its EIDs, then it's still
>> locked into a 'mapping provider'.
> 

On 8/6/08 3:18 AM, Scott Brim allegedly wrote:
>> My understanding is that for a site to have its EIDs aggregate, it 
>> must be part of the virtual topology associated with a given
>> 'mapping provider'. And if they want to change mapping providers,
>> they would need to change EIDs and renumber their site.
> 

Onward ...

 > However, there still

First, I don't see why there is a requirement for renumbering.
However, if there is, I have some faith in people's ability to overcome 
single obstacles.  If the only problem in the world were renumbering we 
would find a way to deal with it.

---

From: "Tony Li" <[email-masked]>
Date: Thu, 7 Aug 2008 13:08:49 -0700

Hi Scott,

|First, I don't see why there is a requirement for renumbering.

Again, renumber seems to be required if you change mapping provider and your
mapping has to aggregate.

|However, if there is, I have some faith in people's ability to 
|overcome 
|single obstacles.  If the only problem in the world were 
|renumbering we 
|would find a way to deal with it.

Well, faith is nice, but Lixia is correct in pointing out that we've needed
a way to renumber and haven't done anything significant on this front in 13
years.

Tony

---

From: Scott Brim <[email-masked]>
Date: Thu, 07 Aug 2008 16:25:30 -0400

> mapping has to aggregate.

If you're talking about ALT specifically, I can conceive of a scheme 
where you can have any 'mapping provider' to handle any prefix you might 
have.  Other map-n-encap schemes might vary.

---

From: "Tony Li" <[email-masked]>
Date: Thu, 7 Aug 2008 13:42:25 -0700

|If you're talking about ALT specifically, I can conceive of a scheme 
|where you can have any 'mapping provider' to handle any prefix 
|you might 
|have.  Other map-n-encap schemes might vary.

Yes, ALT is a fine example.

Ok, so spill...  What's this scheme?

Tony

---

From: Peter Schoenmaker <[email-masked]>
Date: Tue, 12 Aug 2008 11:23:12 -0700

> contiguity a possible/feasible scenario ?

Service providers must have significant business preasure to undertake  
and complete any forced customer renumbering.  The customers  
renumbering have four different reactions.

a.)  Customer says OK. Grins, bears it, and renumbers.  They may ask  
for help, consulting, and/or credit, but the business impact is minimal.

b.)  Customer finds a technical work around.  The most common was to  
use NAT to avoid renumbering, but also satisfy the service provider's  
requirements.  The customer lives with lack of reach-ability when  
their address space is reassigned to someone else.

c.)  Customer flights tooth and nail to retain the address space.   
Fights with the service contract, or purchases service from the  
company reclaiming the address space from the service provider, and  
other options to avoid renumbering.

d.)   Customer realizes that renumbering is a great time to shop for  
new service providers.  This is probably the worst for the service  
provider as it has the largest loss of revenue.

peter