Sue, Comments inline.
Yours Irrespectively, John > -----Original Message----- > From: Susan Hares [mailto:[email protected]] > Sent: Tuesday, February 03, 2015 7:28 AM > To: John E Drake; 'Russ White'; 'Rabadan, Jorge (Jorge)' > Cc: [email protected] > Subject: RE: [bess] EVPN Draft Comments > > 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. [JD] No you didn't. > The Base EVPN > does not utilize the NLRI/Attributes in a way I consider standard BGP > mechanism to allow scaling or efficient processing. [JD] As I said I would like to see specifics - all I see is an assertion of FUD . > 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. [JD] If you are saying that your concerns are the same as those of Russ, then I don't think we have any issues. > > 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
