John - Irrespectively - I cut the email list from the [email protected] working group and I will not bring it back unless instructed by the BESS WG chairs. The Base EVPN does not utilize the NLRI/Attributes in a way I consider standard BGP mechanism to allow scaling or efficient processing. However, I promised the BESS WG chairs that until I did a complete write-up, I would state concerns briefly (aka agreeing with Russ) but not delay any standardization work on the current drafts.
Due to fulfill promise, I did not comment during IETF LC / WG LC because I had not written up my comments on each draft as an IETF Draft. If you wish to engage in a conversation prior to me writing an Internet draft - I welcome it. Pragmatically, Sue -----Original Message----- From: BESS [mailto:[email protected]] On Behalf Of John E Drake Sent: Tuesday, February 03, 2015 6:59 AM To: Susan Hares; 'Russ White'; 'Rabadan, Jorge (Jorge)' Cc: [email protected] Subject: Re: [bess] EVPN Draft Comments Sue, It would be helpful if both you and Russ would offer some specifics. E.g., the next hop issue that you mentioned in the BESS meeting has nothing to do w/ the base EVPN spec. Yours Irrespectively, John > -----Original Message----- > From: Susan Hares [mailto:[email protected]] > Sent: Tuesday, February 03, 2015 12:25 AM > To: 'Russ White'; John E Drake; 'Rabadan, Jorge (Jorge)' > Cc: [email protected] > Subject: RE: [bess] EVPN Draft Comments > > Russ and John: > > I have concerns about the issues Russ has raised as well as other concerns > regarding the EVPN. As I mentioned at the last IETF's BESS meeting, John > Scudder and I have been discussing the next-hop issues in BESS drafts to see > if IDR could create better BGP mechanism for the future BESS drafts. In > this review, it became clear that several of the mechanism in EVPN could > have been done in a simpler and more elegant way in BGP. It was not the > first EVPN specification that made this clear, but the review of several drafts. > > I am pragmatic. It is auth-48. If the EVPN is widely shipping and > deployed in networks, it is unlikely that the vendors or providers > want to change it at this point. They have coded the EVPN solution. > My agreement with the BESS chairs was this investigation was not to derail their work. > > If you are interested, I would appreciate a phone conversation with > both of you. John Scudder indicated that John Drake would be the best > person within Juniper to discuss this point with. Perhaps we can talk > about all of these issues. Since it is a BGP mechanism, perhaps if we > create a more elegant BGP mechanism it could be considered as a "bis" > for EVPN drafts. I suspect EVPN use is only going to grow, and better > BGP mechanisms usually mean more efficient and scalable code. > > Best wishes, > > Sue Hares > > -----Original Message----- > From: BESS [mailto:[email protected]] On Behalf Of Russ White > Sent: Monday, February 02, 2015 7:12 PM > To: 'John E Drake'; 'Rabadan, Jorge (Jorge)' > Cc: [email protected] > Subject: Re: [bess] EVPN Draft Comments > > > > [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. > > And the figure clearly shows the length at 6 octets only. I'm not > arguing the draft didn't _intend_ to make this a variable length field > -- I'm arguing the draft, as written, can easily be misinterpreted, and could use clarification. > > > [JD] Just because you don't like/understand it doesn't necessarily > > mean it's wrong. > > John -- you could have said, "I think it's elegant because..." -- or, > "I agree it's not perfect, but we chose this solution because..." > Instead, you decided to launch a personal attack, calling me stupid/uneducated/ignorant/whatever. > This is one of the things that drives me absolutely nuts about working > in the IETF -- we cannot hold ourselves to an actual discussion, we > have to find some way to make claims about other people personally, no > matter whether or not we think they're true, etc. The next time > someone says, "I can't figure out why we are losing participation in > the IETF," go back and reread your response. > > Now -- to return to the actual topic at hand -- I find the idea of > binding things together tightly, and then creating an "alias," rather > than creating a looser bind and map in the first place, is worse. That > might not fit what you think, but it's still something worth mentioning. > > :-) > > 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
