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
