Re: [16NG] IESG Comments on draft-ietf-16ng-ip-over-ethernet-over-802-dot-16
Jari Arkko <jari.arkko@piuha.net> Thu, 17 September 2009 17:24 UTC
Return-Path: <jari.arkko@piuha.net>
X-Original-To: 16ng@core3.amsl.com
Delivered-To: 16ng@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 393A028C299 for <16ng@core3.amsl.com>; Thu, 17 Sep 2009 10:24:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.641
X-Spam-Level:
X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljV-CqNqwLQm for <16ng@core3.amsl.com>; Thu, 17 Sep 2009 10:24:50 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id E80753A6853 for <16ng@ietf.org>; Thu, 17 Sep 2009 10:24:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A6353D4939; Thu, 17 Sep 2009 20:25:41 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+ZQciMDWJoF; Thu, 17 Sep 2009 20:25:41 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id A6F66D492B; Thu, 17 Sep 2009 20:25:40 +0300 (EEST)
Message-ID: <4AB27114.7010908@piuha.net>
Date: Thu, 17 Sep 2009 20:25:40 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: "Riegel, Maximilian (NSN - DE/Munich)" <maximilian.riegel@nsn.com>
References: <BC27158B99D3064A955ADE084783900C028231BC@DEMUEXC014.nsn-intra.net>
In-Reply-To: <BC27158B99D3064A955ADE084783900C028231BC@DEMUEXC014.nsn-intra.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: magnus.westerlund@ericsson.com, 16ng@ietf.org, Ralph Droms <rdroms@cisco.com>, ext Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
Subject: Re: [16NG] IESG Comments on draft-ietf-16ng-ip-over-ethernet-over-802-dot-16
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Sep 2009 17:24:52 -0000
Please submit the draft and I'll check if there's anything that remains. But this sounds good in general. Jari Riegel, Maximilian (NSN - DE/Munich) wrote: > When checking the datatracker > https://datatracker.ietf.org/idtracker/draft-ietf-16ng-ip-over-ethernet- > over-802-dot-16/ I found the following open comments from last weeks > IESG discussions. > > Meanwhile we have prepared a new revision of the I-D addressing the > issues. We are ready to submit the revised I-D and would like to clarify > that we really solved the issues. > > Bye > Max > pls see inline > > >> Date: 2009-09-10, 04:24:05 >> Document: draft-ietf-16ng-ip-over-ethernet-over-802-dot-16 >> Version: 11 >> Commented by: Jari Arkko >> Comment: [IESG Evaluation DISCUSS] >> The document is now in quite good shape -- there's been progress >> since the previous versions! I did have a few issues, though: >> >> Here the conclusion is right but the rationale needs a bit work: >> >> >>> According to [RFC4861], a link is defined as a communication >>> > facility > >>> or medium over which IP devices can communicate at the link layer, >>> i.e. the layer immediately below IP. Ethernet fully satisfies the >>> definition of the link. IEEE 802.16, however, has limitations on >>> > its > >>> transitive connectivity, i.e. IEEE 802.16 provides point-to-point >>> connections between SSs and the BS but does not enable any direct SS >>> to SS connectivity. Hence, it is required to bridge each of the >>> point-to-point connections between SSs and the BS so that Ethernet >>> > is > >>> realized over IEEE 802.16 access network. >>> >> Here's a piece of Ethernet technology that has the same limitations as >> 802.16: >> >> - it is point to point >> - it doesn't do multicast >> - it has limitations with regards to host - host connectivity >> unless your nic supports either straight and twisted cables >> >> http://www.ccrane.com/images/medium/cat-5e-ethernet-cable.jpg >> > > Great! And congratulation. This is the best explanation of the IEEE > 802.16 link > model which I have ever seen. > > >> But I do agree, of course, that bridging is required. I would suggest >> however that the paragraph be reworded to: >> >> Like in today's wired Ethernet networks, bridging is required to >> implement connectivity between more than two devices. In 802.16, >> > the > >> point-to-point connections between SSs and the BS can be bridged >> so that Ethernet is realized over IEEE 802.16 access network. >> > > Your proposal is much shorter and hits the point. We included the > proposed text > instead of the previous wording. > > >>> The network-side bridging function SHOULD create a new radio side >>> port whenever a new SS attaches to any of the BSs of the network or >>> SHOULD remove a radio side port when an associated SS detaches from >>> the BSs. >>> >> Wouldn't this be more of a case for a MUST than a SHOULD? This is >> > basic > >> functionality for 802.16 Ethernet. >> > > Agreed. It is the essential behavior of the bridge. MUST is more > appropriate. > We changed SHOULD to MUST in the new revision of the I-D. > > >>> The generic IP over Ethernet network scenario assumes that all hosts >>> are residing on the same link with trust relationship between all of >>> them. >>> >> I'm not sure why we need to assume a trust relationship here. I would >> suggest deleting everything from word "link" onwards. >> > > We are mentioning here trust relationship, because it is the main > difference to the public access case, where direct communication on the > link layer is prevented to protect other hosts on the same link from > malicious attacks. For the plain Ethernet functionality, trust > relationship is not required. We deleted as you proposed. > > >>> All multicast and multicast control messages SHOULD be processed in >>> the network-side bridging function according to [RFC4541]. >>> >> This is a fine requirement, except for 4541 being an informational >> document and this spec being proposed standard. I would like to change >> this and similar recommendations in Section 7 to a different wording. >> Say, "can" instead of "SHOULD". Alternatively, we could call out this >> downref in a Last Call, but AFAICT this was not done in the last call >> we just had. >> >> Same for RFC 4562 references. >> > > We changed "SHOULD" to "can". We know about the difficulty to make > normative references to informative specifications. If "can" allows us > to point to the Informational RFCs, we are fine. > > >> -------------------------- >> Date: 2009-09-08, 07:18:44 >> Document: draft-ietf-16ng-ip-over-ethernet-over-802-dot-16 >> Version: 10 >> Commented by: Magnus Westerlund >> Comment: [IESG Evaluation COMMENT] >> Section 5.2, 7.1: >> >> I wonder why these section puts the requirement level on SHOULD and >> > not a MUST? > >> And what are the reasons/motivation for when it is allowable to not do >> > the > >> action? >> > > For Section 5.2 (replicating broadcast messages and sending them unicast > to all hosts) we used 'SHOULD', because later in the document we > describe, when this rule should not be followed. > > In section 7.1 hints are given to conserve radio resources by > selectively processing multicast and broadcast messages. The system > still works even when not all of the hints are adopted. Furthermore some > of the hints are from Informational RFCs, which makes it difficult to > use 'MUST' (see Jari's comment above). > > I hope we were able to sufficiently address all the remaining issues of > the document. If yes, we will submit the revised I-D to the IETF. > > Bye > Max > >
- [16NG] IESG Comments on draft-ietf-16ng-ip-over-e… Riegel, Maximilian (NSN - DE/Munich)
- Re: [16NG] IESG Comments on draft-ietf-16ng-ip-ov… Jari Arkko
- Re: [16NG] IESG Comments on draft-ietf-16ng-ip-ov… Hongseok Jeon