I agree with all your suggestions and hope Alberto will use as input to the changes he makes for the next rev.
>> [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! :-) We will make the pubsub be consistent with the text from 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? > > 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. Agree. >> 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 Then there will be a parsing error and the last 128-bits/64-bits of the packet will be mistakenly processed as an xTR-ID/Site-ID. It means the sender did not conform to the spec. It is an implementation bug. > 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. No, that is not what happens. And I believe we DON'T need to change 6833bis for this. Or the pubsub draft. If the sender sets the I-bit, it is saying the the xTR-ID/Site-ID are at the end of the message. A receiver can detect the error because after processing that last EID-record, if there are no bytes left from processing the message, it can conclude that the I-bit was set errorneously. > >>> 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. Well not totally true. It is only used because an ITR-RLOC is included in a Map-Request, so a responding Map-Reply message should use it. Since a Map-Notify is a Map-Request ack for a subscribption requesst, its only these two types of messages that have this issue. All other "replies" to "query type messages" uses the source IP address from the query. > > >>> 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 Yes, but I'd argue about terminology. The Map-Notify is solicited because of the subscripton request. But the actual message is soliciting an acknowedge Map-Notify message. We call it unsolicited, because some time later, if there is an RLOC-change to an EID subscribed, the message will come without any message requesting it (i.e. it is event triggered). > implementation detail, but it seems to me that adding the extra > configuration step is unnecessary if the xTR is requesting the > information. Right. Dino > > > Alvaro. > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
