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

[Dino Farinacci <dino at cisco.com>]

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

Yes, I think something like that.

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

Yes, which will be trusted. As well as having a registration  
procedure that is pub/priv key protected for the ETRs to register EID- 
to-RLOC mappings.

I think we have a good demarcation design where the LISP-00 ID can  
use various means to obtain the mappings. I can see any or all of the  
following:

o Static
o ICMP
o DNS
o Push-only
o Push-n-pull
o Pull with new database

We can try them all out and start pruning what we think we don't  
like. But the pruning happens after *implementation*. That is we  
obtain rough consensus and running code.  ;-)  I think I heard that  
once before.  ;-)

It would be really nice if folks on this list could pick one to focus  
on. You can use me as a focal point so we don't duplicate effort.

Whadaya think?

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

Yes, I understood what you said. And I realize this new instance  
would carry less stuff.

> 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

Yes, and there could be a good possibility that any given router may  
not run both instances. We might want to make that a goal. Definitely  
at the high-level system deployment (note I didn't say routers,  
because we could have low-cost, fast, linux systems do this).

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

We would have to turn off best-path selection. Many attributes  
wouldn't apply to this new NLRI type, etc.

> 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

Marcelo, I think it's definitely something to consider. I don't want  
to give the wrong impression I'm against BGP.

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

I know, because we wouldn't be routing EIDs. But if we didn't want to  
drop packets in the ITR, the ITR could encapsulate to one of the high- 
level routers that would have the mapping and then it would "re- 
encapsulate" (versus recursive encapsulate as the LISP ID states) to  
the site's ETR.

This increases stretch that we *could* stick with, or the ETR could  
send the mapping to the ITR via an ICMP EID-to-RLOC Reply.

I really think we have a lot of options (maybe too many ;-)).

> 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

Yes, understand. Lixia made the same suggestion using the DNS  
protocol. That is use DNS the protocol as your query/reply protocol  
but don't run it on UDP 53.

But I have to beg the question, why people think this is the long  
pole in the tent? That is designing a straight-forward protocol  
shouldn't be hard or time consuming.

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

Well I was thinking of access control. But in terms of locator  
selection, that is where I think there needs to be focus. Can you  
tell me if what LISP proposes with using priorities and weights per  
locator is not sufficient. It should be familiar to you. ;-)  And I  
did run it by both large-site enterprise types and ISP types.

Thanks,
Dino

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