Subject: [bess] FW: draft-sajassi-bess-evpn-etree

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 25 Mar 2015 16:03:22 +0000

From: Cisco Employee <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 12, 2015 at 11:31 AM
To: Nitin Singh <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Hassan Hosseini <[email-masked]<mailto:[email-masked]>>, Ryan Bickhart <[email-masked]<mailto:[email-masked]>>, Manoj Sharma <[email-masked]<mailto:[email-masked]>>, John E Drake <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-sajassi-bess-evpn-etree
Resent-From: Cisco Employee <[email-masked]<mailto:[email-masked]>>
Resent-To: <[email-masked]<mailto:[email-masked]>>
Resent-Date: Thursday, March 12, 2015 at 11:31 AM

Exactly!

Cheers,
Ali

From: Nitin Singh <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 12, 2015 at 11:02 AM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Hassan Hosseini <[email-masked]<mailto:[email-masked]>>, Ryan Bickhart <[email-masked]<mailto:[email-masked]>>, Manoj Sharma <[email-masked]<mailto:[email-masked]>>, John E Drake <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-sajassi-bess-evpn-etree

Hi Ali ,

Thanks for your response,  it seems like that the proposal for SH segments  is to advertise the 2  AD routes per ESI with the ESI value encoded as 0 , one for SH segments in  Leaf role and other one the SH segments in Root mode .

Regards
Nitin

From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Thursday, March 12, 2015 10:39 AM
To: Nitin Singh; [email-masked]<mailto:[email-masked]>
Cc: Hassan Hosseini; Ryan Bickhart; Manoj Sharma; John E Drake
Subject: Re: draft-sajassi-bess-evpn-etree

Hi Nitin,

From: Nitin Singh <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 12, 2015 at 10:25 AM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Hassan Hosseini <[email-masked]<mailto:[email-masked]>>, Ryan Bickhart <[email-masked]<mailto:[email-masked]>>, Manoj Sharma <[email-masked]<mailto:[email-masked]>>, John E Drake <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-sajassi-bess-evpn-etree

Hi Ali ,

Please note that IM routes are advertised at granularity of Ethernet Tag [ IOW , there is a common IM route for ALL Ethernet Segments ].

Hence I agree that there is doubling of IM routes per Ethernet Tag per EVI  but this does not have the multiplication factor of number of ESIs. Essentially we will have two multicast groups one for the leafs other one for the roots .

I said the number of IM routes are doubled (e.g., 100% overhead) which is the case.

The issue that I see is that the use ESI label in Etree service is slightly different than the one described for ELAN service in RFC 7432 .

In ELAN service , ESI label is only used between the set of MH PEs connected to the ESI , but with the approach described in ETree even the PEs not connected to the ESI have to create forwarding state/SH procedures using the ESI label .

That’s not correct – i.e., ESI label is NOT just used among MH PEs.  Ether–AD per ES route along with ESI label is advertised to all PEs participating in the VPNs. There is a forwarding state that is created for ESI label for P2MP LSP anyway (but not for ingress replication).

Also there can be single homed AC in root/leaf roles , there will be no AD route per ESI routes for these single homed AC hence we cannot use the SH mechanisms  based on ESI label .

That’s why we only need to advertise two such labels per PE (one for root and another for leaf)!

CHeers,
Ali

Thanks
Nitin

From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Thursday, March 12, 2015 10:01 AM
To: Nitin Singh; [email-masked]<mailto:[email-masked]>
Cc: Hassan Hosseini; Ryan Bickhart; Manoj Sharma; John E Drake; Ali Sajassi (sajassi)
Subject: Re: draft-sajassi-bess-evpn-etree

There are bunch of disadvantages for doing it this way:

1.       That’s a lot of advertisements if we do it with IM route - i.e., the BGP messages for IM gets increased by 100% !! A given ES can support hundreds or thousands of IM routes !!
2.      In data-plane we end up increasing the size of LFIB
3.      There are now to different approaches for single-home versus multi-homed sites

Cheers,
Ali

From: Nitin Singh <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 11, 2015 at 5:14 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Hassan Hosseini <[email-masked]<mailto:[email-masked]>>, Ryan Bickhart <[email-masked]<mailto:[email-masked]>>, Manoj Sharma <[email-masked]<mailto:[email-masked]>>, John E Drake <[email-masked]<mailto:[email-masked]>>
Subject: draft-sajassi-bess-evpn-etree
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: <[email-masked]<mailto:[email-masked]>>
Resent-Date: Thursday, March 12, 2015 at 4:50 AM

Hi ,

This is regarding the section 3.2 BUM Traffic .   From my reading of the draft it seems that the assumption here is that BUM traffic will  be send with the ESI label  even to the PEs which are not connected to the ESI.

An alternative solution could be to advertise two  IM routes per Ethernet Tag

1) One for  the AC in leaf mode
2) Second for the AC in Root mode

The advantage of the above solution is that we don’t need the ESI label in label stack for the packet send towards the set of PEs not connected to the ESI .

The use of ESI label could be restricted  for forwarding the BUM traffic between MH PEs connected to ESI operating in all-active mode,  as per the SH procedures  described in the RFC 7432 .

Thanks
Nitin