Subject: [lisp] Some comments on draft-11

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 05 Feb 2009 12:32:49 +0100

Hello,

I did a detailed review of the main parts of draft-11 and have several
comments. I have not yet reviewed the multicast nor the PTR drafts.

1. With draft-11, the maximum number of loc-reach bits is now set to 31.
This is likely to be sufficient for most deployments, but it this
maximum number of loc-reach bits will imply a maximum number of locators
 that can be placed inside a map-reply message ? This question also
relates to the maximum size of the map-reply message and thus the
maximum number of records that can be placed in this message if there is
no fragmentation.

2. The utilisation of the loc-reach bits implies an ordering of the
locators that serve a given EID prefix. Depending on how the mapping
reply is interpreted, there are two possible interpretations for the
ordering.

2a There is a single mapping reply for all the xTRs that serve a given
EID prefix. In this case, the ordering of all locators and the
corresponding loc-reach bits must be the same on all xTR. This requires
some synchronisation (not necessarily through a protocol, but perhaps by
saying that the locators are ordered in numerical order or some other
deterministic ordering) among the xTRs that serve the EID so that they
all use the same ordering.

2b There is a single mapping reply for each xTR that serves a given EID
prefix. In this case, the ordering of the locators is local to the xTR
and two xTRs that serve the same EID prefix can use a different
ordering. No synchronisation is required, but the ETR that receives
encapsulated packets from an ITR can only use the loc-reach bits
provided that it received a mapping reply from this ITR.

I think that this interpertation should be clarified in the draft.
Interpretation 2a requires some coordination among the xTR while
interpretation 2b does not.

3. The current draft allows a site to provide mapping replies at
different granularities, e.g. a mapping for 10.0.0.0/8 and another for
10.0.0.1/32.  When combines with the loc-reach bits, this creates
ambiguities if the same number of locators is not used in both mappings.

For example, consider a site that serves 10/8 (RLOCA and RLOCB) and
10.0.0.1/32 (with RLOCB only). If the ITR of this site sends packets
from EID source=10.0.0.1/32, will it use the loc-reach bits
corresponding to 10/8 or the loc-reach bits corresponding to 10.0.0.1/32
? It is impossible for the ITR to determine whether the remote ETR has
cached both mappings, only 10.0.0.1/32 or 10/8

The interactions between the different mapping granularities for the
same EID and the loc-reach bits should be discussed in more details in
the draft.

4. Map request and map reply messages

The format of the map request and map reply messages is currently fixed.
  This implies that it is difficult to add new information in the map
request and reply messages. It would be interesting to support some
additional TLVs to add more information in a flexbile manner to allow
the protocol to evolve.

5. Negative map replies

In the current draft, it is unclear how a node should react upon
reception of a mapping request for an EID whose mapping is unknown.
Apparently, as no negative reply is defined, it seems that the mapping
request is simply ignored.

In practice, a node should only receive such a request if there is a
misconfiguration somewhere. As misconfiguration happen, I think that the
mapping reply should be able to send a negative reply to inform the
sender of the error and let it react. These negative replies should of
course be rate limited.

6. Utilisation of the Weight

The current description of the weigth parameter appears to be very
strong to me. First, it indicates that if one RLOC has a non-zero
weigth, then all need to have a non-zero weight. What happens if an xTR
receives a mapping reply that does not conform with this rule ? Should
the non-conforming locators be ignored ?
Same question for the sum of the weights that must be equal to 100.
Instead of setting the sum to 100, why not decide that each locator
should receive w/sum(w) where the sum is computed over all the locators
that are considered to be reachable by the ITR and the ITR could be
allowed to replace any weight set to 0 in the mapping reply by any other
value..

I don't think that MUST should be used in this paragraph. A SHOULD would
be better.

7. Clock sweep

The proposed procedure requires many mapping replies and lots of
configuration changes. I don't think that this is the good approach to
solve this problem.

8. Solicit-map-request

I wonder whether the same result could not be achieve by using pure
control plane packets. For example, an ETR that wants to inform an ITR
of a new mapping could send an unsollicited mapping reply with the new
mapping to the ITR. Upon reception of the unsollicted mapping reply, the
ITR could then send a mapping request to obtain the new mapping. If this
mapping request is sent directly to the ETR, it can serve as an
acknowledgement for the unsollicited mapping reply sent earlier.

Olivier

-- 
http://inl.info.ucl.ac.be , UCLouvain, Belgium

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 9 Feb 2009 10:23:05 -0800

> comments. I have not yet reviewed the multicast nor the PTR drafts.

Thanks a lot for your comments Olivier. See my responses below.

> that can be placed inside a map-reply message ? This question also

Well the encoding in the Map-Reply does not have this restriction  
because the locator-set record is free flowing and the R-bit is used  
as the reachability bit. So if the loc-reach-bits in the packet header  
were not used, you could have more than 31 locators.

When the loc-reach-bits are used in the packet header and you have  
more than 31 locators per site, you just break up the number of  
locators across different EID-prefixes. This will probably be the case  
anyways since people will regionalize their EID-prefix assignments.

Also, if you use an anycast address as a RLOC/locaotor address, then  
you get more physical entrance points to your site for the cost of one- 
slot in the locator-set.

