Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)
Gyan Mishra <hayabusagsm@gmail.com> Mon, 15 February 2021 20:59 UTC
Return-Path: <hayabusagsm@gmail.com>
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 1A49E3A115E for <idr@ietfa.amsl.com>; Mon, 15 Feb 2021 12:59:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.097
X-Spam-Level:
X-Spam-Status: No, score=-0.097 tagged_above=-999 required=5 tests=[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, HTTPS_HTTP_MISMATCH=0.1, 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=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 RqgBVwFStP3w for <idr@ietfa.amsl.com>; Mon, 15 Feb 2021 12:59:41 -0800 (PST)
Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 5B34D3A115A for <idr@ietf.org>; Mon, 15 Feb 2021 12:59:41 -0800 (PST)
Received: by mail-pl1-x62e.google.com with SMTP id u11so4327650plg.13 for <idr@ietf.org>; Mon, 15 Feb 2021 12:59:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/6wnvSxZP6YKbqyybhZfvH1bndSLPZXgPljy2To1fXQ=; b=M0roBKbwwigW5fQwNEc7j4X+uGG5rEBlE82IB/gE673GpmJ6QXwTnBgyWeWUUEebVQ k3GH693sosxPF7LGOSXIPiQBLgiS2VM/Bh4osBjMHCpV95mRFok5eEyoh0RYqUAqFjgy PySeJJck8sU8GqDeLdocGSEElphJpdAzwsjR8Be6nzybyxRoxPmw5pu+o/oOdudPyA5S h+7mLODUmA/v2R1zEIKwDUYd8bmXxnsU2ZK3/D5CrqIjS+AigTnCWMKTocQSW0N4sxvz dqRRua66dFDK9p+BBZ5B5xqFZuBjh/tOkhXFgxyNe4/inQ40UjY5v0Adc81cTERXSZ/A DJWQ==
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=/6wnvSxZP6YKbqyybhZfvH1bndSLPZXgPljy2To1fXQ=; b=XRBkkuPwDWa/4CFCN3uih1Qg46WwEgMA3nKzHrfTNSQT6DTY6zT69Tabv1WxS+Z4NH V5LucHDRRJ2FFweOaySh00tZjtIiDSUyWdd5qye8HWm81YbfvWhgY1hHaPW3MIo8NwtT FMvZmkKyBhm/wNhEXy7kT5Ph3sEEpFbtkEVLahzJmAmPptM+18+GEwkA89AaM/WkKY2n 2SULe0TQGaCkt4rQKvaDCVeubYy3HaXzLplBQbE3HCOR9aR5met1+2hzWBrGCwMUX6UU GEHyra8iwBnyLGhBQ995JooKkPo2DyanZa3TvIyxIz1LO4TQD8kmfygB4b/eQxbkP4Pf 3vNQ==
X-Gm-Message-State: AOAM533lZcx+h/u6yjdsC3XZrwSPavCkrXyQmRuu6dy4gQycidZHVaUK cmrLiG1PzOa8RzRaRMci5+wiiqtGwxxWmhM9I7jdSlnZcQI=
X-Google-Smtp-Source: ABdhPJzSvZUYJQdl786h29s/ZggmNJk/hDELx/clOmAlpfBeowgILRPlTfwDk+z8tSfp1pRGnNxvn3yGnI9E9vau7zU=
X-Received: by 2002:a17:902:7c0d:b029:e2:e9cd:6280 with SMTP id x13-20020a1709027c0db02900e2e9cd6280mr17040219pll.22.1613422780372; Mon, 15 Feb 2021 12:59:40 -0800 (PST)
MIME-Version: 1.0
References: <CAOj+MMEviLf-1Ay2NUkNUx_bzDt+cyFZV61rjuKh2crZFjCJ3g@mail.gmail.com> <F9BFBCF7-4985-4F45-9A0A-EB46DB7F9FCB@tsinghua.org.cn> <CABNhwV1RC1rRQz9r7zxMZaGkM=r34JGi1QihvoG0STBvzkwBRw@mail.gmail.com> <MW4PR02MB7394FB00714588E5C4E90652C6889@MW4PR02MB7394.namprd02.prod.outlook.com>
In-Reply-To: <MW4PR02MB7394FB00714588E5C4E90652C6889@MW4PR02MB7394.namprd02.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Mon, 15 Feb 2021 15:59:28 -0500
Message-ID: <CABNhwV0jioD5LtJ3bnV=iYdN+ort1tkHG5w25BdLYzKMKzVd0Q@mail.gmail.com>
To: "UTTARO, JAMES" <ju1738@att.com>
Cc: Aijun Wang <wangaijun@tsinghua.org.cn>, Robert Raszuk <robert@raszuk.net>, Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/related; boundary="000000000000b553f005bb66439e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/zJZgMyFxd4WENjWpQF_8jCSQ7-E>
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 <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Feb 2021 20:59:44 -0000
Hi James Replies in-line On Mon, Feb 15, 2021 at 7:35 AM UTTARO, JAMES <ju1738@att.com> wrote: > *Gyan,* > > > > * Looking at your first bullet (a). It would be useful to > describe the terms below in a manner that in not interpretative. TBH we > seem to be going around in circles as the language being used by the > authors of the draft is imprecise. Below find a number of examples of how > your language could be understood ( Not an exhaustive list )..* > > > > *Offending PE – What does this mean? It seems that is the flooding routes > which is a result of what? * > > 1. *Multiple CEs advertising routes simultaneously causing a wave of > paths at the PE* > 2. *Redistribution from VRF<->VRF.* > 3. *Redistribution from GRT-> VRF. * > 4. *Offending PE is actually an Option B ASBR or is dual purposed* > 5. *Other ?* > > > > *Gyan> a-d are possible. Any trigger as the ones you mentioned that could > cause flooding of routes. Single or Multiple VRFs being flooded > simultaneously hitting VPN maximum prefix. Inter-AS B where “retain RT all” > is specified where all RTs are imported. * > > *Weak PE – How do you characterize a weak PE and how do you define > overwhelmed?* > > 1. *Cannot process a given number of routes in time period X leading > to dropping of routes * > 2. *Delayed processing that may result in an incomplete number of > inputs to the BGP Best Path decision.* > 3. *L3VPN customers experiencing an incorrect VPN specification for > some time period Y ( Timeliness )* > 4. *Control Plane Processing impact Forwarding ( This would be > surprising )* > 5. *Other services that may be instantiated on the “Weak PE” are > impacted i.e VPLS * > 6. *Other ?* > > Gyan> A-D are possible. Definitely multiple services is a big one such as VPLS / EVPN Mac route flood. The control plane issues can impact the data plane forwarding on the weak PE. > > *Can a PE be both “offending” and “weak”? I would assume so. I see no > mention of this in your text below. How does your approach deal with said > PE?* > > *Gyan> It’s possible. The RD-ORF process is locally significant so the > offending and weak PE could be the same device. We can add some verbiage > to the draft to account for this situation.* > > *Thanks,* > > * Jim Uttaro* > > a) the problem this draft is drafting to solve relating to BGP routes, > > The problem we are trying to solve is a scenario where you have an > offending PE that is flooding routes and a weak PE that is overwhelmed by a > flood of routes. This is not a normal situation and is an outage situation > where the weak PE being overwhelmed by a flood of routes. Do we all agree > to the problem statement? > > > > > > *From:* Idr <idr-bounces@ietf.org> *On Behalf Of * Gyan Mishra > *Sent:* Friday, February 12, 2021 10:16 PM > *To:* Aijun Wang <wangaijun@tsinghua.org.cn> > *Cc:* idr@ietf.org; Susan Hares <shares@ndzh.com>; Robert Raszuk < > robert@raszuk.net> > *Subject:* Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt > (2/4/2021 to 2/18/2021) > > > > > > All > > > > From Susan Hares summary of where we are at with the adoption call let’s > start with the problem this draft is trying to solve and gaining > consensus. Once we gain consensus we can get back to RD-ORF solution. See > w > > > > a) the problem this draft is drafting to solve relating to BGP routes, > > The problem we are trying to solve is a scenario where you have an > offending PE that is flooding routes and a weak PE that is overwhelmed by a > flood of routes. This is not a normal situation and is an outage situation > where the weak PE being overwhelmed by a flood of routes. Do we all agree > to the problem statement? > > > > Why and why not? > > > > b) the need for additional mechanisms to solve the problem, > > Do other methods exist that can solve the problem and if not do we need a > new mechanism to solve this? > > RTC, Peer maximum prefix, VPN maximum prefix > > c) a clear description of the technology to solve the problem. > > > > Do we all agree that in a normal situation we would never filter on RD as > that would partition the VPN which is unwanted and what Robert mentioned. > As this is not a normal situation but a unique situation where a weak PE is > overwhelmed by a flood of routes. How best can this be solved? > > > > > > > > On Fri, Feb 12, 2021 at 10:32 AM Aijun Wang <wangaijun@tsinghua.org.cn> > wrote: > > Hi, Robert: > > Yes, the behavior of the device should be determined. There maybe several > factors to be considered for this local behavior, we should describe it > more clearly in this section later. > > We have discussed the differences between RTC and RD-ORF a lot. As Haibo > mentioned, they are not exclusive to each other, and can be used together > in some situations. But they are different and can’t replace each other. > > Aijun Wang > > China Telecom > > > > On Feb 12, 2021, at 23:04, Robert Raszuk <robert@raszuk.net> wrote: > > > > Sorry Aijun, > > > > What you say is just handwaving. There is no room for it in any spec. > > > > When code is written PE must deterministically behave so the RR or any > other network element. > > > > Statements "decisions of PE2 to judge" are not acceptable in protocol > design. > > > > Just imagine that each PE does what it feels like in a distributed network > .... Same for BGP same for IGP etc .... > > > > And all of this is not needed if on ingress between PE1 and HQ1 you apply > max prefix of 2 or even 100. It is also not needed if you enable RTC to > send RT:TO_HUB from PE2 to RR. > > > > But I understand - no matter what we say or how much we spend time to > explain why this idea is a bad idea you are still going to push this fwd. > Oh well ... If I were you I would spend this time to redefine L3VPN such > that customer routes are never needed to be sent to SP core routers. > > > > Thx, > R. > > > > > > On Fri, Feb 12, 2021 at 3:47 PM Aijun Wang <wangaijun@tsinghua.org.cn> > wrote: > > Hi, Robert: > > > > > https://datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf-05#section-5.1.1 > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf-05*section-5.1.1__;Iw!!BhdT!wFDvJUfijC2hIGiH79yASFcLdf_N2ZgRzGAyZFBQ9qPt6NEnHHW4evpmkDA$> has > described such situations, which will require the additional local > decisions of PE2 to judge whether to send the RD-ORF message out. > > In your example, if only the HUB VRF exceed but the resources of PE2 is > not exhausted, then the PE2 will not send the RD-ORF message. It may just > discard the excessive 100000/32 routes. > > If the resources of PE2 is nearly exhausted, it must send the RD-ORF > message out. Or else not only the Spoke VRF, but also other VPNs on this > device can’t be used. > > > > Regarding to RR, it is the same principle: if RR can cope with such > flooding, it need not send out RD-ORF to PE1. If RR can’t cope with, it > must send out the RD-ORF message, or else not only the VPN that import RD > X1 routes can’t work, but also other VPNs that don’t import RD x1 routes. > > > > RD-ORF mechanism just keep the influences as small as possible. > > > > Wish the above explanation can refresh your review of this draft. > > > > We are also hopeful to invite you join us to make RD-ORF mechanism more > robust and meet the critical challenges. > > Aijun Wang > > China Telecom > > > > On Feb 12, 2021, at 19:30, Robert Raszuk <robert@raszuk.net> wrote: > > > > Aijun & Gyan, > > > > Let me try one more (hopefully last time) to explain to both of you - and > for that matter to anyone how supported this adoption. > > > > Let's consider very typical Hub and Spoke scenario as illustrated below: > > > > <image.png> > > > > > > HQ1 is advertising two routes: > > > > - one default with RDX1 with RT TO_SPOKE > > - one or more specifics with RDX1 to the other HUBs > > > > Now imagine HQ1 bought a new BGP "Optimizer" and suddenly is starting to > advertise 100000 /32 routes just to the other HUB with RT: TO_HUB. > > > > <image.png> > > > > > > > > So PE2 detects this as VRF with RDX2 on it got overwhelmed during import > with RT TO_HUB and starts pushing RDX1 (original RD) to RR to stop getting > those routes. > > > > Well all great except now you are throwing baby with the water as all > spokes attached to PE2 which just import default route to HUB HQ1 also can > no longer reach their hub site as their default route will be removed. > Therefor they will have nothing to import with RT:TO_SPOKE > > > > Further if RR "independently" decided ... oh let's push this ORF to PE1 > then all of the spokes attached to perhaps even much more powerful PE3 can > also no longer reach their headquarters. > > > > - - - > > > > *Summary: * > > > > The above clearly illustrates why the proposed solution to use RD for > filtering is in fact harmful. > > > > See when you design new protocol extensions the difficulty is to not break > any existing protocols and deployments. > > > > Hope this puts this long thread to rest now. > > > > > > Thx, > > Robert > > > > -- > > [image: Image removed by sender.] > <https://urldefense.com/v3/__http:/www.verizon.com/__;!!BhdT!wFDvJUfijC2hIGiH79yASFcLdf_N2ZgRzGAyZFBQ9qPt6NEnHHW4U1-UgK8$> > > *Gyan Mishra* > > *Network Solutions Architect * > > > > *M 301 502-1347 13101 Columbia Pike > <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> > *Silver Spring, MD > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
- [Idr] WG Adoption call for draft-wang-idr-rd-orf-… Susan Hares
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Wei Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… wangzitao
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Dongjie (Jimmy)
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Gyan Mishra
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Zhuangshunwan
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Wanghaibo (Rainsword)
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Lizhenbin
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… UTTARO, JAMES
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… UTTARO, JAMES
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Linda Dunbar
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Linda Dunbar
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… UTTARO, JAMES
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Acee Lindem (acee)
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Robert Raszuk
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Jakob Heitz (jheitz)
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Jakob Heitz (jheitz)
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Gyan Mishra
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Robert Raszuk
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Robert Raszuk
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Robert Raszuk
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Jakob Heitz (jheitz)
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Robert Raszuk
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… john heasley
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Jakob Heitz (jheitz)
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Jakob Heitz (jheitz)
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Jakob Heitz (jheitz)
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Gyan Mishra
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Robert Raszuk
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Wanghaibo (Rainsword)
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Robert Raszuk
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Robert Raszuk
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Robert Raszuk
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Susan Hares
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Susan Hares
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Susan Hares
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Acee Lindem (acee)
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Susan Hares
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Gyan Mishra
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… chongfeng.xie@foxmail.com
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Robert Raszuk
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Gert Doering
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Robert Raszuk
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Robert Raszuk
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Robert Raszuk
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… UTTARO, JAMES
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Susan Hares
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Jakob Heitz (jheitz)
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Gyan Mishra
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Jakob Heitz (jheitz)
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… UTTARO, JAMES
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Robert Raszuk
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Brendon H
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Jakob Heitz (jheitz)
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Jakob Heitz (jheitz)
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Aijun Wang
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Gyan Mishra
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Robert Raszuk
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Chenshuanglong
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Chengli (Cheng Li)
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… li_zhenqiang@hotmail.com
- Re: [Idr] WG Adoption call for draft-wang-idr-rd-… Weiqiang Cheng