Re: [bess] WG Last Call for draft-ietf-bess-evpn-prefix-advertisement-04

"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com> Thu, 23 March 2017 01:31 UTC

Return-Path: <jorge.rabadan@nokia.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 4890F12422F for <bess@ietfa.amsl.com>; Wed, 22 Mar 2017 18:31:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.753
X-Spam-Level:
X-Spam-Status: No, score=-0.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 VAEeG9KQPnvK for <bess@ietfa.amsl.com>; Wed, 22 Mar 2017 18:31:31 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0123.outbound.protection.outlook.com [104.47.1.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FFF8129412 for <bess@ietf.org>; Wed, 22 Mar 2017 18:31:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XzgoDfHDILLvOsBL8jeYFrLi+UFx3jFhZd3ayyZIIZ8=; b=YAOEBjaUsU7Aj+Fe01A1m/t19riHHSpTY7BhFvQeknh6JKe5FK/ZD7lFGi73g70AzpBRfmTtvxExqZHkvTcfRL4ZpSxhRlI53nDiQUV1RLzktayyMlugE7YMcuxHsQALH35UMDb0EuJA75Y9aTlFWNs3HdIs2Njguf9OTqkAlMg=
Received: from DB5PR07MB0981.eurprd07.prod.outlook.com (10.161.200.151) by DB5PR07MB0984.eurprd07.prod.outlook.com (10.161.200.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Thu, 23 Mar 2017 01:31:27 +0000
Received: from DB5PR07MB0981.eurprd07.prod.outlook.com ([fe80::ec4e:6da5:9e2a:4ab7]) by DB5PR07MB0981.eurprd07.prod.outlook.com ([fe80::ec4e:6da5:9e2a:4ab7%17]) with mapi id 15.01.0991.013; Thu, 23 Mar 2017 01:31:24 +0000
From: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>
To: "Jeffrey Zhang (Zhaohui)" <zzhang@juniper.net>, "Vigoureux, Martin (Nokia - FR/Nozay)" <martin.vigoureux@nokia.com>, BESS <bess@ietf.org>
Thread-Topic: [bess] WG Last Call for draft-ietf-bess-evpn-prefix-advertisement-04
Thread-Index: AQHShkWh/QxJGJ54gkqeZugGpTJ7OqFuLjaQgDM5CQA=
Date: Thu, 23 Mar 2017 01:31:23 +0000
Message-ID: <61A934B5-F2D4-4180-9EA3-5A5A449DE75E@nokia.com>
References: <3035f4d6-163e-2f90-8462-74fa8801540b@nokia.com> <DM5PR05MB31453ED2211B76A2D59F0C2DD4510@DM5PR05MB3145.namprd05.prod.outlook.com>
In-Reply-To: <DM5PR05MB31453ED2211B76A2D59F0C2DD4510@DM5PR05MB3145.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=nokia.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [99.104.125.72]
x-microsoft-exchange-diagnostics: 1; DB5PR07MB0984; 7:0zdLP6Vzpsy1H/VW2kY9p7bVGSc2jm5+qXfm8p3bX2eLk7/gjmIewTHsXQzglrCYJiLR7PJOz0HWdr+7PvTwyzNhdWgp512D4sEtG2hEfJJO0x2zrQyiL25zfDq5F/XGim6Nb37mT9H/oqTs1MOUIA07EmExJVW/vS7w6DFp36v7OIKHVuwsLL7BcpkiQ/qcswZDBqogeljgfJDiSEpDsfrMoSu5BmxePBRPgscNIqPLZDVGhyRN9DKXbMR7Cj8FcHZbuR/TBPwJ9y+x8Y1SKMWxNw8U8MZyZ4dzhwV4FUy+CcYakPLDMEUS1TV9MhJPnaXnyQiFD0Lbexo1a77TqQ==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39410400002)(39450400003)(13464003)(377454003)(45984002)(24454002)(38730400002)(36756003)(6246003)(83716003)(3660700001)(3846002)(6512007)(2906002)(3280700002)(6116002)(102836003)(33656002)(25786009)(2900100001)(82746002)(66066001)(83506001)(189998001)(6306002)(8676002)(229853002)(6436002)(6486002)(53546009)(99936001)(6506006)(2950100002)(99286003)(54356999)(8666007)(230783001)(50986999)(76176999)(53936002)(7736002)(966004)(305945005)(5890100001)(5250100002)(5660300001)(86362001)(81166006)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB0984; H:DB5PR07MB0981.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
x-ms-office365-filtering-correlation-id: a1ce8841-0e8a-4425-a4df-08d4718c5167
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:DB5PR07MB0984;
x-microsoft-antispam-prvs: <DB5PR07MB0984945638793982F9BFBDBEF73F0@DB5PR07MB0984.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(120809045254105)(138986009662008)(200054503718035);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123558025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:DB5PR07MB0984; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB0984;
x-forefront-prvs: 0255DF69B9
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/mixed; boundary="_003_61A934B5F2D441809EA35A5A449DE75Enokiacom_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 01:31:23.8207 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB0984
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/i8eH0nMJkY5iDuQzCItop8KPA90>
Subject: Re: [bess] WG Last Call for draft-ietf-bess-evpn-prefix-advertisement-04
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: Thu, 23 Mar 2017 01:31:43 -0000

Hi Jeffrey,

Thank you very much for the review and good comments.
Please see my comments in-line, along with the ones addressing Eric’s comments (in a separate email). Also check out the new enclosed version.


On 2/21/17, 6:56 AM, "BESS on behalf of Jeffrey (Zhaohui) Zhang" <bess-bounces@ietf.org on behalf of zzhang@juniper.net> wrote:

    Some nits/questions/comments:
    
    Abstract
    
       EVPN provides a flexible control plane that allows intra-subnet
       connectivity in an IP/MPLS and/or an NVO-based network. In NVO
       networks, there is also a need for a dynamic and efficient inter-
       subnet connectivity across Tenant Systems and End Devices that can be
       physical or virtual and may not support their own routing protocols.
    
    Why is that "need for ..." only in NVO networks?
[JORGE] ok, I removed “NVO”
    
       Overlay index: object used in the IP Prefix route, as described in
       this document. It can be an IP address in the tenant space or an ESI,
       and identifies a pointer yielded by the IP route lookup at the
       routing context importing the route. An overlay index always needs a
       recursive route resolution on the NVE receiving the IP Prefix route,
       so that the NVE knows to which egress NVE it needs to forward the
       packets.  
    
    Given that there is an "underlay next-hop", perhaps rename "overlay index" to "overlay next-hop" and define it after the "underlay next-hop"? It could also be a MAC address (as described in 5.4.3) as well; in fact I really don't see the need of using ESI (more below).
[JORGE] As discussed in the email addressing Eric’s comments, I removed the “underlay next-hop” concept, since I agree there is no need to explain what a BGP next hop is. Also we discussed overlay next-hop vs overlay index in the past and decided overlay index was better to avoid confusion. Finally, I tried to highlight the reasons for the ESI overlay index. Please see the new version.
    
    Suggested text for "overlay next-hop":
    
      Overlay next-hop: an IP/MAC address in the tenant space or an ESI.
      It is included in the IP Prefix route to specify that the destination
      prefix is reached through the overlay next-hop, which requires a
      recursive lookup of the next-hop in the tenant's space.

[JORGE] please check out the new section 3.2.
    
    --------------------------------
    
            o Clean identification, operation of troubleshooting of IP
              Prefixes, not subject to interpretation and independent of the
              IPL and the IP value. E.g.: a default IP route 0.0.0.0/0 must
              always be easily and clearly distinguished from the absence of
              IP information.
    
    I had trouble understanding the "independent of" part; then I realized that it reads better if it is moved to the beginning of the clause: "independent of and not subject to the interpretation of ...".
[JORGE] changed.
    
    Section 4 should be folded into section 2.2. In fact, much of section 6 can be removed as well.
[JORGE] agreed. Please check out the new version.

    
    5.3 ESI overlay index ("Bump in the wire") use-case
    
    How does multicast work, for traffic sourced from SN1?
[JORGE] IP multicast intersubnet forwarding is out of scope. Do you think we need to state that?
    
                 . Destination inner MAC = M2 (this MAC will be obtained
                   from the Router's MAC Extended Community received along
                   with the RT-5 for SN1).
    
    Because the RT-5 has M2 mac attached, the overlay index could be the mac address itself - no need to use the ESI. This has advantage when there is no multihoming (no ESI need to be defined) and can also work with multihoming. In fact, that is what section 5.4.3 does.
[JORGE] I changed the bump-in-the-wire section to clarify why the ESI overlay index has advantages too. I agree a MAC overlay index can be used to. Please check out the new section.
    
    5.4 IP-VRF-to-IP-VRF model
    
       .. EVPN provides connectivity for:
    
       1. Traffic destined to the IRB IP interfaces as well as
       2. Traffic destined to IP subnets seating behind the TS, e.g. SN1 or
          SN2.
       In order to provide connectivity for (1), MAC/IP routes (RT-2) are
       needed so that IRB MACs and IPs can be distributed. Connectivity type
       (2) is accomplished by the exchange of IP Prefix routes (RT-5) for
       IPs and subnets seating behind certain overlay indexes, e.g. GW IP or
       ESI.
    
    I have trouble understanding #1 above (even with the explanation). #2 is about destinations behind the TS; is #1 about TS themselves? Why is "IRB IP" singled out?
[JORGE] ok, fair point. I added: “Traffic destined to the IRB or TS IP interfaces as well as...”
    
    Additionally, I think 5.4 should be promoted to its own section (section 5 is about three use cases of the "overlay index" or "underlay next-hop" and section 6 is about implementing IPVPN using type-5 instead of SAFI 128).
[JORGE] hmm... it’s possible, but is it not one more use-case?

    
    5.4.1 Interface-less IP-VRF-to-IP-VRF model
    
    I suppose this is basically using type-5 vs. SAFI 128 routes to do IPVPN. It's better to point that out.
    
       b) The IP-VRF instances in the NVE/DGWs are directly connected
          through NVO tunnels, and no IRBs and/or MAC-VRF instances are
          defined at the core.
    
    "at the core" is a little bit confusing. Perhaps 5.4.2/5.4.3 can be discussed first, and then come to this new model where no dedicated mac-VRF is used for the purpose of forwarding IPVPN traffic through this mac-VRF.
