Subject: [lisp] [Fwd: RE: LISP Reviews]

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 14 Apr 2010 22:29:12 -0400

Attached and copied below are the review comments prepared several weeks 
ago for us by Dimitri Papadimitriou, based on a request by our routing 
ADs.  THe comments were held up by the chairs, who apologise to Dimitri 
and the working group for the delay.

Please review and comment.

Thank you,
Joel (& Terry)

-------------------

Section 2:

Section 2 states “greatly improving aggregation and reducing the number 
of globally-visible, routable prefixes.” If aggregation is perceived as 
resolving scalability of routing in terms memory size then one should 
also be ready to assume that routing will result in higher stretch due 
to the characteristics of the Internet topology.

Section 2 states “More cost-effective multi-homing” but it is not stated 
what is actually meant by this statement and why the Loc/ID scheme as 
proposed would make multi-homing cost-effective.

Section 2 states “Mobility without address changing” but then “… or 
acquiring a new address based on the new network location.” These 
statements are contradicting each other.

Section 2 states “This draft describes protocol mechanisms to achieve 
the desired functional separation.” But separation between which 
functions ? If this statement is related to the separation between 
forwarding and control/routing, then it is defeated looking at i) the 
way RLOC reachability testing inter-twin control as part of the 
forwarding plane, and ii) the use of “Data Probes” forwarding date as 
part of the control plane of TR’s.

Section 2 the statement “This draft attempts to not compete or overlap 
with such solutions and the proposed protocol changes are expected to 
complement a host-based mechanism when Traffic Engineering functionality 
is desired.” raises the question if these solutions would still be 
complementary if TE functionality is not desired (this is not clearly 
stated in the document). On the other hand, the statement “Building the 
solution into the network will facilitate incremental deployment of the 
technology on the Internet.” should be further developed to explain why 
“network deployment” is considered as facilitating incremental deployment ?

Section 2 states “Some of the design goals of this proposal include:”
Which are the other goals ? there is only partial match with the design 
goals specified at RRG (the term “design goal” seems to have a different 
meaning) and it is unclear what changes are referring to. The statement 
“Minimize required changes to Internet infrastructure.” is vague. The 
statement “most customer site routers” under which condition the 
remaining fraction would have to change.

Section 2 states “7.  Avoid or minimize packet loss when EID-to-RLOC 
mappings need to be performed.” This condition is not addressed by the 
present proposal as the ITRs drop the packet(s) for which they have no 
EID-to-RLOC mapping for (as long as response to Map Request is not 
received and RLOC reachability “tested”).

Section 2 describes LISP variants depending on EID “routability” it 
would be appropriate to state “routability” refers to the core i.e. 
between ITR/ETR (as EID remain routable in “sites” otherwise there is no 
difference with host-based solutions)

Section 2. LISP 1.5 is assumed to make use of a “separate topology” also 
referred to as “alternative topology”. The key question is what is this 
topology ?

Section 2. LISP 3 assumes the existence of EID-to-RLOC database. How the 
existence of the databases is made aware to ITR. This is what determines 
the use of Data probes vs Map requests if both modes are supported.

Section 3:

Section 3. The definition of Provider Independent (PI) Addresses states 
what a PI is not instead of defining what a PI is. Also the document 
refers to EID prefixes and EID “blocks” what is a “block” and a 
“sub-block”?

Section 3. Definition of PA “LISP uses only topologically-assigned and 
aggregatable address blocks for RLOCs, eliminating this demonstrably 
non-scalable practice”. Provide a reference of such demonstration.

Section 3. ITR/ETR are described as routers while they are actually 
functions. Describe them as functions instead of “routers”.

Section 3. Definition of RLOC seems to be limited to ETR. Thus how ITR 
set the Source RLOC ? Section 7 (third bullet) makes this assignment 
even less understandable (the well-defined concept of VRF suddenly appears).

Section 3. Validation of “EID-to-RLOC mappings” in cache is defined as 
time-based only ? not on frequency of usage neither replacement ?

Section 3. The most important definition “EID-to-RLOC mapping lookup” is 
missing. In particular, how a ITR knows that the “incoming” destination 
address is part of an EID prefix ? More generally which event or 
condition triggers such lookup ?

Section 4:

Section 4 states “End-systems (hosts) only send to addresses which are 
EIDs. They don't know addresses are EIDs versus RLOCs but assume packets 
get to LISP routers,…”

Section 4 “an EID is only routable within the scope of a site” what is 
the scope of a site ?

