Subject: [lisp] question on EID reachability (section 6.4)

From: Yakov Rekhter <[email-masked]>
Date: Fri, 20 May 2011 06:28:04 -0700

Folks,

>From the latest LISP spec:

 6.4.  EID Reachability within a LISP Site

   A site may be multihomed using two or more ETRs.  The hosts and
   infrastructure within a site will be addressed using one or more EID
   prefixes that are mapped to the RLOCs of the relevant ETRs in the
   mapping system.  One possible failure mode is for an ETR to lose
   reachability to one or more of the EID prefixes within its own site.
   When this occurs when the ETR sends Map-Replies, it can clear the
   R-bit associated with its own locator.  And when the ETR is also an
   ITR, it can clear its locator-status-bit in the encapsulation data
   header.

One possible solution proposed in the above is for the ETR to clear
the R-bit associated with its own locator in the Map-Replies. But
why would the ETR be sending Map-Replies in the absence of Map-Requests ?
And if the ETR sends Map-Replies in response to (received)
Map-Requests, then why would the ITR originate such Map-Requests
when the ETR loses its reachability to the site ?

Another solution proposed in the above is for the ETR to clear its
locator-status-bit in the encapsulation data header. But it applies
only when the ETR is also an ITR for the traffic going in the
opposite direction, which may, or may not be the case. What are the
procedures for indicating the loss of connectivity when this is not
the case. Moreover, even for the case where the ETR is also an ITR
for the traffic going in the opposite direction, wouldn't that
solution require the ETR to have some traffic going in the opposite
direction ? If yes, then how would the ETR get this traffic, given
that its connection to the site is down ?

Yakov.

---

From: Robin Whittle <[email-masked]>
Date: Sat, 21 May 2011 00:21:55 +1000

Hi Yakov,

I think this is one of LISP's fundamental problems.  The ITR needs to
find out quickly if an ETR can no longer reach the destination network -
so the ITR can tunnel packets to one of potentially multiple alternative
ETRs.

This can't be done by the alternative ETR sending something to the ITR,
for a number of reasons:  How could the alternative ETR know that the
first ETR cannot reach the destination network?  (Maybe it could find
out.)  How could the alternative ETR know all the ITRs which are
currently (however defined) sending packets to the initial ETR?  (There
are scalability problems with the first ETR emitting a body of data of
this kind to the alternative ETR.)  How can the first ETR securely send
the potentially very long message to the alternative ETR?  (Maybe there
is a way . . . )

As you noted, there's not necessarily a way the first ETR can alert the
ITR, unless it is assumed that every ETR which receives even a single
packet for a given destination network is required to remember the
addresses from all the ITRs these packets (seem to) come from - over
some time period such as ten minutes or whatever the caching time is for
map replies.  Then there would need to be rock-solid security
arrangements for the ETR sending appropriate messages to all these ITRs.

If something like this was implemented, then it would be a simple DoS
strategy to fire a bunch of short packets at the ETR, all as if they
came from different ITRs, so loading the ETR with the burden of
remembering all these ITR addresses and then having to do something with
this information if the destination network becomes unavailable.

This is part of the larger problem LISP has with each ITR being on its
own and having to figure out which ETR to send packets to.  I think this
has fundamental scaling problems.

As far as I know, the only way around these problems is to have the
detection of reachability done for the destination network by a
specialised company, who then decides when to change the mapping.  This
is according to whatever reachability detection arrangement and decision
algorithm the destination network specifies.  The mapping change needs
to be sent to the authoritative mapping servers which will then send
them in real-time (via caching mapping servers) to all the ITRs which
are currently sending packets to this destination network.  "Currently"
is defined by the caching time of map replies.

This is what I do with Ivip, via a tree-like structure of mapping
servers.  In the initial deployment, a typically global network of
authoritative mapping servers are provided by a company who is working
for the destination network - probably the company which provides the
destination network's "EID" address space, out of a large (short-prefix)
block which is advertised in the DFZ.  These companies also run a global
network of the Ivip equivalent of LISP's PTRs.

As the system becomes more widely adopted, caching mapping servers will
be provided by ISPs to serve the needs of their ITRs and of ITRs in
their customer networks.

I am not working on this project at present, but one day I will return
to it.

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

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 20 May 2011 12:20:11 -0700

> the R-bit associated with its own locator in the Map-Replies. But

You don't want to do this because you can't determine if the failure  
is for the entire EID-prefix. There will be site subnets that will be  
more specifics of the EID-prefix. Some will be reachable and some may  
not be. You don't want to cut traffic off to the ones that are  
reachable.

Just like we do today with routing protocols. We do not withdraw a  
upstream advertised prefix when one of its more specifics, determined  
from the IGP, becomes unreachable.

> why would the ETR be sending Map-Replies in the absence of Map- 

The ETR will still get Map-Requests because the Map-Server is load- 
splitting the forwarding of the Map-Request to each ETR that is  
registered for the same EID-prefix. And they all return the same  
locator-set information.

> when the ETR loses its reachability to the site ?

The ITR wants to reach the site, so it sends Map-Requests.

Now you bring up a new case that the ETR loses reachability to the  
site. Does that mean the link to the PE router went down? You have to  
be precise on which failure scenario you want to discuss.

If the all the ETR's site-facing interfaces go down, it can set the R- 
bit to 0 when sending Map-Requests.

And Robin, one ETR *can know* the other ETR cannot reach the rest of  
the site when a link-state routing protocol is used inside the site.

> only when the ETR is also an ITR for the traffic going in the

Right.

> the case. Moreover, even for the case where the ETR is also an ITR

Using the R-bit in *either* or *both* the Map-Reply it sends or the  
Map-Register it sends to the map-server.

> that its connection to the site is down ?

Note, when RLOC-probing is used and all site-facing interfaces are  
down, the RLOC-probe reply, which is a Map-Reply can have the R-bit  
set to 0.

Dino

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

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 23 May 2011 07:04:49 -0700

Dino,

> not be. You don't want to cut traffic off to the ones that are  

There is nothing in the spec that indicates that "you don't want to do this".
To the contrary, the following

                     One possible failure mode is for an ETR to lose
   reachability to one or more of the EID prefixes within its own site.
   When this occurs when the ETR sends Map-Replies, it can clear the
   R-bit associated with its own locator.  

clearly allows you to do this (to clear the R-bit).

So, the spec has to be fixed to address this.

> be precise on which failure scenario you want to discuss.

Yes, the link between the site and the ETR/PE router went down. And
prior to this link going down the ITR got (via Map-Reply) the mapping 
from that PE/ETR.

> bit to 0 when sending Map-Requests.

What would trigger the ETR to send Map-Requests when its link to the site 
goes down ?

> the site when a link-state routing protocol is used inside the site.

And when a non link-state routing protocol (e.g., RIP) is used
inside the site, one ETR may *not* know the other ETR cannot reach
the rest of the site.
  
> > only when the ETR is also an ITR for the traffic going in the

So, one can not rely on locator-status-bit when the ETR is not also
an ITR for the traffic going in the opposite direction. 

> Map-Register it sends to the map-server.

Wrt setting the R-bit in the Map-Register, how would it help the ITR
(that already received the mapping from the ETR) to discover that
the ETR can no longer reach the EID ?

Moreover, if the R-bit in the Map-Register is set to 0, then when
some other ITR requests mapping for the EID, and gets back a Map-Reply
with the ETR as an RLOC and the R-bit set to 0, would this other
ITR have to wait for the TTL of the mapping to expire before using
the ETR as the RLOC (which would be 24 hours with default TTL) ?

> down, the RLOC-probe reply, which is a Map-Reply can have the R-bit  

