Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

Eric C Rosen <erosen@juniper.net> Fri, 23 March 2018 17:00 UTC

Return-Path: <erosen@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 A45A81200FC for <bess@ietfa.amsl.com>; Fri, 23 Mar 2018 10:00:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.711
X-Spam-Level:
X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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
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 QnZQ5b9qagpg for <bess@ietfa.amsl.com>; Fri, 23 Mar 2018 10:00:40 -0700 (PDT)
Received: from mx0a-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 1D02A12D94E for <bess@ietf.org>; Fri, 23 Mar 2018 10:00:40 -0700 (PDT)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2NGxpap011693; Fri, 23 Mar 2018 10:00:36 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=PPS1017; bh=yRBoEEGWfKUrmznTE+XXMmEDyJDVlFdnlTW1C3WO2ZE=; b=PXfrNIUpw3yRanFdp7sFFZiXbGzQpu1zcdEMrdKRN5D9+QE547DqHR6MQomuLBJx6GH2 e+CbzInMaf+UhKViw1voihRTkZeX/5qtKa6n8/oYXkuim5mzSDQX6r21mO4fF4d8xQA3 Cx+SGvBhu1KdelwZIlpVEsWOThXa4flt0vJiQ/mUvZTgWhXYG6COib1KKw78PX/Nm7uM fdsRmDRmEebMW9pmvCKNZos7ix+Aqrj+qhfxeS7w+mvDcnviCqSCAgf1jEGVY1Ss3q8O FkeE1lYtPJMc+QCrcPE3ko7gyaQ3iHkTdqW2q+Dh/1K024FCXg5r86aZ9+sWkIH7DgDk kg==
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0082.outbound.protection.outlook.com [207.46.163.82]) by mx0a-00273201.pphosted.com with ESMTP id 2gw4ttr2x1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 23 Mar 2018 10:00:36 -0700
Received: from [172.29.38.238] (66.129.241.12) by SN1PR05MB2304.namprd05.prod.outlook.com (2a01:111:e400:7a42::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.609.6; Fri, 23 Mar 2018 17:00:32 +0000
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>, Sandy Breeze <sandy.breeze@eu.clara.net>, "bess@ietf.org" <bess@ietf.org>
References: <53C24F41-B86F-4FE1-8041-721C95C7E7F0@nokia.com> <b4272e23-0b57-bc23-0840-4a4eb0991966@juniper.net> <373D0F59-2947-4370-9BDC-081E03867B2E@nokia.com>
From: Eric C Rosen <erosen@juniper.net>
Message-ID: <493dc791-599b-b36c-5855-87059b12fb16@juniper.net>
Date: Fri, 23 Mar 2018 13:00:30 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <373D0F59-2947-4370-9BDC-081E03867B2E@nokia.com>
Content-Type: multipart/alternative; boundary="------------6206C84D6804B8FB93E22064"
Content-Language: en-US
X-Originating-IP: [66.129.241.12]
X-ClientProxiedBy: BN6PR1401CA0002.namprd14.prod.outlook.com (2603:10b6:405:4b::12) To SN1PR05MB2304.namprd05.prod.outlook.com (2a01:111:e400:7a42::18)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: eb39fece-1eac-413d-0b18-08d590df9774
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(2017052603328)(7153060)(7193020); SRVR:SN1PR05MB2304;
X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2304; 3:UNrJgmziG0Gi8eNXkGRcuSN+omPFh9d15zcr4TOMStt/VgYg0Z4HNPutnZqCOE2fepr6nYTYPc/BlpJ6KwvgoD2XxDpyzloiKM8YnYy+lF0Pf2j2Z8O5mPvEmcLC0E+CMffSNSl4vgEZhqjALuVj5irke4jcNeZOZQyeICDbr14M75Y+tl2vOSikrvDNDB4fEd0pIFB0nNWXhZPruASbSzbFWyYEBcGti6xcumeavmCEWmMrlMZgNikeBnMJOAD7; 25:rJDbB0jiDWPU0PwOELHU2/7evCjBC7mFajBfKo1pD9/STktRR/iBb5sWkaZM8u11YRGcF+Rf7qu7lFtRGoftOEJcoLELl8ecJHhklT5/6JzFhgIzl4Ai7REA+nbQPJKAw59oITPnxl5K9aYQKPxRwClDoOYJ11jgh0jmktCFOxuvaAiQPQJMybYWRfsjf7l/iAjOCG+WV8IX6WsJ2miUhNt0whSjRtLlHzjjJx8lve58yEM+yihBd2oV1VD9iar9scrbI3itAumjIsoZ7UQILxIcjflhjaQXijHyeVxLWNiu9HJonw8Jzjhowhg3qBfdBQEpfCp7+CEpvyCZvWIijw==; 31:t+NFPvEswch9Ku77Q6e+NDVDKwxU9vFwegrb6nX4o+fty/9IDBP2Z7RrCOSv8sFtoPuoTzzDAaYcgwkJil7Lg7/jw0EguCIgC96dBo95PCr/q1GiBEcBDjBq/JWcyi6racuywiKQxvolbpb+kDXoRboBVMU4zrAMRV+H9B2Pvkx0n4Skojd5tvG0aVlStSwyuA+A4vphIlNwNzsO8eoznVcGb+FwwSXvU3VNT38zk9o=
X-MS-TrafficTypeDiagnostic: SN1PR05MB2304:
X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2304; 20:eVYMZ0n5PZEc5Zjy4U2L8OmuJArOr+cW1OXKGtCdwOpns1l6uaoO2moWB9SYQe2eBsSRfgTkwvPlUYrf5UB7bo8Gjl/TRJTDX2nXCsfVZKEajQAMECb9WCf8CdUOGzs41Tt5mc1PQrGGHH16Wu8b2z3PFyGFqou64ULPXnqZOoN9qmaXKyh2OKaI1lUkWdjVL0hwsbnFgA2J0ZF9UBNsYwb5Iy2DED1iTu8pH2tH39hVN0yLvyLb8FGrRYE2y18aRjnE1iUtWfQob47rAwQoyLeuiHmsH6J2L41ObOHYbyUFoAiGNxj1YWE82z8sY1KmqKj4zrVODXdGddgvQqdI7RuIN4OVLgMh39G+JQSm8F80K2n6uADGECJl+Y0lGB0KIZWZebxJL1OWurGHsadjmBtix0nAcafw0PzB1TH+jqobxyyYnTfY+5arEyMxaLfq3tIjEdpx+irF1+1x6HJC0kmg/rU0+TQSq3+/8oaIBLbjSytaW4J4wzbznqSRu1vVo4a9bWcPF3eJ1FqA9IILPRkK/PfFAaWfcOlNTgJEkeLdrmNirDrD0TyutywvE3PcHFavcouZORvBCwXDPMXsy2OUckb2XTp7kvxPuP7osUw=
X-Microsoft-Antispam-PRVS: <SN1PR05MB2304AD140981988BC85151C4D4A80@SN1PR05MB2304.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(10436049006162)(100405760836317);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231221)(944501327)(52105095)(93006095)(93001095)(6055026)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:SN1PR05MB2304; BCL:0; PCL:0; RULEID:; SRVR:SN1PR05MB2304;
X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2304; 4:44sqAAEwvHcDIRcib1fCZx9RNKXOLhhW+Y+xCbHPJ0tgJCee8aR3S7LkcVaR6nVGWld1sG6nx1vgc+/j7sMWNs70B3asjQ0iDjsQ6e+sxGPmcYy+lRpwzMJ7P4DPaTK9Rxi9S5aPmOeuBK9qjmHFPXSVc5P/IhkQDyXhisLUz9e9Enb90uq87t9+APuZXCv2gRgrJwh2AHosNbcZAbU12PXz1q4TpLnrFweuF/dkXuY0ewwwyvqSkSmN81R96leLwsAjtjKbBZaDLhhfTCkK67qX2VlysL5xjPzgcIDgO12X/nlUk0cpWo6plGOc/eWP9KO4GqsQlt9w4HTLs6aXZSMcIZLJeM+NQRAOAfMwgMM=
X-Forefront-PRVS: 0620CADDF3
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(376002)(39380400002)(366004)(39860400002)(396003)(346002)(189003)(199004)(76176011)(31686004)(31696002)(575784001)(86362001)(64126003)(16526019)(68736007)(561944003)(77096007)(26005)(36756003)(105586002)(6246003)(106356001)(386003)(65826007)(65806001)(6486002)(236005)(66066001)(6306002)(54896002)(3260700006)(65956001)(25786009)(53936002)(5660300001)(37036004)(7736002)(229853002)(16576012)(606006)(59450400001)(478600001)(316002)(6116002)(446003)(16586007)(58126008)(110136005)(84326002)(3846002)(5890100001)(2501003)(8656006)(2906002)(33964004)(8936002)(97736004)(11346002)(81166006)(81156014)(8676002)(52116002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR05MB2304; H:[172.29.38.238]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2304; 23:YxzMJBMR0E/qdXzhOs06KzYl6XKAIfC41aqrZNWl2cuT7eZUgAQcytIZkiwrV36trhCG7J30j15un0WyhCyEyGfndUQK2dhBi8IyJf61tJqXdZCEkzqYWP2ple2B6eM4c7y337PYnkr4wuh9jBymqCffjmUNdB1lfB03uUvBI9JGfmxfd6PdoAHIiZm7QLdpMrrT/AlgNJo/Qtoi9MKTi+lM/iGLfFy08I6QqVR62rmjFnt+QxsFnCJ/MmX0wX88lx+HMqX6fwyd7FsoMCrek6xD7sOVzNVDUBp1SlkUbzZbsRqjfzmNIUW0Ggr/vsjcXLE4CPhM2miVQFZOS0ACtptNEL1ehsIlz5wonAGZeO/q49R/lf4Ybm4P+ZXKriZE6Eb/Hy8feNrvu2GiCNC5h4wIhzjFdb0qPTP2HEknEoGwWhOomZLnBXpgGC6PuQo8/gsg66wOxPwIaMEJtfxO9SI/pVP1N6OZv3iwMzXjozd9UQW8gTX0k+xkMzn6n6/8f4S1XUjKmZiQL2/3bxS8PPAHK5cVmMKpwgjdSu484a2wHiOVPt3034mFGvjCYOwv46ePphAqEBXDUq7McxDq/3725D9lhrXgNnNwU9oj1e+lmYI8aMmOUswOQPPwSMz2p1bqyMvO9W/+r8U91ckPFZpEo8JrLQ/HznZPziUd1XO71mx5tsuatREkdpEOUN/QbJhKhYgMoxKovE1G2L6O680I4QLBsOFmzZ2TmDQGIt2GsqQjqbRpUP7IRVRBxeneH1rFknB7k5dyixgpeXCs1wW2o8fNXXco6DlW0IfsUzjGtuqRyY6ULzS6Gr8BUiNx9pEkacLTaFpuLjFBV5xVusDc83laOrYFhyKRTGn8JKCWocKgTKicjDijPESIvrMIZ1+SkDqyfB5k5Uam57KPZIwoRcO7IIoxtaNjmtQmGgssSAFuOll1kaL5oE7eZVbg1IKq6LdPOKx/n3oqT5tHW82NVvXJ40m9bj7i7TKxL30YUWfo10EAyLffn9DSsL5fdtoSZmSkZQnUQXbkPDq/MlUzMMXBWu+GRnTsj8KnJEyVdtjR1mV1BjVAorVCEUT8ejhKl4UJqyfTmXqnjJj0LwbXRbe2Qe6pV+ZaaxFkfNT+SVD5eTqNybFxHLXCh7YWlVlBH+/u5Y23CoioKhgM6Gmh+mlFxyHTP65dlFIK7jf4oX9RHtyMXHpwauFia634+H6xSTM+hUeUlFa0Xn6AmDjhB9d+pnlVGY/Q91Itp2+rcaieiWTCGDn2bB02YcnrqI0USHqcdtFU8UsjVhd+2puNr/jIDy5UMLerO3rW0jPl7XE1BPJZ/rSMmUvroUxhVBWWd5Es7MvstmUtmVjEMSa5cgsmW9IehhfzkxtHMvAp4JKPXmbFd2TWKEQY6R045XE36Dk5pH3OovTP9dw8Vhy8gijf6Aa/axO/Brazcf0=
X-Microsoft-Antispam-Message-Info: YVBcsEQ4hQ/4vuCaUPPkSKL70Ucx2tJkNHvS4PmpSYoiLTmMgwe2EJX/j8x1Ny3pBRNp81z0R51SYxFTTVJx60sffYY2FNKHwBnJmMhjGURHS0FLiEexnRTnVOFAwwo2U5gGn0YTh+ajXqs3v2b79C9W1U5Hb041yJlwaicMVqfUh5+eD/ANqJdI2sc7QClv
X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2304; 6:Q8+bptmM3yXYBzZBBoUWGgakrbNRwdnLwZIh6MuRMsSxUZEgbOQ6IbQ3t1OJi5UzHBLSJS7WySkA2gd5YhcdPMsicGVH/MgzPU56J+WT7v0edwgsvt4WKz0y3pfcnAWLNagZgldl/jLT/d5FxDScfpKkCSJnpVh18RgIkBEzhtARRcgPC6WC8lilodzAx3NMIqU3HQzC+siuZ53at7puavGJPO69tSpjKWIdtAm/3gVL3J0GrJKsazDBAKzw2/BB7fHAx11vkMgJ9oRQj7gQcQOQLPX3Qs8fIY+XOUZiENVrL+uC35l2lDeGWzAFednU2LNJWSSIiGqxojdG0DXHfZFgH5P130A4Ky/LxQwOTTGAfxJjZ1X4ZkXHjbsqTo9d+xe00XvUQ7Aay7yvUu6UyqsOzZHTw1GQKoFtEIFMkKYK4SzcRGaj7PAZA5xcyqdUaES/AdBxq5YvTsGt2TVtng==; 5:v4CCWohEF5KcggPwoI92NsA0k/A7g3M9ZOWbb/cScBn7kmH8wMcYfpKL3w1Kd7QWmy+UV1borCdNqZcLckJHbir5NnmA2AuE6dQprL14SICZbltQNvCjFBp1JPH4shQffHL2CrGE7/uhXSLAZXVnwMHZSn0cnSC+hpFfUtZlKf4=; 24:ks7vh8g9X/9FfTG1PmV3wPNPRQoG+drgiSixbvl73jCIUEO656xCJvKmxsGOceNqr8h4d7ttv/Z3p0bbHIDJCiynzgf90HbXauuhopaTay8=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2304; 7:17iJ2xrUGvtgES+LpS4Y/vje/yAvsdOcJTGWzDHlMquucDhBqkOnOZppBUzBaAjNVyt1cWelVZv8Swy1Trk6Wp75yp/peiCr3a4NWZrZzMpUWaoBEFWj7L3Q1GOD6YiT+TZ9eOdbwi9DgpY7nfj1KYfO2D3H87UoM7JuzyFxCJ2gwcvFp0eljfytXy7sNHNU5qLczd/jvv0HzFkFhTZHKIl8/o9rc3rA2x09XgtB78DVv4YEIwN+3C0zydwct5Hd
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Mar 2018 17:00:32.9439 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: eb39fece-1eac-413d-0b18-08d590df9774
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR05MB2304
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-23_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803230194
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/w2dX_ZbmBsRyaz7VqgIkoG9dWOk>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 23 Mar 2018 17:00:44 -0000

[Jorge] my interpretation of RFC7432 is that IMET routes are mandatory 
to enable the handling of multi-destination traffic in a BD. But in a 
non-DF PE for a given ES and with no other ACs in the BD, assuming 
Ingress Replication, there is no such multi-destination traffic (Tx or 
Rx). So one could interpret that RFC7432 is ok with withdrawing the IMET 
route in that case.

If we consider the case of all-active multi-homing, then there may well 
be Tx multi-destination traffic in the scenario under discussion, as 
multicast traffic from a given ES could arrive at any PE attached to the 
ES, whether or not that PE is the DF.

The relevant section from RFC 7432 is:

11.  Handling of Multi-destination Traffic

    Procedures are required for a given PE to send broadcast or multicast
    traffic received from a CE encapsulated in a given Ethernet tag
    (VLAN) in an EVPN instance to all the other PEs that span that
    Ethernet tag (VLAN) in that EVPN instance.  In certain scenarios, as
    described in Section 12 ("Processing of Unknown Unicast Packets"), a
    given PE may also need to flood unknown unicast traffic to other PEs.

    The PEs in a particular EVPN instance may use ingress replication,
    P2MP LSPs, or MP2MP LSPs to send unknown unicast, broadcast, or
    multicast traffic to other PEs.

    Each PE MUST advertise an "Inclusive Multicast Ethernet Tag route" to
    enable the above.  The following subsection provides the procedures
    to construct the Inclusive Multicast Ethernet Tag route. Subsequent
    subsections describe its usage in further detail.

Interestingly, this says that the IMET route is mandatory to enable "the 
above", where "the above" is "send broadcast or multicast traffic 
received from a CE".  Note it says "send", not "receive".

If P2MP tunnels are used for the BUM traffic, the IMET route is 
certainly required to support all-active multi-homing.  If IR is used, 
or if single-active multi-homing is used, one could argue that RFC 7432 
didn't really need to require the IMET route. However, it does.

[John] Wouldn’t it be better to have this draft define a bit in the 
Multicast Flags extended community 
(https://tools.ietf.org/html/draft-ietf-bess-evpn-igmp-mld-proxy-01 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dbess-2Devpn-2Digmp-2Dmld-2Dproxy-2D01&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=rs8r_tXnIDIv9e5NNgiXOy5yYuE10r6x9al8H6FgK04&s=V42kiY3ngmDNxMKmk5GgHmy9LcMGdOXpcvbereFtUR8&e=>) 
indicating that that the originating PE is neither DF nor backup DF for 
this broadcast domain on any ES to which it is attached? This allows us 
to always advertise the IMET route and makes the situation explicit.  I 
think the consensus is that this situation is rare so the number of IMET 
route updates shouldn’t be excessive and we could also say that this bit 
is only set by EVPN DC GWs.

If it's worth doing at all, this would be a better method.  Alternatives 
would be omitting the PMSI Tunnel attribute, or setting the MPLS label 
in the PMSI Tunnel attribute to 0.

[Sandy] We’d considered alternative methods other than withdraw, such as 
extended community or something specific in PMSI Tunnel Attribute.  
Withdraw/don’t advertise RT3 approach was chosen for the following reasons;

  * Requires no change to protocol

Since the proposal changes the conditions under which an IMET route is 
originated, it is certainly changing the protocol.  (It's obvious that 
the finite state machine is changed.)  Perhaps what is meant is that the 
protocol change is backwards compatible with systems that implement only 
RFC7432.  But it does not appear to be backwards compatible with systems 
that have IRB, and the draft has no analysis of the impact on all the 
various extensions and proposed extensions to RFC7432.

  * Is computationally easier on all participating PE’s, to deal with a
    simple withdraw than to look for something in an update. For
    instance, on transition from BDF to NDF for example

These are of course not the only considerations.