Subject: [lisp] #56: ETR unreachability (review by Y. Rekhter)

From: "lisp issue tracker" <[email-masked]>
Date: Tue, 20 Apr 2010 22:50:11 -0000

#56: ETR unreachability (review by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Consider the following example:

                  ETR1
   ITR
                  ETR2

 Originally both ETR1 and ETR2 claim to be RLOCs for EIDs 10.1.1/24
 and 10.1/16. So, when ITR sends Map-Request to ETR1 for 10.1.5.1,
 ETR1 returns both 10.1/16 and 10.1.1/24 as EID prefixes, with ETR1
 and ETR2 as RLOCs for these EIDs.

 Assume that at some later point ETR1 is no longer an RLOC for
 10.1.1/24, but still is an RLOC for 10.1/16, while ETR2 still is
 an RLOC for both 10.1.1/24 and 10.1/16. Would ETR1 be required to
 inform ITR that it is no longer an RLOC for 10.1.1/24 ?

 If not then assume that later on a site behind the ITR originates
 a packet for 10.1.1.1. Assume that the ITR selects ETR1 as the best
 RLOC for 10.1.1/24. So, the ITR sends the packet to ETR1.
 How would ITR ultimately decide to stop sending the packets destined to
 10.1.1.1 to ETR1 and instead switch to ETR2 ?

 If ETR1 be required to inform ITR that it is no longer an RLOC for
 10.1.1/24, then what mechanisms, other than the Solicited-Map-Request,
 ETR1 could use? If the only mechanism available is the
 Solicited-Map-Request, then this introduces its own set of problems,
 as follows.

 Since according to 6.5.2 the ETR "will solicit Map-Request from
 sites it is currently sending encapsulated data to, and only from
 those sites", how would that help to update the mapping if the ITR
 that has the old (incorrect) mapping is not the xTR to which the ETR
 sends the encapsulated data?

 Withdraw of a single EID prefix on the ETR may require this ETR to
 send a whole bunch of SMRs messages, in response receive a bunch
 of Map-Requests, and then send Map-Replies. And while doing this
 all the data traffic for that EID prefix is dropped on the floor.
 This has negative implications on the connectivity restoration time.

 Moreover, while the stated goal of Solicit-Map-Request is to control
 the rate an ETR receives Map-Requests messages, in the above scenario in
 order to reduce the connectivity restoration time the ETR has to send all
 these Solicit-Map-Requests messages as soon as ETR1 determines that it is
 no longer an RLOC for 10.1.1/24, which in
 turn would mean that it would receive a burst of Map-Requests causing
 potential congestion in the control plane, which could result in some of
 these Map-Requests being dropped. Would the ETR be required to re-send
 Solicit-Map-Request if it does not receive a corresponding Map-Request
 from the ETR to which it sent Solicit-Map-Request before?
 And even if Map-Request is not dropped, the corresponding Map-Reply
 could get dropped in transit. What would happen in this case?

-- 
Ticket URL: <http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/56>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues