Hi I´ve posted -28 updating the text following your comments, please find inline additional information:
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ On Tue, Jul 7, 2020 at 12:52 AM Martin Duke via Datatracker <nore...@ietf.org> wrote: > > Martin Duke has entered the following ballot position for > draft-ietf-lisp-rfc6833bis-27: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Two issues rise to DISCUSS level, IMO: > > Sec 5.7. Is the intent that the Map-Notifies are only retransmitted if they > are > unsolicited? If not, repeated Map-Registers could result in a storm of > Map-Notifies. > 6833bis specs that Map-Notifies are retransmitted when Map-Notify-Ack are not received. The behaviour of unsolicited Map-Notifies are NOT spec’ed in 6833bis, this is specified in draft-ietf-lisp-pubsub What 6833bis specs -per a review by Mirja- is that if an unsolicited Map-Notify is sent, then it will follow the guidelines of RFC8085 > Sec 7.1. I very well may have missed something, but it doesn't look like the > Map-Request is authenticated. So how can the ETR safely update its Map Cache > based on the information in the Map-Reply? > The Map-Request is just a query to an EID, and as such it is not authenticated. The Map-Reply carries the response to such query, an EID-to-RLOC mapping. This query is authenticated. The Map-Cache is updated based on the received EID-to-RLOC mapping. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Sec. 5. Please clarify that the 576B and 1280B limits include the entire IP > packet. Changed, thanks. > > Sec 5.4. Does the "weight" refer to the percentage of packets or bytes? > This is already clarified (IMO): "Weight is encoded as a relative weight of total unicast packets that match the mapping entry." > Sec 5.5. The first sentence should suggest that the Map Reply could return > multiple EID prefixes. The first sentence reads “A Map-Reply returns an EID-Prefix with…”, IMHO it is already clear. Thanks! > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
