Re: [bess] Last Call: <draft-ietf-bess-evpn-bum-procedure-updates-09.txt> (Updates on EVPN BUM Procedures) to Proposed Standard

["Satya Mohanty (satyamoh)" <[e-mail]>]

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" <[e-mail]>
Date: Tuesday, September 14, 2021 at 12:31 PM
To: "Satya Mohanty (satyamoh)" <[e-mail]>om>, "[e-mail]" <[e-mail]>rg>, IETF-Announce <[e-mail]>
Cc: "[e-mail]" <[e-mail]>om>, "[e-mail]" <[e-mail]>om>, "[e-mail]" <[e-mail]>rg>, "[e-mail]" <[e-mail]>rg>, "[e-mail]" <[e-mail]>
Subject: RE: [bess] Last Call: <draft-ietf-bess-evpn-bum-procedure-updates-09.txt> (Updates on EVPN BUM Procedures) to Proposed Standard

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) <[e-mail]>
Sent: Friday, September 10, 2021 2:10 PM
To: [e-mail]; IETF-Announce <[e-mail]>
Cc: [e-mail] <[e-mail]>om>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [bess] Last Call: <draft-ietf-bess-evpn-bum-procedure-updates-09.txt> (Updates on EVPN BUM Procedures) to Proposed Standard

[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" <[e-mail] on behalf of [e-mail]<mailto:[e-mail][e-mail]>> 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

    [e-mail]<mailto:[e-mail]> mailing lists by 2021-09-07. Exceptionally, comments may

    be sent to [e-mail]<mailto:[e-mail]> 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

    [e-mail]<mailto:[e-mail]>

    https://www.ietf.org/mailman/listinfo/bess


Juniper Business Use Only