Re: [bess] Genart last call review of draft-ietf-bess-evpn-optimized-ir-09
Gyan Mishra <hayabusagsm@gmail.com> Mon, 11 October 2021 15:21 UTC
Return-Path: <hayabusagsm@gmail.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3073A08CB; Mon, 11 Oct 2021 08:21:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFFCFLNFlWDg; Mon, 11 Oct 2021 08:21:37 -0700 (PDT)
Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F713A0A24; Mon, 11 Oct 2021 08:21:37 -0700 (PDT)
Received: by mail-pj1-x1036.google.com with SMTP id pf6-20020a17090b1d8600b0019fa884ab85so14950218pjb.5; Mon, 11 Oct 2021 08:21:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7d1FVwYEYJ7/kFLXGPzkqs7dorBtrfLqtN2vhSkabSY=; b=pb3lRg1cHYC7eVfpiNwwBg/pa1gDWTa9EquUAc6USd50eL5H5/C4dfLx8hDPq3YRBM vVqrqtkZJcl9xxShh1z//sfQBJU+BQPqchCaULFQw6gU/Ukia0tG+YGbe8gEoUKkM47N yU2ltXa7uSifj3/Ub34xUP6fLRre84wIyyDWhfFxroxG9pEtkY8cXjI9c2SoS5j4UYj7 cMUqJI2/8RXXPEXqcgsHZfWrcCcwVA/HAKUTO4cp1m4mwKAwqclAachsN95iERNjSSXp 3jY0f5851g8ghMEN8Hz81U9eni3nKG7WGRl+urcGQiDyZoQMgxcnuPbtPnE8VhHR1mtn kjSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7d1FVwYEYJ7/kFLXGPzkqs7dorBtrfLqtN2vhSkabSY=; b=rgGvkQlsSp7bJnQjRs1I0a+/igf91Y/D5UNAUVVsLScaHV7675v02ekw0KLepyKetw e54y/Jq4C2EZU6Jv/U5+6J1uxR96cRFMtPIqBJCPx2YOIZ2+dKWyaPi6s7JnUJpeDX2d fYRiCBe7t+0PlZ4SaO1bAy0I2Pvf8b6sSe/qzArX/risoJuUQFKKK/yFwkz5KpCcnGBH OfElYaYmf8iPOyb7g5n2CFeO4BxVv3vlHuiOY6uICDmWhfTpainm60MBKoezLKjgaVV3 G6+AdE+XovAJxAdsh/e+fr1pLn4e9WzTuOJhS+0YvqPElBPvXoORIT+bk7X4kani4ORE QxRQ==
X-Gm-Message-State: AOAM532wJOlRn6Mgaj6kgKKr0kjeIxLTuC3+iBY7KFYCSeeC22ajrw5i 5pliKvArnn6WOa/IPaFpESEaU4cesm42sNBYAs4=
X-Google-Smtp-Source: ABdhPJyr3lo04ws+K4i94WVpt87QvGObrfNrAtdWuNt/+itG9zprbvyj470bxXkNv1mmS096mbnTrbgqCPlQJ2DFNws=
X-Received: by 2002:a17:90b:2509:: with SMTP id ns9mr3181826pjb.47.1633965695802; Mon, 11 Oct 2021 08:21:35 -0700 (PDT)
MIME-Version: 1.0
References: <163319819045.17726.80429917001281116@ietfa.amsl.com> <BY3PR08MB7060B85372CE8F5E440AD665F7B09@BY3PR08MB7060.namprd08.prod.outlook.com> <CABNhwV0F=vWkXnibdYqj1T+2ZN+cnxuqF-kpCOWSKD3SLvGRNQ@mail.gmail.com> <BY3PR08MB7060ACC983FCC7EFDCF9CF31F7B29@BY3PR08MB7060.namprd08.prod.outlook.com>
In-Reply-To: <BY3PR08MB7060ACC983FCC7EFDCF9CF31F7B29@BY3PR08MB7060.namprd08.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Mon, 11 Oct 2021 11:21:24 -0400
Message-ID: <CABNhwV3Aaw7FY=CnPbssavJc4nYgLAGjs=-UGg=QmQvv0BBvqw@mail.gmail.com>
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>
Cc: "bess@ietf.org" <bess@ietf.org>, "draft-ietf-bess-evpn-optimized-ir.all@ietf.org" <draft-ietf-bess-evpn-optimized-ir.all@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000dfa17a05ce15485c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/LqXeLBQpIg-0NbgSOLaP1Lme9P8>
Subject: Re: [bess] Genart last call review of draft-ietf-bess-evpn-optimized-ir-09
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Oct 2021 15:21:47 -0000
Hi Jorge, On Fri, Oct 8, 2021 at 11:02 AM Rabadan, Jorge (Nokia - US/Mountain View) < jorge.rabadan@nokia.com> wrote: > Hi Gyan, > > > > Thanks. > > > > 1) About MPLS being out of scope: > > I added the following text in the introduction – while AR is for IP > tunnels only, PFL can be used for MPLS too. Hope it helps: > > > > This document describes a solution that makes use of two IR > > optimizations: > > > > 1. Assisted-Replication (AR) > > > > 2. Pruned-Flood-Lists (PFL) > > > > Both optimizations may be used together or independently so that the > > performance and efficiency of the network to transport multicast can > > be improved. Both solutions require some extensions to the BGP > > attributes used in [RFC7432], and they are described in Section 4. > > * **The AR solution described in this document is focused on NVO > networks* > > * (hence it uses IP tunnels) and MPLS transport networks are out of* > > * scope. The PFL solution MAY be used in NVO and MPLS transport* > > * networks.*** > > Gyan> Excellent > > 2) About adding RFC6513/6514/7117 as informative references: > > - RFC6514 is already added as reference due to the L flag > > - About the others, I see your point, however I still think it would be > confusing to add references to 7117 and 6513: IR is defined in > RFC7432/8365. This document is an extension of those two, so if we refer to > RFC6513/7117 the reader might be thinking we are doing something different > than what RFC7432/8365 say. So I would prefer not to add them. > > Gyan> Understood. > > 3) About the IR-IP and AR-IP in the terminology section, I extended the > text, hope it helps: > > > > OLD: > > - AR-IP: IP address owned by the AR-REPLICATOR and used to > > differentiate the ingress traffic that must follow the AR > > procedures. > > > > - IR-IP: IP address used for Ingress Replication as in [RFC7432]. > > > > NEW: > > - AR-IP: IP address owned by the AR-REPLICATOR and used to > > differentiate the ingress traffic that must follow the AR > > procedures. The AR-IP is also used in the Tunnel Identifier and > > Next-Hop fields of the Replicator-AR route. > > > > - IR-IP: local IP address of an NVE/PE that is used for the Ingress > > Replication signaling and procedures in [RFC7432]. Encapsulated > > ingress traffic with outer destination IP matching the IR-IP will > > follow the Ingress Replication procedures and not the AR > > procedures. The IR-IP is also used in the Tunnel Identifier and > > Next-hop fields of the Regular-IR route. > > Gyan> Perfect! > > 3) about being specific with the type, as you requested, I made this > change: > > > > OLD: > > Each AR-enabled node MUST understand and process the AR type field in > > the PTA (Flags field) of the routes, and MUST signal the > > corresponding type (1 or 2) according to its > > administrative choice. > > > > NEW: > > Each AR-enabled node MUST understand and process the AR type field in > > the PTA (Flags field) of the routes, and MUST signal the > > corresponding type (AR-REPLICATOR or AR-LEAF type) according to its > > administrative choice. > > > > 4) finally about this: > > Do you plan to have a future draft that adds this EVPN IR optimization to > MPLS underlay? > > > > As discussed, I clarified that PFL MAY be used for MPLS underlay. As for > AR, as already mentioned, the agreement with the authors of > draft-ietf-bess-evpn-virtual-hub-00 > <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-virtual-hub-00> > is that the virtual-hub draft addresses AR for MPLS. > > Gyan> Very good. As I am interested in AR use with MPLS I will review > that draft as well. > I am all set. Thank you! Kind Regards Gyan > Thank you. > > Jorge > > > > > > *From: *Gyan Mishra <hayabusagsm@gmail.com> > *Date: *Thursday, October 7, 2021 at 7:58 PM > *To: *Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com> > *Cc: *bess@ietf.org <bess@ietf.org>, > draft-ietf-bess-evpn-optimized-ir.all@ietf.org < > draft-ietf-bess-evpn-optimized-ir.all@ietf.org>, gen-art@ietf.org < > gen-art@ietf.org>, last-call@ietf.org <last-call@ietf.org> > *Subject: *Re: Genart last call review of > draft-ietf-bess-evpn-optimized-ir-09 > > Hi Jose > > > > You are most welcome! > > > > The overall main point I wanted to make is as follows: > > > > As RFC 7432 BGP MPLS EVPN, and RFC 8365 NVO were designed to support both > IP and MPLS underlay. However, for IP underlay scenario both Core or DC > with NVO3 you don’t have PTA PMSI Tunnel encapsulation attribute for all > tunnel types except IR as all other PTA tunnels type are MPLS based. Also > EVPN per RFC 7432 supports all PTAs as it supports both IP and MPLS > underlay, all the PTAs defined in RFC 6514 are supported. Also even though > EVPN per RFC 7432 only supports only inclusive trees prior to this draft > and BUM procedures update draft and proxy draft it does still support all > PTAs defined in RFC 6514. Since RFC 7432 supports MPLS underlay and all > PTA types my recommendation is to explicitly state that MPLS underlay is > not supported and out of scope for this draft as it’s not clear to the > reader. > > > > It maybe worthwhile to mention that although MPLS is out of scope for this > draft that this drafts IR optimization could work for MPLS underlay. > > > > I agree that RFC 7432 does reference RFC 6514 in section 11.2 so RFC 6514 > does not need to mentioned as normative. However since EVPN does used MVPN > style procedures and route types concept, separation of control and from > data plane on RR not just for multicast tree instantiation my > recommendation is to add both RFC 6513 and RFC 6514 as informative > references. > > > > As far as the IR-IP and AR-IP in terminology section I understand the the > additional process is defined in verbiage so need to clear up in the > terminology section, however the additional behavior is setting of the next > hop is to originator router IP address is defined in RFC 6514 and is > standard MVPN instantiation of PTA tunnel. I don’t think you need to > specify that the next hop is being set as that is standard processing > procedure for PTA tunnels per RFC 6514, but only if you reference RFC 6514 > section 5 IR, as at least informative, however if you do decide to keep the > text I would change the SHOULD to a MUST. > > > > Basically when the PTA tunnel type IR is instantiated for X-PMSI P-TREE > the tunnel has endpoints which is the originator IP is the tunnel > identifier and other end of the tunnel egress leaf PE PMSI route sets next > hop to the IR parent node root tunnel identifier. > > > > Originating Router's IP Address MUST be set to an IP address of > > the PE that should be common to all the EVIs on the PE (usually > > this is the PE's loopback address). The Tunnel Identifier and > > Next-Hop SHOULD be set to the same IP address as the > > Originating Router's IP address when the NVE/PE originates the > > route. The Next-Hop address is referred to as the AR-IP and > > SHOULD be different than the IR-IP for a given PE/NVE. > > > > RFC 6514 section 5: > > > > When the Tunnel Type is set to Ingress Replication, the Tunnel > > Identifier carries the unicast tunnel endpoint IP address of the > > local PE that is to be this PE's receiving endpoint address for the > > tunnel. > > > > > > Instead of IR optimization using AR-Route / Leaf-AD could you have used > SMET RT-6 introduced in the BUM procedures update. > > > > Most all of the RT updates that went into BUM procedures draft came from > RFC 7117 as stated in the BUM procedures drat. Most importantly the > optimization of building selective trees used by this draft are introduced > in BUM procedures draft, basically the idea replicated from RFC 7117 S-PMSI > RT-11 and Leaf-AD RT-11. My thoughts as that being the case and IR > optimization utilizes Leaf-AD it would be a good Idea to add informative > references to RFC 7117. > > > > Another reason why RFC 6514 should be added as normative reference is that > in Section 4 middle of page 9 below verbiage is basically the standard > process for Leaf-AD in response to S-PMSI / Inter-AS I-PMSI route with L > bit set. > > > > o The AR-LEAF constructs an IP-address-specific route-target as > > indicated in [I-D.ietf-bess-evpn-bum-procedure-updates <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-optimized-ir-09#ref-I-D.ietf-bess-evpn-bum-procedure-updates>], by > > placing the IP address carried in the Next-Hop field of the > > received Replicator-AR route in the Global Administrator field > > of the Community, with the Local Administrator field of this > > Community set to 0. Note that the same IP-address-specific > > import route-target is auto-configured by the AR-REPLICATOR > > that sent the Replicator-AR, in order to control the acceptance > > of the Leaf A-D routes. > > > > BUM procedures update does not describethis but it’s part of standard MVPN procedures RFC 6514 below: > > > > *9.2.3.4.1 <https://datatracker.ietf.org/doc/html/rfc6514#section-9.2.3.4.1>. Originating Leaf A-D Route into IBGP* > > > > If the Leaf Information Required flag in the PMSI Tunnel attribute of > > the received Inter-AS I-PMSI A-D route is set to 1, then the PE/ASBR > > MUST originate a new Leaf A-D route as follows. > > > > + If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel > > attribute with the Tunnel Type set to Ingress Replication, then > > the Leaf A-D route MUST carry the PMSI Tunnel attribute with the > > Tunnel Type set to Ingress Replication. The Tunnel Identifier > > MUST carry a routable address of the PE/ASBR. The PMSI Tunnel > > attribute MUST carry a downstream-assigned MPLS label that is used > > to demultiplex the MVPN traffic received over a unicast tunnel by > > the PE/ASBR. > > > > + The PE/ASBR constructs an IP-based Route Target Extended Community > > by placing the IP address carried in the Next Hop of the received > > Inter-AS I-PMSI A-D route in the Global Administrator field of the > > Community, with the Local Administrator field of this Community > > set to 0 and setting the Extended Communities attribute of the > > Leaf A-D route to that Community. > > > > > > Do you plan to have a future draft that adds this EVPN IR optimization to > MPLS underlay? > > > > Responses in-line > > > > Kind Regards > > > > Gyan > > > > On Wed, Oct 6, 2021 at 8:58 AM Rabadan, Jorge (Nokia - US/Mountain View) < > jorge.rabadan@nokia.com> wrote: > > Hi Gyan, > > > > Thank you very much for review the document! > > I’m adding comments along your comments with [jorge]. > > > > Please check them out. > > > > Thanks again, > > Jorge > > > > *From: *Gyan Mishra via Datatracker <noreply@ietf.org> > *Date: *Saturday, October 2, 2021 at 8:09 PM > *To: *gen-art@ietf.org <gen-art@ietf.org> > *Cc: *bess@ietf.org <bess@ietf.org>, > draft-ietf-bess-evpn-optimized-ir.all@ietf.org < > draft-ietf-bess-evpn-optimized-ir.all@ietf.org>, last-call@ietf.org < > last-call@ietf.org> > *Subject: *Genart last call review of draft-ietf-bess-evpn-optimized-ir-09 > > Reviewer: Gyan Mishra > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-bess-evpn-optimized-ir-?? > Reviewer: Gyan Mishra > Review Date: 2021-10-02 > IETF LC End Date: 2021-09-07 > IESG Telechat date: Not scheduled for a telechat > > Summary: > I am the GEN-ART reviewer for this draft and am reviewing the draft as a > BESS > WG member familiar with the EVPN technology and issues that exist with IR > and > understand the need for the IR optimized solution for BUM replication. > This > draft clearly defines the problem to be solved with IR BUM replication & > the > proposed EVPN Optimized IR Solution which is technically sound. My > comments, > considerations & recommendations are related re-writing of some of the > technical verbiage to help improve the draft. The draft is well written & > clearly describes the problem with EVPN IR PTA and how the Optimized IR > solution with AR replication RT-11 can be used to provide an optimized > Selective P-Tree so all PEs do not have to receive the BUM as exists today > with > RT-3 I-PMSI. This draft provides a EVPN procedure optimization for IR PTA > R-3 > X-PMSI that utilizes a new RT-11 Leaf A-D that was introduced in Jeffrey > Zhang’s EVPN BUM Procedure update “draft > draft-ietf-bess-evpn-bum-procedure-updates-10” that utilizes the RFC 6513 > Leaf-AD route to create a new Selective tree Leaf A-D Route for optimized > EVPN > BUM procedures for inter-as segmentation for any PTA P-Tree being > instantiated > including IR. > Leaf Auto-Discovery (A-D) routes [RFC6513]: For explicit leaf > tracking purpose. > > Leaf A-D concept from RFC 6514 Leaf A-D route for Multicast in VPLS RFC > 7117 > Section 8.3 bottom of page 33 & optimized selective & inclusive P-Tree > X-PMSI > tunnels with or without inter-as segmentation and “draft > draft-ietf-bess-evpn-bum-procedure-updates-10” P-Tree Multicast both > specifications uses RFC 7524 Section 4 Inter-Area P2MP Segmented Next hop > extended community (S-NH-EC) utilized for tunnel segmentation for seamless > MPLS MVPN Multicast setting of “Leaf information required” L flag in PTA > now > used in EVPN BUM procedures updates in draft “draft > draft-ietf-bess-evpn-bum-procedure-updates-10” Section 6.3 and now also > used in > EVPN IR Optimizations draft for Assisted Replication function in RT-11 > (S-NH-EC) with caveat that S-NH-EC is not used is changed from RFC 7524 > which > should be reflected in the verbiage. > > RFC 7524 S-NH-EC Section 4 > 4. Inter-Area P2MP Segmented Next-Hop Extended Community > > This document defines a new Transitive IPv4-Address-Specific Extended > Community Sub-Type: "Inter-Area P2MP Next-Hop". This document also > defines a new BGP Transitive IPv6-Address-Specific Extended Community > Sub-Type: "Inter-Area P2MP Next-Hop". > > A PE, an ABR, or an ASBR constructs the Inter-Area P2MP Segmented > Next-Hop Extended Community as follows: > > - The Global Administrator field MUST be set to an IP address of the > PE, ABR, or ASBR that originates or advertises the route carrying > the P2MP Next-Hop Extended Community. For example this address > may be the loopback address or the PE, ABR, or ASBR that > advertises the route. > > - The Local Administrator field MUST be set to 0. > > If the Global Administrator field is an IPv4 address, the > IPv4-Address-Specific Extended Community is used; if the Global > Administrator field is an IPv6 address, the IPv6-Address-Specific > Extended Community is used. > > The detailed usage of these Extended Communities is described in > the following sections. > > Excerpt from RFC 7524 Section 6.3 also verbiage used in the BUM procedure > update Section 6.3 as well as this EVPN IR optimization draft Section 4 > page 9: > 6.3. Use of S-NH-EC > > [RFC7524] specifies the use of S-NH-EC because it does not allow ABRs > to change the BGP next hop when they re-advertise I/S-PMSI A-D routes > to downstream areas. That is only to be consistent with the MVPN > Inter-AS I-PMSI A-D routes, whose next hop must not be changed when > they're re-advertised by the segmenting ABRs for reasons specific to > MVPN. For EVPN, it is perfectly fine to change the next hop when > RBRs re-advertise the I/S-PMSI A-D routes, instead of relying on S- > NH-EC. As a result, this document specifies that RBRs change the BGP > next hop when they re-advertise I/S-PMSI A-D routes and do not use S- > NH-EC. If a downstream PE/RBR needs to originate Leaf A-D routes, it > constructs an IP-based Route Target Extended Community by placing the > IP address carried in the Next Hop of the received I/S-PMSI A-D route > in the Global Administrator field of the Community, with the Local > Administrator field of this Community set to 0 and setting the > Extended Communities attribute of the Leaf A-D route to that > Community. > > RFC 7117 Excerpt Section 8.3 bottom: > The PE constructs an IP-address-specific RT by placing the IP > address carried in the Next Hop field of the received S-PMSI A-D > route in the Global Administrator field of the Community, with > the Local Administrator field of this Community set to 0 and > setting the Extended Communities attribute of the leaf A-D route > to that Community. > > This draft EVPN IR Optimization Section 4 page 9 > The AR-LEAF constructs an IP-address-specific route-target as > indicated in [I-D.ietf-bess-evpn-bum-procedure-updates], by > placing the IP address carried in the Next-Hop field of the > received Replicator-AR route in the Global Administrator field > of the Community, with the Local Administrator field of this > Community set to 0. Note that the same IP-address-specific > import route-target is auto-configured by the AR-REPLICATOR > that sent the Replicator-AR, in order to control the acceptance > of the Leaf A-D routes. > > RFC 6514 Leaf A-D route is being used for EVPN procedures RT-11 to build > the > selective tree optimization using a new Assisted Replication (AR) procedure > which is the EVPN IR optimization in this draft. > > The confusing part about this draft is that it mentions NVO3 & MPLS PTA. > In > general, NVO3 overlay encapsulations are used in Data Centers with > typically IP > based underlay, however MPLS EVPN procedures RFC 7432 applies to both DC or > Core any underlay IP, MPLS, SR underlay. This draft as its written > applies to > an NVO3 overlay IR procedure optimization utilized in a Data Centers, > however > the Data Center underlay as well as Core can be MPLS or IP based and can > both > have an NVO3 overlay, however the Data Center environment is generally > where > NVO3 VTEP termination tunnel endpoints reside and the core carries the EVPN > control plane inter-DC. RFC 7432 MPLS / IP EVPN supports both IP & MPLS > underlay with IP underlay supporting IR PTA only and MPLS underlay > supporting > all PTAs for RT-3 I-PMSI inclusive tree. Here are a few scenario for the > authors to think about and where the EVPN IR replication optimization > solution > could be utilized. The point I would like to make here is that for BUM > the use > of Multicast P2MP mLDP or RSVP-TE PTA is always the most preferred method > to > handle BUM for both Core or DC scenario and only certain scenario’s that > exist > where multicast would not be preferred. As the NVO3 & MPLS can be used in > both > DC or Core scenario, I will mention both DC & Core scenario, as both > pertains > to this draft. If MPLS is used in the DC or Core then the DC or Core > could be > “PIM” free & “BGP” free in the underlay and mLPD or RSVP-TE PTA options > could > be utilized as the optimal BUM solution. If MPLS is used in the DC or Core > then the DC or Core could be “BGP” free but PIM is enabled in the core for > PIM > Rosen MDT RFC 6037. In the above use cases the IR optimization would not > optimal or preferred solution. Only if IP Is used in the DC or Core in > which > case MVPN PTA options are not possible as MVPN is only utilized with MPLS > underlay & “PIM” is not desired in the underlay then this IR optimization > could > be utilized. However, in the use case where underlay is IP only and not > MPLS > & “PIM” is not desired then this IR optimization would be the most desired > solution for BUM with the caveat in this case that as MVPN procedures RFC > 6513 > & 6514 is used with MPLS underlay for PTA in this case the only viable PTA > would be IR as all the other PTA have MPLS underlay dependency. So in > summary > if MPLS exists then there are a lot of viable X-PMSI PTA options for both > DC & > Core for EVPN NVO3 BUM and IR would not be the desired, and only the unique > case for IP underlay when “PIM” is not desired. I believe IR optimization > AR > replication solution can be used for MPLS underlay as well as there could > be a > use case where even though other PTAs X-PMSI are available it is desired > to use > IR as PTA’s that use MPLS based multicast is not desired and in those > cases the > IR optimization could be for both DC or Core & could apply to Core “Non > NVO3” > use case of EVPN PE-CE AC MLAG All Active Multi-home. This solution breaks > up > the BUM 3 tuple “Broadcast, Unknown Unicast, Multicast” into BM > “Broadcast/Multicast” & keeps Unknown Unicast separated out treated the > same as > known unicast. As MPLS EVPN has a ubiquitous framework & thus ubiquitous > use > cases and can be used for DC or Core and any underlay IP, MPLS or SR where > the > two primary use cases for EVPN are NVO3 encapsulation overlay for DC > multi-tenant environments and NG L2 VPN PE-CE L2 AC advancement addressing > VPLS/H-VPLS gaps that existed to NG MPLS L2 VPN “EVPN” E-LINE, > E-LAN,E-TREE, > this IR optimization draft as well should apply to any EVPN use case and > not > limited to NVO3. BUM & why to separate out BUM 3-tuple (Broadcast, Unknown > Unicast, Multicast) separate out Unknown Unicast BUM handling from > Broadcast & > Multicast “BM” traffic. > > [jorge] about this: > > “I believe IR optimization AR > replication solution can be used for MPLS underlay as well as there could > be a > use case where even though other PTAs X-PMSI are available it is desired > to use > IR as PTA’s that use MPLS based multicast is not desired and in those > cases the > IR optimization could be for both DC or Core & could apply to Core “Non > NVO3”” > > Gyan> Agreed > > > > The document is focused on NVO solutions, that is, IP-tunnels, because the > AR-REPLICATOR relies on a lookup on the IP tunnel outer IPs. Here NVO > assumes the same as in RFC8365, which is the reference for EVPN as a > control plane for IP tunnels. The terminology in this document follows > RFC8365, however let us know if something needs to be clarified. When there > is an MPLS underlay, an assisted replication solution is possible based on > other procedures that are out of scope, e.g., > draft-ietf-bess-evpn-virtual-hub-00 > <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-virtual-hub-00> > . We can state more clearly that MPLS underlay is out of scope if you think > it is not clear? > > > > With regards to the BUM Broadcast / Unkown Unicast - With Proxy ARP/Proxy > ND > what occurs is when the broadcast occurs as an ARP All Fs broadcast, the > first > ARP packet goes out and the Type 2 change from unknown mac / ip to Mac > when arp > request is sent and then when reply is received the MAC/IP state is > created. > After that point no further ARPs are sent for the device. Most > implementations > have a ARP/ND refresh so to keep the MAC/IP state current and purge the old > entries save on MAC VRF URIB state tradeoff so there is constant ARP and is > does not necessarily stop even with Proxy ARP. Trade off is maintain the > larger MAC VRF if the ARP/ND refresh did not occur which is worse that you > don’t want to hit the ceiling on the MAC VRF which is worse. So the draft > states that Broadcast is greatly reduced by Proxy ARP / Proxy ND > capability & > Unknown Unicast is greatly reduced by in virtualized NVO3 networks where > MAC/IP > is learned in the control plane. Even with Proxy ARP / ND ARP as stated > above > the 1st ARP packet is sent as flood all FFs until the control plane MAC > learning generates the Type 2 MAC-IP route, however since most > implementations > track the MAC-IP control plane state with refresh timer to age out and > purge > old entries the all FF’s ARP broadcast ends up being sent more often then > just > once due to the refresh timers to purge the MAC-IP VRF. Unknown unicast > is a > situation where the switch does not have the MAC address in its CAM table > or in > the EVPN scenario the MAC/IP does not exist in leaf within the fabric. In > a L2 > switch environment the Unknown unicast “out of sync” of Bridge tables can > occur > when first hop routing protocol is salt/peppered even/odd such that only > the > Active Router has the MAC and the Standby router does not. With EVPN All > Active Multi-home MHD/MHN MLAG scenario of host endpoint connections both > leafs > are active so there is never an out of sync situation where one leaf has > the > MAC and the other leaf does not. Also EVPN backup path aliasing uniform > load > balancing over MLAG & local bias may take care of the Unknown Unicast > making it > nill or very rare in a EVPN NVO3 environment. BUM Broadcast ARP/ND traffic > would definitely exist even with Proxy ARP/ Proxy ND and it can be quite > substantial due to refresh/purge timers. > > Is the reason for treating the Unknown Unicast differently broken out from > “BM” > because none exists in a NVO3 environment? > > [jorge] BM and unknown (U) have separate flags in the Pruned-Flood-List > flags, indeed. Also BM and U are handled differently since we want Unknown > and known to follow the same path to avoid reordering. As for the PFL > flags, the thought was that BM are both multipoint traffic always and the > way to handle flooding for both B and M (without snooping mcast protocols) > is similar. Unknown traffic is handled differently, and flooding can be > optimized in a typical use-case where we know some compute based NVEs are > not interested in receiving unknown traffic, since they always advertise > the local MACs in advance. > > > > Gyan> Understood > > With regards to EVPN IR optimization > for BUM traffic as this draft addresses BUM optimization when using IR, as > draft draft-ietf-bess-evpn-igmp-mld-proxy defines a new SMET A-D RT-6 > route for > IR optimization for BUM which is equivalent to this drafts leaf-ad route > but > unsolicited and untargeted. This draft must mention normatively in the > draft, > draft-ietf-bess-evpn-igmp-mld-proxy as an alternative solution for BUM IR > optimization and why this solution should be utilized for BUM IR > optimization > over the SMET RT-6 style optimization. Also how is this drafts RT-11 > selective > trees AR replications solution interoperate with draft > draft-ietf-bess-evpn-igmp-mld-proxy SMET route. Is that possible or do you > have to implement one or the other. > > [jorge] This document is mostly about the Assisted Replication definition > as a new Tree type (besides the PFL flags, which are independent). AR can > be used for BUM, as explained in the document, but it can also be used for > multicast when igmp/mld proxy is enabled in the EVPN BDs, or even in the > case of Optimized Inter-Subnet Multicast (OISM) forwarding – > draft-ietf-bess-evpn-irb-mcast. The latter clearly explains how AR is used > in OISM. > > Gyan> Understood. Agreed. Is it worthwhile to maybe explain how this > draft would work in conjunction with the two drafts you mentioned. I see > that OSIM mentions AR operation. Good. As this draft pre dates the other > two I agree they should mention this draft. > > > Major issues: > > None > > Minor issues: > > Abstract > OLD TXT > Network Virtualization Overlay (NVO) networks using EVPN as control > plane may use Ingress Replication (IR) or PIM (Protocol Independent > Multicast) based trees to convey the overlay Broadcast, Unknown > unicast and Multicast (BUM) traffic. PIM provides an efficient > solution to avoid sending multiple copies of the same packet over the > same physical link, however it may not always be deployed in the NVO > core network. IR avoids the dependency on PIM in the NVO network > core. While IR provides a simple multicast transport, some NVO > networks with demanding multicast applications require a more > efficient solution without PIM in the core. This document describes > a solution to optimize the efficiency of IR in NVO networks. > > NEW TXT > Network Virtualization Overlay (NVO) networks and BGP MPLS Based L2 VPN > E-LINE, E-LAN, E-TREE flavor Ethernet VPN’s in a Service Provider Core and > Data > Center Networks using EVPN as control plane may use any available PMSI > Tunnel > Attribute (PTA)such as Ingress Replication (IR) RFC 7988,PIM (Protocol > Independent Multicast)MDT SAFI RFC 6037, mLDP P2MP MP2MP RFC 6388 or > RSVP-TE > P2MP RFC 4875 based P-Trees to replicate the overlay Broadcast, Unknown > unicast > and Multicast (BUM) traffic. Multicast based PTA tunnel types provides an > efficient solution to avoid sending multiple copies of the same packet > over the > same physical link, however in a Data Center all the PTA tunnel types may > not > be available with IP-Based underlay and native PIM is not desirable or with > MPLS-Based underlay with “BGP” and “PIM” free core where the operator is > migrating to Segment Routing and is in the process of eliminating LDP and > RSVP-TE P2MP PTA is not desirable. In these use cases, the only option > available is to use IR. While IR provides a simple multicast transport, > in the > case of Service Provider Core migrating to Segment Routing or Data Center > NVO > networks with IP-Based underlay with demanding multicast applications > require a > more efficient solution than IR. This document describes a solution to > optimize the efficiency of IR in a Service Provider Core in transition to > Segment Routing or Data Center NVO network with IP-Based underlay. > > [jorge] As explained earlier, the document is really focused on EVPN with > NVO tunnels, as per RFC8365. So no Segment Routing MPLS or no RSVP/LDP. And > for an NVO solution using EVPN (RFC8365), there is only PIM trees > (different flavors of PIM) or IR defined. This document extends the list to > AR as well. But I don’t think we should add the MPLS underlay related text > in the abstract. Based on this, please let us know if you still think we > need to clarify the abstract. > > Gyan> Understood. Agreed as MPLS is out of scope. I think that needs to > be mentioned clearly. > > Introduction > OLD TXT > Ethernet Virtual Private Networks (EVPN) may be used as the control > plane for a Network Virtualization Overlay (NVO) network. Network > Virtualization Edge (NVE) devices and Provider Edges (PEs) that are > part of the same EVPN Instance (EVI) use Ingress Replication (IR) or > PIM-based trees to transport the tenant's Broadcast, Unknown unicast > and Multicast (BUM) traffic. In NVO networks where PIM-based trees > cannot be used, IR is the only option. Examples of these situations > are NVO networks where the core nodes don't support PIM or the > network operator does not want to run PIM in the core. > > In some use-cases, the amount of replication for BUM (Broadcat, Unkown > Unicast, Multicast) traffic is kept under control on the NVEs due to the > following fairly common assumptions: > > a. Broadcast is greatly reduced due to the proxy ARP (Address > Resolution Protocol) and proxy ND (Neighbor Discovery) > capabilities supported by EVPN on the NVEs. Some NVEs can even > provide Dynamic Host Configuration Protocol (DHCP) server > functions for the attached Tenant Systems (TS) reducing the > broadcast even further. > > b. Unknown unicast traffic is greatly reduced in virtualized NVO > networks where all the MAC and IP addresses are learned in the > control plane. > > c. Multicast applications are not used. > > If the above assumptions are true for a given NVO network, then IR > provides a simple solution for multi-destination traffic. However, > the statement c) above is not always true and multicast applications > are required in many use-cases. > > When the multicast sources are attached to NVEs residing in > hypervisors or low-performance-replication TORs (Top Of Rack > switches), the ingress replication of a large amount of multicast > traffic to a significant number of remote NVEs/PEs can seriously > degrade the performance of the NVE and impact the application. > > NEW TXT > Service Provider Core and Data Center networks may use Ethernet Virtual > Private > Networks (EVPN)as the control plane for an Network Virtualization Overlay > (NVO) > network with IP-Based Underlay or BGP MPLS Based L2 VPN E-LINE, E-LAN, > E-TREE > flavor Ethernet VPN’s Virtualization Edge (NVE) devices and Provider Edges > (PEs) that are part of the same EVPN Instance (EVI)can use Ingress > Replication > (IR) or any available MPLS based PTA for P-Tree instantiation to transport > the > tenant's Broadcast, Unknown unicast and Multicast (BUM) traffic. In > Service > Provider Core or Data Center NVO networks where MPLS based PTA’s are not > available such as a Service Provider core migrating to Segment Routing > where > LDP is being eliminated and RSVP-TE P2MP is not desirable or Data Center > network with IP-Based Underlay and Native PIM is not desirable, IR is the > only > option. Examples of these situations are NVO networks where the core nodes > don't support MPLS based PTA with dependency on mLDP and both Native PIM > and > RSVP-TE P2MP LSM is not desirable. > > In some use-cases, the amount of replication for BUM traffic is kept > under control on the NVEs due to the following fairly common > assumptions: > > a. Broadcast is moderately reduced due to the proxy ARP (Address > Resolution Protocol) and proxy ND (Neighbor Discovery) > capabilities supported by EVPN on the NVEs with Selective IR > tunnels optimization defined in draft > draft-ietf-bess-evpn-igmp-mld-proxy. Some NVEs can even > provide Dynamic Host Configuration Protocol (DHCP) server > functions for the attached Tenant Systems (TS) reducing the > broadcast even further. During the Proxy ARP/ND process the first > ARP > packet is still send all F’s broadcast resulting in Type 2 change > from > Unknown Mac-IP route to MAC-IP route when ARP/ND request is sent and > reply is received the MAC VRF MAC-IP state is created. Proxy ARP/ND > then suppresses or proxies all ARP/ND sent by the local hosts. > However, > due to ARP/ND refresh state requirements to keep the MAC-IP state > current and purge the old entries save on MAC VRF URIB state as a > tradeoff there maybe additional ARP/ND packets sent for each MAC VRF > MAC-IP entry. The IGMP-MLD proxy Selective IR tunnel optimization > draft > improves the performance of IR using SMET route and maybe used in > conjunction with this draft. Even though Proxy ARP/ND suppression > techniques are utilized as the refresh/purge must be implemented to > age > old entries to control the MAC VRF size the broadcast traffic is > only > moderately reduced and thus RFC 7432 EVPN IR for BUM is not a viable > solution without the IR optimization solution defined in this draft > and/or draft-ietf-bess-evpn-igmp-mld-proxy. > > ***Please investigate if both EVPN IR optimizations can be used together > and > what are all the caveats and if they cannot be used together and why** The > main point here that should be mentioned is that Broadcast traffic is > reduced > but there is still a considerable amount of broadcast traffic that needs > to be > optimized > > b. Unknown unicast traffic is eliminated in virtualized NVO > networks due to all the MAC and IP addresses are learned in the > control plane for All-Active Multi-home LAG scenario and reduced for > Single-Active Multi-Home EVPN scenario. Unknown unicast is a > situation > where the packet has the IP and MAC, however the switch is missing > the > MAC entry which occurs due to Layer 2 switch BD table > synchronization > becomes unsynchronized due to salt and pepper of first hop router > redundancy active router VLAN between L2 switches resulting in > Unknown > unicast. In an EVPN scenario with All-Active-Multi-Home the MAC-IP > remains synchronized with ESI auto discovery, however with > Single-Active-Multi-Home the MAC-IP may not be synchronized > resulting in > Unknown unicast. As a result, there is minimal to none Unknown > Unicast > in a NVO network. > > c. Multicast applications are not used. > > If the above assumptions are true for a given NVO network, then IR > provides a simple solution for multi-destination traffic. However, > the statement c) above is not always true and multicast applications > are required in many use-cases. > > When the multicast sources are attached to NVEs residing in > hypervisors or low-performance-replication TORs (Top Of Rack > switches), the ingress replication of a large amount of multicast > traffic to a significant number of remote NVEs/PEs can seriously > degrade the performance of the NVE and impact the application. > > In the draft it should be mentioned the reason why BM (Broacast & > Multicast) > are treated differently by this solution then Unknown Unicast. My answer > is > that the Unknown Unicast is minimal to none so does not need the > optimization. > > [jorge] after explaining that MPLS underlay is out of scope, please let us > know if it is ok to keep the OLD text. About AR tunnels being used in > igmp/mld proxy and OISM, yes, compatibility is perfectly okay, but since > this document just defines the AR tree and predates > draft-ietf-bess-evpn-igmp-mld-proxy and draft-ietf-bess-evpn-irb-mcast I > don’t think this document needs to refer to the other two drafts, but > rather the opposite. > > Gyan> I am ok with keeping old txt > > Terminology section: > > OLD TXT > - Regular-IR: Refers to Regular Ingress Replication, where the > source NVE/PE sends a copy to each remote NVE/PE part of the BD. > > - IR-IP: IP address used for Ingress Replication as in [RFC7432]. > > - AR-IP: IP address owned by the AR-REPLICATOR and used to > differentiate the ingress traffic that must follow the AR > procedures. > > New TXT > - Regular-IR: an EVPN RT-3 ( Route Type 3) Regular Ingress Replication, > where > the source NVE/PE sends a copy to each remote NVE/PE part of the BD. > > - IR-IP: PTA Tunnel endpoint identifier which carries the unicast tunnel > endpoint (Loopback) IP address of the Non-AR-Replicator local PE used for > Ingress Replication as defined in RFC 6514. > > [jorge] The document uses the IR-IP as just an IP address, that can be > used in the PTA tunnel identifier but also in the route’s next-hop and > originating IP, also the outer IP DA of the packets is compared against > this IP. So I don’t think the above is correct. I prefer to keep the > current definition and then have the text explaining how to use the IR-IP. > > Gyan> please see responses at beginning of this email. > > - AR-IP: PTA Tunnel endpoint identifier which carries the unicast tunnel > endpoint (loopback) IP address of the AR-REPLICATOR local PE as defined in > RFC > 6514 and used to differentiate the ingress traffic that must follow the AR > procedures. > > [jorge] similar to the IR-IP comment.. AR-IP is an IP address of the > replicator, the text later explains how to use it (not only in the PTA). > > Gyan> Please see response at beginning of this email > > Updated the reference to what the AR-IP & IR-IP is basically is the PMSI > Tunnel > attribute PTA termination endpoint ID, AR-IP for the AR node & IR-IP for > Non-AR > node. > > [jorge] AR-IP and IR-IP are not limited to the PTA, please see above. > > Gyan> Understood > > RFC 7432 section 11.2 references RFC 6514 PMSI tunnel attribute must > contain > the identity of the tree RFC 7432 Section 11.2 11.2. P-Tunnel > Identification > > In order to identify the P-tunnel used for sending broadcast, unknown > unicast, or multicast traffic, the Inclusive Multicast Ethernet Tag > route MUST carry a Provider Multicast Service Interface (PMSI) Tunnel > attribute as specified in [RFC6514]. > > + If the PE that originates the advertisement uses ingress > replication for the P-tunnel for EVPN, the route MUST include the > PMSI Tunnel attribute with the Tunnel Type set to Ingress > Replication and the Tunnel Identifier set to a routable address of > the PE. > > RFC 6514 Section 5 > When the Tunnel Type is set to Ingress Replication, the Tunnel > Identifier carries the unicast tunnel endpoint IP address of the > local PE that is to be this PE's receiving endpoint address for the > tunnel. > > Section 3 Solution Requirements > > OLD TXT > a. It provides an IR optimization for BM (Broadcast and Multicast) > traffic without the need for PIM, while preserving the packet > order for unicast applications, i.e., known and unknown unicast > traffic should follow the same path. This optimization is > required in low-performance NVEs. > > NEW TXT > a. It provides an IR optimization for BM (Broadcast and Multicast) > traffic without the need for PTA’s with MPLS or PIM based > dependencies, > while preserving the packet order for unicast applications, i.e., > known > and unknown unicast traffic should follow the same path. This > optimization is required in low-performance NVEs. > > [jorge] similar comment as earlier about MPLS trees, they are out of scope > of the document. > > Gyan> Understood > > How is IR optimization preserving unicast ordering ? > Normal Unicast traffic is not BUM and thus would not use EVPN IR > optimization > AR mechanism. > > [jorge] the solution uses AR for BM and unknown/known unicast follow > regular ingress replication, that’s how they can follow the same path. This > is the relevant text, let us know if it requires clarification: > > Gyan> I see maybe if you can clarify a bit more how unknown Unicast which > is all Fs flooded in L2 environment so unknown and known Unicast flow is > completely different and how and why the two have the same treatment. Is > it because their is minimal to none unknown in NVO environment is my guess. > > This solution recommends the replication of BM through the > > AR-REPLICATOR node, whereas unknown/known unicast will be delivered > > directly from the source node to the destination node without being > > replicated by any intermediate node. Unknown unicast SHALL follow > > the same path as known unicast traffic in order to avoid packet > > reordering for unicast applications and simplify the control and data > > plane procedures. > > > > Section 4 – Type3 is being extended to support -optimized IR – new type 3 > – so > that is part of capability exchange > > 4. EVPN BGP Attributes for optimized-IR > > This solution extends the [RFC7432] Inclusive Multicast Ethernet Tag > routes and attributes so that an NVE/PE can signal its optimized-IR > capabilities. > > 7432 section 7.3 > 7.3. Inclusive Multicast Ethernet Tag Route > > An Inclusive Multicast Ethernet Tag route type specific EVPN NLRI > consists of the following: > > +---------------------------------------+ > | RD (8 octets) | > +---------------------------------------+ > | Ethernet Tag ID (4 octets) | > +---------------------------------------+ > | IP Address Length (1 octet) | > +---------------------------------------+ > | Originating Router's IP Address | > | (4 or 16 octets) | > +---------------------------------------+ > > Please reference below with RFC 6514 Section 5 > > 5. PMSI Tunnel Attribute > > This document defines and uses a new BGP attribute called the > "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute". This > is an optional transitive BGP attribute. The format of this > attribute is defined as follows: > > RFC 6514 BGP Encodings and Procedures for MVPNs February 2012 > > +---------------------------------+ > | Flags (1 octet) | > +---------------------------------+ > | Tunnel Type (1 octets) | > +---------------------------------+ > | MPLS Label (3 octets) | > +---------------------------------+ > | Tunnel Identifier (variable) | > +---------------------------------+ > > [jorge] are you suggesting this document should refer to RFC6514? This > document is based on RFC7432 and RFC8365, both of which make use of the PTA > in RFC6514, but that should have been already referenced in those… ? > > Gyan> See responses at beginning of email > > Section 4 top of page 8 > > As described in the summary section of the review, this section should > reference RFC 7524 Section 4 which is referenced by > “draft-ietf-bess-evpn-bum-procedure-updates” section 6.3 S-NH-EC and also > reference used by RFC 7117 Section 8.3 and in describe that in > “draft-ietf-bess-evpn-bum-procedure-updates” that for EVPN S-NH-EC in the > Leaf-AD routes is not necessary for the response to Replicator-AR route > RT-3. > This should be included in the verbiage. > > [jorge] hmm… is that necessary given that we already refer to > I-D.ietf-bess-evpn-bum-procedure-updates? > > Gyan> See responses at beginning of email > > I updated some normative language – please check > OLD TXT > In this document, the above RT-3 and PTA can be used in two different > modes for the same BD: > > - Regular-IR route: in this route, Originating Router's IP Address, > Tunnel Type (0x06), MPLS Label and Tunnel Identifier MUST be used > as described in [RFC7432] when Ingress Replication is in use. The > NVE/PE that advertises the route will set the Next-Hop to an IP > address that we denominate IR-IP in this document. When > advertised by an AR-LEAF node, the Regular-IR route SHOULD be > advertised with type T= AR-LEAF. > > - Replicator-AR route: this route is used by the AR-REPLICATOR to > advertise its AR capabilities, with the fields set as follows: > > o Originating Router's IP Address MUST be set to an IP address of > the PE that should be common to all the EVIs on the PE (usually > this is the PE's loopback address). The Tunnel Identifier and > Next-Hop SHOULD be set to the same IP address as the > Originating Router's IP address when the NVE/PE originates the > route. The Next-Hop address is referred to as the AR-IP and > SHOULD be different than the IR-IP for a given PE/NVE. > > o Tunnel Type = Assisted-Replication Tunnel. Section 11 provides > the allocated type value. > > o T (AR role type) = 01 (AR-REPLICATOR). > > o L (Leaf Information Required) = 0 (for non-selective AR) or 1 > (for selective AR). > > In addition, this document also uses the Leaf A-D route (RT-11) > defined in [I-D.ietf-bess-evpn-bum-procedure-updates] in case the > selective AR mode is used. The Leaf A-D route MAY be used by the AR- > LEAF in response to a Replicator-AR route (with the L flag set) to > advertise its desire to receive the BM traffic from a specific AR- > REPLICATOR. It is only used for selective AR and its fields are set > as follows: > > o Originating Router's IP Address is set to the advertising PE's > IP address (same IP used by the AR-LEAF in regular-IR routes). > The Next-Hop address is set to the IR-IP. > > o Route Key is the "Route Type Specific" NLRI of the Replicator- > AR route for which this Leaf A-D route is generated. > > o The AR-LEAF constructs an IP-address-specific route-target as > indicated in [I-D.ietf-bess-evpn-bum-procedure-updates], by > placing the IP address carried in the Next-Hop field of the > received Replicator-AR route in the Global Administrator field > of the Community, with the Local Administrator field of this > Community set to 0. Note that the same IP-address-specific > import route-target is auto-configured by the AR-REPLICATOR > that sent the Replicator-AR, in order to control the acceptance > of the Leaf A-D routes. > > o The Leaf A-D route MUST include the PMSI Tunnel attribute with > the Tunnel Type set to AR, type set to AR-LEAF and the Tunnel > Identifier set to the IP of the advertising AR-LEAF. The PMSI > Tunnel attribute MUST carry a downstream-assigned MPLS label or > VNI that is used by the AR-REPLICATOR to send traffic to the > AR-LEAF. > > Each AR-enabled node MUST understand and process the AR type field in > the PTA (Flags field) of the routes, and MUST signal the > corresponding type (1 or 2) according to its administrative choice. > > NEW TXT > When the PTA builds PMSI tunnel per RFC 6514 section I called the IR-IP > changed > to PTA-ID to make it easier for the reader as the source / destination of > the > PMSI tunnel termination endpoints is the PTA PMSI Tunnel Attribute > Identifier. > > [jorge] I don’t think we should change that since it changes the intended > meaning. > > Gyan> I am good with OLD TXT. Please reference comments at beginning of > email > > **start of the new txt** > > [jorge] please check out my comments and let us know what changes you > would like to make based on them. > > > In this document, the above RT-3 and PTA can be used in two different > modes for the same BD: > > - Regular-IR route: This route is the regular RT-3 I-PMSI > > Originating Router's Unicast IP Address called the IR-IP MUST be set > to > the PMSI Tunnel Identifier for the PTA Tunnel Type (0x06) used for > IR as > described in 6514 when Ingress Replication is used. The NVE/PE that > advertises the route will set the Next-Hop to the remote tunnel > endpoint > PMSI Tunnel Identifier IR-IP as defined in RFC 6514. When > advertised by > an AR-LEAF node, the Regular-IR route MUST be advertised with type T= > AR-LEAF. > > [jorge] I don’t agree we should reference RFC6514, since this IR route is > the same route defined in RFC7432, and we refer to RFC7432. > > Gyan> See comments beginning of email > > o Tunnel Type = Assisted-Replication Tunnel. Section 11 provides > the allocated type value. > > o T (AR role type) = 10 (AR-LEAF). > > o L (Leaf Information Required) = 0 (for non-selective AR=0) or > (for selective AR=1). Regular-IR route is only used only for Non > Selective P-Tree. > > - Replicator-AR route: This route is used by the AR-REPLICATOR to > advertise its AR capabilities, with the fields set as follows: > > o Originating Router's Unicast IP Address called the AR-IP MUST be > set to > the PMSI Tunnel Identifier for the PTA Tunnel Type(0x06) which is > the IP > address of the PE that should be common to all the EVIs on the PE as > defined in RFC 6514. The Tunnel Identifier and Next-Hop MUST be set > to > the same IP address as the Originating Router's IP address PTA > Tunnel ID > when the NVE/PE originates the route as described in RFC 6514. The > Next-Hop address of the Replicator-AR route as seen on the AR-LEAF is > referred to as the AR-IP and MUST be unique and cannot be the same > as the > IR-IP for a given PE/NVE. > > o Tunnel Type = Assisted-Replication Tunnel. Section 11 provides > the allocated type value. > > o T (AR role type) = 01 (AR-REPLICATOR). > > o L (Leaf Information Required) = 1 (for non-selective AR=0) or > (for selective AR=1). Replicator-AR route is only used for > Selective > P-Tree. > > In addition, this document also uses the Leaf A-D route (RT-11) > defined in [I-D.ietf-bess-evpn-bum-procedure-updates] in case the > selective AR mode is used. Draft ietf-bess-evpn-bum-procedure-updates > updates the EVPN BUM procedures for EVPN Multicast optimized selective > trees > used, introducing three new route types RT-9 Per Region I-PMSI A-D, > RT-10 > S-PMSI A/D and RT-11 Leaf A-D utilized for Selective P-Tree PTA inter-as > segmentation optimizations, and utilizes RFC 7117 concept of selective > tree > optimization procedure to signal leaf-ad route to instantiate inter-as > P-Tree framework from Intra-AS and Inter-AS VPLS Multicast I/S-PMSI A/D > & > Leaf A-D solution which now is also leveraged by AR replicator for IR > optimization utilizing RT-11 to build selective tree IR optimization > for BUM > traffic. Section 6 of bess-evpn-bum-procedure-updates defines the RT-11 > Leaf-AD route selective tree optimization concept from RFC 7117 > response to > I-PMSI route, RFC 7524 Inter-Area P2MP Segmented Next Hop Extended > Community > S-NH-EC which is utilized for Inter-AS P2MP Segmented LSP stitching. RFC > 7524 Section 6 states that it requires the ABRs to keep the next hop > unchanged for re-advertisement I/S PMSI A-D route which only needs to be > consistent for MVPN Inter-AS I-PMSI A/D routes whose next hop MUST be > unchanged. EVPN for inter-as readvertisement of I/S-PMSI A-D route the > next > hop can be changed and so does not need to rely on S-NH-EC. > > [jorge] if we have a reference to > I-D.ietf-bess-evpn-bum-procedure-updates, I don’t think we need references > to RFC7524 or 7117. This documents follows the RT-11 use as defined in > I-D.ietf-bess-evpn-bum-procedure-updates, with the specifics described in > the document. Besides, as discussed, MPLS underlay is out of scope. > > Gyan> I agree we don’t have to reference RFC 7524. Please see responses > beginning of email > > The Leaf A-D route MAY be used by the AR-LEAF in response to a > Replicator-AR route (with the L flag set) to advertise its desire to > receive > the BM traffic from a specific AR-REPLICATOR. It is only used for > selective AR > and its fields are set as follows: > > o Originating Router's IP Address is set to the advertising PE's > IP address (same IP used by the AR-LEAF in regular-IR routes). > The Next-Hop address is set to the IR-IP. > > o Route Key is the "Route Type Specific" NLRI of the Replicator- > AR route for which this Leaf A-D route is generated. > > o The AR-LEAF constructs an IP-address-specific route-target as > indicated in [I-D.ietf-bess-evpn-bum-procedure-updates], by > placing the IP address carried in the Next-Hop field of the > received Replicator-AR route in the Global Administrator field > of the Community, with the Local Administrator field of this > Community set to 0. Note that the same IP-address-specific > import route-target is auto-configured by the AR-REPLICATOR > that sent the Replicator-AR, in order to control the acceptance > of the Leaf A-D routes. > > o The Leaf A-D route MUST include the PMSI Tunnel attribute with > the Tunnel Type set to AR, type set to AR-LEAF and the Tunnel > Identifier set to the IP of the advertising AR-LEAF. The PMSI > Tunnel attribute MUST carry a downstream-assigned MPLS label or > VNI that is used by the AR-REPLICATOR to send traffic to the > AR-LEAF. > > Each AR-enabled node MUST understand and process the AR type field in > the PTA (Flags field) of the routes, and MUST signal the > corresponding type (1 or 2) according to its administrative choice. > > **There are a few different flags & new flags defined in the PTA - please > be > specific as to the type 1 & 2 flags** > > [jorge] sure, we can do that in the next revision. > > > > ***Implementation considerations section – important and also details as > to how > does the backwards compatibility work*** As RT-3 introduces a mode and > RT-11 is > new in this draft what devices need to be upgraded and do all need to be > upgraded to support the solution? ***Implementation section of any vendor > implementations thus far please list** Also mention any issues found with > any > implementations also any operators that have deployed the implementation. > > [jorge] we can elaborate on this but the RNVE role is actually a > non-upgraded node, so backwards compatibility is always present in the > document. About implementations, there are two vendors with shipping code > for this afaik. There was public interop testing at the EANTC 2020, and a > public white paper exists with the details of the interop testing for AR. > As this document is in Last Call and seeks publication, I fail to see how > including details on interop testing between specific vendors help the > document. That information will be outdated as more vendors implement it.. ? > > Gyan> Agreed no need for interoperability testing but I think > implementations would be good to include. > > Nits/editorial comments: > > Normative reference should be added per the re-written text provided in the > Minor issues section for the following: > > RFC 7524 Inter-AS P2MP Segmented LSP & RFC 7117 Multicast VPLS and draft > draft-ietf-bess-evpn-igmp-mld-proxy, RFC 6388 mLDP, RFC 6037 MDT SAFI, RFC > 4875 P2MP TE > > [jorge] I discussed, I don’t think we need to refer to the above due to > the reasons stated. > > Gyan> See comments at beginning of email. I still recommend that RFC 7117 > be informative reference. > > Informative reference to MVPN procedures RFC 6513 MVPN, RFC 7988 Ingress > Replication, RFC 7348 VXLAN, RFC 8926 GENEVE > > [jorge] this document does not use any of the procedures in 6513 or 7988 > as discussed. It uses some pieces in RFCs 7432, 8365 and the bum-procedures > draft and those are referenced already. Also yes, we can add references to > VXLAN and GENEVE, but there is no text in the document that refer to those > two, so not sure why we would need references to 7348 or 8926 either? > > Gyan> Agreed. RFC 6514 and RFC 7117 are the only two additional > references I would recommend. As a lot of the basis and changes to EVPN > procedures for multicast are from RFC 7117 I think it would be a good idea. > > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>* > > *M 301 502-1347* > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>* *M 301 502-1347*
- [bess] Genart last call review of draft-ietf-bess… Gyan Mishra via Datatracker
- Re: [bess] Genart last call review of draft-ietf-… Rabadan, Jorge (Nokia - US/Mountain View)
- Re: [bess] Genart last call review of draft-ietf-… Gyan Mishra
- Re: [bess] Genart last call review of draft-ietf-… Rabadan, Jorge (Nokia - US/Mountain View)
- Re: [bess] [Gen-art] Genart last call review of d… Lars Eggert
- Re: [bess] Genart last call review of draft-ietf-… Gyan Mishra