Re: [Errata Rejected] RFC7257 (4059)

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Sun, 23 November 2014 06:38 UTC

Return-Path: <Alexander.Vainshtein@ecitele.com>
X-Original-To: l2vpn@ietfa.amsl.com
Delivered-To: l2vpn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BCE1A1AE5; Sat, 22 Nov 2014 22:38:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 3iQj0JrUaT5W; Sat, 22 Nov 2014 22:38:56 -0800 (PST)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0711.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::711]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A64C51A1ADD; Sat, 22 Nov 2014 22:38:55 -0800 (PST)
Received: from DB3PR03MB0812.eurprd03.prod.outlook.com (25.161.55.144) by DB3PR03MB0811.eurprd03.prod.outlook.com (25.161.55.143) with Microsoft SMTP Server (TLS) id 15.1.16.15; Sun, 23 Nov 2014 06:38:32 +0000
Received: from DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) by DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) with mapi id 15.01.0016.006; Sun, 23 Nov 2014 06:38:32 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: "Rohit Mediratta (romedira)" <romedira@cisco.com>
Subject: Re: [Errata Rejected] RFC7257 (4059)
Thread-Topic: [Errata Rejected] RFC7257 (4059)
Thread-Index: AQHQBONeACPsIVzGZ0yR5QS2cW9v5Zxp3WUAgAPcvZw=
Date: Sun, 23 Nov 2014 06:38:32 +0000
Message-ID: <1416724708290.77016@ecitele.com>
References: <20141120165834.5C57018008D@rfc-editor.org>, <1DC9F8B59EE8154A9BB8AC6D817BD01512880747@xmb-rcd-x08.cisco.com>
In-Reply-To: <1DC9F8B59EE8154A9BB8AC6D817BD01512880747@xmb-rcd-x08.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [79.181.11.49]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0811;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0811;
x-forefront-prvs: 04041A2886
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(189002)(164054003)(377424004)(13464003)(92566001)(86362001)(92726001)(2656002)(87936001)(97736003)(64706001)(20776003)(19580405001)(19580395003)(15975445006)(21056001)(62966003)(77156002)(77096003)(122556002)(40100003)(110136001)(15202345003)(50986999)(76176999)(54356999)(15188155005)(101416001)(16799955002)(31966008)(46102003)(120916001)(99396003)(117636001)(66066001)(36756003)(95666004)(105586002)(4396001)(107046002)(106356001)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0811; H:DB3PR03MB0812.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/TER1-NxcfRnQdOSER1f8DEv45y0
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>, "pals@ietf.org" <pals@ietf.org>, "kkoushik@brocade.com" <kkoushik@brocade.com>
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Layer 2 Virtual Private Networks <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn/>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Nov 2014 06:38:59 -0000

Rohit,
Lots of thanks for your response.

Unfortunately I cannot say it addresses my concerns.

The erratum I've submitted has been about missing definition of VPLS Attachment Circuits as defined in RFC 4665; this definition equally applies both for VPLS implementing RFC 4762 and for those implementing RFC 4761.
RFC 4762  clarifies that "the attachment circuit (AC) connected to the customer could be a physical Ethernet port, a    logical (tagged) Ethernet port, an ATM PVC carrying Ethernet frames, etc., or even an Ethernet PW". The last case in this list is out of scope of my erratum, but all the rest are. 

>From my POV the VPLS MIB should support the following minimal set of operations for a VPLS AC:

- List a given attachment circuits belonging to a given VPLS instance (read-only)
- Add a new attachment circuit to a given VPLS instance, preferably without disrupting forwarding via already existing ACs or PWs attached to this VPLS instance (read-write). This basic operation should be as simple as possible
- Remove an attachment circuit from a VPLS instance, preferably without disrupting forwarding via already existing ACs or PWs attached to this VPLS instance (read-write).

Coming back to RFC 7257, my reading did not find any explicit mention of attachment circuits (easy to check!).
This, by and of itself, looks problematic to me.

