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) <satyamoh@cisco.com>
Sent: Friday, September 10, 2021 2:10 PM
To: last-call@ietf.org; IETF-Announce <ietf-announce@ietf.org>
Cc: EXT-zzhang_ietf@hotmail.com <zzhang_ietf@hotmail.com>om>; martin.vigoureux@nokia.com; bess-chairs@ietf.org; draft-ietf-bess-evpn-bum-procedure-updates@ietf.org; bess@ietf.org
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" <bess-bounces@ietf.org on behalf of iesg-secretary@ietf.org<mailto:bess-bounces@ietf.org%20on%20behalf%20of%20iesg-secretary@ietf.org>> 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@ietf.org<mailto:last-call@ietf.org> mailing lists by 2021-09-07. Exceptionally, comments may

    be sent to iesg@ietf.org<mailto:iesg@ietf.org> 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

    BESS@ietf.org<mailto:BESS@ietf.org>

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

Juniper Business Use Only