Thanks Alberto. I can take care of the 6830bis and 6833bis changes if we need clarifications since it seems we have "opened" these documents for minor changes (per Luigi's email for 6834bis). I am waiting for Albert to give me the green flag for makingt the edits.
Dino > On Apr 27, 2022, at 3:04 PM, Alberto Rodriguez-Natal (natal) > <[email protected]> wrote: > > Hi Alvaro, Dino, > > I scanned through the comments and discussion and it seems that we’re all on > the same page. Thanks to both for the great suggestions. Give me some time to > provide some comments here, since I don’t have the bandwidth right now. I’d > also try to close vendor-lcaf before moving into PubSub. > > Thanks! > Alberto > > From: Dino Farinacci <[email protected]> > Date: Wednesday, April 27, 2022 at 9:04 PM > To: Alvaro Retana <[email protected]> > Cc: [email protected] list <[email protected]>, [email protected] > <[email protected]>, [email protected] <[email protected]> > Subject: Re: [lisp] AD Review of draft-ietf-lisp-pubsub-09 > > 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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
