Re: ID/loc mapping distribution protocol (was Re: [RAM] Incremental Deployment of LISP

[marcelo bagnulo braun <marcelo at it.uc3m.es>]

El 11/04/2007, a las 11:05, Dino Farinacci escribió:
> > but the ITR are the ones than need the information (hence the ones 
> > that should have it), right?
> >
> > Of course, in addition, routers making TE would also benefit from it, 
> > so it makes sense to pass it to them also (but they are ITRs after 
> > all, right?)
>
> If they have the storage capacity sure, but when they don't they have 
> to be cache based and send queries for the mapping they need. There 
> are only two ways to do this.

so are you envisioning an hybrid system that has both the push and pull 
models? In such scheme there would be these mesh of high level routers 
that exchange the whole loc id mapping database and then smaller 
routers that use the pull model to query these high level routers?

the new protocol would then run between these high level routers, is 
that it?

> > > > are you thinking in using a protocol for that distribution, like 
> > > > BGP for instance?
> > >
> > > A new protocol more optimized perhaps for flooding that has 
> > > authentication built-in.
> >
> > what is the motivation for a new protocol?
>
> Because there isn't anything out there that can flood (without doing 
> other things) as well as authenticate bindings.



> > i mean, BGP does seem to provide what is needed, and it is well known 
> > by the community
>
> Every BGP router may not be an ITR/ETR or high-level router. So you 
> are storing the information in places you don't need it. That means 
> everyone is paying the cost.
>
> If we are worried about power, FIB size and line-card costs, we need 
> to move this state to the edges in lesser expensive memories.

i think i didn't explained myself properly

I am not saying to use the BGP instance used today to exchange routing 
information to also exchange loc/id mapping information.

What i am saying is using the BGP protocol for that, meaning to create 
a _new_ instance of BGP and run it for instance between the high level 
routers that you mention above. In this case, these high level routers 
would run two instances of BGP. On instance of BGP, that would 
distribute routing information as it is done today. Another instance of 
BGP would be used to distribute the id loc mapping information

> > do you think that BGP is lacking some of the required capabilities?
>
> Yep. Plus it has more than we want. And many have shown that BGP is 
> not an efficient flooding protocol.

i don't know about that... i mean, BGP as a protocol seems to be quite 
simple and eficient and it is already out there

I mean, i do agree that BGP does provide some features that may not be 
needed for an id loc mapping protocol, but i am not sure this 
outwiegths the benefits of being a protocol already available in 
deployed routers

> > note that for globally distributing the ID to locator mapping 
> > information, you would just need to enable another instance of BGP 
> > with maybe some extensions, that would
>
> That was a possibility we considered with LISP 1.5.

i don't think this is similar than LISP 1.5, please see below...

>  That is, to change less protocols and have a non-topological 
> aggregation benefit as Vince has outlined a number of times.
>
> > carry the id to loc mapping to all the routers running this new 
> > instance. I think that from a deployment perspective, this is much 
> > better than designing a new protocol, since it would only require 
> > configure existent routers (maybe some software patch) but not 
> > deploying a new protocol (I think this would go along with the 
> > general LISP policy of minor changes rather than new protocols, 
> > doesn't it?)
>
> A new protocol can start simple. We made this decision with MSDP. We 
> decided it was better to not put the frequency of multicast source 
> discovery in BGP, and I stand by that decision today being a good one.
>
> BGP already does too many things. And if you want to tweak it to 
> optimize one thing it may have negative effect on other things.

I am not saying to overload BGP with additional information, but to run 
a different instance of BGP to distribute other information. It is 
similar to the considerations being made about the differences between 
the DNS protocol and the DNS system. I am not proposing to use current 
BGP system (the instace of BGP used to currently distribute routing 
information) but to build another instance of the BGP protocol to 
distribute the id loc mapping information. Re use the BGP protocol not 
the current BGP routing system

> > > > There have been a few proposals on this area before, which were 
> > > > very interesting imho, but i guess some people though they were too 
> > > > complex
> > >
> > > We can start simple. This doesn't need to be complex and if we keep 
> > > policy out of it ;-) we can keep it easier
> >
> > but probably the complex part of policy is to provide enough 
> > information and flexibility to allow for local configurations, so 
> > this needs to be build in the protocol from scratch, just as BGP has 
> > it.
>
> Not convinced yet the policy has to be as advanced as BGP.

policy seems to be one of the key features that are missing in 
available solutions, so i  would put quite some focus on that

Regards, marcelo


> Dino


_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram