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