[JORGE] can you check the new text and see if it helps? About the order, we could change if it helps, however at the moment my preference it is to leave it that way – bear in mind that the draft has been like that for a long time and people still refer to the models as IP-VRF-to-IP-VRF models 1st, 2nd and 3rd .

    
    Additionally, it is not really "interface-less" vs. "interface-full". It's really if a dedicated mac-VRF is used or not. If you organize it that way, then 5.4.2 and 5.4.3 can be easily merged (the only difference between 5.4.2 and 5.4.3 is whether IRB IP or mac address is used as the overlay-index).
[JORGE] the interface-less vs. interface-full terminology has been used in the industry for a while, so I think we prefer to keep it. Example from a recent interop event (check out the EVPN IP-VRF-to-IP-VRF section): http://www.eantc.de/fileadmin/eantc/downloads/events/2011-2015/MPLSSDNNFV_2017/EANTC_MPLSSDNNFV2017-WhitePaper-Final.pdf
I added this text on section 4.4. Hopefully it helps clarify the terminology:
“Note that, in an IP-VRF-to-IP-VRF scenario, out of the many subnets that a tenant may have, only a few are attached to a given NVE/PE's IP-VRF. In order to provide inter-subnet connectivity across multiple NVE/PEs, a shared core EVI may be configured in all the tenant NVE/PEs. This core EVI has a core-facing IRB interface that connects the core MAC-VRF to the IP-VRF on each NVE/PE. Based on the characteristics of this core-facing IRB interface, there are three different IP-VRF-to-IP-VRF scenarios identified and described in this document:
   1) Interface-less model
   2) Interface-full with core-facing IRB model
   3) Interface-full with unnumbered core-facing IRB model”

 
    
    BTW - in an upcoming revision of draft-lin-bess-evpn-irb-multicast, a dedicated mac-VRF (or BD) is also used. It is called PBD (Pseudo Bridge Domain). It would be good to synchronize the two. Will follow up on that separately.
[JORGE] ok, however it is not PSB anymore.
    
       c) The solution must provide layer-3 connectivity among the IP-VRFs
          for Ethernet NVO tunnels, for instance, VXLAN or nvGRE.
    
       d) The solution may provide layer-3 connectivity among the IP-VRFs
          for IP NVO tunnels, for example, VXLAN GPE (with IP payload).
    
    Why is c) MUST while d) MAY?
[JORGE] EVPN is an ethernet technology for connectivity of ethernet tunnels (tunnels with ethernet frames in the payload) so that must be guaranteed. In the case of IP-VRF-to-IP-VRF interface-less there is a choice to have IP NVO tunnels (no ethernet heather in the payload) since the destination IP-VRF is identified by the label/VNI and the IP-VRF only does ip-lookups. Nevertheless you can still use an ethernet NVO tunnel – hence (d) is a MAY.
    
            o RD as per [RFC7432].
            o Eth-Tag ID=0 assuming VLAN-based service.
    
    I suppose no matter how many BDs you have, the type-5 is not tied to any particular BD. In case of VLAN-based service, there would be many EVIs, so saying "RD as per [RFC7432]" is not enough; in case of vlan-aware bundle, what Eth-Tag ID do you use? So the second bullet is not good either? My understanding: RD is not really tied to any of the EVPN EVIs; it's really the RD for the IP-VRF; the Eth-Tag would always be 0 as well, even for vlan-aware bundle?
[JORGE] Changed it. Check out the new version.
    
       (2) DGW1 imports the received routes from NVE1:
            ...
            o Since GW IP=0 and the VNI is a valid value, DGW1 will use the
              VNI and next-hop of the RT-5, as well as the MAC address
              conveyed in the Router's MAC Extended Community (as inner
              destination MAC address) to encapsulate the routed IP packets.
    
    s/encapsulate the routed IP packets/set up relevant forwarding state/? This bullet is about what to do when receiving the route (not when receiving the packet).
