Re: [lisp] AD Review of draft-ietf-lisp-6834bis-09

[Luigi Iannone <[e-mail]>]

HI Alvaro,

Thanks, we will wait until IETF last call is over and incorporate your comments and any other comment we receive.

Ciao

L.

 

> On 4 May 2022, at 22:24, Alvaro Retana <[e-mail]> wrote:
> 
> On May 4, 2022 at 2:54:43 AM, Luigi Iannone wrote:
> 
> 
> Luigi:
> 
> Hi!
> 
>> A new revision of the 6834bis has been just submitted.
>> This time considering all of your review!
>> It hopefully addresses all of your concerns.
>> Inline you can find detailed answers to the pints you raised.
> 
> I have some comments (below).  You can consider them with any other
> Last Call comments you may receive.  I am starting the IETf Last Call.
> 
> Thanks!!
> 
> Alvaro.
> 
> 
> ...
>>> (1) Duplication and overlap
> ...
>> [LI] Having a look to 6830bis:
> 
> This is being discussed in the other thread with Dino.
> 
> 
> 
> ...
>>> (2) Document Structure
> ...
>>> Also, I suggest moving §8 to an Appendix.
>> 
>> [LI] Re-organized as suggested (thanks).
> 
> Please mention the appendix in the Introduction so people know to go
> take a look.
> 
> 
> 
> ...
>>> 169 Source Map-Version number: This Map-Version number of the EID-to-
>>> 170 RLOC mapping is used to select the source address (RLOC) of the
>>> 171 outer IP header of LISP-encapsulated packets.
> 
> §3/§4 now include definitions for the Source/Dest Map-Version numbers,
> which are pretty much the same.  Given that these sections are now
> adjacent, I don't think we need to define these terms defined twice.
> 
> 
> 
> ...
>>> 304 If one or both of the above conditions do not hold, the ETR can send
>>> 305 a Map-Request either to make the ITR aware that a new mapping is
>>> 306 available (see Section 5.1) or to update the mapping in the local
>>> 307 EID-to-RLOC Map-Cache (see Section 5.2).
>>> 
>>> [major] Should this behavior be Normative (MUST/SHOULD)? The text
>>> currently says that "the ETR can send"; if the text doesn't require
>>> (or at least recommend) an action then it looks like this document
>>> just talks about carrying extra numbers around that don't serve a
>>> specific purpose. I believe that §10 makes a good case for an action
>>> to be specified.
>> 
>> [LI] Good point. Updated to a SHOULD.
> 
> After reading the rest of the text again, in §7.1/§7.2, I want to
> change my suggestion.  The text now says:
> 
> 324	   An ETR receiving a LISP packet with Map-Version numbers SHOULD check
> 325	   the following predicates:
> 
> 327	   1.  The ITR that has sent the packet has an up-to-date mapping in its
> 328	       EID-to-RLOC Map-Cache for the destination EID and is performing
> 329	       encapsulation correctly.
> 
> 331	   2.  In the case of bidirectional traffic, the mapping in the local
> 332	       ETR EID-to-RLOC Map-Cache for the source EID is up to date.
> 
> 334	   If one or both of the above predicates do not hold, the ETR SHOULD
> 335	   send a Map-Request either to make the ITR aware that a new mapping is
> 336	   available (see Section 7.1) or to update the mapping in the local
> 337	   EID-to-RLOC Map-Cache (see Section 7.2).
> 
> This information is redundant with §7.1/§7.2.  And the action is not
> always the one mentioned above: §7.1/§7.2 contain more details.
> 
> I think we can either remove the text, or provide a (non-normative)
> preview of what comes on the next two sections.
> 
> Suggestion>
>    An ETR receiving a LISP packet with Map-Version numbers checks
>    the following predicates:
> 
>    1.  The ITR that has sent the packet has an up-to-date mapping in its
>        EID-to-RLOC Map-Cache for the destination EID and is performing
>        encapsulation correctly.  See Section 7.1 for details.
> 
>    2.  In the case of bidirectional traffic, the mapping in the local
>        ETR EID-to-RLOC Map-Cache for the source EID is up to date.  See
>        Section 7.2 for details.
> 
> 
> Note that both §7.1/§7.2 say that the check "SHOULD" be done.  When is
> it ok to not check?  Why is the check only a recommendation and not
> required?
> 
> 
> 
> ...
>>> [major] "ETR MAY drop packets"
>>> 
>>> Why is this an optional action and not required? What should the ETR
>>> take into account when deciding if the packets are to be dropped or
>>> not?
>> 
>> [LI] The GW discussed this point. The outcome was to give the operator the
>> choice whether it prefers to drop the traffic for safety or take a risk and
>> avoid dropping traffic (quid to drop the inner packet at the final
>> destination).
>> 
>> However, SHOULD is more correct as assertion. The text has been updated .
> 
> ok.
> 
> The text now says:
> 
>        According to rate limitation policy defined in [I-D.ietf-lisp-
>        rfc6833bis] for Map-Request messages, after 10 retries Map-Requests
>        are sent every 30 seconds, if in the meantime the Dest Map-Version
>        number in the packets is not updated, the ETR SHOULD drop packets
>        with a stale Map-Version number, unless the traffic is considered
>        safe (e.g. in private deployments this can indicate an issue in the
>        ITR, but not malicious traffic).
> 
> "in the meantime ...the ETR SHOULD drop packets...unless the traffic
> is considered safe"
> 
> The ETR may continue sending Map-Request messages "forever" -- they
> will be rate limited.  Using "in the meantime" sounds as if there was
> an end, but the only end is if the Dest Map-Version number is finally
> updated and things go back to normal.
> 
> When is it ok for the ETR to not drop packets?  I understand that we
> want to give the operator a choice, but the "traffic is considered
> safe" example may open up more questions: what is a safe deployment,
> how is safety/security achieved/etc.
> 
> Suggestion>
>    According to the rate-limiting requirements defined in
>    [I-D.ietf-lisp-rfc6833bis], Map-Requests are sent every 30 seconds
>    after 10 retries.  If the Dest Map-Version number is not updated,
>    the ETR SHOULD drop those packets.  Operators can configure exceptions
>    to this recommendation, which are outside the scope of this document.
> 
> 
> 
> ...
>>> [major] "all packets...SHOULD be silently dropped"
>>> 
>>> Why is this action recommended and not required? When is it ok for
>>> the the packets to not be dropped?
>> 
>> [LI] like for a previous point, if the traffic is considered safe it can
>> avoid drop.
>> Text has been updated.
> 
> As above, let's avoid talking about "safe".
> 
> The rest of the paragraph makes the case that "this is not valid
> behavior with respect to the specifications," which is different than
> that case above when the ETR was still sending Map-Requests.  IOW, it
> seems to me that there is no "safe" scenario.
> 
> 
> 
> ...
>>> 396 2. The packet arrives with a Source Map-Version number greater
>>> 397 (i.e., newer) than the one stored in the local EID-to-RLOC Map-
>>> 398 Cache. This means that the ETR has in its EID-to-RLOC Map-Cache
>>> 399 a stale mapping that needs to be updated. A Map-Request SHOULD
>>> 400 be sent to get the new mapping for the source EID. This is a
>>> 401 normal Map-Request message sent through the mapping system and
>>> 402 MUST respect the specifications in [I-D.ietf-lisp-rfc6833bis],
>>> 403 including rate-limitation policies.
>>> 
>>> [major] "Map-Request SHOULD be sent"
>>> 
>>> Why is this action recommended and not required? When is it ok for
>>> the ETR to not send a Map-Request (in response to this event)?
>> 
>> [LI] It is now a MUST.
> 
> No...-10 still uses SHOULD.
> 
> 
> 
> ...
>>> [major] "the packet MAY be silently dropped"
>>> 
>>> Why is this action optional and not required? The rest of the
>>> paragraph talks about how this "case is not valid with respect to the
>>> specifications" -- I then don't understand why it would only be
>>> optional to drop the packet.
>> 
>> [LI] Correct, it is a SHOULD with explanation about exceptions.
> 
> If "not valid with respect to the specifications" it feels like there
> should be no exceptions.
> 
> 
> 
> ...
>>> [major] s/LISP header/LISP-specific header
>> 
>> [LI] Fixed.
> 
> There are still a couple of unchanged instances.
> 
> []