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
