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
