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:bess-boun...@ietf.org] 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: bess@ietf.org Subject: Re: [bess] EVPN Draft Comments Sue, On 2/2/15, 9:25 PM, "Susan Hares" <sha...@ndzh.com> 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:bess-boun...@ietf.org] On Behalf Of Russ White >Sent: Monday, February 02, 2015 7:12 PM >To: 'John E Drake'; 'Rabadan, Jorge (Jorge)' >Cc: bess@ietf.org >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 >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess > >_______________________________________________ >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 _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
