Ali: Ok - I will answer a direct question on the EVPN RFC, and then may we please stop this thread.
I understood that Russ was referring to the EVPN draft (soon to be RFC 7432). I am not referring to the evpn-overlay draft, and this is not "the nexthop" issue. This is Auth-48, and the draft is going to be an RFC (per IETF procedures). EVPNs are important to the industry and the standardization of these features are important. Clarity is important for the base draft and other draft to assure proper interoperability in testing and deployment. Delaying this draft is not good for the industry. I believe we both want the best possible BGP mechanisms to better fit the EVPN environment is. These focuses started on Russ comments: >>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. My original post only confirmed that I felt like Russ the text could have been improved. I just wanted to confirm I that I shared Russ' perceptions of the unclarity of the text. BGP is flexible things, and as you know, BGP attributes and AFIs can be done in many ways so this makes clarity important in BGP drafts. All the rest of these post was to answer other direction questions you or your co-authors posed which were off the topic of the base EVPN RFC. For that, I apologize to the BESS list for the spam. Sue -----Original Message----- From: Ali Sajassi (sajassi) [mailto:[email protected]] Sent: Tuesday, February 03, 2015 12:38 PM To: Susan Hares; 'Russ White'; 'John E Drake'; 'Rabadan, Jorge (Jorge)' Cc: [email protected] Subject: Re: [bess] EVPN Draft Comments Hi Sue, Two points: 1) What you are saying below and the draft that you mentioned below (idr-remote-next-hop) is not relevant to baseline EVPN draft (soon to be RFC 7432). 2) At one point we were thinking of using this draft for evpn-overlay draft (which is different from baseline evpn); however, we decided not to use it and instead use RFC5512. That decision was made about a year ago. Regards, Ali On 2/3/15, 3:12 AM, "Susan Hares" <[email protected]> wrote: >Ali: > >I would be glad to inform Yakov, Keyur and Pedro of these issues I >perceive with the draft. It would be delightful to see why they >thought your structure was reasonable. > >Yakov and Pedro have not been in active discussions regarding IDR >next-hop mechanisms in the last year. For 2014, Keyur and others on >the IDR list have been discussing new next-hop drafts. I suggest you >consult the IDR mail list for these discussion regarding that the following draft. > >https://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/ > >At: >http://www.ietf.org/mail-archive/web/idr/current/msg13658.html (my >comments) >http://www.ietf.org/mail-archive/web/idr/current/msg13689.html (Eric >Rosen's) > > >Eric Rosen raises some very useful points on this specific draft, and the >design of reliable next-hop mechanism. It is Eric's comments and others >that have caused me to start a conversation regarding this topic. > > Please note I lead this discussion on the EVPN with a pragmatic note. >If >the EVPN is deployed and implemented by 2 vendors (as we require for IDR >WC >LC of protocol standards), then it should be standard rather than sit on >the >shelf. We can consider a revised BGP mechanism in the future, but it must >be deemed more efficient or better scaling. > >Best wishes, > >Sue > >-----Original Message----- >From: BESS [mailto:[email protected]] On Behalf Of Ali Sajassi >(sajassi) >Sent: Tuesday, February 03, 2015 2:52 AM >To: Susan Hares; 'Russ White'; 'John E Drake'; 'Rabadan, Jorge (Jorge)' >Cc: [email protected] >Subject: Re: [bess] EVPN Draft Comments > > >Sue, > >On 2/2/15, 9:25 PM, "Susan Hares" <[email protected]> wrote: > >>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. > >If there are any specific suggestions, I¹d like to hear it. At the IETF >BESS >meeting, I believe I didn¹t hear anything specific. > >> >> >>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. > >It should be noted that this draft was written in collaboration with our >BGP >colleagues: Yakov, Pedro, and Keyur right from the beginning. So, if there >are any issues, I am sure not just me but these folks would also be >interested in hearing them. > >Regards, >Ali > >> >> >>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 > _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
