To add to what John said, the remote NH proposal would be less efficient than the EVPN draft in terms of BGP messaging.
On 03/02/15 13:47, "John E Drake" <jdr...@juniper.net> wrote: >Sue, > >I think we have a tempest in a teapot. > >The EVPN Overlay draft >(https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-00) needs to >indicate different data plane encapsulations and initially we had >proposed using the RFC 5512 extended community for this. > >Subsequently, Ali and Keyur proposed using Keyur's remote next hop draft >which you reference, below, because it also specifies data plane >encapsulations. Ultimately, and w/ Yakov's assistance, we re-affirmed >our decision to use the RFC 5512 extended community and I believe that >the necessary additional code points have been allocated. > >So to recap, we have no interest in or any need for remote next hops. > >Yours Irrespectively, > >John > >> -----Original Message----- >> From: Susan Hares [mailto:sha...@ndzh.com] >> Sent: Tuesday, February 03, 2015 6:13 AM >> To: 'Ali Sajassi (sajassi)'; 'Russ White'; John E Drake; 'Rabadan, >>Jorge (Jorge)' >> Cc: bess@ietf.org >> Subject: RE: [bess] EVPN Draft Comments >> >> 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 _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
