Re: [mpls] AD review of draft-ietf-mpls-tp-ethernet-addressing
Stewart Bryant <stbryant@cisco.com> Fri, 01 February 2013 15:35 UTC
Return-Path: <stbryant@cisco.com>
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 DC57821E803D for <mpls@ietfa.amsl.com>; Fri, 1 Feb 2013 07:35:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.517
X-Spam-Level:
X-Spam-Status: No, score=-110.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 zgjXU7ex1JWL for <mpls@ietfa.amsl.com>; Fri, 1 Feb 2013 07:35:54 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id B81EE21E8030 for <mpls@ietf.org>; Fri, 1 Feb 2013 07:35:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6351; q=dns/txt; s=iport; t=1359732954; x=1360942554; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=RNqzTMPapNT6NhC2NQdNXZ/MhZtS9ajDhYdOBig2oWw=; b=D1f3N4Wm4DkWs2rG1O6T+Xgsj3CqgSjdmqlXuChqKj3yGIYcaXIOYKS0 H4efYV9UuBRNkW4mKuQN/9T/naDmFnUGl12t92xTYCrzfqTMYXmt4RyIQ u6rcwZz/HjMGHlG1qMY/G7JuVcmXotsXhEb9aJvtn62opz4MGiRAZJJ5u I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAI3gC1GQ/khN/2dsb2JhbAA7CrtRg1wWc4IeAQEBBDg1BwQBEAsYCRYPCQMCAQIBRRMBBwEBiA3DII0WBoQyA4tZij6GXolygnyBbw
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="scan'208";a="150046149"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 01 Feb 2013 15:35:52 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r11FZq3D017388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Feb 2013 15:35:52 GMT
Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r11FZoKN028072; Fri, 1 Feb 2013 15:35:51 GMT
Message-ID: <510BE0D6.5090702@cisco.com>
Date: Fri, 01 Feb 2013 15:35:50 +0000
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: adrian@olddog.co.uk
References: <01eb01cdf04b$1e64fa40$5b2eeec0$@olddog.co.uk>
In-Reply-To: <01eb01cdf04b$1e64fa40$5b2eeec0$@olddog.co.uk>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: mpls@ietf.org, draft-ietf-mpls-tp-ethernet-addressing.all@tools.ietf.org
Subject: Re: [mpls] AD review of draft-ietf-mpls-tp-ethernet-addressing
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stbryant@cisco.com
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: Fri, 01 Feb 2013 15:35:57 -0000
On 11/01/2013 22:29, Adrian Farrel wrote: > Hi, > > I have conducted my usual AD review of your document as part of the > publication request processing. The aim of my review is to catch any > issues that might show up in IETF last call, directorate reviews, or > IESG evaluation. The intent is to resolve the issues by text changes > or through email discussion to smooth the passage of the document > through the later stages of the process. > > I have reviewed this document jointly with draft-ietf-mpls-gach-adv > and since the author team is the same for the two documents, I > recommend that you process the comments for the two documents at the > same time. > > As usual, all my comments are open for disagreement and discussion. I > think that you will probably want to produce a revision of this > document to address my comments, so I have put it into "Revised I-D > Needed" state in the data tracker. > > Thanks for the work, > Adrian > > === > > The abbreviations GAL and OAM are not used in the document and can be > removed from Section 1.1. Done > --- > > Am I missing something? Why do you only support 48-bit MAC addresses? We have added text specifying the use of EUI-64 and noting that the mapping is defined by the IEEE (and good luck understanding the IEEE formal and tutorial text). > --- > > I am *really* surprised that this document does not mention LLDP. In > [I-D.ietf-mpls-gach-adv] you state... > > Where > it is anticipated that the sole purpose of the GAP will be to provide > Ethernet MAC address learning, the use of LLDP SHOULD be considered. > > So this document needs to say the same thing (all over and in 18pt red > bold). Furthermore, it needs to define what "HOULD" means in this > context. We have added text on this. > > --- > > In Section 4... > > Could you please identify (with TBD1 - to be assigned by IANA) the > application ID of the new "Ethernet Interface Parameters" application. We put this in the IANA section. > > Could you please state: "The format of the TLVs is as defined in > [I-D.ietf-mpls-gach-adv]. Done > > Could you please include the type values for the two TLVs you are > defining (so that people don't have to look ahead to the IANA section). Done > > Since the two TLVs you are defining have predictable lengths, it would > be nice if you included the specific length values to be used. Done > --- > > I think section 4 is missing something. It is clear from > [I-D.ietf-mpls-gach-adv] that at least one TLV must be present in the > Ethernet Interface Parameters" ADB element. Is there a requirement that > the Source MAC Address TLV is always present? What are the rules for > multiple occurrences of either of the TLVs you have defined? > We say Where MAC address learning occurs by some other means, this TLV group MAY be used to advertise only the MTU. If multiple adverisements are made for the the same parameter, use of these advertisments is undefined. > > --- > > Somewhere, probably Section 4, should leverage the stated intention in > [ID.ietf-mpls-gach-adv] by stating that the values received in the new > ADB element SHOULD (or probably MUST) be made accessible for inspection > by network operators, and where local configuration is updated by the > received information, it MUST be clear why the configured value has > been changed. Furthermore, you probably need to discuss whether > information learned in this way is allowed to be persistent across > node or interface discontinuities. (The last point suggests to me that > you might want to include a brief section on handling changes in > adjacent MAC addresses - a point that you have given as a motivation > for the work.) We have added a new section Manageability Considerations The values sent and received by this protocol MUST be made accessible for inspection by network operators, and where local configuration is updated by the received information, it MUST be clear why the configured value has been changed. The advertised information SHOULD be persistent across restarts. Received advertisements MUST be discarded across restarts. If the received values change, the new values MUST be used and the change made visible to network operators. > --- > > In my comments on [I-D.ietf-mpls-gach-adv] I ask about the consequences > of message loss. This issue seems to apply to this document so, > depending on how you handle the issue in [I-D.ietf-mpls-gach-adv] you > may need to add something to this document. Added In the event of the persistent loss of the GAP messages, the receiving node MUST assume that it is now connected to a node that does not support these advertisements and must behave as configured for this eventuality. > > --- > > Section 5 should reference [I-D.ietf-mpls-gach-adv] for the security > properties of the GAP. It should probably note that an effective > attack is modifying the Source MAC Address value, while modifying the > MTU value may also have significant consequences. Furthermore, it may > be the case that visibility into the contents of either of the TLVs > could provide information that is useful for an attacker. An attacker could disrupt communications by modifying the Source MAC Address or the MTU values, however this is mitigated by the use of cryptographic authetication as described in <xref target="I-D.ietf-mpls-gach-adv"> which also describes other considerations applicable to the GAP protocol. Visibility into the contents of either of the TLVs could provide information that is useful for an attacker. This is best addressed by physical security of the links. > --- > > In section 6.1, please include an IANA action to update the reference > for the MAC address to point to the RFC number assigned to this > document on publication. Done, although they usually catch this. > --- > > In section 6.2, could you please replace 0x0001 with TBD1. Done > > --- > > Trivial point, but there are precisely three authors, all marked as > editors. You could safely dispense with the "editor" designation (on > the front page and in the Authors' Addresses section). > > . > Done New version to be uploaded shortly Stewart & Dan
- [mpls] AD review of draft-ietf-mpls-tp-ethernet-a… Adrian Farrel
- Re: [mpls] AD review of draft-ietf-mpls-tp-ethern… Stewart Bryant