Section 4 “This specification mandates that no more than two LISP 
headers get prepended to a packet.” Is there any mechanism preventing 
ITR (or TE ITR) to perform additional prepending ? and at which cost ?

Section 4 last paragraph of p13, refers to Section 8 concerning 
“flexible” placement of TR’s but does not respond to the question is 
there a deployment scenario that would not be supported.

Section 4.1 states “And the Data Probes are sent on the underlying 
topology (the LISP 1.0 variant) but could also be sent over an 
alternative topology (the LISP 1.5 variant) as it would in [ALT].” but 
in Section 2 does refer to [ALT] in LISP 3 context ?

Section 4.1 point 2 (same remark applies to Section 6) misses an 
important aspect how the mapping is performed the first time a new 
destination EID is seen at ITR and how subsequent maps are performed. It 
seems that a) EID-to-RLOC Cache must be first entirely scanned for each 
incoming packet at ITR (not only the first one) and then if there is no 
entry i) Data probe i.e. copy the destination EID value in the 
destination RLOC field (for LISP 1.5) or ii) originate a Map Request; 
otherwise use the corresponding RLOC value in the retrieved entry as 
destination RLOC. Needless to say that the delay is proportional to the 
number of entries in the cache. Nothing is being said if the cache is 
full (which entry should be replaced i.e. the least frequently used, the 
least recently used, or the least recently replaced entry). Nothing is 
said what happens if a more accurate EID prefix is being made available 
when a less EID prefix is being in use for a set of one or more RLOCs.

Section 4.1 point 3 states “The router is configured to "punt" the 
packet to the router's processor. See Section 7 for more details.” 
Looking at Section 7 there is no definition of “punting packets”.

Section 4.1 point 4 states “The LISP header is stripped so that the 
packet can be forwarded by the router control plane.” … forwarding 
traffic by routing control engines result in major drawbacks such as 
attacks, intrusions, etc. if the value encoded in the destination EID is 
one of the routers addresses.

Section 4.1 point 4 supposedly if there the destination EID is not found 
in the ETR's EID-to-RLOC database the packet gets dropped ? On the other 
hand how to prevent that a Map Reply is sent in response for EID prefix 
not reachable but statically configured in the ETR's EID-to-RLOC 
database. The case of ETR responding with “coarser EID-RLOC” mapping due 
e.g. to sub-segmentation is partially addressed in Section 6.1.5.1

Section 4.1 on “gleaned mapping” states “More complete information about 
additional RLOCs SHOULD be verified by sending a LISP Map-Request for 
that EID.” But there is no detail on what happens in case of mismatch 
between the “gleaned mapping” and the result of Map-Request (further 
details are provided in Section 6.2 last bullet but it does not respond 
to the question of mismatch).

Section 5:

Section 5.3 sets the nonce space to 2^24 but does not explain the space 
of applicability of this field as reading goes this value is limiting 
the number of bi-directional relationships between TR’s to this number.

Section 6:

Section 6.1.3 does not explain the result of refresh for which the 
received EID block would be larger than the requested one. Section 6.1.5 
assumes that a “that a Map-Reply may contain different EID-prefix 
granularity (prefix + length) than the Map-Request which triggers it.” 
But it doesn’t say if the associated RLOC shall be identical or not ?

Section 6.1.4 states “R: when this bit is set, the locator is known to 
be reachable from the Map-Reply sender's perspective.” Can author 
explain how a receiver can test its reachability i.e. what is the 
decision criteria to set the R bit ?

Section 6.1.5 where is the “Data Probe packet” format defined actually ?

Section 6.1.5 states “The RLOCs in the Map-Reply are the 
globally-routable IP addresses of the ETR but are not necessarily 
reachable; separate testing of reachability is required.” Section 6.3 
does not define any procedure actually and does not define any criteria 
for deciding when the RLOC is reachable or not. The key question is if 
the ITR persists in testing reachability and there is no criteria 
process by which such decision would stop, the traffic would be 
forwarded by means of the “separate/alternative topology” forever.

Section 6.2 introduces the terms client-side and server-side where are 
these terms defined ? without such definition readability of the section 
is low.

Section 6.2 RLOC reachability can determined and selected but there is 
no description on how the EID-to-RLOC selection is performed.

