|
Hi Satya, Yes it applies to MVPN as well. I am actually in the process of writing a draft to formally extend the inter-region segmentation and per-region aggregation to MVPN, and to do intra-region segmentation
for assisted replication purpose. Jeffrey From: Satya Mohanty (satyamoh) <satyamoh@xxxxxxxxx> [External Email. Be cautious of content] Hi Jeffrey, Thanks for your reply. It makes perfect sense. Am I to assume that the same reasoning applies to Inter-as MVPN as well since EVPN BUM procedures is based significantly on MVPN procedures? Best Regards, --Satya From: "Jeffrey (Zhaohui) Zhang" <zzhang@xxxxxxxxxxx> Hi Satya, That is part of the optional procedure to provide backwards compatibility. An implementation would likely to have configuration controlling whether this procedure is used or not. For the origination of per-region I-PMSI routes, whether it is for the purpose of backwards compatibility or just for the aggregation purpose, some provisioning is needed – at least to enable per-region
aggregation (perhaps at per-VPN level). We are adding per-VPN signaling and procedures, so per-VRF configuration should be reasonable (at least on the source ASBRs). In summary, that is indeed a local implementation issue. Thanks! Jeffrey From: Satya Mohanty (satyamoh) <satyamoh@xxxxxxxxx>
[External Email. Be cautious of content] Hi authors, One question on the draft Page #11, last paragraph; " The ASBRs in an AS originate per-region I-PMSI A-D routes and advertise to their external peers to advertise tunnels used to carry traffic from the local AS to other ASes. Depending on the types of tunnels being used, the L flag in the PTA may be set, in which case the downstream ASBRs and upgraded PEs will send Leaf A-D routes to pull traffic from their upstream ASBRs." How do we originate these per-region I-PMSI? Is it implied that there are EVI configuration at the ASBR?
Or this is a local decision and is not to be discussed in the standard. In L23VPN, usually ASBRs do not have VRFs configured. Therefore asking this question. Thanks, --Satya On 8/24/21, 7:38 AM, "BESS on behalf of The IESG" <bess-bounces@xxxxxxxx on behalf of iesg-secretary@xxxxxxxx> wrote: The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'Updates on EVPN BUM Procedures' <draft-ietf-bess-evpn-bum-procedure-updates-09.txt> as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@xxxxxxxx mailing lists by 2021-09-07. Exceptionally, comments may be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies procedure updates for broadcast, unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN), including selective multicast, and provider tunnel segmentation. This document updates RFC 7432. The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ BESS mailing list Juniper Business Use Only Juniper Business Use Only
Juniper Business Use Only |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
