Subject: Re: [trill] Working group LC on draft-ietf-trill-address-flush-03 (10/2 - 10/16)

From: R Parameswaran <[email-masked]>
Date: Wed, 11 Oct 2017 08:33:36 -0700

Hi,

I support the adoption/standardization of this draft, use case seems real.
Informal review per request, comments:

1. Could probably use a text review prior to the next step. One or
   two sentences can be tightened up:

   a. 2.2 item 3 ("The TLVs in an extensible Address Flush message are .. ")

   b. typo in 2.2.8 (type = 8 vs 7 in figure).

2. The draft gives a number of ways to specify an address flush e.g.
   various ways specify vlans, FGLs and MAC addresses (e.g. lists
   blocks, bitlists). Do we know if valid use cases for all these ways of
   specifying a flush? Also, for block specifiers what happens if there
   are overlapping blocks?

3. With a TLV length of 8 bits you cannot really specify more than
   192 FGLs and 42 MAC addresses. Are multiple TLVs of the same type
   allowed? Instead, would it make sense to have a longer TLV length
   field of say 16 bits?

4. It looks like a spoofed address flush can be used to mount a denial
   of service attack. If that is protected by encryption or by perimeter
   security, it might be good to explicitly call this out in Section 4,
   Security Considerations.

thanks,

Ramkumar

[trill] Working group LC on draft-ietf-trill-address-flush-03 (10/2 - 10/16)

Donald Eastlake <[email-masked]> Mon, 02 October 2017 23:11 UTCShow header
<https://mailarchive.ietf.org/arch/search/?email_list=trill#>

This begins a 2 week WG LC on draft-ietf-trill-address-flush-03.txt.
Please indicate if you think the draft is ready for publication and is
useful for TRILL deployments.

Thanks,
Donald
(WG Secretary for the Chairs: Sue Hares & Jon Hudson)
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

Replies:

   - [trill] 答复: Working group LC on draft-ietf-trill-address-flush-03
   (10/2 - 10/16)
   <https://mailarchive.ietf.org/arch/msg/trill/WPuFWUtnsbt_KsrM27dRPygXZBM>
   zhangdacheng <[email-masked]>

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 18 Oct 2017 12:42:45 -0400

Hi Ramkumar,

> Informal review per request, comments:
 Thanks for your support and thoughtful comments.

>    a. 2.2 item 3 ("The TLVs in an extensible Address Flush message are ..
I think the existing sentence is correct but perhaps a bit hard to
understand. It can be re-written to be a bit more clear.

>    b. typo in 2.2.8 (type = 8 vs 7 in figure).
Thanks for catching that.

>    specifying a flush? Also, for block specifiers what happens if there
For overlapping blocks, the address flush message should be considered to
be applicable to the data label or MAC address (depending on the type of
block) if that data label or MAC address appears in any one or more blocks.
This should be stated in the draft.

The different formats are provided for efficiency of encoding. A block is
most efficient if there are a number of consecutive values. A bit map is
most efficient if there are scattered values within a limited range. And a
list of single values if most efficient if there are widely scattered
values. There does not seem to be a statement saying this in the draft so
probably one should be added.

>    allowed? Instead, would it make sense to have a longer TLV length
Yes, multiple TLVs of the same type are allowed and their is no ordering
restriction on the TLVs. The draft is written to say what addresses are
flushed based on the cumulative result of parsing the TLVs so there is no
inherent difficulty in having multiple TLVs of the same type. But this
should be explicitly stated for clarity.

I think in most cases there will be one or a few blocks of VLANs/FGLs (or
MACs if the optional ability to specify MAC addresses is implemented) and
it would be rare to have large lists of explicit separate FGLs or MACs. And
if you really do have a lot of widely scattered FGL/MAC values you want to
specify, you are probably going to have to send multiple address flush
messages anyway due to MTU limitations. So I think an 8 bit TLV length
field is OK.

>    security, it might be good to explicitly call this out in Section 4,
Yes, that was meant to be implied by the comment about spoofed address
flush messages reducing "network efficiency" but it should be more clearly
stated. Also, the draft needs to make it clear that protection from
forged/spoofed messages is obtained by requiring unsecured Address Flush
messages to be ignored by receivers.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 <(508)%20333-2270> (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

> Donald Eastlake <[email-masked]> Mon, 02 October 2017 23:11 UTCShow
> header <https://mailarchive.ietf.org/arch/search/?email_list=trill#>
>
>  Donald E. Eastlake 3rd   +1-508-333-2270 <(508)%20333-2270> (cell)
>  155 Beaver Street, Milford, MA 01757 USA <https://maps.google.com/?q=155+Beaver+Street,+Milford,+MA+01757+USA&entry=gmail&source=g>
>  [email-masked]
>
> Replies:
>