Subject: [bess] Mirja Kühlewind's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 24 Oct 2018 05:28:22 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-bess-mvpn-expl-track-12: 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-bess-mvpn-expl-track/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

In section 9 (security considerations):
Thanks for discussing network load here! However, I find this sentence a bit
unsatisfactory:
   „The specification of counter-measures for this problem is outside the scope
   of this document.“
Isn’t there any easy way to make some more recommendations for counter measures
that could be discussed here? E.g. implement some rate limiting or filtering.
Or only accept LIR-PF request from preconfigured hosts (given that LIR-PF
support must anyway be pre-configured)? I’m not an expert on this topic and
therefore don’t know if any of such recommendations make sense, however, I
would quickly like to discuss if it is potentially possible to say more than
what’s current said. Thanks!

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Some other minor comments:
 1) section 2: „Use of this flag in the PTA carried by other route types is outside
   the scope of this document.  Use of this flag in the PTA carried by
   an S-PMSI A-D routes whose NLRI does not contain a wildcard is
   outside the scope of this document.“
Maybe you also want to say something like „The flag SHOULD be ignored in these cases.“..?

 2) section 3
s/The result (if any) is the match for tracking“/The result (if any) is the “match for tracking“/
(missing quotes)

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 25 Oct 2018 16:32:57 +0200

Hi!

Protecting the control plane is a topic that is wider than this document…or
even wider than “just for BGP” (as covered by rfc7454).  Additional
recommendations are given in both rfc7454 and rfc6192 — this document
should then have a reference to them.

My 2c.

Alvaro.

On October 24, 2018 at 5:28:55 AM, Mirja Kühlewind ([email-masked])
wrote:

unsatisfactory:

of this document.“
Isn’t there any easy way to make some more recommendations for counter
measures
that could be discussed here? E.g. implement some rate limiting or
filtering.
Or only accept LIR-PF request from preconfigured hosts (given that LIR-PF
support must anyway be pre-configured)? I’m not an expert on this topic and
therefore don’t know if any of such recommendations make sense, however, I
would quickly like to discuss if it is potentially possible to say more than