[mpls] FW: RE: draft-smack-mpls-rfc4379bis

David Allan I <david.i.allan@ericsson.com> Mon, 07 December 2015 16:12 UTC

Return-Path: <david.i.allan@ericsson.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E9E1B381E for <mpls@ietfa.amsl.com>; Mon, 7 Dec 2015 08:12:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxbgDawPCgRC for <mpls@ietfa.amsl.com>; Mon, 7 Dec 2015 08:12:00 -0800 (PST)
Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF4E01B381A for <mpls@ietf.org>; Mon, 7 Dec 2015 08:12:00 -0800 (PST)
X-AuditID: c618062d-f79d16d000001b1c-6f-5665af756576
Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id B3.91.06940.57FA5665; Mon, 7 Dec 2015 17:10:29 +0100 (CET)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Mon, 7 Dec 2015 11:11:59 -0500
From: David Allan I <david.i.allan@ericsson.com>
To: "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: RE: draft-smack-mpls-rfc4379bis
Thread-Index: AdErsl6/5kPkO+iJTna0PsiF4/JB0wEQ/OQAAETiP+A=
Date: Mon, 07 Dec 2015 16:11:58 +0000
Message-ID: <E6C17D2345AC7A45B7D054D407AA205C4B00ABC7@eusaamb105.ericsson.se>
References: <E6C17D2345AC7A45B7D054D407AA205C4B0021F2@eusaamb105.ericsson.se> <56639AFC.1000200@pi.nu>
In-Reply-To: <56639AFC.1000200@pi.nu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.9]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyuXSPt27p+tQwgwnXJSxuLV3J6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujL5z4QWzBSu2d5xgaWA8zdvFyMkhIWAicXXmVjYIW0ziwr31 QDYXh5DAEUaJq1vfskA4yxglfhz6xwJSxSZgILHn/xdGEFtEQFniyMRuVhBbWEBH4t6vrywQ cV2JadN+s0LYVhLPHtwGs1kEVCSev3vPDGLzCvhKfHz3CKxeSCBD4tPqS2A1nAKqEpM7d4Fd xAh00fdTa5hAbGYBcYlbT+YzQVwqILFkz3lmCFtU4uXjf6wQtqLEvv7p7BD1OhILdn9ig7C1 JZYtfA21V1Di5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxchRWlyQk5tuZLCJERj4xyTYdHcw 3p/ueYhRgINRiYd3Q2tKmBBrYllxZe4hRgkOZiURXtnM1DAh3pTEyqrUovz4otKc1OJDjNIc LErivIwMDAxCAumJJanZqakFqUUwWSYOTqkGxrVOjnuFFaVuB55jtb2Wc6FpwvMLXuzcWx8q lXkZqWx0WH+oglFxmeg+b8b4MpkL/3YaLuioeLvKNfne4vsB2u3xX0JebTm6UPXPP0/WTyF9 pUJbbq/Yaj7DMZz5y6sWt/BNOvlL3qVKe0T8MZruOaF3jd+kkC+bVu98kpzzQOHtD3fObM+o HUosxRmJhlrMRcWJADd1asN4AgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/SUy_xSKKfdzbCiwY0acPpyxA-u8>
Subject: [mpls] FW: RE: draft-smack-mpls-rfc4379bis
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 07 Dec 2015 16:12:02 -0000

Cc'd the MPLS list as quested
-------------------------------------------------
HI Loa:

I've read it though and will state up front, that as a next step in the standards process (bis version), I'm applying a tougher standard to the document and looking at this as more of a "last call". Even more so as it is OAM and therefore IMO requires a high degree of interoperability to be useful. As pretty much all of this is from the original document and outside the scope of what has been proposed (errata incorporation
etc.) and likely just complicates life, you can take it with "a grain of salt".

My chief concern with the document is that the language is very non specific and vague, and what I would expect to say "this is..." 
typically says "this might...".  I appreciate that much of this originates with the original RFC 4379, but for a BIS I would expect it to be cleaned up.

Some examples:
"An MPLS echo request with 1 (Do not reply) in the Reply Mode field  may be used for one-way connectivity tests;". IMO it is not a "may be", it "is" used for one way connectivity tests. If there is no reply, what else are you going to do.

"Sub-TLVs have  independent types and MUST also be 4-octet aligned. 
Two examples follow."  The examples would appear to be a normative definition of the ONLY sub-TLVs that are defined in this I-D. Other RFCs (e.g. VCCV) may define more, but these are the ones defined here, they are NOT examples.


And finally....
I'm hoping I'm reading this incorrectly, but assuming my read IS correct, It is obviously far far too late to change it but the FEC stack would have been easier to use if it listed the FECs from BOS to TOS, and not TOS to BOS as it is described now.  An intermediate LSR would need to count from BOS backwards given the depth of the current stack would be arbitrary at any intermediate LSR. Should have caught that years ago....

All of this being said, I have no idea what leeway in an IETF bis that one has to fix editorial and style issues. Meanwhile I do consider correcting the references and applying all errata to be a useful step.

Cheers
Dave