On Mon, Apr 21, 2014 at 05:57:23PM +0000, Igor Bryskin wrote: > >I have a couple of questions: > >1. AFAIK we don't have yet a routing protocol whose speakers exchange XML > >encoded messages, why is that? > > I am not talking about routing protocols, but protocols that constitute > ?APIs? into the system. Such protocols are NC/RC/Y, Forces, OF, PCEP, ...
FWIW, L3VPN has draft-ietf-l3vpn-end-system using XMPP as a component. :-) > As I said before, the protocol by which you learn the route updates is a > small fraction of the overall CPU cycles. For a large scale deployment > it?s more about the right organization of data in the RIB for fast updates > and scale; after that it?s about the speed at which you can install the > routes in hardware. I tend to agree here. I've spent a fair amount of time analyzing the marshalling code in 3 different BGP implementations and while there is room to Do the Wrong Thing, most of the CPU is not spent in these paths. Where bigger mistakes tend to be is taking the information to be presented and deviating too greatly from the internal representation of that information. > >IMHO we can not give convincing answers for 3. and 5. until we see the > >requirements agreed upon by all interesting parties. In this I totally > >agree with Jamal. > > We have been discussing I2RS use cases and requirements for the past year > or so. It is my understanding that at the last IETF there were two > proposals that can meet the requirements: Forces and NC/RC/Y. There have > been cases made for each one of them - Andy and Dean made the case for > NC/RC/Y, and Jamal made the case for Forces. Ed has asked the community to > a vote for one of the two. > > Is my understanding correct or not? If my understanding is correct, why > are we going back to square one? The request was really for two things: 1. Please look at the proposed mechanisms in DETAIL. We already know there are gaps and have been presented many of them by the experts in those mechanisms. Before the WG goes off and chooses something by popularity contest, we owe it to ourselves as engineers to understand the systems well enough to know what we're getting into. 2. By becoming familiar with the other system, we can see if there are properties we really like that would need to be added into the competing system. To give an arbitrary example, if binary encoding is really that helpful in the FORCES protocol, do we want something similar in Netconf/Restconf if we chose that one? If human-readable XML output is what we really want, are there gaps in the properties we get in Yang that FORCES would need? > IB>> I don't think we have a satisfactorily protocol/model requirement > document yet, which is a tightly defined an unambiguous enumeration of > qualitative and qualitative parameters of the protocol and model that are > required, desired, etc. for i2rs architecture to be successful (Take a look > for a good example at MPLS-TP requirements RFC). We have to go to square one > and write such a document, I think Much of the motivation for this discussion was to help decide what should go in such a thing. We're not inventing something completely from scratch in I2RS, we have existing things we can pick from. If we know that something that exists doesn't satisfy all of the needs via either comparison or other means, the selected mechanism will need to evolve. And while inventing our own might be neat, I think the majority of people interested in I2RS related work would really just rather start writing code. -- Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
