Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07

Siddhesh Dindorkar <> Wed, 28 August 2019 21:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 127D1120089 for <>; Wed, 28 Aug 2019 14:43:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 Le54uCjKiO9Z for <>; Wed, 28 Aug 2019 14:43:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B821120059 for <>; Wed, 28 Aug 2019 14:43:01 -0700 (PDT)
Received: by with SMTP id g4so1315085qtq.7 for <>; Wed, 28 Aug 2019 14:43:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zKDaAkoFxHW7RTL4RY+/dltEUxWZQL+7DRSHzlxIXYk=; b=17o/S93OeHQRREHv9T0OJbi07jFC/sFObuZ6qD8jycyQtXQNuGPuMuoH2Jr0xeeDQi uvnZde7XDuTFlT/6zvDGgKvdJbjG2V5bTsuuxcoGT/pNURSwl4l0P101pTiKrkrRHf9t jmhKmNWBe2nTCdUgeB5R87JKRBkoHE6/1t3+0b/j88w7Sh5q489FOa42J3WmfAjAd8+z 8MKin4ghOXuTR29xZDhYvoxKUBihtDt0B3dyJ0mjnulMeD2WO8vb1AgnWSPXDYULsjIh YIeILcPb5RxjgWO3WMhkNstA/m1uS4+lmc+EhcwYBjQyFHwloX2l/8rQAyvNTsRXQ7g1 dcfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zKDaAkoFxHW7RTL4RY+/dltEUxWZQL+7DRSHzlxIXYk=; b=A6s7EZSF1o4dNHCtFbogqaclwvI5DTN43K3FIkqnXb/7Eq/gMmTNNHyUaJSzYrPyiU JsEJAa/Kmvndn/7jXwDsQ/Py9Bcyu6v+eAKNZ7a3GAOsF7CSE7bZGA7HA8gSPaLIJ0gp c50MRNSlv2geGTIzvpb8EqEbuOlT45crwwcXO8Hkstesz+pGR/HZ2JE7/Di0oAmDYNzx seOwe4ReOGYJFXpTFhwKVUf3r72yjokCd1DM7YfVN5ZFI6bKwd2gbs+YdwkGMGTabxux eW5IW1MI9GFYFJbDxRJQPYAwRmxuU3xetvYicfHZajxhGKE9BHzDytMNlP4AawzcFY0R ATKg==
X-Gm-Message-State: APjAAAWw7uTy4MoBlRLbU83tX425Bc1wTsnI2YVVOHopr1R3CVFBlfjk a/HlX4KOnQhfQCtsjZULVpQCEdxNGSOnfSBFrnLaIQ==
X-Google-Smtp-Source: APXvYqziudjcekcsTQXA6uYxe0JRWSL0thAHmPageJQg3bhcPKepRjrF2eR1KLa/Dx0Be8d+oZq4s3F9C2XyJm93De0=
X-Received: by 2002:aed:2e02:: with SMTP id j2mr6400490qtd.89.1567028580017; Wed, 28 Aug 2019 14:43:00 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Siddhesh Dindorkar <>
Date: Wed, 28 Aug 2019 14:42:48 -0700
Message-ID: <>
To: "Ali Sajassi (sajassi)" <>
Cc: Stephane Litkowski <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000dd86c205913445cf"
Archived-At: <>
Subject: Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07
X-Mailman-Version: 2.1.29
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: Wed, 28 Aug 2019 21:43:04 -0000

Hi Ali, thanks for the detailed comments. We understand your view and those
were the discussion points within us as well. However, in reference to your
RR point #3, one of the reason for a vendor specific evpn route type is to
be able to do prototyping within small scale deployements which use other
vendor RRs. Even if we have RFCs for new route types, other vendors may not
implement them if they dont need those usecases and/or is not a release
priority. Hence again comes the restriction in using other vendor RR until
the new route type is implemented by the RR vendor.


On Tue, Aug 27, 2019 at 3:27 PM Ali Sajassi (sajassi) <>

> Hi Jorge,
> I will support this draft if it is modified to specify the routes for
> SD-WAN application specifically as opposed to have an opaque route. My
> concerns are the following:
>    1. The main idea of standardization is interoperability among vendors
>    and this draft doesn’t give us that.
>    2. Also I don’t think having such a draft can facilitate prototyping.
>    This draft has been around for several years and your prototyping should
>    have been independent of this draft since I am not aware of any other major
>    vendor implemented or deployed this draft.
>    3. Even if this draft becomes an RFC, there is no guarantee that in a
>    given network the RR will be compliant with it as we have experienced such
>    things first hand in the field
>    4. Making dependency of an IETF draft on IEEE process is not a good
>    thing – i.e., an new vendor that wants to implement it now needs to apply
>    for an IEEE OUI.  OUI gets allocated to the vendor with Ethernet PHY for
>    MAC addresses and not as route distinguisher. I am not sure how IEEE will
>    look at this. Have you discussed your application with them (e.g., OUI for
>    non-related Ethernet PHY/MAC)
>    5. RR can be used as store and forward mechanism for data that didn’t
>    use BGP before. I have already seen that some people want to use BGP for
>    passing configuration, stats, diagnostics info, etc. With now defining an
>    opaque route, there will be no check on the contents of the route and
>    anyone can put anything they want even if it is not best suited to do them
>    in BGP.
> So, frankly, I don’t see any positives here but just negatives. Can you
> replace the opaque route with the actual routes. At the end of the day, we
> have to do it for multi-vendor interop anyway. So, the sooner, the better.
> If single-vendor deployment is sufficient which is typically the case for
> Enterprises, then there is no need to standardize such draft.
> Cheers,
> Ali
> *From: *BESS <> on behalf of Stephane Litkowski <
> *Date: *Tuesday, August 20, 2019 at 2:16 AM
> *To: *"" <>
> *Subject: *[bess] WG adoption call and IPR poll for
> draft-rabadan-bess-vendor-evpn-route-07
> Hi,
> This email begins a two-weeks WG adoption poll
> for draft-rabadan-bess-vendor-evpn-route-07 [1]
> Please review the draft and post any comments to the BESS working group
> list.
> We are also polling for knowledge of any undisclosed IPR that applies to
> this Document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document won't
> progress without answers from all the authors and contributors.
> Currently, there are no IPR disclosures against this document.
> If you are not listed as an author or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
> This poll for adoption closes on 2nd September 2019.
> Regards,
> Stephane and Matthew
> [1]
> _______________________________________________
> BESS mailing list