That still does not answer my question. Namely, if one relies on
setting the locator-status-bit in the traffic going from the
ETR to the ITR, then how would the ETR get this traffic, given
that its connection to the site is down ?  

As if not, then one can not rely on the locator-status-bit to
determine whether the ETR lost its connectivity to the site, and
therefore the *only* possible mechanism for an ITR to determine
this is the RLOC-probing. With this in mind the following should
be added after the first paragraph in 6.4:

  Another possible failure mode is for an ETR to lose connectivity
  to the site (e.g., due to the link failure between the ETR and 
  the site). The only mechanism specified in this document to
  detect such failure is RLOC-probing.

Yakov

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 23 May 2011 08:38:48 -0700

> So, the spec has to be fixed to address this.

It is not in the spec for the reason I told John Scudder. We are  
experimenting and figuring the best way.

Yakov, we don't want to put text in the code speculating on solutions.  
That is why some things are vague. When we get some experience, we  
will be more than happy to add text to the spec.

Please remember this is an *Experimental* draft. It doesn't mean the  
experiments are over but still occurring.

And if you don't like the text above, sort it out with John Scudder.  
He asked us to put that in there. If you two can agree on the text, we  
will consider changing the above text.

> Yes, the link between the site and the ETR/PE router went down. And

What does this mean? Are you saying the ETR is on the PE router?

> prior to this link going down the ITR got (via Map-Reply) the mapping

I was assuming the ETR was on the CE. So we need to reset the problem  
statement. Can you please restate it? I am now confused.

> What would trigger the ETR to send Map-Requests when its link to the  

ETRs don't send Map-Requests. The discussion is all messed up. Please  
reset me so we can get back on track.

> inside the site, one ETR may *not* know the other ETR cannot reach

There are all sorts of combinations that could arise which we won't  
document in a protocol spec. You could be doing iBGP with RIP as the  
IGP. You could be doing keepalives among the xTRs *at the site*.

> an ITR for the traffic going in the opposite direction.

For setting such bits during encapsulation yes.

> the ETR can no longer reach the EID ?

I was referring to the R-bit in Map-Registers controls if a Map-Server  
should forward a Map-Request to that ETR. I brought that up because I  
thought you were saying that an xTR at a site shouldn't answer a Map- 
Reply if it has all its site-facing interfaces down.

But I don't know what to think now that I discovered you may be  
talking about the case where the ETR is in the PE router.

I can't reply to your text below since it won't be productive. The  
discussion will go in circles. So start a new email thread and please  
restate the problem and be clear on what type of LISP network element  
is where.

Thanks,
Dino

---

From: Robin Whittle <[email-masked]>
Date: Tue, 24 May 2011 01:50:56 +1000

Short version:  Yakov points again to the scalability problems with
                short Map Reply caching times and frequent "RLOC-
                probing" - which are the only mechanisms LISP
                provides for ITRs to be sufficiently responsive to
                changes in ETR liveness and ETR-site connectivity.

                As usual, answers from Planet LISP are avoidant of the
                fundamental nature of these problems.

                I think the only way to make a core-edge separation
                system (such as LISP, Ivip or whatever) sufficiently
                responsive is if reachability and mapping decisions
                are done outside the system - not by the ITRs at all -
                and if the mapping system is capable of sending Mapping
                Updates to all ITRs which need them in a second or two.

Hi Yakov and Dino,

> What would trigger the ETR to send Map-Requests when its link to the site 

I guess Dino meant to write something like "when responding to Map
Requests from the Map Server".

> inside the site, one ETR may *not* know the other ETR cannot reach

Does the LISP specification require all ETRs for a given EID prefix to
know about the reachability of the end-user network for that EID prefix
from all its ETRs?

If so, what sort of delay times might be acceptable?

AFAIK, LISP doesn't provide any mechanism for this communication between
two or more ETRs.  So if you require it, then this needs to be stated as
a responsibility of the end-user network.  Also, I think it needs to be
shown that this is a reasonable requirement that all end-user networks
can achieve in order to adopt LISP.

