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

Donald Eastlake <> Wed, 18 October 2017 16:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 35EA913234B for <>; Wed, 18 Oct 2017 09:43:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dqXiEqpNAh9q for <>; Wed, 18 Oct 2017 09:43:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A84FE1321CB for <>; Wed, 18 Oct 2017 09:43:01 -0700 (PDT)
Received: by with SMTP id j126so9985361oib.8 for <>; Wed, 18 Oct 2017 09:43:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RJiwIzgGneD5vM0SYSnJLpupisYAG1jCxgliEseoEPs=; b=gx0PXUG/S95Z6PPhls1z7b/212oe7C2bHViIyyiZS83hAp7zVVjf2/0bFusFjAYkB5 S/YfR7mr8Kc1tcHuBJFLWt4+BqWYNyGPFZuxsrc9V4sRxZrstqC51+VNbbSHS46aI4G2 zIAS/+XTM+yYmTtPdI/aEg66xd7ZZGOxGrEDhwls+k3TzwPrZH5HaCGWNIqWMp6LjCCY v9OtpV9OVK7vWX9VsBuzLQCrVdVTxHAtGC/gchmIuqlRFvj35Zm2LzjQNZvfqK4x1kCH nEgc97tC/hJJQT5yMwsVLvss7tuvVq/cjWC/IIVcIZBzG+R35BTge+ELvHIo7g5lUtVB yL+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RJiwIzgGneD5vM0SYSnJLpupisYAG1jCxgliEseoEPs=; b=rOfkJwqiFZN+QwcYXtpsNf1bX1QcyzSv1C0jsNY04XOERrBcG7phuCESe+VGQNXZnF KxEMvkrGWBYnkQYz4Vgm6c/4oWWYZe+cGQPYK3SIH2H8zLR1JSAgFYUeKpbcuWB3/Z9l pdjksnhm9NhwCbjG6nTmZZbh8Z6Bp+W5RXsqPTAozEqtDO0nBQIofBHnU0UVZ3QCaLQV Q0/bJDEZtXhasA8qldMic/iqJdaj3sMU/qdKpjNBFjTfXRVsUcPZAFxGnVK+wb4iSaC5 VG/Sf7Wh0bQlGs0KwwR9zQup3o9Tb06GQLYGT4HdHj5Yhy6/HR2QiH1JKwtcCD3uc2g/ CB1w==
X-Gm-Message-State: AMCzsaVzLgIgx3lLKIPG/RhDf2n6thbsSqF3KS8xnWyJdNpd7A8XL3P4 Qh+ca2ZYiMnNn5DDSVOymcL8aEyhre68W4N+NB8=
X-Google-Smtp-Source: ABhQp+Q9yFNKX5EuV/LuKJMQ2eOaWrL5GA0JBCr6zrKGLMBs/2pR5jWsibbukgDLwP21n3Ust/h5JzhSr0dTP/35DTY=
X-Received: by with SMTP id w73mr8618897oie.106.1508344980965; Wed, 18 Oct 2017 09:43:00 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 18 Oct 2017 09:42:45 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Donald Eastlake <>
Date: Wed, 18 Oct 2017 12:42:45 -0400
Message-ID: <>
To: R Parameswaran <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="001a113cf020ca0f4d055bd4ee63"
Archived-At: <>
Subject: Re: [trill] Working group LC on draft-ietf-trill-address-flush-03 (10/2 - 10/16)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Oct 2017 16:43:04 -0000

Hi Ramkumar,

On Wed, Oct 11, 2017 at 11:33 AM, R Parameswaran <>

> 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.

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

> thanks,
> Ramkumar
> [trill] Working group LC on draft-ietf-trill-address-flush-03 (10/2 -
> 10/16)
> Donald Eastlake <> Mon, 02 October 2017 23:11 UTCShow
> header <>
> 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 <,+Milford,+MA+01757+USA&entry=gmail&source=g>
> Replies:
>    - [trill] 答复: Working group LC on draft-ietf-trill-address-flush-03
>    (10/2 - 10/16)
>    <>
>    zhangdacheng <>