[JORGE] ok, changed.
    
            o The IP packet destined to IPx is encapsulated with: Source
              inner MAC = DGW1 MAC, Destination inner MAC = M1, Source outer
              IP (source VTEP) = DGW1 IP, Destination outer IP (destination
              VTEP) = NVE1 IP.
    
    Same comment as in the inter-sbunet-forwarding draft: setting of the inner src/dst mac address to the specific value seems to be tied to certain hardware - in theory they are not needed at all (if not were for certain hardware implementation). If that's the case, the spec should point that out.
[JORGE] ok, added:
“o NVE1 will identify the IP-VRF for an IP-lookup based on the Label (the Destination inner MAC is not needed to identify the IP-VRF).”
    
    5.4.2 Interface-full IP-VRF-to-IP-VRF with core-facing IRB 
       ...
       In this model, the requirements are the following:
    
    Those do not seem to be requirements. Rather they just describe the scenario. Same comment for 5.4.1.
[JORGE] I removed the word “requirements”.
    
            o RD as per [RFC7432].
            o Eth-Tag ID=0 assuming VLAN-based service.
    
    In this case, I suppose type-5 routes are tied to the core mac-VRF, and the RD is tied to that as wel; for Eth-Tag ID, it's tied to that mac-VRF as well. It's better to spell that out instead of just saying "assuming VLAN-based service".
[JORGE] I removed the VLAN-based assumption, since you are right there is no such dependency.  
    
            o MPLS label or VNI corresponding to the IP-VRF. Note that the
              value SHOULD be zero since the RT-5 route requires a recursive
              lookup resolution to an RT-2 route. The MPLS label or VNI to
              be used when forwarding packets will be derived from the RT-
              2's MPLS Label1 field.
    
    Delete "corresponding to the IP-VRF. Note that the value" so that it reads as following?
    
            o MPLS label or VNI SHOULD be zero since the RT-5 route requires a recursive
              lookup resolution to an RT-2 route.
[JORGE] done.
    
    For the following:
    
            o Route type 2 (MAC/IP route for the core-facing IRB)
              containing:
              . Route-target identifying the tenant. This route-target MAY
                be the same as the one used with the RT-5.
    
    The Route-target should really identify the mac-VRF. It is true that the mac-VRF must be present on every NVE for the tenant, but since we're talking about type-2 route it is better to say route target for the mac-VRF.
[JORGE] done.
    
    Similar comments for 5.4.3. However, I suggest to fold 5.4.3 into 5.4.2 - there is really no need to repeat w/ little difference.
[JORGE] It took a long time to agree on the models and terminology among the authors, hence I would prefer to keep the three models and terms. I did my best to clarify along your recommendations though. Please have a look and let us know if you are ok now.

    
    Jeffrey
    
    > -----Original Message-----
    > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Martin Vigoureux
    > Sent: Monday, February 13, 2017 5:08 PM
    > To: BESS <bess@ietf.org>
    > Subject: [bess] WG Last Call for draft-ietf-bess-evpn-prefix-advertisement-04
    > 
    > Hello Working Group,
    > 
    > This email starts a Working Group Last Call on
    > draft-ietf-bess-evpn-prefix-advertisement-04 [1] which is considered
    > mature and ready for a final working group review.
    > Note that this call is longer than usual because we are pushing two
    > correlated documents together.
    > 
    > Please read this document if you haven't read the most recent
    > version yet, and send your comments to the list, no later than
    > *5th of March*.
    > Note that this is *not only* a call for comments on the document; it is
    > also a call for support (or not) to publish this document as a Proposed
    > Standard RFC.
    > 
    > *Coincidentally*, we are also polling for knowledge of any IPR that
    > applies to draft-ietf-bess-evpn-prefix-advertisement, to ensure that IPR
    > has been disclosed in compliance with IETF IPR rules (see RFCs 3979,
    > 4879, 3669 and 5378 for more details).
    > 
    > *If* you are listed as a document author or contributor of
    > draft-ietf-bess-evpn-prefix-advertisement-04 please respond to this
    > email and indicate whether or not you are aware of any relevant IPR.
    > 
    > Note that, as of today, no IPR has been disclosed against this document
    > or its earlier versions.
    > 
    > We are also polling for knowledge of implementations of part or all of
    > what this document specifies. This information is expected as per [2].
    > Please inform the mailing list, or the chairs, or only one of the chairs.
    > 
    > Thank you,
    > M&T
    > 
    > [1]
    > https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-prefix-advertisement/
    > [2]
    > https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
    > 
    > _______________________________________________
    > BESS mailing list
    > BESS@ietf.org
    > https://www.ietf.org/mailman/listinfo/bess
    
    _______________________________________________
    BESS mailing list
    BESS@ietf.org
    https://www.ietf.org/mailman/listinfo/bess