> an ITR for the traffic going in the opposite direction. 

Yes.

> the ETR can no longer reach the EID ?

As you noted below, this depends on how long the ITR caches the Map
Reply information and whether or not, and how frequently, it does "RLOC
Probing" (http://tools.ietf.org/html/draft-ietf-lisp-12#section-6.3.2)

> the ETR as the RLOC (which would be 24 hours with default TTL) ?

I haven't kept up with every change to the LISP spec, but I guess that
is the purpose of the TTL - to inhibit the ITR from bugging the Map
Server again.  So again the LISP designers are back to trying to solve
problems by shortening the caching time of Map Replies.

> that its connection to the site is down ?  

Indeed . . .

>   detect such failure is RLOC-probing.

or perhaps:

  . . . RLOC-probing is the only mechanism specified in this document
  to detect such failure in a shorter time than that specified
  by the ITR's caching of Map Replies.

RLOC-probing might work OK if there were not many ITRs sending packets
to a given ETR.  But it doesn't scale - so it is not something LISP can
rely upon.

Shortening the TTL of Map Replies which Map Servers send to ITRs is
likewise unscalable since it overloads the ALT (or whatever) system and
the Map Servers.

I think LISP was conceived on the assumption that it is possible - or
that it must be possible - for a scheme like this to work without Map
Servers and/or ETRs (whatever sends Map Replies to ITRs) having a means
of sending a Map Update to that Map Reply when the connectivity
situation changes.  This includes when an ETR dies, or comes alive
again, or when an ETR's link to the end-user network goes down or up.

In the absence of such a "Real Time Mapping Update" mechanism, the only
way ITRs could respond rapidly to any of these changes in connectivity
is one or both of:

  1 - Very short times for ITRs to cache Map Reply messages.

  2 - ITRs frequently probing connectivity by directly bugging the
      ETR with something like an "RLOC-Probe".

If one or both of these are implemented to the degree necessary to
ensure ITRs respond quickly, then the whole thing will NOT scale.

Short caching time leads to constant hammering of the Map Servers and/or
ETRs, and whatever mechanisms are used for ITRs to request and receive
this mapping.

ITRs hammering the hapless ETRs with "RLOC-probing" doesn't scale at all
when one ETR is getting packets from lots of ITRs, which will frequently
be the case.  Furthermore, the ITR could be sending packets for a bunch
of EID prefixes to the one ETR, so it should probe the ETR about every
one of these, leading to bulky and perhaps multiple probe and response
packets.

RLOC-probing would be a DoS vulnerability for ETRs.  ETRs can't tell
whether the probe packet comes from a genuine ITR or not.  So the
attacker can send a blizzard of packets, each apparently from an ITR at
a different address.  The ETR will dutifully send off responses to
whatever addresses these are.

The only way of making the system work, AFAIK, is to have exactly one
system test reachability of the end-user network via its various ETRs
and make decisions itself about how this should affect the mapping.
This means ETRs and beyond them the end-user network routers are not
handling an excessive volume of reachability probe packets.  It also
means the probing can be done with whatever protocols, security and
frequency the end-user network desires.

This removes all the reachability testing and map-change decision making
from the LISP, Ivip or whatever system.  End-user networks are required
to do this themselves, or to pay a company to do it for them.  It needs
to be done from outside the end-user's network, so it is best to pay a
specialised company to do it.

