Re: [mpls] Pipelining the inevitable adoption poll on draft-nainar-mpls-rfc8287-len-clarification
"Adrian Farrel" <adrian@olddog.co.uk> Tue, 26 February 2019 12:55 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F60312F295; Tue, 26 Feb 2019 04:55:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level:
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
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 oVGNmJwKoN_3; Tue, 26 Feb 2019 04:55:22 -0800 (PST)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 444ED124BAA; Tue, 26 Feb 2019 04:55:21 -0800 (PST)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id x1QCtH3R027122; Tue, 26 Feb 2019 12:55:17 GMT
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 82E902204E; Tue, 26 Feb 2019 12:55:17 +0000 (GMT)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id 6AEFF2204C; Tue, 26 Feb 2019 12:55:17 +0000 (GMT)
Received: from LAPTOPK7AS653V ([87.112.237.8]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id x1QCtGbr022245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 Feb 2019 12:55:16 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Alexander Vainshtein' <Alexander.Vainshtein@ecitele.com>
Cc: mpls-chairs@ietf.org, draft-nainar-mpls-rfc8287-len-clarification@ietf.org, 'Loa Andersson' <loa@pi.nu>, mpls@ietf.org
References: <033901d4cdc5$4640f2e0$d2c2d8a0$@olddog.co.uk> <AM0PR03MB3828A9DDF9FCBEECADFCE4359D7B0@AM0PR03MB3828.eurprd03.prod.outlook.com>
In-Reply-To: <AM0PR03MB3828A9DDF9FCBEECADFCE4359D7B0@AM0PR03MB3828.eurprd03.prod.outlook.com>
Date: Tue, 26 Feb 2019 12:55:16 -0000
Organization: Old Dog Consulting
Message-ID: <036901d4cdd2$860f1a70$922d4f50$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_036A_01D4CDD2.861275D0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIico/ZR4JBtKMannh3QJeRlGrgqgGPDTZtpUpG+rA=
Content-Language: en-gb
X-Originating-IP: 87.112.237.8
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24456.007
X-TM-AS-Result: No--31.895-10.0-31-10
X-imss-scan-details: No--31.895-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24456.007
X-TMASE-Result: 10--31.895000-10.000000
X-TMASE-MatchedRID: jFqw+1pFnMzxIbpQ8BhdbGzBijri5+RV7q8FE7Y/iI1QKAQSutQYXIrr VDrdF6YEJLIvfOwAGPbejIKemsMsDUEldmG5s6kZb8JTZf0kEzs0AKed0u9fB3Oy6EBOBW1qSzR sdc8l3B5HS+vshkGLkxcdkIXUbTd4exBmwgbVzYfhuXUWQoMQtySF0LR+PMPIVBS/JDYr37C3DI h4Vmbze+ZjKb6ys7Ociz0NiiC/JRwxk+PbmPwK3EKcYi5Qw/RVVX7TxgU0dK5Zps+y1VXzqUFYU JLQupgqwnPRJvFiqpirJ+c2fCxI6QYFn9rUnd9nM71h0SMVl8L3N59hBwdmny62hjZS0WoYx+Uw 4sIsasvUXduftfjvR3fFOUZuMU76BbvHck2HzvxXq5HtSh5C5MnlJe2gk8vISSUXkvSVAdxjuEJ aB1iHgv37Sl/qiuKeIc0OTKdFkD34LNiDhk5IJn9NanCUA4VeudcAdgVI8xlGvu3Cr8OtFkc5A8 5pTadYuAsML43hVSl9/wjow1SVlyTtChVcJtE4Vo6mn+xXmdVMFWXO7lee9bt4BAaULwAVN8RGT fW9Fj3DgGiSi1hwZ2dlOj9QIwpdxb2ZByTuHA+puD25aEtgtyGZtiDVlw6eN2d3n0B/sI84kr4x 1zfYTWMNA1KnBCuxzzU2+MLrDVRfDKWvP/4QA7U+IyHhkXf1W1DDwVjMhE5ZGhC8KIepNrKZXdc PRJJRRyrOW/EBT3K6Qny7Q2uEd4iceOuNnLyW/Sl5cYQQGW+uiAW0p38/t5b7No0srrTk7KBBZ2 QBUyzQ23n+P5pIMRQjizXtCXfTWYqLLUX2mAueAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDPPeN6H N6d7GlnRC7/pAaFU6baA36eiawgbhiVsIMQK7ebCOc2vNHr5dGVkKe/kiVfXumc4O21pKaxBAu0 XzMcGU0fg84rnFjFhXMjdQIJpg==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/6waJ5XwHTHklezDA3kTMpuA1y8A>
Subject: Re: [mpls] Pipelining the inevitable adoption poll on draft-nainar-mpls-rfc8287-len-clarification
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 26 Feb 2019 12:55:26 -0000
Hmmm, I think I am now erring towards agreeing with you having found 8029 ss3.9. That has three trailing MBZ bytes, but still has a length of 4. I'm still not sure that reproducing the figures is necessary, but if you phrase the text as "this figure replaces that figure" it'll work out OK. A From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Sent: 26 February 2019 11:55 To: adrian@olddog.co.uk Cc: mpls-chairs@ietf.org; draft-nainar-mpls-rfc8287-len-clarification@ietf.org; 'Loa Andersson' <loa@pi.nu>; mpls@ietf.org Subject: RE: [mpls] Pipelining the inevitable adoption poll on draft-nainar-mpls-rfc8287-len-clarification Adrian, Just to make it clear, I have filed the erratum on RFC 8287 (which, I believe is the singular form while errata is plural) that has been rejected by Deborah because "This change requires an update to the RFC, requires consensus". I agree that we could make the draft somewhat shorter - but not by much: the part that looks too long to you takes roughly 2 pages out of 5.5. The added value is that the current version means that the implementer does not have to do any length calculations (that always carry with them the risk of miscalculations): everything is spelled out in the same way as it is in RFC 8029. I also think that when the "reserved" field is explicitly defined as following: <quote> Reserved The Reserved field MUST be set to 0 when sent and MUST be ignored on receipt. <end quote> it is somewhat different to distinguish it from a "true" MBZ field: What's in a name? And I do not think that this field has been intended for the future sub-TLVs since it itself is part of a sub-TLV. The bottom line: I think that the draft is ready for adoption by the WG. If the WG, following adoption, requests to make it shorter, we can do that. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com <mailto:Alexander.Vainshtein@ecitele.com> -----Original Message----- From: mpls <mpls-bounces@ietf.org <mailto:mpls-bounces@ietf.org> > On Behalf Of Adrian Farrel Sent: Tuesday, February 26, 2019 1:20 PM To: 'Loa Andersson' <loa@pi.nu <mailto:loa@pi.nu> >; mpls@ietf.org <mailto:mpls@ietf.org> Cc: mpls-chairs@ietf.org <mailto:mpls-chairs@ietf.org> ; draft-nainar-mpls-rfc8287-len-clarification@ietf.org <mailto:draft-nainar-mpls-rfc8287-len-clarification@ietf.org> Subject: [mpls] Pipelining the inevitable adoption poll on draft-nainar-mpls-rfc8287-len-clarification Hi, Since Loa is polling for IPR, I suspect an adoption poll is likely to follow. I know this document arises from confusion during interop, and I have some sympathy with people who find RFCs hard to parse. I also understand that the AD rejected fixing this through an Errata Report, and so the only option is to publish an RFC (the motivation here appears to be that consensus is needed for the resolution). IMHO, 8029 is clear on how to set the length of a TLV or sub-TLV. The sub-TLV length includes all of the fields of the sub-TLV, but not any trailing padding. The TLV length includes all of the sub-TLV padding. Thus, the only issue I can see here was that there was confusion about whether fields marked as "Reserved" formed part of the sub-TLVs. The only reason they would be, would be to allow for future extensions, otherwise they would just be padding. Clearly (according to this document) they were intended to be part of the sub-TLVs (for extensions). That is inconsistent with how 8029 is written, but since 8287 uses "Reserved" not "MBZ" it is acceptable if that is really want people want to achieve (i.e., that is the consensus decision that is needed). Doesn't that mean that the *only* text needed is to say... "Fields marked 'Reserved' in sub-TLVs defined in RFC 8287 are an integral part of the sub-TLVs and MUST be accounted in computation of the length of the sub-TLVs."? The current draft seems like a lot of text to make that clarification. Thanks, Adrian -----Original Message----- From: mpls < <mailto:mpls-bounces@ietf.org> mpls-bounces@ietf.org> On Behalf Of Loa Andersson Sent: 26 February 2019 07:09 To: <mailto:mpls@ietf.org> mpls@ietf.org Cc: <mailto:mpls-chairs@ietf.org> mpls-chairs@ietf.org; <mailto:draft-nainar-mpls-rfc8287-len-clarification@ietf.org> draft-nainar-mpls-rfc8287-len-clarification@ietf.org Subject: [mpls] IPR poll on draft-nainar-mpls-rfc8287-len-clarification Working Group, authors, We have started to prepare draft-nainar-mpls-rfc8287-len-clarification for working group adoption, prior to the wgap we need to do an IPR poll. This mail starts this IPR poll. Are you aware of any IPR that applies to draft-nainar-mpls-rfc8287-len-clarification? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). There no IPR disclosures against draft-nainar-mpls-rfc8287-len- clarification. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS WG mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. /Loa mpls wg co-chair -- Loa Andersson email: <mailto:loa@pi.nu> loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 _______________________________________________ mpls mailing list <mailto:mpls@ietf.org> mpls@ietf.org <https://www.ietf.org/mailman/listinfo/mpls> https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list <mailto:mpls@ietf.org> mpls@ietf.org <https://www.ietf.org/mailman/listinfo/mpls> https://www.ietf.org/mailman/listinfo/mpls ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________
- [mpls] Pipelining the inevitable adoption poll on… Adrian Farrel
- Re: [mpls] Pipelining the inevitable adoption pol… Alexander Vainshtein
- Re: [mpls] Pipelining the inevitable adoption pol… Adrian Farrel
- Re: [mpls] Pipelining the inevitable adoption pol… Alexander Vainshtein