On April 26, 2022 at 6:05:24 PM, Dino Farinacci wrote: > Alvaro, here are some responses. I cut out text I didn't need to comment on.
Thanks Dino -- some replies inline. > > [major] This is the only place, including rfc6830bis/rfc6833bis, where > > "proxy-reply mode" is used. Is this operation specified anywhere, > > maybe using a different name? This seems to be related to the > > Map-Server being able to offer non-authoritative Map-Replies -- please > > be specific. > > In 6833bis, we refer to the P-bit in the Map-Register as "proxy Map-Reply > bit". And occurs 11 times in 6833bis. Ah, ok. Please just be consistent with the terminology. Not everyone is as familiar with lisp -- including me, of course! :-) > > [major] What happens if one of these assumptions is not met? If the > > rest of the specification is followed (setting the I and N bits, etc.) > > what are the "failure scenarios" if the conditions are not met? > > When the N bit is not set, the message is processed like a regular > Map-Request (and state is not put in the subscription cache on the map- > server). That wasn't clear? Alberto? The assumptions I was referring to are these: 129 3. Deployment Assumptions 131 The specification described in this document makes the following 132 deployment assumptions: 134 (1) A unique 128-bit xTR-ID (plus a 64-bit Site-ID) identifier is 135 assigned to each xTR. 137 (2) Map-Servers are configured in proxy-reply mode, i.e., they are 138 solicited to generate and send Map-Reply messages for the 139 mappings they are serving. I think all I'm looking for is a short explanation that the pubsub will not work. Maybe something like this: If either assumption is not met, a subscription cannot be established and the network will continue operating without this enhancement. > > 144 4. Map-Request PubSub Additions > > ... > > 190 xTR-ID bit (I-bit): This bit is set to 1 to indicate that a 128 > > 191 bit xTR-ID and a 64 bit Site-ID fields are present at the end of > > 192 the Map-Request message. For PubSub operation, an xTR MUST be > > 193 configured with an xTR-ID and Site-ID, and it MUST set the I bit > > 194 to 1 and include its xTR-ID and Site-ID in the Map-Request > > 195 messages it generates. ... > > [major] "MUST set the I bit to 1 and include its xTR-ID and Site-ID" > > > > What should the receiver do if the I bit is set but the ID fields are > > not included? ... > > We will fix this. If the I bit not set, the Map-Request is not processed as a > subscribe-request. The question was the other way around: what if the I-bit is set but the IDs are not included? The lengths are handled by the IP/UDP header lengths, so the Map-Request (and the rest of the packet) may have the correct length while still having the I-bit set. I assume the answer is that the subscription cannot be processed and "normal" processing is done...but it should be stated in the document. > > 253 (3) The Map-Server MUST send the Map-Notify to one of the ITR-RLOCs > > 254 received in the Map-Request (which one is implementation > > 255 specific). > > > > [major] Does this need to be specified here? Where are Map-Notify > > messages sent to? I couldn't find a specific answer, but it seems to > > me that choosing a destination address should be pretty "basic"; i.e. > > something that should have been specified in the base spec. > > It is basic but there are many choices, *especially* in the presents of NATs. > You can send to one of the "Local" RLOCs or to the source IP address of the > Map-Request. If you want to get the message back to the xTR you need to use > the source IP address. Yes. The point was that choosing an address is not an issue that comes up only when sending Map-Notify messages when using pubsub -- it is a general issue. Any considerations should be mentioned in the "general" document (rfc6833bis) so that all extensions can benefit and don't have to include additional text about it. > > 331 When the xTR receives a Map-Notify with an EID not local to the xTR, > > 332 the xTR knows that the Map-Notify has been received to update an > > 333 entry on its map-cache. Processing of unsolicited Map-Notify > > 334 messages MUST be explicitly enabled via configuration at the xTR. > > 335 The xTR MUST keep track of the last nonce seen in a Map-Notify > > 336 received as a publication from the Map-Server for the EID-Record. If > > 337 a Map-Notify received as a publication has a nonce value that is not > > 338 greater than the saved nonce, the xTR drops the Map-Notify message > > 339 and logs the fact a replay attack could have occurred. To compare > > 340 two nonces, the xTR uses the serial number arithmetic defined in > > 341 [RFC1982] with SERIAL_BITS = 64. The nonce field space (64 bits) is > > 342 considered large enough to not be depleted during normal operation of > > 343 the protocol (e.g., assuming a fast publication rate of one Map- > > 344 Notify per EID-Record per Map-Server per second, the nonce field > > 345 space will not be depleted in 0.5 trillion years). The same > > 346 considerations discussed in Section 5.6 of [I-D.ietf-lisp-rfc6833bis] > > 347 regarding storing Map-Register nonces apply here for Map-Notify > > 348 nonces. > > > > [major] "Processing of unsolicited Map-Notify messages MUST be > > explicitly enabled via configuration at the xTR." > > > > rfc6833bis added the Map-Notify-Ack, but it doesn't require > > configuration anywhere to process unsolicited Map-Notify messages. > > IOW, this requirement is not in line with rfc6833bis. > > Its because in 6833bis all Map-Notify messages are always solicited. Yes, I missed that. Can it be assumed that if the xTR sends a "subscription request" it will accept unsolicited Map-Notify messages? This may be an implementation detail, but it seems to me that adding the extra configuration step is unnecessary if the xTR is requesting the information. Alvaro. _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
