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 <[email protected]> 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. > > [] _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
