Re: [lisp] John Scudder's Discuss on draft-ietf-lisp-6834bis-12: (with DISCUSS and COMMENT)

[John Scudder <[e-mail]>]

Hi Dino,

Thanks for your comments. Let’s look at them in the context of the Map-Versioning draft this thread is about — 

> On Jun 2, 2022, at 6:14 PM, Dino Farinacci <[e-mail]> wrote:
> 
> 
>> I thought it was clear but let me restate. I’ll use an example since the first attempt wasn’t clear.
>> 
>> - Suppose an ETR E gets packet P, which dest map-version N.
>> - Suppose N is “greater than” the current map-version at the ETR.
>> - According to the spec, E silently discards P.
>> - I’m wondering if E could forward P according to its local mapping.
>> - Note that E would not generate a SMR.

I guess the section that relates to my example would be 7.1, "Handling Destination Map-Version Number”.

> There are a couple of issues with the description of this scenario. The ITR with a version N map-cache entry encapsulates to the ETR. The ETR doesn't necessarily have a map-cache entry

AFAICT all the text in Map-Versioning relates to ETRs that do have map-cache entries. I assume (but haven’t checked) that the base spec must already say what to do in the other case. I think in the context of §7.1 there’s a map-cache entry:

   When an ETR receives a packet, the Dest Map-Version number relates to
   the mapping for the destination EID for which the ETR is an RLOC.

Or is there a way for the ETR to be an RLOC for the destination EID but yet not have a map-cache entry for it?

> (because it is not encapsulated, it is decapsulating).
> 
> If the ETR is registering the EID with an older version number, it means it could have been idled. But if this is the case, the implementation should not register anymore (a mis-implementation of a deconfiguration event).

Clearly if the packet has a map-version number in the future of what the ETR has, *something* is wrong, yes. Could be what you said, could be something else.

>> Benefits:
>> + user traffic gets delivered.
> 
> If this ETR is not in the RLOC-set, and the ITR is currently out of date, and therefore is encapsulating to this ETR, the ETR should not forward the packet. It is likely the EID moved and hence this ETR is no longer the RLOC for it. So likely, the packet would be forwarded into a black hole.

… and if that were the case, it would be better for the network and no worse for the user if the ETR drops the packet outright, ok.

>> Drawbacks:
>> - lack of delivery can be a (very crude!) signal to the user that something is wrong, so maybe the problem would be less likely to be fixed.
>> - ?
> 
> The SMR should be sent

The Map-Version draft says the opposite, that the SMR should *not* be sent:

   2.  The packet arrives with a Dest Map-Version number newer (as
       defined in Section 6) than the one stored in the EID-to-RLOC
       Database.  Since the ETR is authoritative on the mapping, meaning
       that the Map-Version number of its mapping is the correct one,
       this implies that someone is not behaving correctly with respect
       to the specifications.  In this case, the packet carries a
       version number that is not valid and packet MUST be silently
       dropped.

(If an SMR were sent that wouldn’t be “silent”.)

> because the ETR is indicating to the ITR "dude, why are you sending traffic to me". And this typically happens when the EID moves, the ITR DOES HAVE an updated mapping but there is a train of packets in the network. The drops by the ETR, in a sense, "drain out the network".

I get that if the EID has moved away from the ETR then forwarding the packet would be futile. But in that case wouldn’t the ETR be in a different state as you describe earlier — it would have no relevant map-cache entry?

> I have found in practice, that ITRs get SMRs and look at their map-cache and don't find the source of the SMR in the RLOC-set, so it simply drops the SMR beliving the ETR is catching up on draining.
> 
> Dino

—John