Russ, I am under the impression that Adrian's email asked for comments on the proposed change to section 6.3.
Yours Irrespectively, John > -----Original Message----- > From: BESS [mailto:[email protected]] On Behalf Of Russ White > Sent: Monday, February 02, 2015 8:42 AM > To: [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
