Hi Russ, as someone who was involved early on in the EVPN, I can assure you that we had considered load-balancing as achieved via aliasing early on in the process. John may not be aware of it because it pre-dates his involvement with EVPN, but please see section 20.1 of https://tools.ietf.org/html/draft-raggarwa-sajassi-l2vpn-evpn-01#section-20.1. And you will find that it describes the aliasing functionality as far back as Nov 2010. So it is more than 4 years old, if not older - and if you look at that draft, same holds for other major concepts introduced in EVPN.
Thanks. - Ravi Shekhar. -----Original Message----- From: BESS [mailto:[email protected]] On Behalf Of John E Drake Sent: Monday, February 02, 2015 12:41 PM To: Russ White; Rabadan, Jorge (Jorge) Cc: [email protected] Subject: Re: [bess] EVPN Draft Comments Russ, Comments inline. Yours Irrespectively, John > -----Original Message----- > From: BESS [mailto:[email protected]] On Behalf Of Russ White > Sent: Monday, February 02, 2015 3:02 PM > To: Rabadan, Jorge (Jorge) > Cc: [email protected] > Subject: Re: [bess] EVPN Draft Comments > > > If the length of the layer 2 address is fixed, there is no way to > accommodate future use cases regardless of the inclusion of a length > field. The way the draft is written, it would be justifiable to ignore > the length field, destroying future expansion. Adding a length field > to a fixed length filed doesn't mean the length of the fixed length > field can change -- otherwise it wouldn't be fixed length. [JD] What RFC 7432 actually says is: "The MAC Address Length field is in bits, and it is set to 48. MAC address length values other than 48 bits are outside the scope of this document." So, The MAC Address field is a variable length field whose length is currently set to 48. > > The aliasing procedure, to me,says "we didn't think through these > relationships well, so let's throw in a way to get around the > limitations we put into the original draft." This isn't an elegant solution. [JD] Just because you don't like/understand it doesn't necessarily mean it's wrong. > > If the esi must be unique, and it's important, then the esi must be > unique as used. Using a non-unique part of the esi destroys the point > of building a unique esi in the first place. [JD] The ESI is unique. The ES-Import RT is not. This means that some PEs may import an Ethernet Segment route that are not attached to the ES specified in the Ethernet Segment route. When they examine the Ethernet Segment route they will realize this and discard it. > > Two of these are going to be problems in real world deployments, and > need, imho, to be fixed in a bis. > > :-) > > Russ > > > > On Feb 2, 2015, at 10:39 AM, Rabadan, Jorge (Jorge) > <[email protected]> wrote: > > > > Hi Russ, > > > > Since we are I think in agreement this must NOT hold the process, I > > give you my 2 cents if I may... > > > > Section 7.2 - the mac length field is fixed in EVPN to 48, but it > > has to be there to allow future use-cases. For instance, it might > > make sense to use variable mac lengths in PBB-EVPN since the BMACs > > are > operator-managed. > > > > > > Section 7.6 - this is not an issue to me. The ESI has to be unique > > in the network. The mechanisms to auto-derive the ESI can only be > > used if they guarantee the uniqueness of the ESI. And since the > > ES-import route-target is a route-target, its value can only be > > present on the PEs where you want to import the route. I don’t think > > there is a need for clarification of the text. > > > > Also, I think aliasing is a great thing to support. > > > > Thanks. > > Jorge > > > > > > -----Original Message----- > > From: Russ White <[email protected]> > > Date: Monday, February 2, 2015 at 5:42 AM > > To: "[email protected]" <[email protected]> > > Subject: [bess] EVPN Draft Comments > > > >> Y'all: > >> > >> I know this is in auth-48 (or maybe past), but I've been through > >> these docs a number of times, and still come up with questions that > >> I think need to be addressed/answered at some point. In general, > >> eVPN seems to be on the receiving end of "I can imagine a lot of > >> different use cases, some of which are self-contradictory, but > >> let's just throw it all in the bucket anyway, regardless of the > >> complexity and other problems." But, aside from that -- some > >> specific comments on the base draft -- > >> > >> == > >> Section 7.2 > >> > >> The MAC address field in the TLV is specified as 6 octets, but > >> there is also a MAC address length field -- normally you would only > >> include a length field if the field itself is variable length, > >> which doesn't appear to be the case here. Is there some specific > >> reason a length field is included, and the length of the field is > >> specified? > >> > >> == > >> Section 7.6 > >> > >> This is a new transitive Route Target extended community carried > >> with the Ethernet Segment route. When used, it enables all the PEs > >> connected to the same multi-homed site to import the Ethernet > >> Segment routes. The value is derived automatically from the ESI by > >> encoding the high order 6-octet portion of the 9-octet ESI Value in > >> the ESImport Route Target. The high order 6-octet of the ESI > >> incorporates MAC address of ESI (for type 1, 2, and 3) which when > >> encoded in this RT and used in the RT constrain feature, it enables > >> proper routetarget filtering. The format of this extended community > >> is as > >> follows: > >> > >> However, the high order 6 octet portion of the ESI is not unique -- > >> the section on forming the ESI actually includes instructions that > >> would mean multiple ESIs with the same higher order 6 octet. When > >> we're dealing with MAC addresses and overlapping IP address sets, > >> it will be problematic to install destinations from one ESI into > >> the MAC-VRF > in another ESI. > >> > >> This is related to section 8.1.1, as well, which deals with route > >> filtering. > >> > >> == > >> 8.2.1 > >> > >> Throughout most of the document, the ESI is described as being 9 octets. > >> Here it is described as being 10 octets. No explanation is given. > >> > >> == > >> 8.4 > >> > >> The entire concept of aliasing appears dangerous to me. It would > >> have been better to separate the MAC address from the EVI in two > >> separate advertisements, making reachability to the MAC address in > >> reference to the EVI, and reachabality to the EVI it's "own thing," > >> rather than tying the two together and then creating an "alias." > >> > >> == > >> 8.5 > >> > >> The definition of "service carving" is buried in the text in the > >> middle of section 8.5. Shouldn't this be included in the glossary, at > >> least? > >> > >> == > >> 8.5 > >> > >> In step 3 of DF election, the list of IP addresses is ordered in > >> "increasing numeric value." What if you have a mix of v4 and v6 > >> addresses? > >> > >> == > >> > >> :-) > >> > >> Russ > >> > >> _______________________________________________ > >> BESS mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/bess > > > > _______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