Section 6.3 proposes “encapsulated traffic” based procedures thus, if 
there is no traffic there is no RLOC reachability “test” possible. On 
the other hand, that section states certain “ICMP exchanges” are 
documented but reachability of RLOC does not mean availability of the 
associated EID. There no actual “EID-to-RLOC” testing procedure being 
defined in the document?

What is struggling here is that the “introductory” sections of the 
document refer to “functional” separations but all the techniques 
described in this document (and for RLOC reachability testing in 
particular) result in a complex inter-twin between control messaging as 
part of the forwarding plane and forwarding date as part of the control 
plane of routers. The latter is typical from Data Probes processing. If 
this is the design choice of LISP so let it be but 1) please proof it 
offers any better functionality compared to “current” design and 2) 
better cost/performance. It is far from obvious that the complexity 
concentrated at TR taking into the proposed design offers any real 
compelling argument. This may also defeat the argument stated in the 
introduction that “network deployment” is facilitated by network-based 
solutions.

Section 6.3 Point 1 what is the use of the “Loc-Status-Bits” if there is 
no return traffic (or more precisely no return traffic passing via this 
ETR i.e. the ETR is not an ITR for the source RLOC-EID pair). The ETR 
may process this information but never use it.

Section 6.3 states “Each ITR can thus observe the presence or lack of a 
default route originated by the others to determine the Locator Status 
Bits it sets for them.” This does not tell which technique to use when 
no default route are used at all (under “non-normal” circumstances … 
what should define normality in this context).

Section 6.3.1 states “This mechanism does not completely solve the 
forward path reachability problem as traffic may be unidirectional.” The 
forwarding path may simply be asymmetric (there is nothing that imposes 
reverse path reaching the source RLOC in case of dual attached sites). 
This shortcoming defeats this mechanism as an ITR is not “aware” of its 
neighboring ITR EID-to-RLOC mappings (connected to the same site). This 
mechanism can only be safely used if the RLOC pair between two sites is 
unique and remains unique.

Section 6.3.2 RLOC Probing by means of the “control plane” this opens 
the question of what is actually probed the “RLOC” or the EID-to-RLOC 
entries of the ETR’s database. The difference stems because the latter 
are static entries the liveness of the former are dependent on the 
incoming interface liveness. That is entries can be available in the 
database but if database entries are not in sync with the actual RLOC 
status there is no possibility to detect reachability of RLOCs by means 
of this mechanism.

Section 6.3.2 states “RLOC Probing can also provide RTT estimates 
between a pair of locators which can be useful for network management 
purposes as well as for selecting low delay paths.” If the exchanges are 
performed in the control plane it is not clear how such RTT/delay values 
can be derived for the forwarding path ? Can authors explain ? Authors 
should also check the accuracy of the estimate vs overhead generated by 
such technique.

Section 6.5 the section does not actually explain which messages are 
used to update the list of Loc-Reach or Loc-Status bits. If it is data 
traffic-driven then the mechanism is again dependent on the symmetry of 
the reverse path and the packet rate but also packet differential delays 
between packets. In the latter case, it is not clear how ITR could 
retrieve the correct RLOCs to be used if a sequence of 8 packets sent 
from ETR to ITR indicates 0,0,0,0,0,0,0,1 for a given RLOC (indicated as 
available at arrival of the 8th packet) is received as 1,0,0,0,0,0,0,0. 
The section makes a long digression on ordering locator set this is not 
the issue without a sequence number it will never be possible for the 
receiving ITR to determine the actual state of the EID-to-RLOC mappings 
at ETRs. This is even if ETR do not keep track of who requested mappings 
upon communication they should tell the state of their mapping but also 
their transition.

Section 6.5.2 is this technique mandatory or not (this is not specified 
in the text). Point 5 results in obvious situations where the ETR may 
never stop sending SMR messages. As there is no means a way to prevent 
that ITR use “old mappings” this result in a deadlock situation (a 
non-cooperating ITR prevents ETR to stop sending SMR messages).

Section 6.5.2 states “So an xTR will solicit Map-Requests from sites it 
is currently sending encapsulated data to, and only from those sites.” 
Thus instead of keeping track of ITR, ETR keep track of the encapsulated 
traffic ITR send. The mechanism is often cited but never explained e.g. 
over which time period is the ETR expected to determine the set of 
communicating ITR’s ?

Section 6.5.2 states “Map request” shall be rate limited … rather 
unclear: assume a single ETR sends one SMR message to 10 different ITRs 
how the 10 ITR will individually rate limit a single Map Request in 
response to this SMR message. It is thus worth specifying the flow 
control of SMR and Map-Request messages in a more systematic way to 
prevent ETR overloads.

