[bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop-04

Xiejingrong <xiejingrong@huawei.com> Mon, 08 July 2019 11:47 UTC

Return-Path: <xiejingrong@huawei.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D03A312016C; Mon, 8 Jul 2019 04:47:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id x3Ghv3e_1MDw; Mon, 8 Jul 2019 04:46:57 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com []) (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 6AF7C120159; Mon, 8 Jul 2019 04:46:57 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id C595EEA90E2F6DD8C8A4; Mon, 8 Jul 2019 12:46:54 +0100 (IST)
Received: from NKGEML411-HUB.china.huawei.com ( by lhreml704-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 8 Jul 2019 12:46:54 +0100
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml411-hub.china.huawei.com ([]) with mapi id 14.03.0415.000; Mon, 8 Jul 2019 19:45:17 +0800
From: Xiejingrong <xiejingrong@huawei.com>
To: "draft-sajassi-bess-evpn-mvpn-seamless-interop@ietf.org" <draft-sajassi-bess-evpn-mvpn-seamless-interop@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop-04
Thread-Index: AdU1fmJYM0J07SQ7RZCnsK/ZU/6ikA==
Date: Mon, 8 Jul 2019 11:45:17 +0000
Message-ID: <16253F7987E4F346823E305D08F9115AAB8DACA4@nkgeml514-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_16253F7987E4F346823E305D08F9115AAB8DACA4nkgeml514mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/SWY3fzK1unFbY5MYnD7dkaBSZ9I>
Subject: [bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop-04
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: Mon, 08 Jul 2019 11:47:01 -0000


Thanks the authors to introduce this very useful, very clear draft.
I do think it deserves very much the adoption by the WG as an solution option.

Here are some minor comments after I read the latest draft (which I think does not affect the adoption):

6.  Solution Overview
   This section describes a multicast VPN solution based on [RFC6513]
   and [RFC6514] for EVPN PEs operating in IRB mode that want to perform
   seamless interoperability with their counterparts MVPN PEs.
[XJR] with or without their counterparts MVPN PEs (since this document covers both).

   EVPN-PEs advertise unicast routes as host routes using EVPN route
   type 2 for sources that are directly attached to a tenant BD that has
   been extended in the EVPN fabric. EVPN-PE may summarize sources (IP
   networks) behind a router that are attached to EVPN-PE or sources
   that are connected to a BD, which is not extended across EVPN fabric
   and advertises those routes with EVPN route type 5. EVPN host-routes
   are advertised as IPVPN host-routes to MVPN-PEs only incase of
   seamless interop mode.
[XJR] Editorial error. Incase of -> in case of

   In gateway model, EVPN-PE advertises unicast routes as IPVPN routes
   along with VRI extended community for all multicast sources attached
   behind EVPN-PEs. All IPVPN routes SHOULD be summarized while
   adverting to MVPN-PEs.
[XJR] VRI is used before its definition ---- VRF Route Import(6514) or IPv6 VRF Route Import(rfc6515) in my opinion.

   VRI is constructed as following:
      -  The 4-octet Global Administrator field MUST be set to an IP
         address of the PE.  This address SHOULD be common for all the
         IP-VRFs on the PE (e.g., this address may be the PE's loopback
         address or VTEP address).
      -  The 2-octet Local Administrator field associated with a given
         IP-VRF contains a number that uniquely identifies that IP-VRF
         within the PE that contains the IP-VRF.
[XJR] Does this document want to cover Underlay IPv6 network (described in RFC6515) ? If it does(I guess), then the VRI can be IPv6 VRF Route Import as pointed above, and the Global Administrator can be a 16-octet field.

   EVPN PE MUST have Route Target Extended Community to import/export
   MVPN routes. In data center environment, it is desirable to have this
   RT configured using auto-generated method than static configuration.
[XJR] is it a new specification for EVPN PE to have RT Extended Community ? if it does not, then MUST word is unnecessary.

   The following is one recommended model to auto-generate MVPN RT:
      - The Global Administrator field of the MVPN RT MAY be set
        to BGP AS Number.
      - The Local Administrator field of the MVPN RT MAY be set to
        the VNI associated with the tenant VRF.
[XJR] It's very helpful to have a method to auto-generate RT. Should this case be pointed out to help decision of using this method or not : the VNI is 24bit, and the Local Administrator is 16bit ?

9.2.3.  Other Encapsulation
   In order to signal a different tunneling encapsulation such as NVGRE,
  GPE, or GENEVE the corresponding BGP encapsulation extended community
   [TUNNEL-ENCAP] SHOULD be appended to the MVPN I-PMSI and S-PMSI A-D
   routes. If the Tunnel Type field in the encapsulation extended-
   community is set to a type which requires Virtual Network Identifier
   (VNI), e.g., VXLAN-GPE or NVGRE [TUNNEL-ENCAP], then the MPLS label
   in the PMSI Tunnel Attribute MUST be the VNI associated with the
   customer MVPN. Same as in VXLAN case, a gateway is needed for inter-
   operation between the EVPN-IRB PEs and non-EVPN MVPN PEs.
[XJR] I suggest remove the over-thought about various Encapsulation, we have seen different BGP attribute other than the TUNNEL-ENCAP attribute in https://datatracker.ietf.org/doc/draft-geng-bier-ipv6-inter-domain/
Hope you have a look at that one, and see if this kind of BIERv6 tunnel be useful for some scenario this document want to solve ---- to have a non-segmented P2MP tunnel from TOR in SPDC to BNGs outside of the SPDC.
Welcome your comments as well.