Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover
"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Sat, 01 December 2018 01:14 UTC
Return-Path: <zzhang@juniper.net>
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 D4B7D130F04; Fri, 30 Nov 2018 17:14:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.171
X-Spam-Level:
X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.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 KJ1OOxafk77g; Fri, 30 Nov 2018 17:14:40 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D89212D7F8; Fri, 30 Nov 2018 17:14:40 -0800 (PST)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id wB11Edbi008844; Fri, 30 Nov 2018 17:14:39 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=reZkcuzjQM3EhqxSuX/TwrLci++84D9lnBzrJ4n0byM=; b=goCylkCwq5rbnr9n7d/rDOGM/pextY3dxHeDxe8rtv7qU0hR5XzP7g6lM33ke2llfGg/ FnnuVZHkrXYa/6LHNX3yLhtDcLri3FNkaIZ9RDO87u0xHuaVBUejIidTRu/tyR1ZA6z1 tK1mXfBjFzYg5DzBR0SGz9uleG0UWYFlpho9v5lTQiMjyWF6jmBxKV/yZ7Sb0MtUXndZ B4y/z4nPvTBmUN356bdaOPAAsYW+xLXJJB/FboQPqAqXXW5GlseCKc/ciPbFxtH9ECwm ZggTwsrM4lttqRUJmTdHFC9eRaMTVHvw7O4ejqsEOJdacPW/7k+JhX56WpVZmavJs5WF rg==
Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2058.outbound.protection.outlook.com [104.47.36.58]) by mx0a-00273201.pphosted.com with ESMTP id 2p39p3rnxm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 30 Nov 2018 17:14:38 -0800
Received: from BL0PR05MB5025.namprd05.prod.outlook.com (20.177.241.152) by BL0PR05MB5668.namprd05.prod.outlook.com (10.167.240.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1382.14; Sat, 1 Dec 2018 01:14:35 +0000
Received: from BL0PR05MB5025.namprd05.prod.outlook.com ([fe80::c047:4e89:4fdf:e860]) by BL0PR05MB5025.namprd05.prod.outlook.com ([fe80::c047:4e89:4fdf:e860%4]) with mapi id 15.20.1404.011; Sat, 1 Dec 2018 01:14:35 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: "EXT - thomas.morin@orange.com" <thomas.morin@orange.com>, Robert Kebler <rkebler@juniper.net>, Greg Mirsky <gregimirsky@gmail.com>
CC: "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover
Thread-Index: AdSCOGobvyszpShjQe6cTmshOOxpcQGwJ0Sw
Date: Sat, 01 Dec 2018 01:14:35 +0000
Message-ID: <BL0PR05MB5025A934922FDDC316AFD2E4D4AC0@BL0PR05MB5025.namprd05.prod.outlook.com>
References: <26502_1542873261_5BF660AD_26502_47_1_9E32478DFA9976438E7A22F69B08FF924B7752E9@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
In-Reply-To: <26502_1542873261_5BF660AD_26502_47_1_9E32478DFA9976438E7A22F69B08FF924B7752E9@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.0.400.15
dlp-reaction: no-action
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BL0PR05MB5668; 6:s5JcG94DE0584NwpcQszwfOMMR5KagR02oAUKRFhaP0dZx5c0gq91MB/PfJ17/fCyyfYIaDb5p9LgRPgVDLild+s3ydmB2idbwHrC1U17+GXp5DGTNqu5Hje4f+5lul9JpgfFo2tSKXcB5xxrL/Lmr7VsemwAM3l5psA08ZzbwJZVuT0G7PMSjYorATjcB/6fTkGeZ1VEVpnkJufBA5FhnINWUu5ituLXa0IbR7NIThxGpPrsiFPl8M5/5caqKuTmcqDqkspwf3sSYxVD+hmn4+b0eSR7JB5LJ4qhF8x2VphqedPYMH9D7pGCxJYJ0UBuIhwXamsf5K6JogMsHmdPnR2qLuW7BxuZz9H/6wkzry5wRUYWNt70iOWDHPHecoMbrpcPmeoDAvh/w17OyR16Uzl69OXa/GcwhjbNiszfZlQi/tK6ffNJt5/jrqsxUD7j+KDyRi7p+wFzDslHuWIEA==; 5:5atRIh/6+hM/dnzul0vjso3hY5fmChnkfa05tDnFhTPciTAS/uDU6CooKxlG/04WwV1VwnHlecTFfN+NOKpNwP6bFqYj7JCiN7gE1XFA3HeMK/M1L1pbSQyO8j3sOx9z7EY99rXIvY5iZPjFTp6/En+Bg9kQrXY19+1u16ytoxM=; 7:uT1lEF55lSfGdMsOG4pCcZvGEyA13YPVOy7/7GUydG+O/6rczaLe0re469N9SE85RVYe8AeizG9/V6Xsi5Ja1AB6d82owQLXbTXBPwKMAl42vKCriL3qxWFn1uBUfdpfCGqOCNdw0zB0kZSrxE6+zw==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: e05893da-94c1-454e-0d53-08d6572a5b66
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BL0PR05MB5668;
x-ms-traffictypediagnostic: BL0PR05MB5668:
x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr
x-microsoft-antispam-prvs: <BL0PR05MB5668030FFAA8414693D8AD09D4AC0@BL0PR05MB5668.namprd05.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231453)(999002)(944501410)(52105112)(6055026)(148016)(149066)(150057)(6041310)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:BL0PR05MB5668; BCL:0; PCL:0; RULEID:; SRVR:BL0PR05MB5668;
x-forefront-prvs: 087396016C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(376002)(346002)(366004)(136003)(189003)(199004)(60444003)(37854004)(86362001)(186003)(26005)(14454004)(33656002)(966005)(2906002)(478600001)(6116002)(3846002)(790700001)(316002)(110136005)(54906003)(76176011)(97736004)(53546011)(6506007)(74316002)(102836004)(7736002)(7696005)(8936002)(5024004)(1941001)(14444005)(25786009)(9326002)(8676002)(81156014)(81166006)(446003)(99286004)(476003)(11346002)(5660300001)(55016002)(105586002)(53936002)(39060400002)(106356001)(256004)(486006)(236005)(6436002)(54896002)(9686003)(4326008)(6306002)(606006)(71190400001)(71200400001)(6246003)(68736007)(229853002)(53946003)(66066001)(559001)(579004)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR05MB5668; H:BL0PR05MB5025.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: KNCMVSeJWUVEC9k0GK+RAcpAoesSktnOsp0zICocr+Gr/3vF1Q5YFhntd0o0fNyjSFFVMPx51IbyeVmD3H6PeaEUYIx+ItUMBR1dzzRR1lPfQINeBaHRNwJ8z2WXUnf0w+2Cwww/oUOzNKbCT7/H3svbg8+Rbyl8u2komavHpE4ubd987rKQjOG9e7zb+C6KW67ilkXxahm4QzDXetZ+pHfEsfFTMNljbCf4fn9NtNCDfslrS1apZXbyBQXpzTaLYNAYo9weFLtPSsbL7OB9dSyK89eu6ssQmOvciYWXpGE78h7scU6GaXLe9ENvzw0PLk1SztrP8iBUoQW8chICYkQmIZ42N5av6LiB72OAJf4=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BL0PR05MB5025A934922FDDC316AFD2E4D4AC0BL0PR05MB5025namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: e05893da-94c1-454e-0d53-08d6572a5b66
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2018 01:14:35.1470 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB5668
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-30_13:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812010008
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/pGqme6voKfixZLwnI4vTItpqfBk>
Subject: Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover
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: Sat, 01 Dec 2018 01:14:44 -0000
Hi, I have the following questions/comments: The procedure described here is an OPTIONAL procedure that consists of having a downstream PE take into account the status of P-tunnels rooted at each possible upstream PEs, for including or not including each given PE in the list of candidate UMHs for a given (C-S,C-G) state. The result is that, if a P-tunnel is "down" (see Section 3.1), the PE that is the root of the P-tunnel will not be considered for UMH selection, which will result in the downstream PE to failover to the upstream PE which is next in the list of candidates. Is it possible that a p2mp tunnel is considered up by some leaves but down by some other leaves, leaving to them choosing different UMH? In that case, procedures described in Section 9.1.1 ("Discarding Packets from Wrong PE") of RFC 6513 must be used. I see that this is actually pointed out later in section 6 - good to have a pointer to it right here. Additionally, the text in section 3 seems to be more biased on Single Forwarder Election choosing the UMH with the highest IP address. Section 5 of RFC6513 also describes two other options, hashing or based on "installed UMH route" (aka unicast-based). It is not clear how the text in this document applies to hashing based selection, and I don't see how the text applies to unicast-based selection. Some rewording/clarification are needed here. For P-tunnels of type P2MP MPLS-TE, the status of the P-tunnel is considered up if one or more of the P2MP RSVP-TE LSPs, identified by the P-tunnel Attribute, are in Up state. Why is "one or more of ..." used in the above text? There are several occurrences of ((S, G)). I assume they should be changed to (C-S, C-G). A PE can be removed from the UMH candidate list for a given ((S, G)) if the P-tunnel for this (S, G) (I or S , depending) is leaf triggered (PIM, mLDP) Perhaps either remove the (I or S , depending)or move it to before the "for". This document defines the format and ways of usingr a new BGP attribute called the "BGP- BFD attribute". s/usingr/using/ o MUST use [Ed.note] address as destination IP address when transmitting BFD control packets; [Ed.note]? If tracking of the P-tunnel by using a p2mp BFD session is to be enabled after the P-tunnel has been already signaled, the the procedure described above MUST be followed. What if the tracking is to be enabled before the P-tunnel has been signaled? The text implies different behavior? s/the the/then the/ ... The dedicated p2mp BFD session MAY monitor the state of the Standby Upstream PE. What does the above text mean? Do you mean "A different p2mp BFD session ..."? When such a procedure is used, in the context where fast restoration mechanisms are used for the P-tunnels, leaf PEs should be configured to wait before updating the UMH, to let the P-tunnel restoration mechanism happen. A configurable timer MUST be provided for this purpose, and it is recommended to provide a reasonable default value for this timer. What does "such a procedure" refers to? s/recommended/RECOMMENDED/? 3.1.7. Per PE-CE link BFD Discriminator The following approach is defined for the fast failover in response to the detection of PE-CE link failures, in which UMH selection for a given C-multicast route takes into account the state of the BFD session associated with the state of the upstream PE-CE link. 3.1.7.1. Upstream PE Procedures For each protected PE-CE link, the upstream PE initiates a multipoint BFD session [I-D.ietf-bfd-multipoint] as MultipointHead toward downstream PEs. A downstream PE monitors the state of the p2mp session as MultipointTail and MAY interpret transition of the BFD session into Down state as the indication of the associated PE-CE link being down. Since the BFD packets are sent over the P2MP tunnel not the PE-CE link, my understanding is that the BFD discriminator is still for the tunnel and not tied to the PE-CE link; but different from the previous case, the root will stop sending BFD messages when it detects the PE-CE link failure. As far as the egress PEs are concerned, they don't know if it is the tunnel failure or PE-CE link failure. If my understanding is correct, the wording should be changed. ... If the route to the src/RP changes such that the RPF interface is changed to be a new PE- CE interface, then the upstream PE will update the S-PMSI A-D route with included BGP-BFD Attribute so that value of the BFD Discriminator is associated with the new RPF link. If the RPF interface changes on the upstream PE, why should it update the route to send a new discriminator? As long as there is a new RPF interface couldn't the upstream PE do nothing but start tracking the new RPF interface? Regardless which way (the currently described way and my imagined way), some text should be added to discuss how the downstream would not switch to another upstream PE when the primary PE is just going through a RPF change. 4. Standby C-multicast route The procedures described below are limited to the case where the site that contains C-S is connected to exactly two PEs. The procedures require all the PEs of that MVPN to follow the single forwarder PE selection, as specified in [RFC6513]. Why would it not work with more than two upstream PEs? Why is it limited to single forwarder selection? What about unicast based selection? This route, that has the semantics of being a 'standby' C-multicast route, is further called a "Standby BGP C-multicast route", and is constructed as follows: o the NLRI is constructed as the original C-multicast route, except that the RD is the same as if the C-multicast route was built using the standby PE as the UMH (it will carry the RD associated to the unicast VPN route advertised by the standby PE for S) Since you mention RD, you might as well mention it carries a Route Target derived from the standby RE's UMH route's VRF RT Import EC. If at some later point the local PE determines that C-S is no longer reachable through the Primary Upstream PE, the Standby Upstream PE becomes the Upstream PE, and the local PE re-sends the C-multicast route with RT that identifies the Standby Upstream PE, except that now the route does not carry the Standby PE BGP Community (which results in replacing the old route with a new route, with the only difference between these routes being the presence/absence of the Standby PE BGP Community). Additionally the LOCAL_PREF should also change? 4.3. Reachability determination The standby PE can use the following information to determine that C-S can or cannot be reached through the primary PE: Shouldn't this be 4.2.1 instead of 4.3? 5. Hot leaf standby The mechanisms defined in sections Section 4 and Section 3 can be used together as follows. This section is a little confusing to me. It seems that it really should be how a leaf should behave when hot root standby is used, not that there is a "hot leaf" mode. A leaf is just a leaf, not a cold/warm/hot/primary/standby leaf. Thanks. Jeffrey From: BESS <bess-bounces@ietf.org> On Behalf Of stephane.litkowski@orange.com Sent: Thursday, November 22, 2018 2:54 AM To: bess@ietf.org Cc: bess-chairs@ietf.org Subject: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover Hello Working Group, This email starts a two-week Working Group Last Call on draft-ietf-bess-mvpn-fast-failover-04 [1] This poll runs until *the 6th of December*. We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an Author or a Contributor of this Document please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR. The Document won't progress without answers from all the Authors and Contributors. Currently two IPRs have been disclosed against this Document. If you are not listed as an Author or a Contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. We are also polling for any existing implementation as per [2]. Thank you, Stephane & Matthew [1] https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Dmvpn-2Dfast-2Dfailover_&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=21UeMvv2ofELpScacCIlRV64tml5G3zQ3NN5NqhC90s&s=ZKwzFkFZdTKGHJdgRZ6PExBQcl1Ck5CGjhXDxYQYvvI&e=> [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_bess_cG3X1tTqb-5FvPC4rg56SEdkjqDpw&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=21UeMvv2ofELpScacCIlRV64tml5G3zQ3NN5NqhC90s&s=fR1eK_EmnRha7QRf37WKaJmt1F5OLq7ynG7afcmPhM0&e=> _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
- [bess] WGLC, IPR and implementation poll for draf… stephane.litkowski
- Re: [bess] WGLC, IPR and implementation poll for … Thomas Morin
- Re: [bess] WGLC, IPR and implementation poll for … Greg Mirsky
- Re: [bess] WGLC, IPR and implementation poll for … Robert Kebler
- Re: [bess] WGLC, IPR and implementation poll for … Jeffrey (Zhaohui) Zhang
- Re: [bess] WGLC, IPR and implementation poll for … Greg Mirsky
- Re: [bess] WGLC, IPR and implementation poll for … stephane.litkowski
- Re: [bess] WGLC,IPR and implementation poll for d… zhang.zheng
- Re: [bess] WGLC, IPR and implementation poll for … Greg Mirsky
- Re: [bess] WGLC,IPR and implementation poll for d… zhang.zheng
- Re: [bess] WGLC, IPR and implementation poll for … Greg Mirsky
- Re: [bess] WGLC,IPR and implementation poll for d… zhang.zheng
- Re: [bess] WGLC, IPR and implementation poll for … Mankamana Mishra (mankamis)
- Re: [bess] WGLC, IPR and implementation poll for … Jeffrey (Zhaohui) Zhang
- Re: [bess] WGLC, IPR and implementation poll for … Jeffrey (Zhaohui) Zhang
- Re: [bess] WGLC, IPR and implementation poll for … Greg Mirsky
- Re: [bess] WGLC, IPR and implementation poll for … Greg Mirsky
- Re: [bess] WGLC, IPR and implementation poll for … Jeffrey (Zhaohui) Zhang
- Re: [bess] WGLC, IPR and implementation poll for … Greg Mirsky
- Re: [bess] WGLC, IPR and implementation poll for … Greg Mirsky
- Re: [bess] WGLC, IPR and implementation poll for … Jeffrey (Zhaohui) Zhang
- Re: [bess] WGLC, IPR and implementation poll for … Greg Mirsky
- Re: [bess] WGLC, IPR and implementation poll for … Jeffrey (Zhaohui) Zhang
- Re: [bess] WGLC, IPR and implementation poll for … Greg Mirsky
- Re: [bess] WGLC, IPR and implementation poll for … Jeffrey (Zhaohui) Zhang