Re: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt
Gyan Mishra <hayabusagsm@gmail.com> Wed, 26 August 2020 15:58 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 027553A1639 for <idr@ietfa.amsl.com>; Wed, 26 Aug 2020 08:58:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.987
X-Spam-Level:
X-Spam-Status: No, score=-1.987 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, HTTPS_HTTP_MISMATCH=0.1, 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 xRAO90u2ESee for <idr@ietfa.amsl.com>; Wed, 26 Aug 2020 08:58:25 -0700 (PDT)
Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 909233A1634 for <idr@ietf.org>; Wed, 26 Aug 2020 08:58:13 -0700 (PDT)
Received: by mail-vs1-xe2d.google.com with SMTP id o184so1215609vsc.0 for <idr@ietf.org>; Wed, 26 Aug 2020 08:58:13 -0700 (PDT)
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=59li6itNQ07JLQRNEzV0o0TRoi6ljoXX4d46sq4on9w=; b=KaGzAHK2LY947aOYmRPk/fGfDLa76Ua7OBpEO31bUrwpoCZekmL3qZlrz8U4yX57LP 4gYARpU3SjUmeO6VilJ2dSicaSINm/Fs8poO0QQPJ5NCUIFAMsi3QnjSaMsVXLkHxjdk gIsR/q1v1FaH9hzWLCmtsVb4s0596Cj3YD0mEa2i7ucsqHOT2nm0ajjfB+MOMngiVM6T qBarEcO4at3F0XwW0aWzJzcNtwSBEA8nY7eIxpkgxWHN7Neh6ymHhWrPInoJYOO6Couf fxXviH7+hf672TpYt5ANRu7H5JB6rsQxB0gwI3xV/BDaeBueGzOAsHobRxADgMo6hqKq CnRw==
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=59li6itNQ07JLQRNEzV0o0TRoi6ljoXX4d46sq4on9w=; b=HjinPFq434ZowhSfXCM3wFi6/k1de0VeiL8BouakKAmYo8I1ZZgeUpSgSbPtMgm3HE rh53rEZMhCA8BdK9NL/avdtISG30/Z0qO5MjQL2JjilYimnVFd6ZdlUeRQ9ztGSmTFnl FPtrQTVcTdXmAq1qtm5CjulpFiOzt7rMJCC4hJmJUNfJM/jDnzffRIjJEJJhlUMz2D4m h+k0wjC8rDPzZizt/wLsYhbSrc+Q9lcWsbqz0P2Jp6nZZj5QSroAb3HY7bo3dIaj2sBM WyzdapR4VCrDV3IP3A05Psc3r6GEJuwql6rGp6bkYaf6+QNTFD7dJv899gcwQb6ffva+ hH4g==
X-Gm-Message-State: AOAM5335ggwR8sew4RplrUAtQoMkKwAV8pvHRQ90OrySQPVQQLKuG0fu OANX/7OSF7x3kXaEq+ALJiV18411yCRroPyXNMc=
X-Google-Smtp-Source: ABdhPJz/QdL3d5PLfULq5e4HRo3JPdw6KaP6di3A2KSxJbUK9lPELJQPAmB7aJldq7iOTwsdC6IDthnKD0gz+zFf46Q=
X-Received: by 2002:a67:f502:: with SMTP id u2mr10221577vsn.111.1598457492307; Wed, 26 Aug 2020 08:58:12 -0700 (PDT)
MIME-Version: 1.0
References: <tencent_EA7B36E1CC8F28E736B6F6623DB239F57907@qq.com> <CAOj+MME8i2D1BP8A1fRcye0D+VySMi==wzr_uhmCBm2ydSonLQ@mail.gmail.com>
In-Reply-To: <CAOj+MME8i2D1BP8A1fRcye0D+VySMi==wzr_uhmCBm2ydSonLQ@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Wed, 26 Aug 2020 11:58:01 -0400
Message-ID: <CABNhwV1fnVtKwCaQ7SrdK8fzdHD7BbGijWZCuQ2MxG8XbVghow@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: "UTTARO, JAMES" <ju1738@att.com>, Wei Wang <weiwang94@foxmail.com>, idr <idr@ietf.org>, "wangw36@chinatelecom.cn" <wangw36@chinatelecom.cn>
Content-Type: multipart/alternative; boundary="00000000000004816505adc9e335"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/WkZWmQmxPGRffg-A6VtZOgV_KuU>
Subject: Re: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt
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: Wed, 26 Aug 2020 15:58:30 -0000
Robert Good points and agreed. That needs to be clarified. On Wed, Aug 26, 2020 at 3:58 AM Robert Raszuk <robert@raszuk.net> wrote: > Allow me to clarify a few things here. > > VRF-LIMIT does not and should not discard routes. It only stops import and > logs the exceeded message. The route is still in VPNv4 table. Best path > indeed is needed in the vpnv4 table. > Gyan> Agreed. Will fix the verbiage. The VPN table RR to PE VPN rib has all routes from each unique RD originator that was reflected by the RR. The per VRF-LIMIT stops the import of routes into each customer VRF. By default all PEs have “RT filtering” enabled so if they don’t have at least one explicit import the RT is dropped. > > PREFIX-LIMIT does drop the routes and can bring down the session. Best > path is not executed. This is very cheap operation. Btw - by > default PE only accepts routes carrying RTs matching at least one local > import anyway. > Gyan> Agreed. Bring down session unless you have warning flag with % threshold set. Understood by default all PEs have “RT filtering” enabled so if they don’t have at least one explicit import the RT is dropped. > > - - - > > In this entire thread no one explained in technical terms why use of > prefix limit on the customer <--> service provider boundary is not > sufficient to prevent from the issues this work seems to be targeting. The > only explanation given that this is one way and why not to invent yet > another way. That explanation is not sufficient. > Gyan> The primary use case is for inter as opt a or b flood of routes and there it is very difficult to control in either scenario as it is going between administrative domains. One domain may have per VRF maximum prefix and per maximum prefix set on each PE-CE link while the other domain may not. The option b you do have some control but at the PE ASBR as you have to do a retain-route-target-all as RT filtering is enabled on PEs by default and then you are either doing RT translation or filtering by RT but don’t have any other granularity. As the RD has to be unique for RR to reflect all paths the RD-ORF cab filter on origin RD from the other AS and that could be beneficial versus sledge hammer filtering on the RT level blocking all prefixes for the VRF. For option c as the RR does not have RT filtering enabled by default and floods all routes the RD-ORF mechanisms can provide control of flood of routes as well as with option c where the route origin is outside or the administrative boundary. > > I see that some may think that maybe there is one weak PE among 100 of > powerful PEs and such weak PE should not be receiving all routes.. Well if > this is the case this is an operational mistake and not something we should > address with any protocol extension. In L2 or L3 VPNs number of routes (IP > prefixes or MACs) should be bounded and well known allowing to plan the > deployments well. If an operator is missing that critical operational state > that is pretty bad. > Gyan> Agreed > > As far as reachability IMO 0% reachability is much better then random 50% > for a given VPN customer. When you have no reachability it is very easy to > troubleshoot. When you have partial reachability it is a nightmare with > current tools we have. > Gyan> Agreed no routes is better then few less routes from a troubleshooting perspective. > > Thx, > R. > > Thx, > R. > > > > > > > > > > > On Wed, Aug 26, 2020 at 4:11 AM Wei Wang <weiwang94@foxmail.com> wrote: > >> Hi Sergey, >> >> Before route discarding, the router must parse the BGP updates, perform >> BGP best path algorithm. These processes will cost CPU cycles and further >> burden the overflowing PE. Flitering these updates at the sender side can >> ease such process, this is the same aim as other ORF mechanism. >> >> Best Regards, >> >> Wei Wang >> China Telecom >> >> ------------------ Original ------------------ >> *From:* "Fomin, Sergey (Nokia - US/Mountain View)" < >> sergey.fomin@nokia.com>; >> *Date:* Wed, Aug 26, 2020 04:57 AM >> *To:* "wangw36@chinatelecom.cn"<wangw36@chinatelecom.cn>; >> *Cc:* "idr"<idr@ietf.org>;"UTTARO, JAMES"<ju1738@att.com>; >> *Subject:* Re: [Idr] New Version Notification for >> draft-wang-idr-rd-orf-03.txt >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hi Wei Wang, >> >> >> >> >> >> *>> But the soft actions cannot reduce the burden of PE.* >> >> >> *>> Because for the overflow PE, a local-only discard mechanism can't >> make it better.. If it receive more VPN routes continuously, it must waste >> more resources to log them.* >> > >> >> Probably we look at this from different perspectives, could you please >> clarify what exact burden and resources are we talking about? >> >> >> >> >> >> In my view, route discard is a cheap operation in terms of CPU cycles, >> and discarded routes use no RIB or FIB resources. >> >> >> >> >> >> >> >> -- >> >> >> Sergey >> >> >> >> >> >> >> >> >> >> >> >> *From:* wangw36@chinatelecom.cn <wangw36@chinatelecom.cn> >> >> >> >> >> *Sent:* Monday, August 24, 2020 7:12 PM >> >> >> *To:* UTTARO, JAMES <ju1738@att.com>; Fomin, Sergey (Nokia - US/Mountain >> View) <sergey.fomin@nokia.com> >> >> >> *Cc:* idr <idr@ietf.org> >> >> >> *Subject:* Re: RE: [Idr] New Version Notification for >> draft-wang-idr-rd-orf-03.txt >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hi Sergey and Jim, >> >> >> >> >> >> >> >> >> >> >> >> >> >> Thanks for your review. Please see comments in-line. >> >> >> >> >> >> >> >> >> >> >> >> >> >> Best Regards, >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ------------------------------ >> >> >> >> >> >> >> >> >> >> >> >> >> Wei Wang >> >> >> >> >> >> >> China Telecom >> >> >> >> >> >> >> >> >> >> >> >> wangw36@chinatelecom.cn >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> *From:* UTTARO, >> >> JAMES <ju1738@att.com> >> >> >> >> >> >> >> *Date:* 2020-08-25 05:43 >> >> >> >> >> >> >> *To:* Fomin, >> >> Sergey (Nokia - US/Mountain View) <sergey.fomin@nokia.com>; >> >> wangw36@chinatelecom.cn >> >> >> >> >> >> >> *CC:* idr <idr@ietf.org> >> >> >> >> >> >> >> *Subject:* RE: [Idr] New Version Notification for >> >> draft-wang-idr-rd-orf-03.txt >> >> >> >> >> >> >> >> >> >> >> >> >> *Comments In-Line.* >> >> >> >> >> >> *Thanks,* >> >> >> * Jim Uttaro* >> >> >> >> >> >> >> >> >> >> *From:* Idr <idr-bounces@ietf.org> >> >> *On Behalf Of *Fomin, Sergey (Nokia - US/Mountain View) >> >> >> *Sent:* Monday, August 24, 2020 4:28 PM >> >> >> *To:* wangw36@chinatelecom.cn >> >> >> *Cc:* idr <idr@ietf.org> >> >> >> *Subject:* Re: [Idr] New Version Notification for >> draft-wang-idr-rd-orf-03.txt >> >> >> >> >> >> >> >> >> >> Hi Wei Wang, >> >> >> >> >> >> From your description of existing solutions: >> >> >> >> >> >> > 4) Configure the Maximum Prefix for each VRF on edge nodes >> >> >> > >> >> >> > When a VRF overflows, PE will break down the BGP session with RR >> >> >> > according to the Maximum Prefix mechanism. However, there may have >> >> >> > several VRFs on PE rely on the PE-RR session, this mechanism will >> >> >> > influence other VRFs. >> >> >> This is not correct. A good implementation of _per-vrf prefix-limit_ does >> not mandate MP-BGP session teardown, it allows to use soft actions instead, >> such as discard routes + log. >> >> >> *[Jim U>] Yup.. That is the way my implementations work.. The goal is to >> ensure maximum correctness of a given VPN. Tearing down the PE-RR session >> is killing a fly with a sledge hammer..* >> >> >> *[Wei Wang] But the soft actions cannot reduce the burden of PE.* >> >> >> >> >> >> Additionally, if you insist that a local-only discard mechanism is not >> good enough (why?) >> >> >> *[Wei Wang] Because for the overflow PE, a local-only discard mechanism >> can't make it better. If it receive more VPN routes continuously, it must >> waste more resources to log them.* >> >> >> and you want to prevent route advertisement(s) from an RR/remote PE for >> a specific VRF, it is hard to see real-world benefits of the proposed >> solution vs, for example, extra logic on top of RTC (i.e. if you implement >> >> a feature "withdraw an RTC route after FIB/memory utilization reaches >> 95%"). >> >> >> *[Wei Wang] Yes, VRF with 0% reachability may be achieved in this way.* >> >> >> Yes, RD-ORF might be a bit more granular in such case, but does it bring >> any benefit? VRF with 50% reachability or VRF with 0% reachability from a >> given PE are both examples of unintended network state (and the >> >> earlier could be worse) that requires intervention. >> >> >> *[Wei Wang] In my opinion, VRF with 50% reachability may be able to keep >> part of user traffic normal. It is better than VRF with 0% reachability.* >> >> >> >> >> >> -- >> >> >> Sergey >> >> >> >> >> >> >> >> >> >> *From:* Idr <idr-bounces@ietf.org> >> >> *On Behalf Of *wangw36@chinatelecom.cn >> >> >> *Sent:* Sunday, August 23, 2020 6:51 PM >> >> >> *To:* idr <idr@ietf.org> >> >> >> *Subject:* Re: [Idr] New Version Notification for >> draft-wang-idr-rd-orf-03.txt >> >> >> >> >> >> >> >> >> >> >> >> Hi IDR experts, >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Based on the previous discussion, we update our draft as follows: >> >> >> >> >> >> >> >> >> >> - the description of the limitations of existing solutions is added >> - clarifying that the operation process of RD-ORF on each device is >> independent >> - modifying the withdraw mechanism of RD-ORF >> >> >> >> >> >> >> >> Any comments are welcome. >> >> >> >> >> >> >> >> >> >> Best Regards. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ------------------------------ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Wei Wang >> >> >> >> >> >> >> China Telecom >> >> >> >> >> >> >> >> >> >> >> >> >> >> wangw36@chinatelecom.cn >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> *From:* internet-drafts <internet-drafts@ietf.org> >> >> >> >> >> >> >> *Date:* 2020-08-24 09:43 >> >> >> >> >> >> >> *To:* Haibo >> >> Wang <rainsword.wang@huawei.com>; >> >> Gyan S. Mishra <gyan.s.mishra@verizon.com>; >> >> Wei Wang <wangw36@chinatelecom.cn>; >> >> Aijun Wang <wangaj3@chinatelecom.cn>; >> >> Shunwan Zhuang <zhuangshunwan@huawei.com>; >> >> Jie Dong <jie.dong@huawei.com>; >> >> Gyan Mishra <gyan.s.mishra@verizon.com> >> >> >> >> >> >> >> *Subject:* New Version Notification for draft-wang-idr-rd-orf-03.txt >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> A new version of I-D, draft-wang-idr-rd-orf-03.txt >> >> >> >> >> >> >> has been successfully submitted by Wei Wang and posted to the >> >> >> >> >> >> >> IETF repository. >> >> >> >> >> >> >> >> >> >> >> >> >> >> Name: draft-wang-idr-rd-orf >> >> >> >> >> >> >> Revision: 03 >> >> >> >> >> >> >> Title: Route Distinguisher Outbound Route Filter (RD-ORF) for BGP-4 >> >> >> >> >> >> >> Document date: 2020-08-24 >> >> >> >> >> >> >> Group: Individual Submission >> >> >> >> >> >> >> Pages: 14 >> >> >> >> >> >> >> URL: >> >> https://www.ietf.org/internet-drafts/draft-wang-idr-rd-orf-03.txt >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dwang-2Didr-2Drd-2Dorf-2D03.txt&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=T-GmdIk3xStsk13lycUmUrbLRODstoJm4CN-V2JjExU&s=14kL4f6cO3I39QTIY9-i3boaLA2giY4KiD3j2Tu9fi0&e=> >> >> >> >> >> >> >> Status: >> >> https://datatracker.ietf.org/doc/draft-wang-idr-rd-orf/ >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dwang-2Didr-2Drd-2Dorf_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=T-GmdIk3xStsk13lycUmUrbLRODstoJm4CN-V2JjExU&s=Aw-Mc7bSxvLnYtxEpzTjMz5qVGpXvLZRkDb0Ze8kZ0I&e=> >> >> >> >> >> >> >> Htmlized: >> >> https://tools.ietf.org/html/draft-wang-idr-rd-orf-03 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dwang-2Didr-2Drd-2Dorf-2D03&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=T-GmdIk3xStsk13lycUmUrbLRODstoJm4CN-V2JjExU&s=PIKT-TH9C9zny7t-hQj9xqSwHgV_XG4VXGx5sMbWTJg&e=> >> >> >> >> >> >> >> Htmlized: >> >> https://datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dwang-2Didr-2Drd-2Dorf&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=T-GmdIk3xStsk13lycUmUrbLRODstoJm4CN-V2JjExU&s=Tre2skoFxacQ9M124fvYpANTrlrA5iYvyGv_RdEOntc&e=> >> >> >> >> >> >> >> Diff: >> >> https://www.ietf.org/rfcdiff?url2=draft-wang-idr-rd-orf-03 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dwang-2Didr-2Drd-2Dorf-2D03&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=T-GmdIk3xStsk13lycUmUrbLRODstoJm4CN-V2JjExU&s=CcQDMR1B4HvydxNGlDcsW01YUNWiuGyrtr_o1w2wWnE&e=> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Abstract: >> >> >> >> >> >> >> This draft defines a new Outbound Route Filter (ORF) type, called the >> >> >> >> >> >> >> Route Distinguisher ORF (RD-ORF). RD-ORF is applicable when the >> >> >> >> >> >> >> routers do not exchange VPN routing information directly (e.g. >> >> >> >> >> >> >> routers in single-domain connect via Route Reflector, or routers in >> >> >> >> >> >> >> Option B/Option AB/Option C cross-domain scenario). >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> >> >> >> >> >> >> until the htmlized version and diff are available at tools.ietf.org. >> >> >> >> >> >> >> >> >> >> >> >> >> >> The IETF Secretariat >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> Idr mailing list >> >> >> Idr@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/idr >> >> >> > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
- Re: [Idr] New Version Notification for draft-wang… wangw36@chinatelecom.cn
- Re: [Idr] New Version Notification for draft-wang… Fomin, Sergey (Nokia - US/Mountain View)
- Re: [Idr] New Version Notification for draft-wang… UTTARO, JAMES
- Re: [Idr] New Version Notification for draft-wang… wangw36@chinatelecom.cn
- Re: [Idr] New Version Notification for draft-wang… Fomin, Sergey (Nokia - US/Mountain View)
- Re: [Idr] New Version Notification for draft-wang… Wei Wang
- Re: [Idr] New Version Notification for draft-wang… Gyan Mishra
- Re: [Idr] New Version Notification for draft-wang… Robert Raszuk
- Re: [Idr] New Version Notification for draft-wang… Gyan Mishra
- Re: [Idr] New Version Notification for draft-wang… Robert Raszuk
- Re: [Idr] New Version Notification for draft-wang… Robert Raszuk
- Re: [Idr] New Version Notification for draft-wang… Gyan Mishra
- Re: [Idr] New Version Notification for draft-wang… Fomin, Sergey (Nokia - US/Mountain View)
- Re: [Idr] New Version Notification for draft-wang… Gyan Mishra
- Re: [Idr] New Version Notification for draft-wang… Gyan Mishra
- Re: [Idr] New Version Notification for draft-wang… Aijun Wang
- Re: [Idr] New Version Notification for draft-wang… Robert Raszuk
- Re: [Idr] New Version Notification for draft-wang… Aijun Wang
- Re: [Idr] New Version Notification for draft-wang… Fomin, Sergey (Nokia - US/Mountain View)
- Re: [Idr] New Version Notification for draft-wang… Robert Raszuk
- Re: [Idr] New Version Notification for draft-wang… Aijun Wang
- Re: [Idr] New Version Notification for draft-wang… Aijun Wang
- Re: [Idr] New Version Notification for draft-wang… Robert Raszuk
- Re: [Idr] New Version Notification for draft-wang… Aijun Wang
- Re: [Idr] New Version Notification for draft-wang… Robert Raszuk
- Re: [Idr] New Version Notification for draft-wang… Aijun Wang
- Re: [Idr] New Version Notification for draft-wang… Robert Raszuk
- Re: [Idr] New Version Notification for draft-wang… Gyan Mishra