Ravi, Thanks but I think you misread my email. I was actually pointing out to Russ that he hadn't expressed anything more than a visceral dislike for the current EVPN aliasing design.
Yours Irrespectively, John > -----Original Message----- > From: Ravi Shekhar > Sent: Tuesday, February 03, 2015 3:24 AM > To: John E Drake; Russ White; Rabadan, Jorge (Jorge) > Cc: [email protected] > Subject: RE: [bess] EVPN Draft Comments > > 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