Implicit reference to attachment circuits via the PW MIBs is also problematic because:
- RFC 5061 only mentions attachment circuits in the following context: "When the PW is managed as an ifIndex, by default it SHOULD NOT be stacked, i.e., this ifIndex SHOULD NOT be layered above the respective PSN tunnel ifIndex or the attachment circuit ifIndex or the interface carrying the attachment circuit." 
- RFC 5062 does not mention attachment circuits at all
- RFC 5603 (Ethernet PW MIB) allows association of one or more pairs {Ethernet Port, VLAN} with a given Ethernet PW instance  with the Ethernet port being represented by its ifIndex (pwEnetPortIfIndex). However, it explicitly states in description of pwEnetPortIfIndex  that "This object is used to specify the ifIndex of the Ethernet port associated with this PW for point-to-point Ethernet service, or the ifIndex of the virtual interface of the VPLS instance associated with the PW if the service is VPLS".  From my POV this means that Ethernet PWs associated with a VPLS instance cannot refer via this attribute to any Ethernet ports.

Last, but not least, I'd like to mention Tom's response to my question on the mailing list (referenced and quoted in the original Erratum). To the best of my understanding it does not match your response.

I agree with the Adrian that errata are not intended for fixing major gaps in already approved and published RFCs.

I will consider posting a draft (7257bis) fixing this problem, and I would be glad to work together with you and/or the rest of the authors of the original 7257 in this.

Regards,
Sasha 


________________________________________
From: Rohit Mediratta (romedira) <romedira@cisco.com>;
Sent: Thursday, November 20, 2014 8:55 PM
To: RFC Errata System; Alexander Vainshtein; tnadeau@lucidvision.com; kkoushik@brocade.com
Cc: adrian@olddog.co.uk; iesg@ietf.org; l2vpn@ietf.org
Subject: RE: [Errata Rejected] RFC7257 (4059)

Hi Alexander,
  The mapping is done through the PW-MIB. The pwIndex is an index into vplsPwBindEntry of the VPLS-MIB.
Please refer to Figure 1 of RFC 7257 for the linkage.

Thanks,
Rohit

-----Original Message-----
From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]
Sent: Thursday, November 20, 2014 8:59 AM
To: Alexander.Vainshtein@ecitele.com; tnadeau@lucidvision.com; kkoushik@brocade.com; Rohit Mediratta (romedira)
Cc: adrian@olddog.co.uk; iesg@ietf.org; l2vpn@ietf.org; rfc-editor@rfc-editor.org
Subject: [Errata Rejected] RFC7257 (4059)

The following errata report has been rejected for RFC7257, "Virtual Private LAN Service (VPLS) Management Information Base".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7257&eid=4059

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Alexander ("Sasha") Vainshtein <Alexander.Vainshtein@ecitele.com>;
Date Reported: 2014-07-23
Rejected by: Adrian Farrel (IESG)

Section: 6

Original Text
-------------
N/A - this is about some missing MIB objects that should be there

Corrected Text
--------------
N/A - this is hardly the right place to define missing MIB objects

Notes
-----
As per RFC 4762 (which defines at least one of the two VPLS types for which this RFC defines Management Information Base), Virtual Switching Instance (VSI)(a local representation of a given VPLS instance within a given PE) is connected to CE devices via Attachment Circuits (AC). Hence I would expect that Management Information Base for VPLS would provide for some representation of ACs that perform this function for a given VSI.

However, this RFC does not even mention attachment circuits in any way.

I have tried to raise this issue with the WG and the authors. One of the authors has replied (see http://www.ietf.org/mail-archive/web/l2vpn/current/msg04539.html) that "ACs are attached to the VPLS instances and are represented as IfMIB entries". However, neither Interfaces MIB nor any of its key elements (e.g., ifIndex) are mentioned in this RFC.
 --VERIFIER NOTES--
The errata system isn't to be used for recording future work or major defects in RFCs. These need to be taken to the relevant mailing lists (in this case pals@ietf.org) and progressed with Internet-Drafts.

This concern could probably be addressed through a new MIB module that augments the on in RFC 7257.

--------------------------------------
RFC7257 (draft-ietf-l2vpn-vpls-mib-15)
--------------------------------------
Title               : Virtual Private LAN Service (VPLS) Management Information Base
Publication Date    : July 2014
Author(s)           : T. Nadeau, Ed., A. Kiran Koushik, Ed., R. Mediratta, Ed.
Category            : PROPOSED STANDARD
Source              : Layer 2 Virtual Private Networks
Area                : Routing
Stream              : IETF
Verifying Party     : IESG