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

[Alvaro Retana <[e-mail]>]

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.

[]