Hi Mankamana Mishra and Luc Andre,

Thanks for replying and sorry for quoting wrong type, yes its Type-0
instead of Type-1.
As clarified in the draft Type-0 also can follow same Es-import RT as long
as it doesnt overlap, that's good.

Was trying to understand Type-3 how PE's MAC is going to make it same ESI
on two PE's.

Regards,
Prasanna

On Fri, Jun 29, 2018 at 8:59 PM, Luc Andre Burdet (lburdet) <
lbur...@cisco.com> wrote:

> 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é
>
>
>
> [image:
> http://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/09_standard_graphic.png]
>
> *Luc André Burdet*
>
> lbur...@cisco.com
>
> Tel: *+1 613 254 4814*
>
> Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
>
> Cisco.com <http://www.cisco.com/web/CA/>
>
>
>
>
>
> *From: *BESS <bess-boun...@ietf.org> on behalf of "Mankamana Mishra
> (mankamis)" <mankamis=40cisco....@dmarc.ietf.org>
> *Date: *Friday, June 29, 2018 at 11:24 AM
> *To: *Prasannakumara S <prasannakumar...@ipinfusion.com>
> *Cc: *"bess@ietf.org" <bess@ietf.org>
> *Subject: *Re: [bess] Reg: RFC7432 EVPN - ES-import RT
>
>
>
> Hi Prasanna,
>
>
>
>
>
> On Jun 29, 2018, at 6:30 AM, Prasannakumara S <
> prasannakumar...@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
> https://www.ietf.org/mailman/listinfo/bess
>
>
>

-- 
..
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Reply via email to