From nobody Fri Feb 12 07:09:53 2021 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD293A102F for ; Fri, 12 Feb 2021 07:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net 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 anDEsiTgu9E8 for ; Fri, 12 Feb 2021 07:09:42 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 B2E4C3A1638 for ; Fri, 12 Feb 2021 07:09:41 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id e18so11888804lja.12 for ; Fri, 12 Feb 2021 07:09:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aLFJsn0sQFvh0FXcJqC+y6QrhIe3D4dq1zpfBVQAHTM=; b=Hu3msJSV+1EJclajRPmiU96PxY2uP+kYYRL/dulFCftZVdkgYb4lBSvrHsFzQ3aFzY G8LPrFMbEyCBwoXM7feGMCa/fZm+NKMKPo6Jh0ILUHuuRj3ZZGP0K1KQQYpodc03oALY eI08/a1Rw+vW26C/JKReaqIYGq/Niq3pugagbgqlGCtzJ5uQiwQnMbElX4Q3UsyTes22 Gem6/igNU9sShnHxwlp367L38DvXKKLYFqrCgkARNvXYBzbFcPgay2vwdfWQhgrin7TI Tb23rrPI36yHTfo3KDV30yPGovEmYVBou6/2opDuq6nGjUU5XpqXgJrV2R9t6fSUwUoO jfkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aLFJsn0sQFvh0FXcJqC+y6QrhIe3D4dq1zpfBVQAHTM=; b=MWRQ7Zj1lOm7VIo30I7MIuZ1T1/meWDV3lv6H32/LPORart8xxfgK33Hnjo12l27d6 XEVXi8nwevztND3xohC6vfPdjlCSy9OS4BikhnNMqGhbXjRj4/DnehJmEZ6N3Z4H4RPB YBx8BdgDkrUKXB52KFIle2o26eX8C+44/bhPkx2Y98VPPfkQBWsawQBSLLXACIBpZzgq UxPByl3nJ87za85qx0rHVL5QMkVh3pZ3ss620LNLwv5m2UETJpVRpMhA8wSW9xjkvl4r V+ccr80rAHWsvp2eMFhnem6qRQ1PIGvby4LpYwV+5oNNgQzpRwGFKJyNmStMPOM3F4dX gn/w== X-Gm-Message-State: AOAM532tYED3IRpIsJybAuFWUuHOVBtygiixYuz/u5UDZf4V751aQ+9U bzGOSEwZ8wkoiQnrWcdD83p5FPEUCG29XspZILE3Cg== X-Google-Smtp-Source: ABdhPJyKzBhqJ0PCLTB9ZKdJaNQIL29uEOf00tgLI0bv46I4Uta9HAEZUPaqMfS0mv8IA3l665+dVduQdXT29iEBRzQ= X-Received: by 2002:a2e:145e:: with SMTP id 30mr2039556lju.199.1613142576304; Fri, 12 Feb 2021 07:09:36 -0800 (PST) MIME-Version: 1.0 References: <22103C76-7D0B-4452-B6D3-914AC63E828B@tsinghua.org.cn> <283a4847d02a444c9cfdbd31cf313485@huawei.com> In-Reply-To: <283a4847d02a444c9cfdbd31cf313485@huawei.com> From: Robert Raszuk Date: Fri, 12 Feb 2021 16:09:25 +0100 Message-ID: To: "Wanghaibo (Rainsword)" Cc: "idr@ietf. org" , Susan Hares Content-Type: multipart/alternative; boundary="0000000000003bb23405bb250634" Archived-At: Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 15:09:44 -0000 --0000000000003bb23405bb250634 Content-Type: text/plain; charset="UTF-8" > > The receiver device, such as the access router, may have weak performance, > while the sender device, such as the RR, may have strong performance. > Yes., That is precisely why we have https://tools.ietf.org/html/rfc4684 The ORF is a tool and does not exist independently. The deployment problem > described here occurs only when the RD-ORF mode is used. > > Actually, the ORF can be used together with other ORFs, such as Prefixed > ORF. > > RD-ORF provides a more efficient filtering method, making solution > deployment more flexible. > > > > In fact, most vendors' devices support rd-filter, but only support the > configuration. > > > > In addition, if the RR decides to push the RD-ORF to its route source only > when PE1 and PE3 do not want that RD. > See this is one more time indication that you have serious gap in understanding L3VPNs. PEs which import routes do not understand sender's ORF. They take routes and based on RT make a local copy to importing VRF. In RFC4364 RTs are used to build arbitrary VPN topologies not RDs. Thx --0000000000003bb23405bb250634 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The rece= iver device, such as the access router, may have weak performance, while th= e sender device, such as the RR, may have strong performance.


Yes., That is precisely why we ha= ve=C2=A0 https://tools.ietf.org/html= /rfc4684

The ORF is a tool and does not exist independe= ntly. The deployment problem described here occurs only when the RD-ORF mod= e is used.

Actually, the ORF can be us= ed together with other ORFs, such as Prefixed ORF.

RD-ORF provides a more effi= cient filtering method, making solution deployment more flexible.=

=C2=A0=

In fact, most vendors' = devices support rd-filter, but only support the configuration.

=C2=A0=

In addition, if the RR deci= des to push the RD-ORF to its route source only when PE1 and PE3 do not wan= t that RD.


See this = is one more time indication that you have serious gap in understanding L3VP= Ns.=C2=A0

PEs which import routes do not understan= d sender's ORF. They take routes and based on RT make a local copy to i= mporting VRF.=C2=A0

In RFC4364 RTs are used to bui= ld arbitrary VPN topologies not RDs.=C2=A0

Thx


--0000000000003bb23405bb250634--