> maximum number of records that can be placed in this message if  

If the control messages exceed 1500 bytes, the packet is IP fragmented.

> reply is interpreted, there are two possible interpretations for the

Not "depending" on how the Map-Reply is interrupted. The spec says the  
first locator in the locator set is ordinal 0 and the last one is  
ordinal N. And that is how you address the bits from the LSB to MSB  
from 0 to N. So it is spec'ed how you should encode and decode it. It  
is not left up to the Map-Reply processor as an option.

> corresponding loc-reach bits must be the same on all xTR. This  

That is correct.

> all use the same ordering.

This is not a problem. In the prototype implementation, it was  
designed to type in each of your "ip lisp database-mapping" commands  
first in each xTR, then you enable LISP functionality by typing the  
configuration command "ip lisp itr" and "ip lisp etr". It's at this  
later point, that LISP becomes globally operational.

> provided that it received a mapping reply from this ITR.

This is not the way it works.

> interpretation 2b does not.

We will make it more clear. Thanks for the good point.

> ambiguities if the same number of locators is not used in both  

Yes they do. If there are a different set of locators for each EID- 
prefix, the encapsulator must do a longest match lookup for the  
database-mapping entry that applies.

> corresponding to 10/8 or the loc-reach bits corresponding to  

This would be the same if a site was multi-national and ARIN assigned  
it 153.16.1.0/24 and RIPE assigned it 153.16.128.0/24 and the site  
decided to use US RLOCs for the .1 and EURO RLOCs for the .128. In  
this case the ETR replies with a different locator-set for each and  
the ITR, when encapsulating data packet, must be consistent.

This is working in the prototype and behaves just fine.

> same EID and the loc-reach bits should be discussed in more details in

Will do. It is implicit because we do refer to this when calling it  
"per EID-to-RLOC mapping entry" which implies disjoint or overlapping  
EID-prefixes. But we will make it even more clear.

> additional TLVs to add more information in a flexbile manner to allow

We considered this. I personally have designed dozens of protocols  
with TLV encoding, so you are speaking to the choir. The problem here  
is that we don't know what parts need to be optional versus required  
so we decided to just introduce a new packet type.

I believe it is still early and we can revisit this later. But a new  
packet-type can be ignored just like a TLV you don't understand. It's  
the same concept. It's just a packaging issue.

> reception of a mapping request for an EID whose mapping is unknown.

I don't know what you quite mean here. Do you mean I'm an ETR and I  
receive a Map-Request for an EID that is not for my site?

> request is simply ignored.

There is a negative Map-Reply, it's just implicit. It's a empty  
locator-set. And we plan to have some future use for it.

> sender of the error and let it react. These negative replies should of

This depends on your mapping database service. In this case, to make  
this happen your LISP-ALT configuration would *also* have to be in  
error. Otherwise, the Map-Request would not arrive at the wrong place.

We have seen this case on the LISP network. What the implementation  
does, in the even, the Map-Request makes it to an ETR but the ETR does  
not have a database-mapping for the EID, it will drop the Map-Request  
and issue a local log message. This is an appropriate result because  
the source site will not reach it's intended destination and then a  
debug investigation will occur. It will be determined either the LISP- 
ALT configuration was hosed or the database-mapping entry was typed in  
error, *or* the database-mapping entry was not entered yet.

> the non-conforming locators be ignored ?

It can be left up to the implementation. Our implementation would do  
this for a 4-RLOC locator set:

RLOC1, priority 1, weight 20
RLOC2, priority 1, weight 20
RLOC3, priority 1, weight 20
RLOC4, priority 1, weight 20

There is 20% left over and not accounted for. So RLOC4 gets 40%.  ;-)

Note, this is a rough approximation on how load-splitting flows across  
the 4 RLOCs would occur.

I haven't done this but I could issue a log message indicating that  
received Map-Reply does not total all it's high-priority RLOCs to  
100%. Ditto for the case where it could exceed 100%.

> allowed to replace any weight set to 0 in the mapping reply by any  

I'm not following you I think. You want uneven weight support don't  
forget.

> I don't think that MUST should be used in this paragraph. A SHOULD  

Okay, I'll see what the other authors have to say about that.

> configuration changes. I don't think that this is the good approach to

No, it requires less because it only happens at the 24-hour, 1-hour,  
and 1-minute periods.

This *operational* technique is use for timing out DNS entries and  
sees to work pretty easily. We have received advice from many network  
operators about using this approach.

> mapping to the ITR. Upon reception of the unsollicted mapping reply,  

For security reasons we don't want an ITR to process unsolicited Map- 
Replies. And we want the nonce to be carried from SMR-packet, into Map- 
Request, into Map-Reply to reduce spoofing attacks.

> acknowledgement for the unsollicited mapping reply sent earlier.

If the Map-Reply is a probe or a solicitation for the ITR to send the  
Map-Request, and we are concerned about processing solicited Map-Reply  
contents, then the point of putting any data in the Map-Reply becomes  
useless. Hence, all we need is a single bit. And if data is going to a  
site, then you probably want to update it. The data-plane will tell us  
the last time packets are sent and received from such a site and what  
the input and output packet counts are per locator, so we know which  
sites to update sooner, in a rate-limited manner from the ETR with the  
changed mapping.

Dino