[Idr] Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT)
Robert Wilton via Datatracker <noreply@ietf.org> Fri, 24 April 2020 09:49 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BB93A1120; Fri, 24 Apr 2020 02:49:29 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-idr-rfc5575bis@ietf.org, idr-chairs@ietf.org, idr@ietf.org, Jie Dong <jie.dong@huawei.com>, aretana.ietf@gmail.com, jie.dong@huawei.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.127.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <158772176873.17533.3566124086139075762@ietfa.amsl.com>
Date: Fri, 24 Apr 2020 02:49:29 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/V8LFOkeKb0JPi-jvjmA9LGrX_0A>
Subject: [Idr] Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Apr 2020 09:49:30 -0000
Robert Wilton has entered the following ballot position for draft-ietf-idr-rfc5575bis-23: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I don't know if this is a valid discuss point, so happy to be educated that it is always written this way and I'll remove my discuss ... I note that in 5 places this document has text that states the equivalent to "SHOULD be set to 0 on encoding, and MUST be ignored during decoding." (example given below). Doesn't this make extending this in future more risky because if new meaning are given to these bits then there could be senders already transmitting non 0 values which a receiver might then misinterpret? Hence, I was surprised that the constraints did not also include a MUST on the encoding side (i.e. be strict in what you send ...), i.e. "MUST be set to 0 on encoding, and MUST be ignored during decoding." Example: The extended is encoded as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | reserved | reserved | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | r.| DSCP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Traffic Marking Extended Community Encoding o DSCP: new DSCP value for the transiting IP packet. o reserved, r.: SHOULD be set to 0 on encoding, and MUST be ignored during decoding. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, I also had a few minor comments on this document: 4.1. Length Encoding o If the NLRI length is smaller than 240 (0xf0 hex) octets, the length field can be encoded as a single octet. o Otherwise, it is encoded as an extended-length 2-octet value in which the most significant nibble of the first octet is all ones. This describes the first nibble in binary, and then later it is shown in hex. It might be more clear to write ... in which the most significant nibble has the hex value 0xf. In Figure 1 above, values less-than 240 are encoded using two hex digits (0xnn). Values above 239 are encoded using 3 hex digits (0xfnnn). The highest value that can be represented with this encoding is 4095. For example the length value of 239 is encoded as 0xef (single octet) while 240 is encoded as 0xf0f0 (2-octet). 4.2. NLRI Value Encoding Components MUST follow strict type ordering by increasing numerical order. A given component type may (exactly once) or may not be present in the Flow Specification. If present, it MUST precede any component of higher numeric type value. I wasn't sure, but wondering whether "may (exactly once) or may not be" should be "MAY (exactly once) be"? 5.1. Ordering of Flow Specifications For all other component types, unless otherwise specified, the comparison is performed by comparing the component data as a binary string using the memcmp() function as defined by [ISO_IEC_9899]. For strings with equal lengths the lowest string (memcmp) has higher precedence. For strings of different lengths, the common prefix is compared. If the common prefix is not equal the string with the lowest prefix has higher precedence. If the common prefix is equal, the longest string is considered to have higher precedence than the shorter one. I think that the intended comparison here is clear, but I was wondering whether this text should flag endian concerns at all. E.g. if the component data has been stored in memory and any numeric values have had endian conversion performed on them then a naive memcmp() could give a different answer.
- [Idr] Robert Wilton's Discuss on draft-ietf-idr-r… Robert Wilton via Datatracker
- Re: [Idr] Robert Wilton's Discuss on draft-ietf-i… Susan Hares
- Re: [Idr] Robert Wilton's Discuss on draft-ietf-i… Rob Wilton (rwilton)
- Re: [Idr] Robert Wilton's Discuss on draft-ietf-i… Susan Hares
- Re: [Idr] Robert Wilton's Discuss on draft-ietf-i… Rob Wilton (rwilton)
- Re: [Idr] Robert Wilton's Discuss on draft-ietf-i… Alvaro Retana
- Re: [Idr] Robert Wilton's Discuss on draft-ietf-i… Susan Hares
- Re: [Idr] Robert Wilton's Discuss on draft-ietf-i… Alvaro Retana