Three more things are required to complete the system:

   1 - ITRs can request mapping from either one centralised mapping
       system (Ivip in its original incarnation) or from the correct
       one of the multiple mapping systems - the one which handles this
       EID prefix (Distributed Real Time Mapping for Ivip and LISP:
       http://tools.ietf.org/html/draft-whittle-ivip-drtm-01
       Diagrams: http://www.firstpr.com.au/ip/ivip/drtm/).

   2 - The ITR caches the mapping for some time specified in the
       Map Reply packet, chosen by the Map Server.  10 to 30 minutes
       might be a good choice, but if the ITR's cache is overloaded
       then it will cache it for a shorter time if it is not sending
       data for this EID prefix.

   3 - Most crucially, the Map Server system needs to be able to
       securely and quickly (a few seconds at most) fan out Mapping
       Updates to all ITRs which are caching the Map Replies for
       whatever EID prefix has just had its mapping changes.  Ivip
       has always had this.  Its not hard - both the Map Replies and
       the Map Updates are secured by a nonce in the Map Request.
       This would not scale very well with ITRs directly requesting
       mapping from a few authoritative Map Servers, but if they
       do it through one or more layers of caching Map Servers,
       which pass on the Updates, fanning them out to multiple
       ITRs or other Caching Map Servers closer to the ITRs, then
       it can scale well and still work, typically in a fraction of
       a second.

The unscalable nature of LISP was obvious from the outset four years
ago.  Short caching times and/or frequent RLOC-probings - choose your
poison.

Furthermore, the LISP architecture monolithically integrates the
reachability and mapping decision making work with the mechanisms which
actually handle the traffic.  Ivip separates the reachability and
mapping decision making so it is the responsibility of the end-user
network, and does not need to be specified by the Ivip system itself.
LISP requires every ITR to figure out for itself which ETR to send
packets to, so all aspects of probing and decision making need to be
done by the ITRs individually, and need to be defined in the LISP spec.

 - Robin

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 23 May 2011 09:08:17 -0700

Dino,

[clipped...]

> restate the problem and be clear on what type of LISP network element  

As you asked, I started a new e-mail thread. The subject is "ETR 
connectivity to site - question on EID reachability (section 6.4)"

Yakov.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 23 May 2011 10:20:06 -0700

>                short Map Reply caching times and frequent "RLOC-

This is not true. The spec indicates echo-noncing and locator-status- 
bits can be used.

Short caching times are only required if you don't have enough memory  
in your xTR. Memory is cheap in CPE equipment, the negative comments  
about caching based systems are highly over-rated.

>                fundamental nature of these problems.

This is not true. The specs have been open and work in progress for  
4.5 years, dozens of authors and 100s of contributions and comments.  
We have to make tradeoffs, we want to be practical, we don't want a  
system to be overly complex.

>                are done outside the system - not by the ITRs at all -

There is nothing saying you cannot do it outside of the LISP  
architecture. But you still have to add the machinery somewhere.

>                Updates to all ITRs which need them in a second or two.

You just said that ITRs can't have big caches but the mapping system  
has to track anyone who has sent it a Map-Request?

Dino

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 23 May 2011 10:41:28 -0700

Dino,

> This is not true. The spec indicates echo-noncing and locator-status- 

In my e-mail I explained why relying on locator-status-bits may not
work.

> about caching based systems are highly over-rated.

Note that CPE is not the only places that would need to support
LISP.  Interworking between LISP-capable sites and the rest of the
Internet would require deployment of PxTRs, and these PxTRs will
be deployed by the ISPs. Would you also claim that the forwarding
table memory "is cheap" in the ISPs' routers ?

Yakov.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 23 May 2011 10:52:16 -0700

> In my e-mail I explained why relying on locator-status-bits may not

And there are cases it does work. See my email about RLOC-probing.

> table memory "is cheap" in the ISPs' routers ?

Depends on the equipment vendor.  ;-)

Dino

---

From: Alia Atlas <[email-masked]>
Date: Mon, 23 May 2011 14:04:59 -0400

> And there are cases it does work. See my email about RLOC-probing.

How are you suggesting that the RLOC-probing work in a scalable fashion?

Do you envision responding to RLOC-probes to be done in the forwarding
plane so that the ETR's control plane isn't impacted?  How could the ITR's
control plane impact be minimized?

