Re: optional ethernet A-D per EVI route

[Jakob Heitz <[e-mail]>]

Tony,

Ali clarified it like this for me: Aliasing requires the 'per EVI' route. Aliasing is optional. Therefore, the 'per EVI' route is optional.

And I know a cat named Socrates :)

--
Jakob Heitz.


On May 11, 2014, at 11:10 PM, "Antoni Przygienda" <[e-mail]<mailto:[e-mail]>> wrote:

Actually, I’m struggling with the ‘optional per EVI route’ which I also think should be dropped as Jakob suggests. I’m referring to the -07 and unrolling the issue:


Per 14.1.2


        A remote PE that receives a MAC advertisement route with non-
   reserved ESI SHOULD consider the advertised MAC address to be
   reachable via all PEs that have advertised reachability to that MAC
   address' EVI/ES via the combination of an Ethernet A-D per EVI route
   for that EVI/ES (and Ethernet Tag if applicable) AND an Ethernet A-D

   per ES route for that ES.


   -If a set of Ethernet A-D per ES routes for that ES AND an Ethernet
   A-D route per EVI exist, only then the label from that latter route
   *must* be used.



First, should that be a capital MUST ?  Second, that seems to imply that load balancing cannot be done without the per EVI route ? Or that without a per EVI route all-active-redundancy mode cannot install MACs from remote PEs ?



Per 8.4


        Therefore, in order to handle corner cases and race conditions, the
   Ethernet A-D per EVI route MUST NOT be used for traffic forwarding by
   a remote PE until it also receives the associated set of Ethernet A-D
   per ES routes.


        To address this issue, EVPN introduces the concept of 'Aliasing'
   which is the ability of a PE to signal that it has reachability to an
   EVPN instance on a given ES even when it has learnt no MAC addresses
   from that EVI/ES. The Ethernet A-D per EVI route is used for this
   purpose. A remote PE that receives a MAC advertisement route with
   non-reserved ESI SHOULD consider the advertised MAC address to be
   reachable via all PEs that have advertised reachability to that MAC
   address' EVI/ES via the combination of an Ethernet A-D per EVI route
   for that EVI/ES (and Ethernet Tag if applicable) AND Ethernet A-D per
   ES routes for that ES with the 'Single-Active' bit in the flags of
   the ESI Label Extended Community set to 0.



Now, what does that mean exactly since English is tad loose here (same as in 14.1.2) :
the MAC is valid if  (EITHER the EAD per EVI is here or EAD per ES) OR does it imply that  BOTH must be present and lack of an A-D per EVI route will prevent aliasing (but nothing else, i.e. the route can be installed into the fwd path) ? Or can the MAC be installed anyway since it’s all a SHOULD ?

I seem to read the intention as:

               . if you have an EAD per EVI and  _NO_ EAD per ESI you cannot use the MAC (no load-balancing until ESI is up per section 8.4 above )
               . if you have ESI only, you can (that’s just aliasing)
               . if you have EVI _AND_ ESI, the EVI label (in the route) takes precedence and we start to ‘load-balance’



--- tony


From: Ali Sajassi (sajassi) [mailto:[e-mail]]
Sent: Sunday, May 11, 2014 10:17 PM
To: Jakob Heitz; [e-mail]<mailto:[e-mail]>
Cc: Antoni Przygienda
Subject: Re: optional ethernet A-D per EVI route


Hi Jakob,

We are talking about two different routes. Section 8.4.1 talks about Ethernet A-D per EVI; whereas, section 9.2.2 talks about Ethernet A-D per ES. The former one is optional but no the latter one. As the matter of fact section 8.2.1 states that the support of the latter one is mandatory (1st para).

For rev 7, I added a clarification sentence to the end of the 3rd para of section 9.2.2 saying:

       "The
dependency of MAC routes installation on Ethernet A-D
per ES routes,

   is to ensure that MAC routes don't get accidentally installed during

   mass withdraw period."



Cheers,

Ali

From: Jakob Heitz <[e-mail]<mailto:[e-mail]>>
Date: Sunday, May 11, 2014 9:43 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: Antoni Przygienda <[e-mail]<mailto:[e-mail]>>
Subject: optional ethernet A-D per EVI route

Tony and I have an issue.
The draft says
8.4.1<http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07#section-8.4.1> Constructing the Ethernet A-D per EVPN Instance (EVI) Route





   This section describes the procedures used to construct the Ethernet

   A-D per EVPN Instance (EVI) route, which is used for aliasing (as

   discussed above). Support of this route is OPTIONAL.

And

9.2.2<http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07#section-9.2.2> Route Resolution


…

   If the Ethernet Segment Identifier field in a received MAC

   Advertisement route is set to a non-reserved ESI, then if the

   receiving PE decides to install forwarding state for the associated

   MAC address, it MUST be when both the MAC Advertisement route AND the

   associated set of Ethernet A-D per ES routes have been received.


Should this sentence be changed to “Support of this route is OPTIONAL unless non-reserved ESIs are used” or just be changed to MANDATORY?

Thanks,
Jakob.