IETF Logo Mail Archive

Re: [bess] Reg: RFC7432 EVPN - ES-import RT

"Mankamana Mishra (mankamis)" <mankamis@cisco.com> Fri, 29 June 2018 15:24 UTC

Return-Path: <mankamis@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 1EC4512F1A6 for <bess@ietfa.amsl.com>; Fri, 29 Jun 2018 08:24:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 uA6CmJaPRzCM for <bess@ietfa.amsl.com>; Fri, 29 Jun 2018 08:24:37 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 234B1126CC7 for <bess@ietf.org>; Fri, 29 Jun 2018 08:24:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12268; q=dns/txt; s=iport; t=1530285876; x=1531495476; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aaFCIrLofEYDawP0nCxv4WPB+LmQtJ9WZkuEGa9533w=; b=MZvDrY4R8FPT5CKki0HCrrqeHOcIJuh4T02WVdZz4lCMN8n9sygPSnfZ iKo0lpSxAmTpXi0W3rLou0q6K+SrzFSlV6vvWHmfWPp5g6ruTEiilhPwa ocgtGmElPvSeP5gGS/nApZYcy9nQTObjHilcQ2bhy/SqyveXNe7+GHuZ/ U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DAAACFTjZb/40NJK1cGQEBAQEBAQEBAQEBAQcBAQEBAYJTdmJ/KAqDb4gEjD6BZZA3hQyBegsYAQqESQIXgwohNBgBAgEBAgEBAm0cDIU3AgEDAQEhSwsQAgEIPwMCAgIlCxQRAgQOBYMgAYEbZA+sNYIchFuDdIEfBYhtgVY/gQ8nDIJcgUGBVwEBAgGEXjGCJAKRYIdjCQKGAoJkhjOBQIQJiAiKLocoAhETAYEkHTiBUnAVOyoBgj6BczyIZIU+bwGPcIEaAQE
X-IronPort-AV: E=Sophos;i="5.51,285,1526342400"; d="scan'208,217";a="417110254"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2018 15:24:35 +0000
Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w5TFOZ7h028305 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Jun 2018 15:24:36 GMT
Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 29 Jun 2018 10:24:35 -0500
Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1320.000; Fri, 29 Jun 2018 10:24:35 -0500
From: "Mankamana Mishra (mankamis)" <mankamis@cisco.com>
To: Prasannakumara S <prasannakumara.s@ipinfusion.com>
CC: "bess@ietf.org" <bess@ietf.org>
Thread-Topic: [bess] Reg: RFC7432 EVPN - ES-import RT
Thread-Index: AQHUD61kNLUOLdk1E0OyKO13k0GRU6R3rwcA
Date: Fri, 29 Jun 2018 15:24:35 +0000
Message-ID: <54D753F8-6276-4D9E-912A-FC7CFA927456@cisco.com>
References: <CAN4tJ45FxFdTgQeGHgAkJ-vWog34U4ZaYd5hHzYy+yOzinAG-Q@mail.gmail.com>
In-Reply-To: <CAN4tJ45FxFdTgQeGHgAkJ-vWog34U4ZaYd5hHzYy+yOzinAG-Q@mail.gmail.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.24.6.63]
Content-Type: multipart/alternative; boundary="_000_54D753F862764D9E912AFC7CFA927456ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/FuENjp0a0AO8OGxGsKrDiMgEPFo>
Subject: Re: [bess] Reg: RFC7432 EVPN - ES-import RT
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.26
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: Fri, 29 Jun 2018 15:24:40 -0000

Hi Prasanna,


On Jun 29, 2018, at 6:30 AM, Prasannakumara S <prasannakumara.s@ipinfusion.com<mailto:prasannakumara.s@ipinfusion.com>> wrote:

Hi All,

Related sections are:
https://tools.ietf.org/html/rfc7432#section-5
https://tools.ietf.org/html/rfc7432#section-7.6

Would like to understand how ES-import RT should behave in case of

1. ESI type 1 - statically configured
    In this case on what basis one should import the ESI route as ES-import RT does not talk about ESI type 1. Why this should not follow the same semantics of creating ES-import RT as done for ESI Type 2; with the 6 high-order octates? If same ESI is configured in different VTEPS then it would still work.
This question comes because manually configuring the manual RT is tough to meet multiple combinations of multihomed sites.

 - Type 1 (T=0x01) - When IEEE 802.1AX LACP is used between the PEs
     and CEs, this ESI type indicates an auto-generated ESI value
     determined from LACP by concatenating the following parameters:

     + CE LACP System MAC address (6 octets).  The CE LACP System MAC
       address MUST be encoded in the high-order 6 octets of the ESI
       Value field.

     + CE LACP Port Key (2 octets).  The CE LACP port key MUST be
       encoded in the 2 octets next to the System MAC address.

     + The remaining octet will be set to 0x00.

     As far as the CE is concerned, it would treat the multiple PEs that
     it is connected to as the same switch.  This allows the CE to
     aggregate links that are attached to different PEs in the same
     bundle.

     This mechanism could be used only if it produces ESIs that satisfy
     the uniqueness requirement specified above.

I do not think, Type 1 is statically configured.


And if question was about


   - Type 0 (T=0x00) - This type indicates an arbitrary 9-octet ESI
     value, which is managed and configured by the operator.

Should it not be up to implementation to decide if they want to derive ES-import RT with 6 high-order octates  ?



2. ESI type 3 - MAC based ESI of the PE
    If MAC of the PE is considered then how different PE's can produce the same unique ESI? instead it should have used CE's MAC address?
Since last/hig-order 6 octets are used for import how RT-import works?

There is already Type 1 defined (Pasted above) which uses CE’s MAC address.

As mentioned in https://tools.ietf.org/html/rfc7432#section-7.6 Auto derivation is only for Type 1, 2 , and 3. For other types, Admin would be responsible to configure correct ES-import RT.


Let me know if I am missing something.

Please refer me to any other drafts which are trying to address this; I can discuss over there and be part of that.

Thanks in advance.

Regards,
Prasanna


.._______________________________________________
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess

v2.30.2 | Report a Bug | By Email | System Status