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

["Luc Andre Burdet (lburdet)" <[e-mail]>]

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
[e-mail]<mailto:[e-mail]>
Tel: [phone]






Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
Cisco.com<http://www.cisco.com/web/CA/>







From: BESS <[e-mail]> on behalf of "Mankamana Mishra (mankamis)" <mankamis=[e-mail]>
Date: Friday, June 29, 2018 at 11:24 AM
To: Prasannakumara S <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [bess] Reg: RFC7432 EVPN - ES-import RT

Hi Prasanna,



On Jun 29, 2018, at 6:30 AM, Prasannakumara S <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/bess