Section 7: the first paragraph is a wish not a fact. As such it is 
doubtful what such paragraph actually brings in the context of a 
protocol architecture/specification.

Section 8:

Section 8.1 first paragraph, it is not the location of the source that 
determines the “size” of the working set of the EID prefix-to-RLOC cache 
but the number of EID prefixes this “source site” has to reach. The same 
issue occurs at ETR, small sites may have to be configured with a large 
list of EID-to-RLOC mapping entries. Next to this the granularity of the 
EID prefix allocation is also important.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 15 Apr 2010 12:00:27 -0700

> Attached and copied below are the review comments prepared several  
> weeks ago for us by Dimitri Papadimitriou, based on a request by our  
> routing ADs.  THe comments were held up by the chairs, who apologise  
> to Dimitri and the working group for the delay.

The working group chairs and the co-authors have discussed that we  
want to put updates in to reflect Dimitri's comments in the -08  
revision and not the -07 revision, since the -07 revision has a lot of  
changes and people may have already started reviewing them.

Dimitri, is that okay? Once we publish -07 (end of next week), we can  
turn around a -08 quickly and definitely before next IETF.

Dino/Dave/Vince/Darrel

> Section 2 states “greatly improving aggregation and reducing the  
> number of globally-visible, routable prefixes.” If aggregation is  
> perceived as resolving scalability of routing in terms memory size  
> then one should also be ready to assume that routing will result in  
> higher stretch due to the characteristics of the Internet topology.
>
> Section 2 states “More cost-effective multi-homing” but it is not  
> stated what is actually meant by this statement and why the Loc/ID  
> scheme as proposed would make multi-homing cost-effective.
>
> Section 2 states “This draft describes protocol mechanisms to  
> achieve the desired functional separation.” But separation between  
> which functions ? If this statement is related to the separation  
> between forwarding and control/routing, then it is defeated looking  
> at i) the way RLOC reachability testing inter-twin control as part  
> of the forwarding plane, and ii) the use of “Data Probes” forwarding  
> date as part of the control plane of TR’s.
>
> Section 2 the statement “This draft attempts to not compete or  
> overlap with such solutions and the proposed protocol changes are  
> expected to complement a host-based mechanism when Traffic  
> Engineering functionality is desired.” raises the question if these  
> solutions would still be complementary if TE functionality is not  
> desired (this is not clearly stated in the document). On the other  
> hand, the statement “Building the solution into the network will  
> facilitate incremental deployment of the technology on the  
> Internet.” should be further developed to explain why “network  
> deployment” is considered as facilitating incremental deployment ?
>
> Which are the other goals ? there is only partial match with the  
> design goals specified at RRG (the term “design goal” seems to have  
> a different meaning) and it is unclear what changes are referring  
> to. The statement “Minimize required changes to Internet  
> infrastructure.” is vague. The statement “most customer site  
> routers” under which condition the remaining fraction would have to  
> change.
>
> mappings need to be performed.” This condition is not addressed by  
> the present proposal as the ITRs drop the packet(s) for which they  
> have no EID-to-RLOC mapping for (as long as response to Map Request  
> is not received and RLOC reachability “tested”).
>
> between ITR/ETR (as EID remain routable in “sites” otherwise there  
> is no difference with host-based solutions)
>
> Section 2. LISP 1.5 is assumed to make use of a “separate topology”  
> also referred to as “alternative topology”. The key question is what  
> is this topology ?
>
> Section 2. LISP 3 assumes the existence of EID-to-RLOC database. How  
> the existence of the databases is made aware to ITR. This is what  
> determines the use of Data probes vs Map requests if both modes are  
> supported.
>
> Section 3:
>
> Section 3. The definition of Provider Independent (PI) Addresses  
> states what a PI is not instead of defining what a PI is. Also the  
> document refers to EID prefixes and EID “blocks” what is a “block”  
> and a “sub-block”?
>
> Section 3. Definition of PA “LISP uses only topologically-assigned  
> and aggregatable address blocks for RLOCs, eliminating this  
> demonstrably non-scalable practice”. Provide a reference of such  
> demonstration.
>
> Section 3. Definition of RLOC seems to be limited to ETR. Thus how  
> ITR set the Source RLOC ? Section 7 (third bullet) makes this  
> assignment even less understandable (the well-defined concept of VRF  
> suddenly appears).
>
> Section 3. Validation of “EID-to-RLOC mappings” in cache is defined  
> as time-based only ? not on frequency of usage neither replacement ?
>
> Section 3. The most important definition “EID-to-RLOC mapping  
> lookup” is missing. In particular, how a ITR knows that the  
> “incoming” destination address is part of an EID prefix ? More  
> generally which event or condition triggers such lookup ?
>
> Section 4:
>
> Section 4 states “End-systems (hosts) only send to addresses which  
> are EIDs. They don't know addresses are EIDs versus RLOCs but assume  
> packets get to LISP routers,…”
>
> Section 4 “an EID is only routable within the scope of a site” what  
> is the scope of a site ?
>
> headers get prepended to a packet.” Is there any mechanism  
> preventing ITR (or TE ITR) to perform additional prepending ? and at  
> which cost ?
>
> alternative topology (the LISP 1.5 variant) as it would in [ALT].”  
> but in Section 2 does refer to [ALT] in LISP 3 context ?
>
> destination EID is seen at ITR and how subsequent maps are  
> performed. It seems that a) EID-to-RLOC Cache must be first entirely  
> scanned for each incoming packet at ITR (not only the first one) and  
> then if there is no entry i) Data probe i.e. copy the destination  
> EID value in the destination RLOC field (for LISP 1.5) or ii)  
> originate a Map Request; otherwise use the corresponding RLOC value  
> in the retrieved entry as destination RLOC. Needless to say that the  
> delay is proportional to the number of entries in the cache. Nothing  
> is being said if the cache is full (which entry should be replaced  
> i.e. the least frequently used, the least recently used, or the  
> least recently replaced entry). Nothing is said what happens if a  
> more accurate EID prefix is being made available when a less EID  
> prefix is being in use for a set of one or more RLOCs.
>
> attacks, intrusions, etc. if the value encoded in the destination  
> EID is one of the routers addresses.
>
> Section 4.1 point 4 supposedly if there the destination EID is not  
> found in the ETR's EID-to-RLOC database the packet gets dropped ? On  
> the other hand how to prevent that a Map Reply is sent in response  
> for EID prefix not reachable but statically configured in the ETR's  
> EID-to-RLOC database. The case of ETR responding with “coarser EID- 
> RLOC” mapping due e.g. to sub-segmentation is partially addressed in  
> Section 6.1.5.1
>
> Section 4.1 on “gleaned mapping” states “More complete information  
> about additional RLOCs SHOULD be verified by sending a LISP Map- 
> Request for that EID.” But there is no detail on what happens in  
> case of mismatch between the “gleaned mapping” and the result of Map- 
> Request (further details are provided in Section 6.2 last bullet but  
> it does not respond to the question of mismatch).
>
> Section 5:
>
> Section 5.3 sets the nonce space to 2^24 but does not explain the  
> space of applicability of this field as reading goes this value is  
> limiting the number of bi-directional relationships between TR’s to  
> this number.
>
> Section 6:
>
> received EID block would be larger than the requested one. Section  
> 6.1.5 assumes that a “that a Map-Reply may contain different EID- 
> prefix granularity (prefix + length) than the Map-Request which  
> triggers it.” But it doesn’t say if the associated RLOC shall be  
> identical or not ?
>
> Section 6.1.4 states “R: when this bit is set, the locator is known  
> to be reachable from the Map-Reply sender's perspective.” Can author  
> Section 6.1.5 states “The RLOCs in the Map-Reply are the globally- 
> routable IP addresses of the ETR but are not necessarily reachable;  
> separate testing of reachability is required.” Section 6.3 does not  
> define any procedure actually and does not define any criteria for  
> deciding when the RLOC is reachable or not. The key question is if  
> Section 6.2 introduces the terms client-side and server-side where  
> are these terms defined ? without such definition readability of the  
> section is low.
>
> Section 6.2 RLOC reachability can determined and selected but there  
> is no description on how the EID-to-RLOC selection is performed.
>
> Section 6.3 proposes “encapsulated traffic” based procedures thus,  
> if there is no traffic there is no RLOC reachability “test”  
> possible. On the other hand, that section states certain “ICMP  
> exchanges” are documented but reachability of RLOC does not mean  
> availability of the associated EID. There no actual “EID-to-RLOC”  
> testing procedure being defined in the document?
>
> particular) result in a complex inter-twin between control messaging  
> as part of the forwarding plane and forwarding date as part of the  
> control plane of routers. The latter is typical from Data Probes  
> processing. If this is the design choice of LISP so let it be but 1)  
> please proof it offers any better functionality compared to  
> “current” design and 2) better cost/performance. It is far from  
> obvious that the complexity concentrated at TR taking into the  
> proposed design offers any real compelling argument. This may also  
> defeat the argument stated in the introduction that “network  
> deployment” is facilitated by network-based solutions.
>
> Section 6.3 Point 1 what is the use of the “Loc-Status-Bits” if  
> there is no return traffic (or more precisely no return traffic  
> passing via this ETR i.e. the ETR is not an ITR for the source RLOC- 
> EID pair). The ETR may process this information but never use it.
>
> Section 6.3 states “Each ITR can thus observe the presence or lack  
> of a default route originated by the others to determine the Locator  
> Status Bits it sets for them.” This does not tell which technique to  
> use when no default route are used at all (under “non-normal”  
> circumstances … what should define normality in this context).
>
> forward path reachability problem as traffic may be unidirectional.”  
> The forwarding path may simply be asymmetric (there is nothing that  
> imposes reverse path reaching the source RLOC in case of dual  
> attached sites). This shortcoming defeats this mechanism as an ITR  
> is not “aware” of its neighboring ITR EID-to-RLOC mappings  
> (connected to the same site). This mechanism can only be safely used  
> if the RLOC pair between two sites is unique and remains unique.
>
> Section 6.3.2 RLOC Probing by means of the “control plane” this  
> opens the question of what is actually probed the “RLOC” or the EID- 
> to-RLOC entries of the ETR’s database. The difference stems because  
> the latter are static entries the liveness of the former are  
> dependent on the incoming interface liveness. That is entries can be  
> available in the database but if database entries are not in sync  
> with the actual RLOC status there is no possibility to detect  
> reachability of RLOCs by means of this mechanism.
>
> between a pair of locators which can be useful for network  
> management purposes as well as for selecting low delay paths.” If  
> the exchanges are performed in the control plane it is not clear how  
> such RTT/delay values can be derived for the forwarding path ? Can  
> authors explain ? Authors should also check the accuracy of the  
> estimate vs overhead generated by such technique.
>
> used to update the list of Loc-Reach or Loc-Status bits. If it is  
> data traffic-driven then the mechanism is again dependent on the  
> symmetry of the reverse path and the packet rate but also packet  
> differential delays between packets. In the latter case, it is not  
> clear how ITR could retrieve the correct RLOCs to be used if a  
> sequence of 8 packets sent from ETR to ITR indicates 0,0,0,0,0,0,0,1  
> for a given RLOC (indicated as available at arrival of the 8th  
> packet) is received as 1,0,0,0,0,0,0,0. The section makes a long  
> digression on ordering locator set this is not the issue without a  
> sequence number it will never be possible for the receiving ITR to  
> determine the actual state of the EID-to-RLOC mappings at ETRs. This  
> is even if ETR do not keep track of who requested mappings upon  
> communication they should tell the state of their mapping but also  
> their transition.
>
> Section 6.5.2 is this technique mandatory or not (this is not  
> specified in the text). Point 5 results in obvious situations where  
> the ETR may never stop sending SMR messages. As there is no means a  
> way to prevent that ITR use “old mappings” this result in a deadlock  
> situation (a non-cooperating ITR prevents ETR to stop sending SMR  
> messages).
>
> Section 6.5.2 states “So an xTR will solicit Map-Requests from sites  
> it is currently sending encapsulated data to, and only from those  
> sites.” Thus instead of keeping track of ITR, ETR keep track of the  
> encapsulated traffic ITR send. The mechanism is often cited but  
> never explained e.g. over which time period is the ETR expected to  
> determine the set of communicating ITR’s ?
>
> unclear: assume a single ETR sends one SMR message to 10 different  
> ITRs how the 10 ITR will individually rate limit a single Map  
> Request in response to this SMR message. It is thus worth specifying  
> the flow control of SMR and Map-Request messages in a more  
> systematic way to prevent ETR overloads.
>
> Section 8.1 first paragraph, it is not the location of the source  
> that determines the “size” of the working set of the EID prefix-to- 
> RLOC cache but the number of EID prefixes this “source site” has to  
> reach. The same issue occurs at ETR, small sites may have to be  
> configured with a large list of EID-to-RLOC mapping entries. Next to  
> this the granularity of the EID prefix allocation is also important.
>
>
>
>
> <LISP Core review.rtf>_______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp