[bess] Chair review of draft-ietf-bess-evpn-bum-procedure-updates

<slitkows.ietf@gmail.com> Wed, 13 November 2019 15:41 UTC

Return-Path: <slitkows.ietf@gmail.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD721200FA; Wed, 13 Nov 2019 07:41:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 aKDBnC7iWx8K; Wed, 13 Nov 2019 07:41:01 -0800 (PST)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A362B120073; Wed, 13 Nov 2019 07:41:01 -0800 (PST)
Received: by mail-wr1-x433.google.com with SMTP id a15so2887761wrf.9; Wed, 13 Nov 2019 07:41:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version:thread-index :content-language; bh=Xh1M0q8Qencfx3JyQPfMx7Hk0e9CqtnuMaJOuHFsoxs=; b=d0VOX30JO37Xg2+hApuniENyimpWvUCRN/ay61JCFpdTFJ09k5k8yxOQPk2VnCnIZ0 U37Hhb5DkZIDtZ8q8CMrqMOiANi8NsDcHP+e4j3uytx1P8PxOk8mqPYeHnkZPQh2j/Sy 5v3gkKzdR7rHvw2Ob3XIBNW+Oy3FU4C0DwL4gSFbBDBA+BLLaa5ITl2vdgnmA5dEw9Um cBwHSt2VUocptTwtfI3VF7lTQWzRB8Pffmbqby6ZCWkkR8qWnoCTiKDOQ4rtKLJa6Fo3 I/6T1DT8S+90sxJYFmEMau31ptnJYClwWh4O1uyAULRQVTIKE875b5pAg2CYADXHLyEf gGJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :thread-index:content-language; bh=Xh1M0q8Qencfx3JyQPfMx7Hk0e9CqtnuMaJOuHFsoxs=; b=TtopuIWY5a/0f+nkIQHdLYy3b6F8WhOyhBzlXKN1ERJ7ak6fyT3nJet4TXbUQdFc+O y7C4qtHfDYR1JkWRqp1M3PlXgQBgVOTjKA8fu74s7OzyUGQEJqIdEIP9WrOPMWiHGrv9 DvG3KHPm1bw3dtcvcEyggvf0SB4QGYljQ0bEzPet2Q8g0meX3djegP85jZkcdPmhyf4w L2h02seNxwN8EvcM6LS+qWvBxmt1spYRVNjPzoVpjDpZHFqauzBtv3Qz4KNRjbEeAEHs oH7XegC96o3t2t16VIuaY7EIv1ty2XZW/vBiMRyaWNqZZXJQNIhs36nN0isTXrdXgWHW l8ow==
X-Gm-Message-State: APjAAAUApSEHfv7SOXezjbEvvKqmjRT0IYXWb7lxsTbWXlX9/tjJ2ZHX xVCKgVhB+n9kQLQ5Ryhmanut6uM=
X-Google-Smtp-Source: APXvYqzYeXn5wFiirC7kplGWjF/T6/VcbJbBhD9cLHnwkr5oN7aIptswhTvrUlG+sxuwrd5xlMEMgA==
X-Received: by 2002:adf:d083:: with SMTP id y3mr3294881wrh.53.1573659659674; Wed, 13 Nov 2019 07:40:59 -0800 (PST)
Received: from SLITKOWS3YYU6 ([173.38.220.42]) by smtp.gmail.com with ESMTPSA id u7sm3684691wre.59.2019.11.13.07.40.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Nov 2019 07:40:58 -0800 (PST)
From: slitkows.ietf@gmail.com
To: bess@ietf.org, draft-ietf-bess-evpn-bum-procedure-updates@ietf.org
Date: Wed, 13 Nov 2019 16:40:57 +0100
Message-ID: <018e01d59a38$becade70$3c609b50$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_018F_01D59A41.20919060"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdWaMbQQDiEFR7jeRl6keTOttTevBg==
Content-Language: fr
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/um_Ss8RFx-sf2Wl0YyhqUwMVRk8>
Subject: [bess] Chair review of draft-ietf-bess-evpn-bum-procedure-updates
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Nov 2019 15:41:05 -0000

Hi,

 

Before moving forward to IESG, here is my review of the document:

 

Section 2:

"Note that these are to be applied
   to EVPN only, even though sometimes they may sound to be updates to
   [ <https://tools.ietf.org/html/rfc7117> RFC7117] or [
<https://tools.ietf.org/html/rfc7524> RFC7524]. >

The second part of the sentence is not really appropriate for a standard
document. The text should always be crystal clear that it applies to EVPN
only, reuse the procedures from other RFCs with the associated
modifications. But you must never talk about updating VPLS RFCs, if you
don't.

 

Section 3:

Not all the route types are coming from RFC7432, could you provide a
reference for route-types that are not defined in RFC7432 ?

 

Section 3.1:

As you say in the text, the extended community is not an attribute here.
Wouldn't it be better to rename it as Region ID, telling then in the text
that it is encoded similarly to an extended community using type/subtype/.

In case you agree, update of 6.2 is necessary.

 

 

Section 4:

s/and an receiving NVE/and a receiving NVE

s/In a nut shell/In a nutshell

s/S-SPMSI/S-PMSI

 

s/an egress NVE may omit the Leaf/an egress NVE MAY omit the Leaf

s/if it already advertises/if it has already advertised

s/and the source NVE will use that/and the source NVE MUST use that

 

Section 5.1

In the proposal text changes for 7.2.2.4 in RFC7117, please use normative
language s/must/MUST

 

Section 5.2:

I don't understand this sentence (ps: I'm not telling the sentence is wrong)
:

"Note
   that in case of Ingress Replication, when an ASBR re-advertises IBGP
   I-PMSI A-D routes, it MUST advertise the same label for all those for
   the same Ethernet Tag ID and the same EVI. "

Could you please explain me ? Do you mean that ASBR allocate the same label
for different routes with same ETAG/EVI ?

 

Consider the following setup

 

PE1 -(CORE)-- ASBR1 ---- ASBR2 ---(CORE)  ---PE2

                      --ASBR3 --- ASBR4 ---         ------- PE3

 

PE1 being the source of BUM.

 

PE2 and PE3 send IMET route for EVI1/ETAG1 respectively with label 20 and 30
(IR assumed).

ASBR2 and ASBR4 sends the route as Inter-AS A-D routes setting themselves as
NH and using PTA type set to IR. Does it set a different label value for
each Inter-AS A-D route ?

I understand that the behavior described above (from your draft) applies to
ASBR1 and ASBR3 which will readvertise the same label for both routes but
why not doing the label aggregation at ASBR2/4 ?

The text talks about I-PMSI A-D routes, but do you confirm that you talk
about Inter-AS I-PMSI A-D routes ?

 

In addition, you should use normative language in :

"When an ingress PE builds
   its flooding list, multiple routes may have the same (nexthop, label)
   tuple and they will only be added as a single branch in the flooding
   list. >