Re: [trill] Alvaro Retana's Discuss on draft-ietf-trill-arp-optimization-06: (with DISCUSS)
Donald Eastlake <d3e3e3@gmail.com> Fri, 29 July 2016 23:19 UTC
Return-Path: <d3e3e3@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243D712D798; Fri, 29 Jul 2016 16:19:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQ9zyN3JAM-1; Fri, 29 Jul 2016 16:19:22 -0700 (PDT)
Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 575A612D0C4; Fri, 29 Jul 2016 16:19:22 -0700 (PDT)
Received: by mail-vk0-x231.google.com with SMTP id n129so64280401vke.3; Fri, 29 Jul 2016 16:19:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4gv3KOwaqO18ERZWYnj0XoWK355VPVHRrWt5JKsBOBM=; b=TPV/L7X8L1TJ+Wd9uankGxRXde6VYg7Hgqr1XT2M+oJ8oaMlOizW0BlOUfmzaP8sdX dF/rGNfjL6WcX+tyMiyH6OTfROEpvwuezvI+6kPBWVmdoBEoDoSgzJ8U0pMzewY1P/mM V9XdHADtq4GqDL0A5qUIT3sH9xJcGhy4Wa6+lR9RXffmsZtHGAkktKrHtnprCWEW1lRY Ai8gU5MQf7YRgVyyYT5GLSmaR/E6gwkvwsVIxvlmZu6xNV+IAbtD/caugPpbweXTbEQZ rqCURiNavfgr1FhdcbN8b6nkD8NIIj2Mx2WU/eQoEShByGPBcrxHBSaQqqX7rrLdFOZq Y4+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4gv3KOwaqO18ERZWYnj0XoWK355VPVHRrWt5JKsBOBM=; b=iRXxW15nZImw3H1GcpptHW+UUMy6BTaI11SZX55Bfq0Fs3WLWLCaM0yurs3ratCZ1V kA1mJmm2H4y1fiCG6D1Xxv1yLIf3VUkwIUQ3ttmBPHTROrzLtC+rfhuFIVUQNB6isYxi XZQWIXMLf1xANEnlzDfPUlUPtcInFICyGlKrceZGf0fiH0LRXlxD3Tq46JoO0ECU7Zge 9BpcsXV5HAjY0vsAFb/QwSyFNsawsyw/zf1kTNx78rUH+wIHot9/Zi6GWhurzur6wuTg EmKixfcSH+GRpnBSMG5qknbh2nZE4+0BkGwMStCgTWgB+7Aa5xdMBlTareTXxIa/20fw n1ng==
X-Gm-Message-State: AEkoouvngTR2d3wPijkw75LxafUDgMR1U5IKubEmtIturZXr6ZAdTMOS0QO/hHE2kRkEgBmHTTBYNlL7oLsiPg==
X-Received: by 10.31.173.149 with SMTP id w143mr19922743vke.124.1469834361288; Fri, 29 Jul 2016 16:19:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.104.2 with HTTP; Fri, 29 Jul 2016 16:19:06 -0700 (PDT)
In-Reply-To: <20160707031345.26704.68365.idtracker@ietfa.amsl.com>
References: <20160707031345.26704.68365.idtracker@ietfa.amsl.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Fri, 29 Jul 2016 19:19:06 -0400
Message-ID: <CAF4+nEGKaJeip3-eMFG=+W=A4b0xAAvsZTg6+gttfwg29dssMg@mail.gmail.com>
To: Alvaro Retana <aretana@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/up9DXORJxbU_eWT1IBhKN3mW634>
Cc: draft-ietf-trill-arp-optimization@ietf.org, "trill-chairs@ietf.org" <trill-chairs@ietf.org>, The IESG <iesg@ietf.org>, "trill@ietf.org" <trill@ietf.org>, Susan Hares <skh@ndzh.com>
Subject: Re: [trill] Alvaro Retana's Discuss on draft-ietf-trill-arp-optimization-06: (with DISCUSS)
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2016 23:19:24 -0000
Hi Alvaro, On Wed, Jul 6, 2016 at 11:13 PM, Alvaro Retana <aretana@cisco.com> wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-trill-arp-optimization-06: Discuss > > ... > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I know this is an optional optimization, as described by the “MAY” > in the Introduction. However, some of the other normative language > is not as strong as it should be to clearly specify the required > behavior (if the mechanisms are being used), cause confusion, or is > simply out of place. > > 1. In 3.1 (Get Sender's IP/MAC Mapping Information for Non-zero IP) > the text says that the “RBridge MAY use different strategies to do > so”. That “MAY” contradicts the “SHOULD” used before it, which > directs the RBridge to verify a duplicate address. s/MAY/may OK. > 2. Still in 3.1: “…the RBridge SHOULD verify if a duplicate IP > address has already been in use…” What are the reasons where the > RBridge would not verify this situation? IOW, why is this “SHOULD” > not a “MUST”? If the network manager's philosophy is have the network behave as if the relevant set of end stations were on a single link and just believe an ARP it received, it might not do anything to try to verify conflicting prior attachment information. > 3. I’m confused as to whether the APPsub-TLV is required or not. > The source of my confusion comes from Section 3.3 (Determine How to > Handle the ARP/ND Response) which says that “R2 SHOULD initiate a > link state update to inform all the other RBridges of the target's > location…The update message can be carried by an IA APPsub-TLV > [IA-draft]…” This text seems to say that the APPsub-TLV SHOULD be > used to carry the information — but text in Section 2 (IP/MAC > Address Mappings) sounds to me as if the use of the APPsub-TLV is > optional: “If the RBridge has extracted the sender's IP/MAC address > pair from the received data packet (either ARP or ND), it MAY save > the information and use the IA APPsub-TLV…” Also, 3.1 and 3.2 both > say that an “RBridge MAY use the IA APPsub-TLV”. And finally the > Security Considerations section seems to recommend using it… Maybe > it’s just me, but please clarify. [BTW, if it is required, then I > think that both the IA-draft and DirMech references should be > Normative.] I agree that the wording should be clarified. RBridges are interested in the nickname of the RBridge to which some destination address is attached, since RBridges route on nickname. This information can be communicated for IP addresses with IP reachability link state TLVs and for MAC addresses with MAC reachability link state TLVs (each genrally within the scope of a VLAN (or FGL)). However, for ARP/RARP/ND optimization, you generally want to know the MAC<->IP mapping which is absent with separate MAC and IP reachability. The IA APPsub-TLV is, as far as I know, the only link state data format that can be used to bind together the MAC and IP address(es) for an interface (port), as well as providing the nickname of the RBridge to which that interface is attached and possibly other information. Thus, if you are to communicate information useful to, for example, provide a locally created response to an ARP, you need to use IA APPsub-TLV. > 4. In Section 2 (IP/MAC Address Mappings) the “MAY” in the following > sentence is out of place since that is already the function of the > confidence (as described in draft-ietf-trill-ia-appsubtlv and > RFC6325): “A different confidence level MAY also be used to indicate > the reliability of the mapping information.” That should be a lower case "may" (or perhaps "can" or something else). > 5. In Section 3.2 (Determine How to Reply to ARP/ND), both options > (?) a and b say that the “RBridge MAY take one…”. If the RBridge > selected that option, then I think the action is no longer optional. > s/MAY/MUST OK. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com
- [trill] Alvaro Retana's Discuss on draft-ietf-tri… Alvaro Retana
- Re: [trill] Alvaro Retana's Discuss on draft-ietf… Alvaro Retana (aretana)
- Re: [trill] Alvaro Retana's Discuss on draft-ietf… Donald Eastlake