Alvaro, here are some responses. I cut out text I didn't need to comment on.
> [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. > [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? > 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. > > [nit] s/I bit/I-bit > > > [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? > > > [major] IANA hasn't assigned this bit yet. Please include a note with > a forward reference to ยง10. We will fix this. If the I bit not set, the Map-Request is not processed as a subscribe-request. > > 213 5. Mapping Request Subscribe Procedures > > 215 The xTR subscribes for changes for a given EID-prefix by sending a > 216 Map-Request to the Mapping System with the N-bit set on the EID- > 217 Record. The xTR builds a Map-Request according to Section 5.3 of > 218 [I-D.ietf-lisp-rfc6833bis] but also does the following: > > 220 (1) The xTR MUST set the I-bit to 1 and append its xTR-ID and Site- > 221 ID to the Map-Request. The xTR-ID uniquely identifies the xTR. > > 223 (2) The xTR MUST set the N-bit to 1 for each EID-Record to which the > 224 xTR wants to subscribe. > > [minor] If I understand correctly, it is ok for a Map-Request to have > the I-bit set (+ xTR-ID + Site-ID), but include no records with the > N-bit set. Is that right? If so, the mention of the N-bit in the > intro paragraph makes that a little confusing. Yes, correct. This is a regular Map-Request that is processed according to 6833bis procedures. > ... > 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. > ... > 279 If an xTR-ID is successfully added to the list of subscribers for an > 280 EID-Record, the Map-Server MUST extract the nonce and ITR-RLOCs > 281 present in the Map-Request, and store the association between the > 282 EID-Record, xTR-ID, ITR-RLOCs and nonce. Any already present state > 283 regarding ITR-RLOCs and/or nonce for the same xTR-ID MUST be > 284 overwritten. > > [major] ...and a Map-Notify MUST be sent, right? The specification > of the subscription seems incomplete. Yes, it must so the xTR knows the subscribe-request made it to the map-server. > 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. Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
