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 protected]> 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
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
