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 <ru...@riw.us> Date: Monday, February 2, 2015 at 5:42 AM To: "bess@ietf.org" <bess@ietf.org> 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 >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
