Some observations/questions on inter-subnet and type-5 draft for EVPN

Antoni Przygienda <antoni.przygienda@ericsson.com> Sun, 17 August 2014 06:08 UTC

Return-Path: <antoni.przygienda@ericsson.com>
X-Original-To: l2vpn@ietfa.amsl.com
Delivered-To: l2vpn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D381A072D for <l2vpn@ietfa.amsl.com>; Sat, 16 Aug 2014 23:08:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 gh5LUP-jm1S5 for <l2vpn@ietfa.amsl.com>; Sat, 16 Aug 2014 23:08:02 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 359E61A072E for <l2vpn@ietf.org>; Sat, 16 Aug 2014 23:08:02 -0700 (PDT)
X-AuditID: c6180641-f79916d00000623a-2f-53eff010081f
Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 51.29.25146.010FFE35; Sun, 17 Aug 2014 01:58:09 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Sun, 17 Aug 2014 02:07:52 -0400
From: Antoni Przygienda <antoni.przygienda@ericsson.com>
To: "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: Some observations/questions on inter-subnet and type-5 draft for EVPN
Thread-Topic: Some observations/questions on inter-subnet and type-5 draft for EVPN
Thread-Index: Ac+54Vj/kFnQLaMuTYuhBZ6GvOXmLQ==
Date: Sun, 17 Aug 2014 06:07:51 +0000
Message-ID: <2E4BB27CAB87BF43B4207C0E55860F181845DE@eusaamb103.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.9]
Content-Type: multipart/alternative; boundary="_000_2E4BB27CAB87BF43B4207C0E55860F181845DEeusaamb103ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyuXSPn67gh/fBBpvfC1o8/naI3YHRY8mS n0wBjFFcNimpOZllqUX6dglcGQtbb7IVnGhlrJi3bSFbA+PFki5GTg4JAROJeVsmMUHYYhIX 7q1n62Lk4hASOMoosfL7fhYIZzmjxKz/f5hBqtgELCQuf3sKZHNwiAioSuxu4QIJCwsESHS8 e8oKYosIhEq0XG+DsvUkPj39zQJiswCVL/vQzwbSyivgLbF8QxlImBFo7/dTa8BuYBYQl7j1 ZD7UPQISS/acZ4awRSVePv7HCmErSuzrn84OMoZZIF/i/8pykDCvgKDEyZlPWCYwCs1CMmkW QtUsJFUQJToSC3Z/YoOwtSWWLXzNDGOfOfCYCVl8ASP7KkaO0uLUstx0I8NNjMCgPybB5riD ccEny0OMAhyMSjy8D5LfBwuxJpYVV+YeYpTmYFES59WsnhcsJJCeWJKanZpakFoUX1Sak1p8 iJGJg1OqgbFMQ2pD4IIDeobu+1VyHqz9sV5ufdsZn/n2932MdLJaZju6a6zmeMIdxr+sZFbB O/aFjCKhhXor7GU7pb96ceXL3CpzWThBJfine/T8SFuVun9hvc8jM0rNI8Uud541YLx24mKZ T3Trz4flNXo+YjP2Xg1Jlp4RusXx6MZzN8y+l0iYlNbeU2Ipzkg01GIuKk4EAHper7VbAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/48muQR-b1_aPdbuJ6UHNnUO-zTU
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Layer 2 Virtual Private Networks <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn/>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Aug 2014 06:08:05 -0000

So, wrapping around my head around EVPN type 5 and inter-subnet drafts and some observations (all on version -02 of type  5 and version -04 of inter-subnet)


a)       Nitpick first: in type-5 section 3.1 the IP Address Length field is not a particularly well chosen name for the field. It really is prefix length and other drafts use IP Address Length being 1 byte to indicate 4 bytes or 16 bytes and not mask length (e.g. evpn-07). I suggest changing to 'IP Prefix Length' or something like this.


b)      The new BGP attribute have couple unclear things to it (I mean the 'EVPN-GW-2-EVPN-GW tunnel attribute' for lack of a clearly specified name (which I think it needs) in draft inter-subnet section 6)

i.       I assume the intention of lack of such an attribute is that the tunnel is MPLS and therefore the label-2=l3vpn-label since I don't see an 'MPLS-tunnel-type' in the attribute ? But then, how do we figure out e.g. the MAC of the NVE. Did I misread completely or is that an oversight or did I get lost in all the tunneling ?

ii.      Bump-in-the-wire-use-case seems to indicate that the 'EVPN-GW-2-EVPN-GW tunnel attribute' is carried on route type 1 (but it seems it could be carried on the type-5 route with ESI!=0 equally well ?  In the VRF-2-VRF case however it's clear that type-5 is carrying the tunnel attribute so it may be more consistent to not stick it on type-1 albeit sticking it on type-1 is more consistent with it being stuck on RT-2 routes to resolve the MAC-2-tunnel in e.g. floating ip use case

iii.     It is not clear whether multiple tunnel attributes can be sent within a route & used for load balancing



c)      I start to ask myself whether we should start to think about IP route preferences in EVPN. Observe that currently we can install/use IP addresses/prefixes for IRB in EVPN assigned VRFs from multiple sources (or rather inter-subnet route on them)


1.      IP-MAC (RT-2) containing /32 (incl. gateway attribute)

2.      RT-5 containting /0 all the way to /32

3.      Draft-inter seems to allow to use IP-VPN routes to be used for lookup incl. prefixes (if not explicitly then surely implicitly via RTs)

4.      Redistribution from other protocols that do either IP prefix or IP-MAC bindings (but that's kind of well-known protocol distance we have today already)


Question here becomes: Should we specify the IP route preferences for all those routes being installed into the IP-VRF (or in broader sense, which address type should be preferred in inter-subnet lookup) ?  If not, looping criteria start to become imaginable IMO if implementations do not agree on the protocol preference as was the case for a while in L3 routing.

thanks

--- tony