Fully agree with John. Thanks. Jorge -----Original Message----- From: John E Drake <[email protected]> Date: Monday, February 2, 2015 at 12:41 PM To: Russ White <[email protected]>, Jorge Rabadan <[email protected]> Cc: "[email protected]" <[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
