Re: [bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-vpws-13: (with COMMENT)

Robert Raszuk <> Sun, 07 May 2017 20:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7328C12932A; Sun, 7 May 2017 13:05:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d93C9woNlNyx; Sun, 7 May 2017 13:05:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B2F5E120721; Sun, 7 May 2017 13:05:33 -0700 (PDT)
Received: by with SMTP id k91so39665230ioi.1; Sun, 07 May 2017 13:05:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=AUJ3/PJg/ql2PmtClptSyQ0xK/plpLvJfByVi47fryI=; b=h9oOFVrztO3kZtryIto2Z1BA8sY3DAqzuNONJisMegxYbFneFQWu+YlhOQsjjM74N9 b3Nj+JE95nV5CNK26L50xvqlrGv36frUm/vehLEQ2mMhL01EDxeGwBfrIRRSYs8//Y1M joQnMzb5Q5CMapCDTKvdv+GlBo9qRLRyyE1cU3YNPYJ4WjJqbjjkkXWT+N2sqyTaloUa 1OY+MFS0g1Yza1mm3LYH0ri6Rc0AXWWNapqLOrQM0QNWvHZXZZApTFpn/bnXjqoTMISv xOdU536ccqTuV5nUfXnvaeaQE2mu4xi0LvSY6KwS2HorXmTp4wcxqEl1p5rASoMkPWlM pskw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=AUJ3/PJg/ql2PmtClptSyQ0xK/plpLvJfByVi47fryI=; b=JwzKbykXokEtgW9f7EhzUlQdDMK/xJ7WJTAhNsEcgOj+p1AYAM9q1LIeAM/4BF1hTw PNHCuMSJ/+CmvcswEpgRw2RdV4psa3CBix5eEVwLwN3CssfYpr3qZ5FUVrJXRi3FBlCq fyNH6XdJRYCS3dhffQGdqv8zEXZbmt6lgfrK6uToSnLY0wOwBEDtVK66y8fbiCza9yyW 8L7i93wNM1Qwq3/DPGYEh/o5ULIefyUcpPazAA2LZxAbItoHduEyrKn1M11Gwu+as1/l Y+a1DCv+shexmeYXLOSUrLT0hPx4aPG2CjO3pLgf4qPNorxZMI+QNCED4q3EZLj2Z3Vi 2yTA==
X-Gm-Message-State: AN3rC/4YY72jkZeumpmIZBpZPXExi2XrSjdiRzt3CrqOuWsaODgYM/dy jSHET2HJ3g3CiyufPUwJZkvr4tm/ig==
X-Received: by with SMTP id n189mr54351850iof.179.1494187533072; Sun, 07 May 2017 13:05:33 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 7 May 2017 13:05:32 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Robert Raszuk <>
Date: Sun, 07 May 2017 22:05:32 +0200
X-Google-Sender-Auth: 45ibfCzaUslIftmT1jMScvu41fw
Message-ID: <>
To: Warren Kumari <>
Cc: "Alvaro Retana (aretana)" <>, "Jeffrey (Zhaohui) Zhang" <>, The IESG <>,, "" <>,
Content-Type: multipart/alternative; boundary="94eb2c0c85e42300e1054ef4a5c4"
Archived-At: <>
Subject: Re: [bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-vpws-13: (with COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 07 May 2017 20:05:37 -0000

> is there any reason for the authirs *not* to make things easier for your
> readers by saying: "
> This document describes how EVPN [RFC7432] can be ..."?

​That clearly is a good edit suggestion for all alone occurrences of
[RFC7432] in the draft. ​

That sounds like a fine idea - perhaps the authors should add something
> like "Readers of this document are expected to be familiar with RFC7209 and
> RFC7432."
> Mainly I don't understand why we wouldn't want to make it easier for
> someone new to the technology...

​I think in number of IETF drafts extending existing specifications there
is an implicit assumption that the reader is ​familiar with the base spec
or specs around it related to new work. IMHO normative or informative
references is a good place for it. So Adding RFC7209 to the latter may be
indeed helpful.

- - -

Regarding the draft itself my personal comment is that just like other
specs defining VPWS service this proposal also fails to include OEM section
describing or even defining tools which will allow user of such emulated
circuit to get all errors (or even MTU fluctuations) from the underlay it
traverses to be exposed and reported to the wire/circuit end points.

Being on the enterprise side which uses such circuits I can only see now
that there is huge missing gap between providing spec to construct given
service and the perspective of actual use of such emulated wires
established over third party IP or IP/MPLS networks.

IMO OEM NNI between those two planes should be made mandatory in all specs.

Kind regards,