A push model is always nice for learning about failures.  Otherwise, traffic
can be impacted for at least the delay between probes (in the worst case).
Are there assumptions about the locator-status-bits that depend upon application
traffic behavior?  E.g. if traffic is TCP, it has acknowledgements
that cause two-way
flow?   I'm not sure whether such assumptions are adequate for the case of
separate ITR and ETR?

Certainly, it would be very useful to narrow down functionality to a particular
set so the discussion can focus on that common functionality - and then expand
once that is understood.   Perhaps you could explain about the anticipated
traffic loss in reaction to a failure for a co-located ETR/ITR when traffic is
running over TCP between 2 LISP-sites?  Then we can go on to the other cases?

Thanks,
Alia

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 23 May 2011 11:11:00 -0700

> How are you suggesting that the RLOC-probing work in a scalable  

Work in progress.

> Do you envision responding to RLOC-probes to be done in the forwarding

No.

> control plane impact be minimized?

Work in progress. Want to help?

> A push model is always nice for learning about failures.  Otherwise,  

How do you scale pushing everything everywhere? You definitely won't  
have enough memory for that.

> traffic behavior?  E.g. if traffic is TCP, it has acknowledgements

No.

> running over TCP between 2 LISP-sites?  Then we can go on to the  

What? Perhaps you could make your question more clear and not so open  
ended.

Dino

---

From: Alia Atlas <[email-masked]>
Date: Mon, 23 May 2011 14:24:23 -0400

> Work in progress. Want to help?

:-) Thanks for asking.

> How do you scale pushing everything everywhere? You definitely won't have
> enough memory for that.

Well, the IGP does it by advertising changes & so really does BGP.
Theoretically & without much thought, presumably an ETR could notify a
Map-Server
that its EID-RLOC mapping has changed.  Then those notifications could be passed
up in summary.  Finally, a Map-Resolver could notify the ITRs it
serves (if known/registered)
of changes; of course, that would require some decent way of filtering
EID-prefixes of
interest by the Map-Resolver/ITR

> What? Perhaps you could make your question more clear and not so open ended.

Please describe a complete example of the subset of LISP where you believe that
this problem is handed properly and even ideally and describe the
traffic loss anticipated
by that.  Let's see if we have agreement on that case - and then we
can talk about the
others.

Alia

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 23 May 2011 11:31:30 -0700

> Well, the IGP does it by advertising changes & so really does BGP.

Alia, think the scale that DNS works at today. Could it scale if all  
that data was pushed around?

> that its EID-RLOC mapping has changed.  Then those notifications  

It does.

> up in summary.  Finally, a Map-Resolver could notify the ITRs it

That means the map-servers have to track all the map-resolvers in the  
world that are interested.

That means the map-resolvers have to track all the ITRs in the world  
that are interested.

> interest by the Map-Resolver/ITR

The changes are done with SMRs, so when a locator-set changes for a  
given EID-prefix, or it moves/roams, the current active sessions are  
the ones that get notified first. It is event triggered on a pair-wise  
conversation basis.

>>> set so the discussion can focus on that common functionality - and  
>>> then
>>> expand
>>> running over TCP between 2 LISP-sites?  Then we can go on to the  
>>> other
>>> cases?
>>

I don't know what "this problem" is. That is the problem. I can't  
answer a question I don't understand.

Dino

---

From: John Scudder <[email-masked]>
Date: Mon, 23 May 2011 11:32:43 -0700

Dino,

Since you mentioned me...

> will consider changing the above text.

Can you point to where I "asked you to put that in there"?  I did look through the mailing list archives pretty carefully and the closest I came up with was a couple of messages on April 23.  First:

	Date: 	April 23, 2010 1:05:07 PM EDT
	Message-Id: 	<[email-masked]>

