Re: Some observations/questions on inter-subnet and type-5 draft for EVPN

["Rabadan, Jorge (Jorge)" <[e-mail]>]

Tony,

About the last comment, I think we can add something to the EVPN-IP-VPN interop draft. That could be the right place to do it.
I can suggest a paragraph or two to the authors.
Thank you.
Jorge

From: Antoni Przygienda <[e-mail]<mailto:[e-mail]>>
Date: Monday, August 18, 2014 at 8:46 PM
To: Jorge Rabadan <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: Some observations/questions on inter-subnet and type-5 draft for EVPN

Jorge, inline as well

From: Rabadan, Jorge (Jorge) [mailto:[e-mail]]
Sent: Monday, August 18, 2014 8:17 PM
To: Antoni Przygienda; [e-mail]<mailto:[e-mail]>
Subject: Re: Some observations/questions on inter-subnet and type-5 draft for EVPN

Tony,

Thank you for your comments.
Please see in-line.

From: Antoni Przygienda <[e-mail]<mailto:[e-mail]>>
Date: Saturday, August 16, 2014 at 11:07 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Some observations/questions on inter-subnet and type-5 draft for EVPN

So, wrapping around my head around EVPN type 5 and inter-subnet drafts and some observations (all on version -02 of type  5 and version -04 of inter-subnet)


a)       Nitpick first: in type-5 section 3.1 the IP Address Length field is not a particularly well chosen name for the field. It really is prefix length and other drafts use IP Address Length being 1 byte to indicate 4 bytes or 16 bytes and not mask length (e.g. evpn-07). I suggest changing to ‘IP Prefix Length’ or something like this.

The reason why we called it IP Address Length was to keep it consistent with the route type 2 (at the time where the evpn draft suggested that the MAC Address Length might have been used as a prefix length). Now the draft evpn-07 clearly states that the MAC address length is 48, and IP address length 32 or 128.
So yes, I think we can change the name to IP Prefix Length for clarity. Good suggestion. Thanks.
[Tony said] ack



b)      The new BGP attribute have couple unclear things to it (I mean the ‘EVPN-GW-2-EVPN-GW tunnel attribute’ for lack of a clearly specified name (which I think it needs) in draft inter-subnet section 6)

i.       I assume the intention of lack of such an attribute is that the tunnel is MPLS and therefore the label-2=l3vpn-label since I don’t see an ‘MPLS-tunnel-type’ in the attribute ? But then, how do we figure out e.g. the MAC of the NVE. Did I misread completely or is that an oversight or did I get lost in all the tunneling ?

ii.      Bump-in-the-wire-use-case seems to indicate that the ‘EVPN-GW-2-EVPN-GW tunnel attribute’ is carried on route type 1 (but it seems it could be carried on the type-5 route with ESI!=0 equally well ?  In the VRF-2-VRF case however it’s clear that type-5 is carrying the tunnel attribute so it may be more consistent to not stick it on type-1 albeit sticking it on type-1 is more consistent with it being stuck on RT-2 routes to resolve the MAC-2-tunnel in e.g. floating ip use case

iii.     It is not clear whether multiple tunnel attributes can be sent within a route & used for load balancing

There are a couple of things that we need to fix and clarify in the next rev of both drafts. “i” is one of them. “iii” can be clarified too.
About ii, the draft only suggests the use of the attribute for the VRF-to-VRF use-case.
[Tony said] I reread the  5.4 (bump-in-the wire) and you’re correct, all the VXLAN is derived from the A-D-1. I assume the correct tunnel (vxLAN,nvGRE) is correlated purely by BGP next-hop then on which NVE2 and NVE3 reside so that makes it complete.

I agree that in VRF-2-VRF case carrying it on type-5 makes sense (well, there is no other place since there is no type-2 advertised ;-)   That answers ii)




c)      I start to ask myself whether we should start to think about IP route preferences in EVPN. Observe that currently we can install/use IP addresses/prefixes for IRB in EVPN assigned VRFs from multiple sources (or rather inter-subnet route on them)


1.      IP-MAC (RT-2) containing /32 (incl. gateway attribute)

2.      RT-5 containting /0 all the way to /32

3.      Draft-inter seems to allow to use IP-VPN routes to be used for lookup incl. prefixes (if not explicitly then surely implicitly via RTs)

4.      Redistribution from other protocols that do either IP prefix or IP-MAC bindings (but that’s kind of well-known protocol distance we have today already)


Question here becomes: Should we specify the IP route preferences for all those routes being installed into the IP-VRF (or in broader sense, which address type should be preferred in inter-subnet lookup) ?  If not, looping criteria start to become imaginable IMO if implementations do not agree on the protocol preference as was the case for a while in L3 routing.

I believe all the protocols feeding a VRF routing table should have a different preference, but that is really a vendor specific implementation and it is not a new issue. As far as I know there is no RFC suggesting default routing preferences among routing protocols.
In particular for EVPN to IP-VPN interworking, there are two things to bear in mind (again, nothing new if you compare it with IP-VPN to PE-CE BGP interworking):

  *   Both types of IP prefixes, EVPN and IP-VPN must have different preference/distance. In the implementation I know of, by default, EVPN has lower preference than IP-VPN, which I think it makes sense.
  *   In case of PE redundancy, routing loops may occur if both PEs exchange EVPN and IP-VPN prefixes for the same VRF. If that is the case, loops may be avoided by tagging the routes with e.g. site-of-origin communities and filtering out prefixes received with self-owned site-of-origin.
[Tony said] yes, agreed to all you said. In l3 case @ certain point in time e’one copied Cisco values on startup & issue was resolved ;-)  IPVPN over EVPN does make sense. Once the packet is thrown off using L3, the chance to loop is smaller & albeit delivery is without L2 shortcut, it will be ‘safer’ as well ;-)
Maybe a paragraph stating ‘here be dragons’ would be good or some such suggestions like this one which is ‘SHOULD’ only.
I have to think about the tagging, new angle to me.
--- tony