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

[Dino Farinacci <dino at cisco.com>]

Sorry for the delay on this response.

> > > > You are right non Marcelo. I think taking the high-road by doing  
> > > > a LISP-push model gives you the best of all worlds.
> > >
> > > by push model, we are talking about destributing the ID to  
> > > locator mapping database to all LISP routers?
> >
> > I would say all high-level routers
>
> i am not sure what do you mean by high level router... could you  
> expand?

I mean a set of routers at the highest level of a hierarchy.

> 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.

> > > 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.

> 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.

> 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. 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.

> > > 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.

Dino

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