Hi Ramkumar,
On Wed, Oct 11, 2017 at 11:33 AM, R Parameswaran <[email protected]>
wrote:
> Hi,
>
> I support the adoption/standardization of this draft, use case seems real.
> Informal review per request, comments:
>
Thanks for your support and thoughtful 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 ..
> ")
>
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.
> 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?
>
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.
> 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?
>
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.
> 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.
>
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 protected]
> thanks,
> Ramkumar
> [trill] Working group LC on draft-ietf-trill-address-flush-03 (10/2 -
> 10/16)
>
> Donald Eastlake <[email protected]> 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 <(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 protected]
>
> 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 protected]>
>
>
_______________________________________________
trill mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trill
