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

["Kesavan Thiruvenkatasamy (kethiruv)" <[e-mail]>]

Hi Jingrong

Thanks for your comments. Please find responses below.

Regards,
Kesavan



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

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

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).



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





   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



Kesavan>> Will take care in the next revision





   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.





Kesavan>> Will take care in the next revision







   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.





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







   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 ?





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







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.



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