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

From: Xiejingrong <[email-masked]>
Date: Mon, 8 Jul 2019 11:45:17 +0000

Hi

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.

Thanks
Jingrong

---

From: "Kesavan Thiruvenkatasamy (kethiruv)" <[email-masked]>
Date: Mon, 15 Jul 2019 21:10:15 +0000

Hi Jingrong

Thanks for your comments. Please find responses below.

Regards,
Kesavan

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

Xiejingrong <[email-masked]> Mon, 08 July 2019 11:47 UTCShow header<https://mailarchive.ietf.org/arch/msg/bess/SWY3fzK1unFbY5MYnD7dkaBSZ9I>

Hi

6.  Solution Overview

Kesavan>> This section covers with MVPN PE. Later section covers EVPN only PEs.

   seamless interop mode.

Kesavan>> Will take care in the next revision

   adverting to MVPN-PEs.

Kesavan>> Will take care in the next revision

Kesavan>>  Thanks for pointing this out.  Will add this in the next revision.

        to BGP AS Number.

Kesavan>> This is an AS specific EC. Local Administrator field is 4 bytes

Kesavan>>  We need to cover encapsulation methods used in the underlay.  Will check other draft that has been pointed out here and get back to you.

Thanks

Jingrong