Re: [mpls] [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-ethernet-addressing-05.txt
Stewart Bryant <stbryant@cisco.com> Fri, 05 April 2013 18:02 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 4CABF21F9865; Fri, 5 Apr 2013 11:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TUKDNd3Kk5k; Fri, 5 Apr 2013 11:02:03 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5765121F9863; Fri, 5 Apr 2013 11:02:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6479; q=dns/txt; s=iport; t=1365184922; x=1366394522; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=T0DRyczVvExjmGtArYJr+6XEZeIQN42LckVe8xleX9M=; b=JvTvPQm3bH3Kw1WBzui3W8AhAN7kqszQVS/auciawfI24xDcIf/ZIuzo 4hsa1U4qp+ICXzf4VjMgyOYvnvB7/opHiui9UqyUfdn4w0IOdNrRcTOJb iqx30w5j7CvzuPTFNWQIETqQYR8c5I7YF1FfdexX+mByyA2lrG4/A4fFz g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAJcQX1GQ/khN/2dsb2JhbABLgwY2wSWBDRZ0gh8BAQEDAThAARALDgYECRYPCQMCAQIBRQYNAQcBAQWIBQYMwX+PGweDQAOTKINGkQ2DDA
X-IronPort-AV: E=Sophos;i="4.87,416,1363132800"; d="scan'208";a="152559307"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 05 Apr 2013 18:01:58 +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 r35I1us0032606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Apr 2013 18:01:56 GMT
Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r35I1te6004298; Fri, 5 Apr 2013 19:01:55 +0100 (BST)
Message-ID: <515F1193.8070305@cisco.com>
Date: Fri, 05 Apr 2013 19:01:55 +0100
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Lou Berger <lberger@labn.net>
References: <5120E158.8080705@labn.net>
In-Reply-To: <5120E158.8080705@labn.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: rtg-dir@ietf.org, mpls@ietf.org, draft-ietf-mpls-tp-ethernet-addressing.all@tools.ietf.org, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Subject: Re: [mpls] [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-ethernet-addressing-05.txt
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, 05 Apr 2013 18:02:04 -0000
Lou Thanks for the review. Please see inline. On 17/02/2013 13:55, Lou Berger wrote: > 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.) I have added The choice of lifetime for the TLV is an operational issue and not an inter-working issue, and thus the operator is free to set the lifetime according to their own preference. There is no requirement for the lifetime to be symmetric. To expedite the initialization of a link it is RECOMMENDED that a node that has been reconfigured, rebooted or is aware that it have been disconnected from its peer send a GAP Ethernet Interface Parameter message, and that it issues a GAP request message for the Ethernet parameters at the earliest opportunity. > > - Some guidance on how address changes should be handled. I have added When the MAC address in the received Source MAC Address TLV changes the new MAC address MUST be used (see Section 5.2 of [I-D.ietf-mpls-gach-adv]. > > - Some guidance on how MTU changes should be handled. I have added If a minimum MTU is configured for a link and the MTU advertised by the peer is lower than that minimum, the link the NMS MUST notified of the event. Under these circumstances the operator may choose to configure the LSR to shut the link and trigger thereby triggereing a fault and causing the end-to-end path to be repaired, or they may choose to leave the link up so that an OAM message can is used to verify the actual MTU. > > - 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). The MTU definition now says: MTU (type = 1, length = 4): The Value of this object is a 32-bit unsigned integer encoded in network byte order that specifies the maximum transmission unit size in octets of an MPLS label stack plus payload that can be sent over the sending interface. I am unconvinced that a reference is needed, although if you can find one that fits this description I am not averse to including it. However the new definition seems self defining. > > > 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] Ref added > > - TLV formats should be provided for the defined TLVs Done > > - "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? The degree of loss is a matter for the operator. The latter point is already covered in the text. > > Section 5: > - Earlier in Section 4 you say, "...must behave as configured for this > eventuality.", but such configuration isn't mentioned in section 5. I am beginning to think that manageability consideration sections are more of a liability than they are worth. I would assume that the implementer will read the whole text and provide the required controls without the need to list them in this section. This section is a reminder of text in the GAP protocol document and could if you prefer be deleted. > > - Reporting of MTU mismatch counts and/or details is probably worth > mentioning (and optionally reporting). That is now with the MTU text. > > 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. That would surely be a strange thing to do, but presumably is what the operator intended. I would leave it to the implementation to choose if and how it logged such an event. > > 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 ..." done. > > 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. It is a bit late, but will discuss with the others. - Stewart
- [mpls] RtgDir review: draft-ietf-mpls-tp-ethernet… Lou Berger
- Re: [mpls] [RTG-DIR] RtgDir review: draft-ietf-mp… Stewart Bryant