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

"Acee Lindem (acee)" <acee@cisco.com> Mon, 13 March 2017 14:44 UTC

Return-Path: <acee@cisco.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 5C81D1296CB; Mon, 13 Mar 2017 07:44:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ozGrWQcUeRsh; Mon, 13 Mar 2017 07:44:25 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC18A1296D0; Mon, 13 Mar 2017 07:44:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14289; q=dns/txt; s=iport; t=1489416264; x=1490625864; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=8jrik9EreZYVJ0VJhx1YpHXlpEr6+NYbejv+auxxKcg=; b=Lt73i4qGas/CSPnE0OYjhu0gMtRACzGGuZ2kf0JFROYC6SMjA+rOmaI/ daeBl+P0GUClNiT82ZbsEFrPjngSQwDdnydM2zqeab+JH8SBRGIeHknYj LCo2xtFHXV1S/JxqN+6i1PkYs+TFMH+38efMUi3rq7HKWJbg8gp440HYP Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ATAQAPr8ZY/49dJa1dGQEBAQEBAQEBAQEBBwEBAQEBg1FhgQoHjWeRTpU7gg4fC4V4AoJbPxgBAgEBAQEBAQFrKIUWAQEBAwEBbBsCAQgYLicLJQIEARIUC4lhDrB1ilYBAQEBAQEBAQIBAQEBAQEBARsFiz2EHTeFZQWJG4cBilqBSwGSOIF7hSWKBZNCAR84gQRYFUGEVx2BY3WIRoENAQEB
X-IronPort-AV: E=Sophos;i="5.36,159,1486425600"; d="scan'208";a="1737993"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Mar 2017 14:44:23 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v2DEiNfO026274 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 Mar 2017 14:44:23 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 13 Mar 2017 10:44:22 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Mon, 13 Mar 2017 10:44:22 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Rabadan, Jorge (Nokia - US)" <jorge.rabadan@nokia.com>, Sami Boutros <sboutros@vmware.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: AQHSnAhNDkRm37V8YU+DvTKEaJsC+A==
Date: Mon, 13 Mar 2017 14:44:22 +0000
Message-ID: <D4EC2687.A195C%acee@cisco.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>
In-Reply-To: <A9F382CB-F71A-46C6-96E8-FD00778A9E46@nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.198]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <FFBD4E2B1595574EA6C5CA9DC47150C3@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/EUpiXLvqoS4bNdD-3OyaLNVO3xA>
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 14:44:27 -0000

Hi Jorge, 

On 3/13/17, 9:04 AM, "BESS on behalf of Rabadan, Jorge (Nokia - US)"
<bess-bounces@ietf.org on behalf of 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.****²

Yes - but during DF election, you¹d want the former Primary or Backup
advertisement to relinquish their respective roles. Now, there a multiple
ways this could be accomplished and the -11 version on using the last
advertised Primary or Backup should also result in the correct behavior.
However, withdrawal would assure DF convergence as well as provide
consistent behavior for both P and B Flags set and P and B Flags clear.

Thanks,
Acee 




>
>
>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