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
