Re: [bess] Deborah Brungard's Yes on draft-ietf-bess-evpn-vpls-seamless-integ-05: (with COMMENT)

"Ali Sajassi (sajassi)" <> Tue, 22 January 2019 08:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C35F012E04D; Tue, 22 Jan 2019 00:36:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -19.053
X-Spam-Status: No, score=-19.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jdniCltbc9_a; Tue, 22 Jan 2019 00:36:57 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A523D128BCC; Tue, 22 Jan 2019 00:36:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2808; q=dns/txt; s=iport; t=1548146216; x=1549355816; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fwsEKd3tzcikb8/8OFxlnZBZ/DhfmLDnqsvlRSyDvMc=; b=g/e6pgjfJOpjjo7SOMzB/JnbuK117iTKp9zR3e/+F8kQf1VVstu5XhhD vsiHXl+c25DH8ZGcjT7xXjWfDy2SRQ7mn+0gkj9pvTOfd78gWkT/E39Nd zxzua6/nDZLsYnz8sDV6UlDPMIhc2mYhga4SPSqKRtA1Hh6dFe836pLeQ w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.56,505,1539648000"; d="scan'208";a="229673274"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jan 2019 08:36:55 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id x0M8at61017934 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 Jan 2019 08:36:55 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 22 Jan 2019 03:36:54 -0500
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Tue, 22 Jan 2019 03:36:54 -0500
From: "Ali Sajassi (sajassi)" <>
To: Deborah Brungard <>, The IESG <>
CC: "" <>, Matthew Bocci <>, "" <>, "" <>
Thread-Topic: Deborah Brungard's Yes on draft-ietf-bess-evpn-vpls-seamless-integ-05: (with COMMENT)
Thread-Index: AQHUqF8V1aXFeenvu0CGmvyoQ660CaW62DeA
Date: Tue, 22 Jan 2019 08:36:54 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [bess] Deborah Brungard's Yes on draft-ietf-bess-evpn-vpls-seamless-integ-05: (with COMMENT)
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: Tue, 22 Jan 2019 08:36:59 -0000


Thanks for your review and feedback. You are spot on. If the document was talking about only VPLS/PBB-VPLS or EVPN/PBB-EVPN, then BCP would be appropriate but this document specifies the mechanism needed for an EVPN/PBB-EVPN PEs to simultaneously interoperate with both EVPN/PBB-EVPN and VPLS/PBB-VPLS PEs. It specifies the control-plane and forwarding behavior for unicast, multicast, discovery of VPN members, and MAC mobility in context of such a mix mode. 


On 1/9/19, 1:05 PM, "Deborah Brungard" <> wrote:

    Deborah Brungard has entered the following ballot position for
    draft-ietf-bess-evpn-vpls-seamless-integ-05: Yes
    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)
    Please refer to
    for more information about IESG DISCUSS and COMMENT positions.
    The document, along with other ballot positions, can be found here:
    I agree with the current status as PS. While it does not define new
    codepoints or protocol extensions, it defines new mechanisms
    which need to be supported by all (PBB-)EVPN nodes. The mechanisms
    are not supported by operational configuration, they are new
    mechanisms which need to be supported by the node itself.
    A BCP/Informational status would be appropriate if this document
    was only defining the procedures related to the VPLS or PBB-VPLS
    PEs. For those nodes, there is no change, as all the new mechanisms
    supporting seamless integration need to be supported on the EVPN nodes.