[Tsvwg] Re: Last Call: 'Mapping of IP/MPLS packets into IEEE 802.17 (Resilient packet ring) Networks' to Proposed Standard (draft-ietf-iporpr-basic)
Pekka Savola <pekkas@netcore.fi> Thu, 09 November 2006 23:50 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJfU-0003Wm-VR; Thu, 09 Nov 2006 18:50:48 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi9yP-0007bz-7z; Thu, 09 Nov 2006 08:29:41 -0500
Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi9yO-0006c8-JI; Thu, 09 Nov 2006 08:29:41 -0500
Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id kA9DTcXo007173; Thu, 9 Nov 2006 15:29:38 +0200
Date: Thu, 09 Nov 2006 15:29:38 +0200
From: Pekka Savola <pekkas@netcore.fi>
To: iesg@ietf.org, tsvwg@ietf.org
In-Reply-To: <E1GeZ2V-00036j-Vm@stiedprstage1.ietf.org>
Message-ID: <Pine.LNX.4.64.0611091520320.4849@netcore.fi>
References: <E1GeZ2V-00036j-Vm@stiedprstage1.ietf.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Virus-Scanned: ClamAV 0.88.6/2178/Thu Nov 9 02:08:09 2006 on otso.netcore.fi
X-Virus-Status: Clean
X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS autolearn=ham version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
X-Mailman-Approved-At: Thu, 09 Nov 2006 18:50:38 -0500
Cc: iporpr@ietf.org
Subject: [Tsvwg] Re: Last Call: 'Mapping of IP/MPLS packets into IEEE 802.17 (Resilient packet ring) Networks' to Proposed Standard (draft-ietf-iporpr-basic)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org
On Mon, 30 Oct 2006, The IESG wrote: > The IESG has received a request from the IP over Resilient Packet Rings > WG to consider the following document: > > - 'Mapping of IP/MPLS packets into IEEE 802.17 (Resilient packet ring) > Networks ' > <draft-ietf-iporpr-basic-03.txt> as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2006-11-13. I took a look at the spec. There are a couple of issues that should be realtively easily fixable, but I believe there is also one, potentially major problem. The doc appears to use RFC4594 "Configuration Guidelines for DiffServ Service" as a baseline how implementations should map DiffServ DSCPs to different kind of IPoRPR service classes. Unfortunately, I'm not sure if there is IETF consensus for this practice; RFC4594 is an Informational document, and I believe at least earlier the DSCP treatments has been a domain's internal matter. As such I'd encourage people from Transport area to take a close look at the specification to ensure its DiffServ use is appropriate. Some detailed comments below, substantial ----------- ==> (ID-nits issues) the document lacks normative/informative references split, and ToC is missing. 3.1.2. Source_address The source_address SHOULD be the address assigned to the station that is transmitting the packet. Per [2] if the client omits this parameter then the MAC inserts the correct address. ==> I'm not sure if I understand the meaning of the first sentence. It could be interpreted at least two ways: 1) source_address SHOULD be filled in, with an address of the station; or 2) source_address SHOULD be an address of the station (but in some cases, it might be something else). I suspect you meant the former, but this may also be read as the latter. Does that mean that source_address not belonging to the station may also be used if you deem it necessary? Are there scenarios where this would be needed? Given that source_address is to be filled by MAC automatically, is there even need to not just leave it empty in the spec? Like 802.3 Ethernet, 802.17 defines the maximum regular frame payload as 1500 bytes. Note that a maximum jumbo frame payload size that MAY be supported is defined at 9100 bytes. ==> how does a node know what's the maximum frame payload size supported in the ring? Does it need to know it in advance? Is this the same as with GigE, "manual configuration"? Due to the ring nature of IPoRPR, this seems to call for at least as big warnings about config consistency as would be required for GigE jumboframes. The DSCP field denotes the differentiated services codepoint. The DSCP is used to select the per hop behavior a packet experiences at each network node. As per [6], [7], [8] and [9], the DSCP field description is illustrated in Table 1. ==> The table seems to be mainly based on reference [9], which is unfortunately Informational. If I recall correctly, the long tradition has been that the DSCP PHBs are for most purposes, each domain's own business. I think the current Table 1 and Table 2 might have significant implications on DiffServ and diffserv networks and should be very carefully studied by DiffServ experts and DiffServ using operators to see whether this is the correct course of action. editorial --------- ==> a number of sentences at the end of a paragraph are missing the period at the end. traffic. The mark_fe parameter indicate a request to mark and treat ==> s/indicate/indicates/ 3.4. Byte Order As described in "APPENDIX B: Data Transmission Order" of RFC 791 [3], IP and MPLS datagrams are transmitted over the IEEE 802.17 network as a series of 8-bit bytes in "big endian" order. This is the same byte order as used for Ethernet. ==> well, actually, RFC 791 doesn't mention anything about IEEE 802.17, so the sentence above needs minor rewording. 3.3. Payload The payload contains the IPv4, IPv6, or MPLS packet. The first byte of the IPv4 header, IPv6 header, or top MPLS label begins immediately after the 802.17 header. ==> do you count 'ARP' as an IPv4 packet (even though it has a different protocol type); should it be added to the list here? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
- [Tsvwg] Re: Last Call: 'Mapping of IP/MPLS packet… Pekka Savola