[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