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

[Dino Farinacci <[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 — 

Thank you for your extensive comments on the draft. The working group thanks you as well.

> 
>> 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”.

Yes, and in this context the destination Map-Version is the one that the destination assigns and increments, meaning the ETR.

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

Terminology level-set. A map-cache lives in an ITR. A mapping lives and is registered by an ETR. Mappings are stored in the mapping system and when ITR's resolve EIDs, they put the mappings in their map-cache. That is the authoriative definition from 6830bis/6833bis.

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

See above.

> (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.

Right.

> 
>>> 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”.)

In the EID-mobility draft, we have something called "data-driven SMRs". They happen if Map-Versioning is in use or not. And we made it a configuraiton parameter if they should be sent. And if so, carefully rated-limited (in total and per EID).

And the text above IS correct. Note that ITRs also RLOC-probe ETRs (the ones they have cached in their map-cache) so they can find out the latest destination version-number from the control-plane as well. So one would argue that you can drop packets silently between RLOC-probes just in case the ITR has old RLOC-set data.

So I wouldn't want to change the above text.

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

It has no relevant mapping entry, correct.

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

Note, it may be subtle but having different terms is really important. A map-cache entry is an entry that is more temporal than a mapping entry. The former is cached from a lookup and the latter is configured (or discovered ala draft-ietf-lisp-eid-mobiligy) and has longer lifetime.

Dino