Re: [bess] Routing Directorate Review for draft-ietf-bess-evpn-vpws-10

"Shah, Himanshu" <hshah@ciena.com> Mon, 13 March 2017 16:51 UTC

Return-Path: <hshah@ciena.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 9EAFD12987B; Mon, 13 Mar 2017 09:51:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=cienacorp.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 ljtzZ23ZB7hs; Mon, 13 Mar 2017 09:51:45 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0064.outbound.protection.outlook.com [104.47.41.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90532129875; Mon, 13 Mar 2017 09:51:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cienacorp.onmicrosoft.com; s=selector1-ciena-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9Q+RyC7qwAO6tieluRyXYv6EfzXH3G8FUxy1EinPSno=; b=ZfS3IgkPpZxS56NoAxBbxbI8COY4Q15SEvK9sghy/eLHMTbJ/NvmYzw7Hewu9GgGnequzpFyOAGDcHMDwvLFbPGqW5IFbiYt5obJVAdxMHmayYfivs0iOqT9T9dFPA99hoahAzoCnXZ5bXKfL7LgSEPkyaWY7/IzvBbCYzup0ak=
Received: from DM5PR04MB0234.namprd04.prod.outlook.com (10.168.234.135) by DM5PR04MB0236.namprd04.prod.outlook.com (10.168.234.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Mon, 13 Mar 2017 16:51:31 +0000
Received: from DM5PR04MB0234.namprd04.prod.outlook.com ([10.168.234.135]) by DM5PR04MB0234.namprd04.prod.outlook.com ([10.168.234.135]) with mapi id 15.01.0947.020; Mon, 13 Mar 2017 16:51:31 +0000
From: "Shah, Himanshu" <hshah@ciena.com>
To: Sami Boutros <sboutros@vmware.com>, "Rabadan, Jorge (Nokia - US)" <jorge.rabadan@nokia.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: AQHSnBoQSKnSoPn6iE6duv123EiT0w==
Date: Mon, 13 Mar 2017 16:51:31 +0000
Message-ID: <C3F816AD-65C8-4BED-9E44-59C0DDF78267@ciena.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>
In-Reply-To: <3E103056-7E56-4DC6-BA09-0DE906B4D8AC@vmware.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1e.0.170107
authentication-results: vmware.com; dkim=none (message not signed) header.d=none;vmware.com; dmarc=none action=none header.from=ciena.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [63.118.37.72]
x-ms-office365-filtering-correlation-id: 92353a6f-94fa-4286-1b46-08d46a313336
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR04MB0236;
x-microsoft-exchange-diagnostics: 1; DM5PR04MB0236; 7:XwRTtYAYWRDByJkmZEU8DJcLm72rxphQ9yKO66IyO402YP4iXBfSNp0nud8K01/QOGaoGpJN/sVdRFTXM/TAtZ+YyAMPv2k/xXXtYI8wHUUjBBM1YVgYdRLa/rJFW31QUZaHrQIeAu6MLyKpgMlo2txDCbwFVR2WpyUFgRUdNq1fykVf6qXG2hYoaeQFlScdEJp/SSBSL2Tt9Zgnpskt9wXfE3MLNAkhH2vfeYaq/RLlS5QApgQHAU8k4+CPwiN2oRyqAdlqlbwsEdESHtduNtrVqYU29+hmI1+FjzDNAUUXmigJTI9F8ZJdYddWuOHCWnYcBA4LL/+Ddeo/Y5H8YQ==
x-microsoft-antispam-prvs: <DM5PR04MB023681F62D903F4D17293976AF250@DM5PR04MB0236.namprd04.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(61668805478150)(82608151540597)(95692535739014)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123560025)(20161123558025)(20161123562025)(20161123555025)(6072148); SRVR:DM5PR04MB0236; BCL:0; PCL:0; RULEID:; SRVR:DM5PR04MB0236;
x-forefront-prvs: 0245702D7B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(39450400003)(377424004)(377454003)(24454002)(50986999)(76176999)(36756003)(25786008)(66066001)(106116001)(5660300001)(53546007)(53946003)(6436002)(236005)(606005)(77096006)(33656002)(54896002)(230783001)(6512007)(86362001)(6306002)(6486002)(99286003)(6506006)(189998001)(2950100002)(229853002)(54356999)(122556002)(4001350100001)(93886004)(82746002)(38730400002)(6246003)(53936002)(7736002)(7906003)(81166006)(5890100001)(3846002)(6116002)(8676002)(2906002)(83506001)(83716003)(3280700002)(8936002)(2900100001)(102836003)(2501003)(3660700001)(104396002)(579004)(559001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR04MB0236; H:DM5PR04MB0234.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_C3F816AD65C84BED9E4459C0DDF78267cienacom_"
MIME-Version: 1.0
X-OriginatorOrg: ciena.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2017 16:51:31.0157 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 457a2b01-0019-42ba-a449-45f99e96b60a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR04MB0236
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/YcrjOyesOY3TWxx004M2wYYoM4U>
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 16:51:48 -0000

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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess