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.
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. 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. 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