where I wrote:

        Even if "we aren't going to spec that", at a minimum the spec
        ought to point out that this limitation exists and that
        solutions are considered out-of-scope.  Something like this:

        "Section X.Y  Site Partition

        "A site may be multihomed using two or more ETRs.  The hosts and
        infrastructure within a site will be addressed using one or more
        EID prefixes that are mapped to the RLOCs of the relevant ETRs
        in the mapping system.  One possible failure mode of such a
        deployment is for an ETR to lose reachability to one or more of
        the EID prefixes.  This architecture does not provide a solution
        for data to be reliably delivered to hosts within the site in
        this scenario; provision of such a solution is beyond the scope
        of this document."

And then a little later in reply to Noel:

	Date: 	April 23, 2010 3:51:16 PM EDT
	Message-Id: 	<[email-masked]>

>>         at a minimum the spec ought to point out that this limitation
>>         exists a and that solutions are considered out-of-scope.
>>         Something like this:
> 
>         'currently out of scope'... This is the Experimental protocol,
>         not the Proposed Standard... :-)
> 
>>         "This architecture does not provide a solution for data to be
>>         reliably delivered to hosts within the site in this scenario;
>>         provision of such a solution is beyond the scope of this
>>         document."
> 
>         Make it "not currently provide" and I at least would be OK with
>         that.

        If you like it better that way it's OK:

        "This architecture does not currently provide a solution for
        data to be reliably delivered to hosts within the site in this
        scenario; provision of such a solution is beyond the scope of
        this document."

While this is generally related to the quote above, what I proposed is simply to identify the issue.  You and Yakov are discussing text about a proposed solution to that issue.

Can you clarify exactly what it is that I'm supposed to sort out with Yakov?

Thanks,

--John

---

From: Alia Atlas <[email-masked]>
Date: Mon, 23 May 2011 14:40:01 -0400

On Mon, May 23, 2011 at 2:31 PM, Dino Farinacci <[email-masked]> wrote:
> Alia, think the scale that DNS works at today. Could it scale if all that
> data was pushed around?
>
> That means the map-servers have to track all the map-resolvers in the world
> that are interested.
>
> That means the map-resolvers have to track all the ITRs in the world that
> are interested.

Yup - it works if map-resolvers are always co-located with map-servers.  Also,
an ITR could register with the particular Map-Resolver(s) it uses.  As I
said, it's an off-the-cuff idea - I'm not trying to solve it in
detail, but I do think it is
solvable.

> The changes are done with SMRs, so when a locator-set changes for a given
> EID-prefix, or it moves/roams, the current active sessions are the ones that
> get notified first. It is event triggered on a pair-wise conversation basis.
>
> I don't know what "this problem" is. That is the problem. I can't answer a
> question I don't understand.

When the link between a CE and its site fails so that the CE ETR can no longer
reach all or part of its advertised EID-prefix, how long does traffic
loss occur and how
is it recovered?

Alia

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 23 May 2011 11:40:51 -0700

With all due respect John, I am not going to dig through this.

We have been working on this experimental spec for 4.5 years and we  
have seen comment after comment, we have seen contributions and  
changes on top of contributions. We spent at least since 6 months  
alone refining the definition of EID and EID-prefix to death.

If I misrepresented you I am sorry. But the section was put in based  
on you bringing up this issue.

Dino

On May 23, 2011, at 11:32 AM, John Scudder wrote:

>>>>> EID
> Can you point to where I "asked you to put that in there"?  I did  
> look through the mailing list archives pretty carefully and the  
> closest I came up with was a couple of messages on April 23.  First:
>
> While this is generally related to the quote above, what I proposed  
> is simply to identify the issue.  You and Yakov are discussing text  
> about a proposed solution to that issue.
>

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 23 May 2011 11:44:58 -0700

Dino,

> > How are you suggesting that the RLOC-probing work in a scalable  

That should be documented as an open issue in the LISP spec.

> > plane so that the ETR's control plane isn't impacted?  How could the  
> > ITR's control plane impact be minimized?
> 
> have enough memory for that. From earlier e-mail:

