Hi Prasanna, FYI the ES-Import auto-extraction is expanded to ES Type 0,4,5 in https://tools.ietf.org/html/draft-ietf-bess-evpn-df-election-framework-03#section-3.3.
Thanks Luc André [http://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/09_standard_graphic.png] Luc André Burdet [email protected]<mailto:[email protected]> Tel: +1 613 254 4814 Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE Cisco.com<http://www.cisco.com/web/CA/> From: BESS <[email protected]> on behalf of "Mankamana Mishra (mankamis)" <[email protected]> Date: Friday, June 29, 2018 at 11:24 AM To: Prasannakumara S <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [bess] Reg: RFC7432 EVPN - ES-import RT Hi Prasanna, On Jun 29, 2018, at 6:30 AM, Prasannakumara S <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/bess
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
