[trill] Alvaro Retana's Discuss on draft-ietf-trill-arp-optimization-06: (with DISCUSS)
"Alvaro Retana" <aretana@cisco.com> Thu, 07 July 2016 03:13 UTC
Return-Path: <aretana@cisco.com>
X-Original-To: trill@ietf.org
Delivered-To: trill@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF0612D597; Wed, 6 Jul 2016 20:13:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alvaro Retana <aretana@cisco.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.25.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160707031345.26704.68365.idtracker@ietfa.amsl.com>
Date: Wed, 06 Jul 2016 20:13:45 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/XiS0g4XjszaIsDjmQ8GJBux_oVU>
Cc: draft-ietf-trill-arp-optimization@ietf.org, trill-chairs@ietf.org, trill@ietf.org, skh@ndzh.com
Subject: [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
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: Thu, 07 Jul 2016 03:13:45 -0000
Alvaro Retana has entered the following ballot position for draft-ietf-trill-arp-optimization-06: 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-trill-arp-optimization/ ---------------------------------------------------------------------- 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 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”? 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.] 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.” 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
- [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