Re: [bess] Routing Directorate Review for draft-ietf-bess-evpn-vpws-10
"Rabadan, Jorge (Nokia - US)" <jorge.rabadan@nokia.com> Mon, 13 March 2017 17:03 UTC
Return-Path: <jorge.rabadan@nokia.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 7A40F1298A4; Mon, 13 Mar 2017 10:03:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 G4WW7RGXorxq; Mon, 13 Mar 2017 10:03:43 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10138.outbound.protection.outlook.com [40.107.1.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B0AB12989E; Mon, 13 Mar 2017 10:03:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UEEIPHVUUSNWcHIDlIFxArgUPmqGyO/yDMZJJE5KM24=; b=ODj5XqtpSGDoSYZXamIXth3aTBJK7aRvEZKuaDx2BYuEQHl9/z2w7GVHyh42D5X1lzco6aQrncepUWk5hCUeH+Sp0accpfYstL77i6KVtAOCKFlD/t2jDxayH/r2iTPex5LkZUfZUCDT5MwV/iYahfffqrb0qzSB+9d3hioFp1U=
Received: from HE1PR07MB0985.eurprd07.prod.outlook.com (10.162.27.154) by HE1PR07MB0987.eurprd07.prod.outlook.com (10.162.27.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Mon, 13 Mar 2017 17:03:38 +0000
Received: from HE1PR07MB0985.eurprd07.prod.outlook.com ([10.162.27.154]) by HE1PR07MB0985.eurprd07.prod.outlook.com ([10.162.27.154]) with mapi id 15.01.0947.012; Mon, 13 Mar 2017 17:03:38 +0000
From: "Rabadan, Jorge (Nokia - US)" <jorge.rabadan@nokia.com>
To: "Shah, Himanshu" <hshah@ciena.com>, Sami Boutros <sboutros@vmware.com>, "Acee Lindem (acee)" <acee@cisco.com>, "bess@ietf.org" <bess@ietf.org>, Routing ADs <rtg-ads@tools.ietf.org>, Routing Directorate <rtg-dir@ietf.org>, "draft-ietf-bess-evpn-vpws@ietf.org" <draft-ietf-bess-evpn-vpws@ietf.org>
Thread-Topic: [bess] Routing Directorate Review for draft-ietf-bess-evpn-vpws-10
Thread-Index: AQHSlDuI/Ow9Knx4yEm0UAqeXGTsw6GM45SAgATD4oD//4dBgIABrjyA//+WhICAAJCxgP//jqmAAA8bKYAAAoRTgA==
Date: Mon, 13 Mar 2017 17:03:37 +0000
Message-ID: <FF6D91E2-A35D-41B7-932D-95587D13A6DC@nokia.com>
References: <D4DF046E.A0B7A%acee@cisco.com> <3954A93E-FA95-43DE-9CC5-40725C94C4A1@vmware.com> <D4EB020B.A1450%acee@cisco.com> <2F8E6D0C-D7C6-4693-901D-0EF2AC2D6224@vmware.com> <A9F382CB-F71A-46C6-96E8-FD00778A9E46@nokia.com> <C119CFBA-D7D2-49D0-9DEF-3345E752F259@vmware.com> <C1500DF7-FCB0-4FA8-996C-E5D0610D15BF@nokia.com> <3E103056-7E56-4DC6-BA09-0DE906B4D8AC@vmware.com> <C3F816AD-65C8-4BED-9E44-59C0DDF78267@ciena.com>
In-Reply-To: <C3F816AD-65C8-4BED-9E44-59C0DDF78267@ciena.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170304
authentication-results: ciena.com; dkim=none (message not signed) header.d=none;ciena.com; dmarc=none action=none header.from=nokia.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [135.245.48.254]
x-microsoft-exchange-diagnostics: 1; HE1PR07MB0987; 7:qmRvmufoubMoOrcyfk/JnGIMI4RmAsORsNil3mD/zFZ4AiCwH1+emnpK5bnnd+rvUqGOb3wuAKcEaLrnRHPP8BT7hvEqq9kdBWuPXIWBQW4KjQFbXU0h6IWZ0u96FEaBFZ9ZHrgOC2Sl775QH0DpJdE8dEf8XkreIaDbh/bUabf0/P/W9WEWsgqxsqoN6wP6+SyL7kuRVpsZeGSLCIc2Ny6ji+NFJqmZuCpqzpeVkF0xIETc0ha7lEhsk9Q1ubYAe6dKV+w5legPqiFD4kX7w6SdzC8pakFiSiETUOnUbBrNAL1VPs0BX8LNT2ZxNJXuHoKubHYTo9a1PgGj6es/pg==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39850400002)(39410400002)(39860400002)(377454003)(24454002)(377424004)(51914003)(33656002)(2501003)(2950100002)(7736002)(86362001)(6506006)(5660300001)(8936002)(6306002)(230783001)(93886004)(305945005)(25786008)(81166006)(102836003)(8676002)(53546007)(6436002)(3846002)(66066001)(5890100001)(83506001)(82746002)(53946003)(106116001)(189998001)(6512007)(2900100001)(36756003)(6116002)(53936002)(99286003)(6246003)(83716003)(3660700001)(38730400002)(50986999)(54356999)(2906002)(76176999)(77096006)(229853002)(6486002)(3280700002)(122556002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB0987; H:HE1PR07MB0985.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
x-ms-office365-filtering-correlation-id: 6d7cda9f-8765-4583-d0ef-08d46a32e478
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:HE1PR07MB0987;
x-microsoft-antispam-prvs: <HE1PR07MB0987D2F94025F7B09BAD69D1F7250@HE1PR07MB0987.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(61668805478150)(82608151540597)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(6072148); SRVR:HE1PR07MB0987; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB0987;
x-forefront-prvs: 0245702D7B
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <AFE830571E810C479596493D3C6472CA@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2017 17:03:37.7614 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB0987
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/nsi2HrgXHhxAfjWaoNg2fxHng-4>
Subject: Re: [bess] Routing Directorate Review for draft-ietf-bess-evpn-vpws-10
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.17
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, 13 Mar 2017 17:03:47 -0000
Hi Sami, About this: “I think having a PE send P=B=0 to be ignored by the receiving PE is not a good logic to start with, One can argue why send something that will be ignored anyway?” [JORGE] yes, ignore is not the best term. I’m not sure I get what you mean by wrongly withdraw the route? we have to remove any previously learned state from the PE advertising P=B=0, so we can’t keep any previous routes, given that the new route with P=B=0 will implicitly withdraw the previous route, so why not say that the P=B=0 route should be treated as withdraw? [JORGE] Yes, you have to remove any previous forwarding state if the received route has P=B=0 and the ESI=non-zero. But I think you should still keep the route in the RIB if P=B=0 and ESI=(zero OR non-zero), since it is a valid route. Given the above, I am in favor of leaving the text as is. [JORGE] That’s fine, you can keep it. It will not cause any interop issue anyway since the text clearly says “in multi-homing single-active scenario...”. Thanks for the explanations Sami. Jorge On 3/13/17, 5:51 PM, "Shah, Himanshu" <hshah@ciena.com> wrote: I agree with Sami. Thanks, Himanshu From: BESS <bess-bounces@ietf.org> on behalf of Sami Boutros <sboutros@vmware.com> Date: Monday, March 13, 2017 at 12:38 PM To: "Rabadan, Jorge (Nokia - US)" <jorge.rabadan@nokia.com>, "Acee Lindem (acee)" <acee@cisco.com>, "bess@ietf.org" <bess@ietf.org>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-bess-evpn-vpws@ietf.org" <draft-ietf-bess-evpn-vpws@ietf.org> Subject: Re: [bess] Routing Directorate Review for draft-ietf-bess-evpn-vpws-10 Hi Jorge, Isn’t the end result is to clear any previous state that the receiving PE learned from the PE that’s advertising now P=B=0? I think having a PE send P=B=0 to be ignored by the receiving PE is not a good logic to start with, One can argue why send something that will be ignored anyway? I’m not sure I get what you mean by wrongly withdraw the route? we have to remove any previously learned state from the PE advertising P=B=0, so we can’t keep any previous routes, given that the new route with P=B=0 will implicitly withdraw the previous route, so why not say that the P=B=0 route should be treated as withdraw? Given the above, I am in favor of leaving the text as is. Thanks, Sami On 3/13/17, 8:24 AM, "Rabadan, Jorge (Nokia - US)" <jorge.rabadan@nokia.com> wrote: Hi Acee and Sami, Thank you both for explaining, I think I now understand your point. I thought the sentence had more to do with error handling at application level, hence my point that P=B=0 was a legitimate combination. I think the three of us agree that receiving an update with P=B=0 is an indication of relinquishing the DF or BDF role by the sender PE, when it previously sent different flags. However I think it would be clearer if we differentiate both cases: Update with P=B=1 -> invalid combination, treat as withdraw Update with P=B=0 -> valid combination, clears previous DF/BDF indication from the sender PE Otherwise we give the impression that P=B=0 is invalid and implementations may wrongly withdraw the route, even at BGP level. Thank you. Jorge On 3/13/17, 3:46 PM, "Sami Boutros" <sboutros@vmware.com> wrote: Hi Jorge, The issue I see with ignoring the routes with P and B Flags clear is the following: What if a PE advertised P or B Flag set then decide to send P and B Flags clear, what should we do in that case? Ignore the P and B Flags clear route and keep the old P or B Flag set route, wouldn’t that be incorrect? Thanks, Sami On 3/13/17, 6:04 AM, "Rabadan, Jorge (Nokia - US)" <jorge.rabadan@nokia.com> wrote: >Sami, > >About this one: > >“ 1. Why is receiving an extended community with both the P and B flags >set treated as a withdrawal, while it is ignored for the case when both >the P and B flags are clear? > >I agree both should be treated as a withdrawal, I will change the text.” > > >[JORGE] Sami, please correct this: > >“If the PE receives a route with both B and P > clear, it MUST treat the route as a withdrawal from the sender PE.” > >As you have in the following paragraph, flags P=B=0 is perfectly valid: > >“In multihoming single-active scenario for a given VPWS service > instance, the DF election should result in the Primary-elected PE for > the VPWS service instance advertising the P Flag set and the B Flag > clear, the Backup elected PE should advertise the P Flag clear and > the B Flag set, ****and the rest of the PEs in the same ES should signal > both P and B Flags clear.****” > > >Let me know if I’m missing something please. Don’t want to hold the progress, but this is important. >Thank you. >Jorge > > > >On 3/12/17, 8:24 PM, "Sami Boutros" <sboutros@vmware.com> wrote: > > Hi Acee, > > Please find attached document with all comments addresses, if all good will > Submit before the cut-off tomorrow. > > Please see comments inline. > On 3/12/17, 11:36 AM, "Acee Lindem (acee)" <acee@cisco.com> wrote: > > > >Hi Sami, > > > >I think this version reads much better. I still have a couple comments and > >questions. > > > > 1. Why is receiving an extended community with both the P and B flags > >set treated as a withdrawal, while it is ignored for the case when both > >the P and B flags are clear? > > I agree both should be treated as a withdrawal, I will change the text. > > > 2. A related question is if a route with both the P and B flags clear is > >ignored, won’t this break DF election described on the bottom of page 8? > >It says “the rest of the PEs in the same ES should single both the P and B > >Flags clear.” > > The DF election is between the PE(s) attached to the ES and has nothing to do > With the remote PE receiving the routes from the PE(s) attached to the ES. > The remote PE expect to receive one route with P Flag set and another route > With with B flag set from another PE, all other routes received from other PE(s) > Attached to the same ES are not needed, and hence can be treated as withdrawal > Of previous routes from those Pe(s). > > > > > 3. Also, during DF election, is it implementation specific which backup > >is chosen if multiple PEs advertise the B Flag set in their respective > >extended communities? > > The DF election MUST always result in one Backup and One primary, however > During transit more than one route with P or B Flags can be received. > > >Why isn’t it the last one similar to the primary PE > >selection? > > Ok, to be consistent, will change the text to have the remote PE select the > last advertising backup PE. > > > > > 4. Both VID and VLAN ID are used in the document. I didn’t research this > >but from the context it appears these are synonymous. If VID is used, I’d > >also add it to the “Terminology” in 1.1. > > Ok. > > > > A few more Nits: > >*** draft-ietf-bess-evpn-vpws-11.txt.orig 2017-03-12 13:56:46.000000000 > >-0400 > >--- draft-ietf-bess-evpn-vpws-11.txt 2017-03-12 14:34:06.000000000 -0400 > >*************** > >*** 153,163 **** > > instance. As with the Ethernet Tag in standard EVPN, the VPWS service > > instance identifier has uniqueness within an EVPN instance. > > > >! For EVPN routes, the Ethernet Tag ID are set to zero for Port-based, > >! VLAN-based, and VLAN-bundle interface mode and it is set to non-zero > >! Ethernet tag ID for VLAN-aware bundle mode. Conversely, for EVPN- > > VPWS, the Ethernet tag ID in the Ethernet A-D route MUST be set to a > >! non-zero value for all four service interface types. > > > > In terms of route advertisement and MPLS label lookup behavior, EVPN- > > VPWS resembles the VLAN-aware bundle mode of [RFC7432] such that when > >--- 153,163 ---- > > instance. As with the Ethernet Tag in standard EVPN, the VPWS service > > instance identifier has uniqueness within an EVPN instance. > > > >! For EVPN routes, the Ethernet Tag IDs are set to zero for Port-based, > >! VLAN-based, and VLAN-bundle interface mode and set to non-zero > >! Ethernet Tag IDs for VLAN-aware bundle mode. Conversely, for EVPN- > > VPWS, the Ethernet tag ID in the Ethernet A-D route MUST be set to a > >! non-zero value for all four service interface types. > > > > In terms of route advertisement and MPLS label lookup behavior, EVPN- > > VPWS resembles the VLAN-aware bundle mode of [RFC7432] such that when > >*************** > >*** 181,188 **** > > Ethernet frames are transported as is and the tags are not altered. > > > > The MPLS label value in the Ethernet A-D route can be set to the > >! VXLAN Network Identifier (VNI) for VxLAN encap, and this VNI may have > >! a global scope or local scope per PE and may also be made equal to > > the VPWS service instance identifier set in the Ethernet A-D route. > > > > The Ethernet Segment identifier encoded in the Ethernet A-D per-EVI > >--- 181,188 ---- > > Ethernet frames are transported as is and the tags are not altered. > > > > The MPLS label value in the Ethernet A-D route can be set to the > >! VXLAN Network Identifier (VNI) for VXLAN encap, and this VNI may have > >! a global scope or local scope per PE and may also be equal to > > the VPWS service instance identifier set in the Ethernet A-D route. > > > > The Ethernet Segment identifier encoded in the Ethernet A-D per-EVI > >*************** > >*** 312,321 **** > > > > 2.3 VLAN-Aware Bundle Service Interface > > > >! Contrary to EVPN, in EVPN-VPWS this service interface maps to VLAN- > > based service interface (defined in section 2.1) and thus this > > service interface is not used in EVPN-VPWS. In other words, if one > >! tries to define data-plane and control plane behavior for this > > service interface, one would realize that it is the same as that of > > VLAN-based service. > > > >--- 312,321 ---- > > > > 2.3 VLAN-Aware Bundle Service Interface > > > >! Contrary to EVPN, in EVPN-VPWS this service interface maps to a VLAN- > > based service interface (defined in section 2.1) and thus this > > service interface is not used in EVPN-VPWS. In other words, if one > >! tries to define data plane and control plane behavior for this > > service interface, one would realize that it is the same as that of > > VLAN-based service. > > > >*************** > >*** 326,332 **** > > signal VPWS services. The Ethernet Segment Identifier field is set to > > the customer ES and the Ethernet Tag ID 32-bit field MUST be set to > > the VPWS service instance identifier value. The VPWS service instance > >! identifier value MAY be set to a 24-bit value, when 24-bit value is > > used, it MUST be right aligned. For both EPL and EVPL services using > > a given VPWS service instance, the pair of PEs instantiating that > > VPWS service instance will each advertise a per-EVI Ethernet A-D > >--- 326,332 ---- > > signal VPWS services. The Ethernet Segment Identifier field is set to > > the customer ES and the Ethernet Tag ID 32-bit field MUST be set to > > the VPWS service instance identifier value. The VPWS service instance > >! identifier value MAY be set to a 24-bit value and when a 24-bit value > >is > > used, it MUST be right aligned. For both EPL and EVPL services using > > a given VPWS service instance, the pair of PEs instantiating that > > VPWS service instance will each advertise a per-EVI Ethernet A-D > >*************** > >*** 354,361 **** > > > > 3.1 EVPN Layer 2 attributes extended community > > > >! This draft proposes a new extended community [RFC4360], to be > >! included with the per-EVI Ethernet A-D route. This attribute is > > mandatory if multihoming is enabled. > > > > +------------------------------------+ > >--- 354,361 ---- > > > > 3.1 EVPN Layer 2 attributes extended community > > > >! This document defines an extended community [RFC4360], to be > >! included with per-EVI Ethernet A-D routes. This attribute is > > mandatory if multihoming is enabled. > > > > +------------------------------------+ > >*************** > >*** 423,429 **** > > > > In a multihoming all-active scenario, there is no DF election, and > > all the PEs in the ES that are active and ready to forward traffic > >! to/from the CE will set the P Flag. A remote PE will do per-flow load > > balancing to the PEs that set the P Flag for the same Ethernet Tag > > and ESI. The B Flag in control flags SHOULD NOT be set in the > > multihoming all-active scenario and MUST be ignored by receiving > >--- 423,429 ---- > > > > In a multihoming all-active scenario, there is no DF election, and > > all the PEs in the ES that are active and ready to forward traffic > >! to/from the CE will set the P Flag. A remote PE will do per-flow load- > > balancing to the PEs that set the P Flag for the same Ethernet Tag > > and ESI. The B Flag in control flags SHOULD NOT be set in the > > multihoming all-active scenario and MUST be ignored by receiving > >*************** > >*** 493,499 **** > > > > All PEs and ASBRs are enabled for the EVPN SAFI and exchange per-EVI > > Ethernet A-D routes, one route per VPWS service instance. For inter- > >! AS option B, the ASBRs re-advertise these routes with NEXT_HOP > > attribute set to their IP addresses as per [RFC4271]. The link > > between the CE and the PE is either a C-tagged or S-tagged interface, > > as described in [802.1Q], that can carry a single VLAN tag or two > >--- 493,499 ---- > > > > All PEs and ASBRs are enabled for the EVPN SAFI and exchange per-EVI > > Ethernet A-D routes, one route per VPWS service instance. For inter- > >! AS option B, the ASBRs re-advertise these routes with the NEXT_HOP > > attribute set to their IP addresses as per [RFC4271]. The link > > between the CE and the PE is either a C-tagged or S-tagged interface, > > as described in [802.1Q], that can carry a single VLAN tag or two > >*************** > >*** 570,576 **** > > Finally, EVPN may employ data plane egress link protection mechanisms > > not available in VPWS. This can be done by the primary PE (on local > > AC down) using the label advertised in the per-EVI Ethernet A-D route > >! by the backup PE to encapsulate the traffic and direct it to backup > > PE. > > > > 6 Failure Scenarios > >--- 570,576 ---- > > Finally, EVPN may employ data plane egress link protection mechanisms > > not available in VPWS. This can be done by the primary PE (on local > > AC down) using the label advertised in the per-EVI Ethernet A-D route > >! by the backup PE to encapsulate the traffic and direct it to the > >backup > > PE. > > > > 6 Failure Scenarios > >*************** > >*** 592,600 **** > > For a faster convergence in multi-homed scenarios with either Single- > > Active Redundancy or All-active redundancy, a mass withdraw technique > > is used. A PE previously advertising a per-ES Ethernet A-D route, can > >! withdraw this route signaling to the remote PEs to switch all the > > VPWS service instances associated with this multi-homed ES to the > >! backup PE > > > > 7 Acknowledgements > > > >--- 592,600 ---- > > For a faster convergence in multi-homed scenarios with either Single- > > Active Redundancy or All-active redundancy, a mass withdraw technique > > is used. A PE previously advertising a per-ES Ethernet A-D route, can > >! withdraw this route by signaling to the remote PEs to switch all the > > VPWS service instances associated with this multi-homed ES to the > >! backup PE. > > > > 7 Acknowledgements > > Thanks, > > Sami > > > > _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
- [bess] Routing Directorate Review for draft-ietf-… Acee Lindem (acee)
- Re: [bess] Routing Directorate Review for draft-i… Sami Boutros
- Re: [bess] Routing Directorate Review for draft-i… Acee Lindem (acee)
- Re: [bess] Routing Directorate Review for draft-i… Sami Boutros
- Re: [bess] Routing Directorate Review for draft-i… Acee Lindem (acee)
- Re: [bess] Routing Directorate Review for draft-i… Rabadan, Jorge (Nokia - US)
- Re: [bess] Routing Directorate Review for draft-i… Acee Lindem (acee)
- Re: [bess] Routing Directorate Review for draft-i… Sami Boutros
- Re: [bess] Routing Directorate Review for draft-i… Rabadan, Jorge (Nokia - US)
- Re: [bess] Routing Directorate Review for draft-i… Sami Boutros
- Re: [bess] Routing Directorate Review for draft-i… Shah, Himanshu
- Re: [bess] Routing Directorate Review for draft-i… Rabadan, Jorge (Nokia - US)