Opened 10 years ago

Closed 9 years ago

#56 closed technical (duplicate)

ETR unreachability (review by Y. Rekhter)

Reported by: wmhaddad@… Owned by:
Priority: major Component: draft-ietf-lisp
Severity: - Keywords:


Consider the following example:




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

Change History (3)

comment:1 Changed 9 years ago by luigi@…

The first part of this issue is covered by section 6.6 of the current draft, while the second part is overlapping with issue #66.

comment:2 Changed 9 years ago by luigi@…

  • Resolution set to duplicate
  • Status changed from new to resolved

comment:3 Changed 9 years ago by luigi@…

  • Status changed from resolved to closed
Note: See TracTickets for help on using tickets.