[mpls] RtgDir review: draft-ietf-mpls-tp-ethernet-addressing-05.txt
Lou Berger <lberger@labn.net> Sun, 17 February 2013 13:55 UTC
Return-Path: <lberger@labn.net>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D672421F87F9 for <mpls@ietfa.amsl.com>; Sun, 17 Feb 2013 05:55:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.815
X-Spam-Level:
X-Spam-Status: No, score=-101.815 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEa5yCtaNcxX for <mpls@ietfa.amsl.com>; Sun, 17 Feb 2013 05:55:57 -0800 (PST)
Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 2D87121F8716 for <mpls@ietf.org>; Sun, 17 Feb 2013 05:55:57 -0800 (PST)
Received: (qmail 16645 invoked by uid 0); 17 Feb 2013 13:55:35 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 17 Feb 2013 13:55:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=fJWeOFvs91aE9jdiRUFAHb0vv0IWjnYAARJLRCSWmWI=; b=h8HGCr6Ti3CqkPDwtCsuCjHEZJFzA05CGovoyjIzpQRzTq87hNqC52W+k2fwMFn5hkvOWBQnEHOirIQou76gyc4+nFgY1PfF1gVx4k7Jfq+8yQGa0kYdxZDjYuwOfQG/;
Received: from box313.bluehost.com ([69.89.31.113]:37052 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from <lberger@labn.net>) id 1U74iN-0004Lv-GO; Sun, 17 Feb 2013 06:55:35 -0700
Message-ID: <5120E158.8080705@labn.net>
Date: Sun, 17 Feb 2013 08:55:36 -0500
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: rtg-dir@ietf.org, draft-ietf-mpls-tp-ethernet-addressing.all@tools.ietf.org, mpls@ietf.org
Subject: [mpls] RtgDir review: draft-ietf-mpls-tp-ethernet-addressing-05.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Feb 2013 13:55:59 -0000
Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-mpls-tp-ethernet-addressing-05.txt Reviewer: Lou Berger Review Date: 2013-02-17 IETF LC End Date: 2013-02-18 Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: This document is pretty straight forward and I don't have any major issues with it. I found the "MAC address discovery" a bit thinly defined. This document relies on the mechanisms defined in draft-ietf-mpls-gach-adv which has just entered last call. Major Issues: I think the "MAC address discovery" mechanisms defined in Section 4, need some additional details in order to ensure independent interoperable implementations. I don't think any of these issues should difficult or controversial, but I think they should be blocking. I think the following really needs to be covered: - The frequency in which the discovery information needs to be (re)sent & retained. (I think this is simply 1 or 2 sentences that relate back to Lifetime defined in gach-adv.) - Some guidance on how address changes should be handled. - Some guidance on how MTU changes should be handled. - MTU scope needs to be defined. It is completely unclear if MTU is intended to be the MTU based on the maximum frame size supported by the sending physical interface represented in the Source MAC Address TLV, or the MTU supported by the logical (IP) interface associated with the Source Address TLV. The ability to advertise the latter is IMO the minimum required, which I assume was the intent of the document, and just needs to be clarified. Also the basic term should be defined (via appropriate reference). Minor Issues: Section 4: - since assignment of the mac address is not in this document: s/01-00-5e-80-00-0d/defined in Section 7 of [mpls-gach-adv] - TLV formats should be provided for the defined TLVs - "Persistent loss" should be defined in quantitative terms. Also which GAP messages, all? What about handling of the case where GAP messages are received, but no MAC address TLVs are included? Section 5: - Earlier in Section 4 you say, "...must behave as configured for this eventuality.", but such configuration isn't mentioned in section 5. - Reporting of MTU mismatch counts and/or details is probably worth mentioning (and optionally reporting). Section 6: - I think it would be worth mentioning that Section 5 based Address Discovery allows the advertised MAC to be different than the MAC frame source address, and covering related security implications. Nits: Section 2: - for clarity, s/these forms of/broadcast or multicast in "not known to be point-to-point, these forms of addressing MUST ..." One final comment: While I'm sure it's too late to make such a change, I think including MTU in the [mpls-gach-adv] Source Address TLV (in place of the reserved field) would have simplified the protocol. -- clearly this is not a blocking comment or one that really needs to be addressed. That's it, Lou
- [mpls] RtgDir review: draft-ietf-mpls-tp-ethernet… Lou Berger
- Re: [mpls] [RTG-DIR] RtgDir review: draft-ietf-mp… Stewart Bryant