Dino> Memory is cheap in CPE equipment, 
 
Yakov> Note that CPE is not the only places that would need to support
Yakov> LISP.  Interworking between LISP-capable sites and the rest of the
Yakov> Internet would require deployment of PxTRs, and these PxTRs will
Yakov> be deployed by the ISPs. Would you also claim that the forwarding
Yakov> table memory "is cheap" in the ISPs' routers ?

Dino> Depends on the equipment vendor.  ;-)

Since as you claimed above, memory is cheap for both CPE routers and
for the ISPs routers (at last for some vendor(s) known to you),
then why wouldn't we "have enough memory for that" ?

Yakov.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 23 May 2011 11:50:00 -0700

> That should be documented as an open issue in the LISP spec.

Already there:

6.3.2.  RLOC Probing Algorithm

...

    There are advantages and disadvantages of RLOC Probing.  The  
greatest
    benefit of RLOC Probing is that it can handle many failure scenarios
    allowing the ITR to determine when the path to a specific locator is
    reachable or has become unreachable, thus providing a robust
    mechanism for switching to using another locator from the cached
    locator.  RLOC Probing can also provide rough RTT estimates  
between a
    pair of locators which can be useful for network management purposes
    as well as for selecting low delay paths.  The major disadvantage of
    RLOC Probing is in the number of control messages required and the
    amount of bandwidth used to obtain those benefits, especially if the
    requirement for failure detection times are very small.

    Continued research and testing will attempt to characterize the
    tradeoffs of failure detection times versus message overhead.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 23 May 2011 11:53:47 -0700

> detail, but I do think it is

The map-servers have state for registered sites not what EID-prefixes  
those sites are sending to. That state would have to be maintained in  
the MR/MS.

Also, the map-resolver I use may not be the map-server I register to.  
I may want a map-resolver that is close to me to get my Map-Request on  
the database mapping system sooner where the map-server I used is  
based on my EID-prefix allocation.

Dino

---

From: John Scudder <[email-masked]>
Date: Mon, 23 May 2011 12:14:10 -0700

Dino,

As I'm sure you'll agree, "put in based on you bringing up this issue" is quite different from "[you] asked us to put that in there".  I think we are clear on that point now.  

This frees you to respond to Yakov's point on its own merits rather than referring him to something I didn't actually say.

--John

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 24 May 2011 09:37:09 +0200

Hi Alia,

On May 23, 2011, at 20:40 , Alia Atlas wrote:

[snip]

> Yup - it works if map-resolvers are always co-located with map-servers.  

This does not solve the scalability problem. Pushing all the information around is not the way to go.
Thin as well about the churn you will create. Each time a MS/MR has issues you will propagate that information to everybody.

> Also,

Definitively it is, but not the way you are suggesting. As Dino suggested above, DNS works because is an on-demand architecture, you ask for what you need. Having a proactive architecture, everybody tells you everything, will not scale.

Luigi

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 24 May 2011 10:53:08 -0700

Dino,

> > There is nothing in the spec that indicates that "you don't want to 
> > do this". To the contrary, the following
> >

As John said in his e-mail,

  As I'm sure you'll agree, "put in based on you bringing up this issue" 
  is quite different from "[you] asked us to put that in there". I think 
  we are clear on that point now.  

  This frees you to respond to Yakov's point on its own merits rather 
  than referring him to something I didn't actually say.

With this in mind we can now return to the issue raised in the above, 
and specifically to the following text:
  
   One possible solution proposed in the above is for the ETR to clear
   the R-bit associated with its own locator in the Map-Replies. 

Here is your comment on the above text:

I think this is a valid point, and given that I would suggest to
delete

   One possible solution proposed in the above is for the ETR to clear
   the R-bit associated with its own locator in the Map-Replies. 

Alternatively, if you want to keep this sentence, then please
add something like the following:

   Note that doing this may result in cutting traffic off
   to the EIDs that are still reachable.

Yakov.