Subject: Re: [lisp] Martin Duke's Discuss on draft-ietf-lisp-rfc6833bis-27: (with DISCUSS and COMMENT)

From: Albert Cabellos <[email-masked]>
Date: Sun, 20 Sep 2020 23:58:24 +0200

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
<[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp