Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS and COMMENT)
"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Thu, 21 October 2021 14:11 UTC
Return-Path: <zzhang@juniper.net>
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 E360E3A16E6; Thu, 21 Oct 2021 07:11:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level:
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=juniper.net header.b=gV4xvi2c; dkim=pass (1024-bit key) header.d=juniper.net header.b=BlZJXL+d
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 2jKWsAxD5mJk; Thu, 21 Oct 2021 07:11:08 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38E903A16E1; Thu, 21 Oct 2021 07:11:08 -0700 (PDT)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19LCselx009547; Thu, 21 Oct 2021 07:11:04 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=k5rdKdSDD8y+tb+KbN5kGseT7niGdgVT0nmVUoQgG8o=; b=gV4xvi2cNnzPLMHd/bG3eSWw4rbxq1qYJlXBNzsHFm/gCneORgdLJEDAobIfUdT4CPck 3IDWeCo+/6sgr9772kBKjXQdvdQiH41NKITdyw2en9T9s2OtGyZTrPvRN6L7KHdBuXCh gB43qwaA6pCjq/Mw2eq8HZIxHe+AABPlpQJw15DjtCTc6hsraoMhqlPcGQ5Kepit/xOG tU+9a3xS49DGZC0ShQBP8Hk6zgbsmIE9AItmx1eMZN9VkdV8P39X07YimOdHWDJHV25J LKHtpt9/rh8tHT74HD2khUiWHkDWc5R69X+5OXDswMEeqa757JdBesnIg3CoW4q02DA9 tw==
Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2168.outbound.protection.outlook.com [104.47.56.168]) by mx0a-00273201.pphosted.com with ESMTP id 3bu8mh8657-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Oct 2021 07:11:04 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IWOh6nVHhPBxo+2390VYUClRXmOxt98DvsnoW0VerWJfe8e/yV2AMtxGnh1c64qc8/mudyPt4YgqDnc586q4H10+mrElux8TP1NofnDjj8Zhv9cvRP78T9OmRCR37Ijz/YtLjk01vY13blYEbid4iI0r3EHmFmhsKkxl+r9xfqhsydruOVZf007SGSB2VB+zNjd70XczRfqcAOWrW2IFVKv/PHFnzUePLXoPra6xH6EJaAKPNAnNk6LzmVgEDeuo9N9DzdnoVqKYhTJ5BgfW5ceDYwTMFqlMLNhuFtMXGih7aW0FjBeL8YZWmfXBgIzktajEnL0fOdT7QyICx+/taQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=k5rdKdSDD8y+tb+KbN5kGseT7niGdgVT0nmVUoQgG8o=; b=QpsSr8eM7slfOcevqFxnsVnwiVGk5YxxaA0RSeqAizRlZqF88h6vndC4DMFy7rUnYJeBo/NExsog+AHQXCaJu+Gts4NLc+MiMGbogfyscD0diI9FYWMpv29BX6Apf5tUGFNJtCZqA9fQYTTlEFQIj0TpGupf/eT115d47cLJYCGSi9yWzf3gjqyucTbSTm65+OruewVkTvAKN3jGd2l1SwIhksqy8ZFQqfroWUhA0ewBGQqw+wUu3pJrgPU5pCjF40iNd1BJI8Dn2ytEkuLWXs4sHW7fx6gLnKqJW9UAjJZh8j6JxT7Mfujhwq98jueIeTbnGRdBO5/mZq+b4bMkGw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k5rdKdSDD8y+tb+KbN5kGseT7niGdgVT0nmVUoQgG8o=; b=BlZJXL+dWbfJW8QB9UHCSmnuQc4LenzW2eeiBbsYjwy/1PnINY4Dr3U5RK0FnmeGt81E3GnuTqNxsht6xvCF41lN/Nb/9r5lSJDFqLQgvIxccJPKodyQ4wdH7MoGMmD9DiGeaN0Y6qBshqzRvOErWJLYJUJp2pSdrPK8NopnTNM=
Received: from BL0PR05MB5652.namprd05.prod.outlook.com (2603:10b6:208:6a::19) by BL0PR05MB4946.namprd05.prod.outlook.com (2603:10b6:208:8c::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.13; Thu, 21 Oct 2021 14:11:02 +0000
Received: from BL0PR05MB5652.namprd05.prod.outlook.com ([fe80::311e:aa39:d3cc:db8d]) by BL0PR05MB5652.namprd05.prod.outlook.com ([fe80::311e:aa39:d3cc:db8d%7]) with mapi id 15.20.4649.010; Thu, 21 Oct 2021 14:11:01 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "draft-ietf-bess-evpn-bum-procedure-updates@ietf.org" <draft-ietf-bess-evpn-bum-procedure-updates@ietf.org>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "bess@ietf.org" <bess@ietf.org>, "EXT-zzhang_ietf@hotmail.com" <zzhang_ietf@hotmail.com>
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS and COMMENT)
Thread-Index: AQHXxj9xbFZfrcWHn0u5uFOJuB9Pbqvdeo2A
Date: Thu, 21 Oct 2021 14:11:01 +0000
Message-ID: <BL0PR05MB565267D77F58E52C11A662EFD4BF9@BL0PR05MB5652.namprd05.prod.outlook.com>
References: <163479537252.27220.2471413856188998579@ietfa.amsl.com>
In-Reply-To: <163479537252.27220.2471413856188998579@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.6.100.41
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=ff12e481-2b45-4279-b200-1d9c18aa30b8; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-21T13:57:02Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4;
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=juniper.net;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9f917429-120a-45bf-000f-08d9949c9cff
x-ms-traffictypediagnostic: BL0PR05MB4946:
x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr
x-microsoft-antispam-prvs: <BL0PR05MB4946BE01D9F63C72CCB25ECCD4BF9@BL0PR05MB4946.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: iMQxWshDCGnl76Dl2A4WjC1ydjN2pyo1wqbVftTxb8mAcdeabPEfBNEys+BV9ZZh7g9LczKtrLLppP0XNpEmSs1LhNJTcYHEzSqYLfK9jR+XyuIYmvbt8Yxjqo5rSnniRI1fiNDvN6FQ9XFK2AmO3XLUtnd3kP62m/QOTJ4zqqChQZL9FinKBzwAaQeAuYKaO11W1Bm9MqAVxvFoNiev50wEhafh9HZ4VtFT57WEl1xrk7WDz/kTGcKJ5r8SHRXmIZkLV/OQOGBNUvMBB1jAhQm5Q7lqx1F+JpD/iGWCUM7tWeKXpvQ2zmZwCXi+Kjz0p9ariYrBKqh05mcqO6enutwXfQtq/Ll8b55qU6iDo68EFFv1fmZ5flDGRNA0KDISS5pAVRFPUnsRWynD+YaVlT0bdbpMMgUim9u3q/xQfS52tHHT8Bb9m55ZPdqg1lpfPBKpubXISN43FeVeiIZww4ZiqDhcreKKbiWUi7THG9ouWLMWo6umeMBVjmg6v4KvXhgTpA2IocYJR22Wv1VX5h45aMNbc6+l1lqwLgroRK2T8NezgxdWEmQX+rZPCuRAU+F/SjZ882YlYL5QetWdV8InMU9CRDmDQAPitWHfCtDBwLStOxPh2FsYKMwsVBgUSqjaXIqh9ZiJVOLpQawOvRTsrxAoBB0Miz+bZBGRbYkai3d8YoOo371htqQ9qoRlT4jvCXsMOMDhhb9l028MYxAnqyc6VU1a+qgR7hY69GBMmDD/lePNqirkZFPP72nhGZ+/D8wHITqoHBpkOtB0yG7UfYxuRll5aA/ZhzNNKsiHJizoQcj4socor/gLim3dJfD+eRvW3ibvgnjJSG0onA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5652.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(33656002)(83380400001)(2906002)(66574015)(316002)(966005)(30864003)(186003)(8676002)(54906003)(110136005)(7696005)(45080400002)(6506007)(71200400001)(64756008)(53546011)(66446008)(66556008)(4326008)(15650500001)(66476007)(508600001)(9686003)(38070700005)(5660300002)(66946007)(38100700002)(52536014)(76116006)(8936002)(86362001)(122000001)(55016002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: UJLmiQISBU9DQxJYR9ZxPqJAS1S5fzs2IfSah59jTyejCfJTL/Or8Bb+Q+S4OaBIP4Xz2LsiNg+b4/MCfsrJSTymkBZHLv/fTT48FtadbU1V09yN0l5okjRMgr5qxDsfbCOlLG9vp/GP5rBN3Yi3bphwCw0u7K9NcKeW8NeGwIwpNZlckqwgv/CCJr+Qrr1WOuwcsT9Jtilw5pFGuKV41Y3leU+mfVxVk7HwgyzjEjSNaB/nUtP1BqCoqlQfFdVm6uG/yRraSshnpTXXGnf/keKG0/rWRFSvL5EfWPEPC8A+alsmQvv4yYeMwPBZ7lcw3eUtGoSu/bX3PpoPlpjPV5YpHqQPS1DeR9ej4WydRtceKUtUrrKQQ/kRuxdeKWQ6dDycFqzSgnKjQSOAj4q7MiO7RYU/Yqcca14scSMpzH5oazhhBZ/Yn92+SgZbTDryFLxrsPN23kFAVCu0wXWfL6owyBR72IuQWW1wt1V3ZP+EvlULfRnIyA2ZrX5Bwh8T02snIvPaGsR9jJIbg18nWThPKrA06pGNRAzoMm8X6OEvrpWzWJtw83Kx9PRLQB40/Th3lowtv6qxkXctlSx8Y9oPhaQLBaxji4/4KyvrmmdeyS4bX8E/53GmlHVo/bxcxtBhWHmidaqC3nuLNQDJL25Tm3zJ0RPgp3bnlzzay/qrClVmykLm5HN3c5yAa9fpy6vhIC0kdRzKElMPmt8KzgG+u4I9vyEVOc40kmF0mdxm/tz2ZSyIBc/ApEw2pneIlHgWN9SuH4zEOcXT15o+VubBSFqTk6VCa6hBE4+Z1JSNGw5ukONUycGabrvTFMobJx1xhtUcbAylvua3Ga2lTk2nQmmHPouEolxVX6nC0hcWxbDyLPKnWWgODlQR5Ih8r4OV/v5vNZaMrB5/edNTO/+zZS/hEhyXOPMcb7kS7pff8JZ44a7XpQVZ0XmGT29uDYTtCAYm2qeDuk8+W10VNf6SpGEiiQkZKSK7KhUDm5OuIocP2dBiS2yAMgcU+AZLqj/GTyiy+k1rFBhZVS6WUOFWxSBvw3/uCxhpGKSyO4nnwEPKCy60lj9WEC1l8ohu04jkxBHCgaXsXM8uzh3ZuQ2tgVaJf+ifesjB65yccGx0Iu3IICrXFNcVVnaNfKtCfW5iS9MfTFm7w3GKYt2NuRl4R92qczmgflghQI00FxXBlqS74pIUZNguaux37PXxYuJggcZCkqp1Ik+l1IJ8hwyNcnTmEWrVrLl1g3YtgH+/5EKZMl2S16LAQir/ZTr2Z8qfdP07SKFYoxEsSGDc1utZITWJ0KGNuBSVDRp/YzoYiQgrxDKVCAHTzG6pBQsQ8SO84o7JP6jAuMeZ3ZS2lLs1g3iwhKu8+45gO2YnQ6GkJm4SuG1yTvChdj74HgMtCmvl3Hpu1AmGT6kGW10vPfBaE35YWtbcNQ19fU0LcrMikQN3nNHjsEi39U0jSVet7QMayi/Fgp2vk1j1Ilr8XuUVHobHXa2RT4jLFzhm+Zc=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5652.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9f917429-120a-45bf-000f-08d9949c9cff
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2021 14:11:01.7533 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: zzhang@juniper.net
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB4946
X-Proofpoint-GUID: VRO3NAxpWOk1gEKHcydCGvTzYBiTKxRG
X-Proofpoint-ORIG-GUID: VRO3NAxpWOk1gEKHcydCGvTzYBiTKxRG
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-21_04,2021-10-21_02,2020-04-07_01
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1015 malwarescore=0 mlxlogscore=999 phishscore=0 suspectscore=0 lowpriorityscore=0 adultscore=0 spamscore=0 bulkscore=0 impostorscore=0 priorityscore=1501 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110210075
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/jsVBrHgN68-GKvADGyIjus-KMQ0>
Subject: Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS and COMMENT)
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: Thu, 21 Oct 2021 14:11:17 -0000
Hi Ben, Thanks for your review and comments. Let me first address the DISCUSS point below and then follow up with another email on other points. -----Original Message----- From: Benjamin Kaduk via Datatracker <noreply@ietf.org> Sent: Thursday, October 21, 2021 1:50 AM To: The IESG <iesg@ietf.org> Cc: draft-ietf-bess-evpn-bum-procedure-updates@ietf.org; bess-chairs@ietf.org; bess@ietf.org; EXT-zzhang_ietf@hotmail.com <zzhang_ietf@hotmail.com>; EXT-zzhang_ietf@hotmail.com <zzhang_ietf@hotmail.com> Subject: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS and COMMENT) [External Email. Be cautious of content] Benjamin Kaduk has entered the following ballot position for draft-ietf-bess-evpn-bum-procedure-updates-11: Discuss 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 https://urldefense.com/v3/__https://www.ietf.org/blog/handling-iesg-ballot-positions/__;!!NEt6yMaO-gk!S0XsefTxpcM08Cegf69h1Kt6chs_TkO5AGOfS5hXEhy1jFTSKNgIn4vlXZV7E-lH$ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/__;!!NEt6yMaO-gk!S0XsefTxpcM08Cegf69h1Kt6chs_TkO5AGOfS5hXEhy1jFTSKNgIn4vlXVyyzOC6$ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'm not sure whether the Leaf A-D route (route type specific field) as specified by this document is guaranteed to have a unique interpretation (§3.3). It's supposed to start with the "route key", which is just the route-type-specific field of the PMSI route that triggered the Leaf A-D route. That makes the route key variable length (as stated), and this variation is clearly achieved given that even the Per-Region I-PMSI A-D route and S-PMSI A-D route defined in this document have different length and layout. I'm not sure what information is expected to be available to bound and determine the length of this "route key" field, other than "not the rest of the stuff". "The rest of the stuff" is the originator's address and length thereof, but the length is in the middle of the structure, so even if we start parsing from the back we still can't distinguish reliably between a 4-byte IPv4 address and a 16-byte IPv6 address. It seems that the Originator's Addr Length would need to be the last field in order to provide a unique interpretation, with "parse backwards" used to extract the Originator's Address, and "the rest of the stuff" being the route key that can be matched to the triggering PMSI route. Is there some other procedure or contextual information available that ensurs a unique interpretation of this data? Looking at RFCs 6514 and 7117, it does not seem like this document has some key change that renders it fundamentally different in this regard, so I mostly assume that the received route can be disambiguated somehow; I just don't know what that way is. Zzh> All routes have the following format: +-----------------------------------+ | Route Type (1 octet) | +-----------------------------------+ | Length (1 octet) | +-----------------------------------+ | Route Type specific (variable) | +-----------------------------------+ Zzh> For a Leaf A-D route, its "Route Type specific" part is the triggering PMSI route's NLRI, so it explodes into the following (the three lines marked with '*' are the triggering PMSI). Route Type 11 (Leaf A-D) Length (of the entire Leaf A-D route NLRI) * Route Type x (for the triggering PMSI route) * Length (of the PMSI route NLRI) * Route Type specific (for the PMSI route) Originator's Addr Length (for the Leaf A-D route) Originator's Addr (for the Leaf A-D route) Zzh> With the above, there should be no problem parsing the NLRI? Zzh> Thanks. Zzh> Jeffrey ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1 It is expected that audience is familiar with EVPN and MVPN concepts and terminologies. For convenience, the following terms are briefly Please provide references for EVPN and MVPN that would serve as entry points for gaining such familiarity. E.g., RFCs 7432 and 6513/6514. explained. I suggest including PMSI Tunnel Attribute in this list, especially since RFC 6514 does not actually use the PTA acronym. Section 2.1 There is a difference between MVPN and VPLS multicast inter-as segmentation. For simplicity, EVPN will use the same procedures as in MVPN. All ASBRs can re-advertise their choice of the best route. While it is defensible to rely on the stated expectation that the reader is familiar with EVPN and MVPN concepts (hmm, which does not actually include VPLS concepts?), it would be appreciated to include some indication of the nature of the difference, before stating which variant EVPN will use. For inter-area segmentation, [RFC7524] requires the use of Inter-area P2MP Segmented Next-Hop Extended Community (S-NH-EC), and the setting of "Leaf Information Required" L flag in PTA in certain situations. Either of these could be optional in case of EVPN. Removing these "Could be"? It sometimes is and sometimes isn't? When is it still mandatory? Section 2.1.1 For example, an MVPN/VPLS/EVPN network may span multiple providers and Inter-AS Option-B has to be used, in which the end-to-end Is this "option (b)" of §7.2 of RFC 7117? Regardless, a specific reference seems in order. Another advantage of the smaller region is smaller BIER sub-domains. In this new multicast architecture BIER [RFC8279], packets carry a RFC 8279 was published just about four years ago. Does that still qualify as "new"? (I honestly am not sure, given the distribution of time from -00 to RFC.) Section 3 The "Route Type specific" field of the type 9 and type 10 EVPN NLRIs starts with a type 1 RD, whose Administrator sub-field MUST match that of the RD in all non-Leaf A-D (Section 3.3) EVPN routes from the same advertising router for a given EVI. Is the requirement really so specific as "everything except Leaf A-D"? What if some new type is allocated that also doesn't start with an RD? Is it safe to say that any type that does have an RD must meet this criterion? Section 4 The optional optimizations specified for MVPN in [RFC8534] are also applicable to EVPN when the S-PMSI/Leaf A-D routes procedures are used for EVPN selective multicast forwarding. Are we going to need a draft-ietf-something-bum-procedure-further-updates in another five years to perform the same type of "gap filling" that this document is doing for how RFC 7432 referred to the RFC 7117 procedures? Section 5.1 The above VPLS behavior requires complicated VPLS specific procedures for the ASBRs to reach agreement. For EVPN, a different approach is used and the above quoted text is not applicable to EVPN. What about the text we didn't quote, that places MUST-level requirement on the "best route selection procedures" that determine whether a given ASBR re-advertises the route within its own AS? "The PMSI Tunnel attribute MUST specify the tunnel for the segment. If and only if, in order to establish the tunnel, the ASBR needs to know the leaves of the tree, then the ASBR MUST set the L flag to 1 in the PTA to trigger Leaf A-D routes from egress PEs and downstream ASBRs. It MUST be (auto-)configured with an import RT, which controls acceptance of leaf A-D routes by the ASBR." It seems like we might want to make some further statement about what scope that import RT is expected to limit acceptance of the route to. Section 5.2 considered as leaves (as proxies for those PEs in other ASes). Note that in case of Ingress Replication, when an ASBR re-advertises IMET A-D routes to IBGP peers, it MUST advertise the same label for all those for the same Ethernet Tag ID and the same EVI. When an ingress This seems like an eminently reasonable thing to require. I wonder if it's worth saying a little more about why it is required, though -- what breaks if you don't do this? PE builds its flooding list, multiple routes might have the same (nexthop, label) tuple and they MUST only be added as a single branch in the flooding list. I'm not entirely confident that I could implement this behavior for the flooding list right now. On the other hand, I also haven't written any BGP code, so maybe it's expected that I couldn't implement it, but it still seems like this might be glossing over some details. Section 5.3 o An egress PE sends Leaf A-D routes in response to I-PMSI routes, if the PTA has the L flag set (by the re-advertising ASBRs). I don't think I understand the parenthetical. Which previous text is it intending to refer to? Additionally, while we mention in the first paragraph of §5.2 the RFC 7432 requirement to not set the L flag in IMET A-D routes, I don't see where we lift that requirement for the segmented procedures. The change in §5.1 to let the ASBR set the L flag does not seem constructed in a way that lifts the requirement from §11.2 of RFC7432. To address this backward compatibility problem, the following procedure can be used (see Section 6.2 for per-PE/AS/region I-PMSI A-D routes): Can be used, but is in no way mandatory, not even to implement? That's rather surprising. o The ASBRs in an AS originate per-region I-PMSI A-D routes and advertise to their external peers to advertise tunnels used to carry traffic from the local AS to other ASes. Depending on the This may or may not just be a grammar nit: *what* do the ASBRs advertise to their external peers to advertise tunnels? (Are we just missing "them" for "advertise them"?) Section 6.3 [RFC7524] specifies the use of S-NH-EC because it does not allow ABRs to change the BGP next hop when they re-advertise I/S-PMSI A-D routes I failed to find any place where RFC 7524 used the string "S-NH-EC", and suggest writing out "Segmented Next-Hop Extended Community" somewhere. Section 9 I would posit that at least some of the security considerations from RFC 6513 are relevant here, in addition to the (already mentioned) 6514 considerations. Section 12.1 I do not think that RFC 7988 needs to be classified as normative; we reference it only once, in an example; RFCs 4875 and 6388 are used in the same way for the same example, but are classified as informative. Section 12.2 I don't see what's different between RFCs 6513 and 6514 to make the latter normative while the former is informative -- they are referenced in largely the same places, and often. NITS Abstract This document specifies procedure updates for broadcast, unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN), I'd suggest NEW: This document specifies updated procedures for handling broadcast, unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN), Section 1 o IMET A-D route [RFC7432]: Inclusive Multicast Ethernet Tag A-D route. The EVPN equivalent of MVPN Intra-AS I-PMSI A-D route. I would say that a de novo explanation is likely to be of more general applicability than a dense MVPN reference. Perhaps "Advertised by PEs to enable reception of BUM traffic for a given VLAN" or similar? o SMET A-D route [I-D.ietf-bess-evpn-igmp-mld-proxy]: Selective Multicast Ethernet Tag A-D route. The EVPN equivalent of MVPN Leaf A-D route but unsolicited and untargeted. Likewise, this might be something like "Advertised by PEs to indicate that the indicated BUM traffic should be sent to the advertising PE." Section 2 [RFC7117] specifies procedures for Multicast in Virtual Private LAN Service (VPLS Multicast) using both inclusive tunnels and selective tunnels with or without inter-as segmentation, similar to Multicast VPN (MVPN) procedures specified in [RFC6513] and [RFC6514]. s/to Multicast/to the Multicast/ Section 2.1.1 Segmentation can also be used to divide an AS/area to smaller regions, so that control plane state and/or forwarding plane state/ s/to smaller/into smaller/ Section 4 of egress PEs for selective forwarding with BIER). An NVE proxies the IGMP/MLD state that it learns on its ACs to (C-S,C-G) or (C-*,C-G) SMET routes and advertises to other NVEs, and a receiving I think s/and/that it/ NVE converts the SMET routes back to IGMP/MLD messages and send them s/send/sends/ Section 5.3 o An ingress PE uses the Next Hop instead of Originating Router's IP Address to determine leaves for the I-PMSI tunnel. It was not previously required to use Originating Router's IP Address, so maybe s/instead of/and not use/. Section 6.1 changes the next hop to its own address and changes PTA to specify the tunnel type/identification in the neighboring region 3. Now the I'm not sure that we ever explicitly named the region. We implicitly do in the following figure that says "segment 3", but the number and string "region" don't seem paired anywhere directly. Section 6.2 propagated to other regions. If multiple RBRs are connected to a region, then each will advertise such a route, with the same route key (Section 3.1). Similar to the per-PE I-PMSI A-D routes, RBRs/PEs Mention of route key seems to be in §3.3, not 3.1. Section 6.3 NH-EC. The advantage of this is that neither ingress nor egress PEs need to understand/use S-NH-EC, and consistent procedure (based on BGP next hop) is used for both inter-as and inter-region segmentation. s/consistent/a consistent/ Section 7 including Ingress Replication. Via means outside the scope of this document, PEs know that ESI labels are from DCB and existing multi- homing procedures work as is, whether a multi-homed Ethernet Segment spans across segmentation regions or not. I'm not sure this is a well-formed sentence. Is it supposed to be a list? Or just two things that PEs know OOB: (ESI labels are from existing multi-homing procedures work as is) and (whether or not a multi-homed Ethernet Segment spans across segmentation regions)? Juniper Business Use Only
- [bess] Benjamin Kaduk's Discuss on draft-ietf-bes… Benjamin Kaduk via Datatracker
- Re: [bess] Benjamin Kaduk's Discuss on draft-ietf… Jeffrey (Zhaohui) Zhang
- Re: [bess] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [bess] Benjamin Kaduk's Discuss on draft-ietf… Jeffrey (Zhaohui) Zhang
- Re: [bess] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [bess] Benjamin Kaduk's Discuss on draft-ietf… Jeffrey (Zhaohui) Zhang