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 21:18, Dino Farinacci escribió:

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

So are you using a trust model that is based on a closed set of 
participants that trust each other rather than a mean to certify that 
the actual information about binding is correct?

> 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

i don't think we should preclude this one, but i don't think it is 
general enough to solve our problems (i would leave it as a corner case 
for testing and exceptions)

> o ICMP

My take on this one is that much needs to change from its current form 
to be secured. In particular you will need a few more message exchange 
to achieve this.

Besides, you need a valid ID to locator mapping (with at least one 
working locator) to actually send the initial request, so this needs to 
be complemented with an additional mechanism. In LISP 1, the mechanism 
is the identity, since the identifier is also a valid locator.
In HIP is the DNS, where you can obtain the locators and the identifier 
from the DNS query (note that this requires a fqdn, since there is no 
id to locator mapping service)
In shim6, is both of them

> o DNS

not sure what do you mean here...

the DNS as used in HIP? i.e. using the DNS to obtain both the 
identifier and the locator set associated to a fqdn
or the DNS system to retrieve identifier to locator mapping, like for 
instance using ULAs as identifiers and using the DNS reverse tree entry 
for the ULA for retrieving the locators associated with this 
identifier?

the DNS as a generic protocol independent of the current DNS system to 
make a directory service for retrieving Id to locator mapping?

In any case, in order to answer this question, i guess that an 
important previous question is how do you think the identifier 
namespace will be? I mean, it seems that DNS type of approach will not 
scale to support an 128 bit unstrucutred identifier namespace. OTOH, if 
you are thinking of using ULAs or PI addresses as identifier, then this 
may work

> o Push-only
> o Push-n-pull

i like your argument that it is good not to require every ITR to have 
the full database, even in a push model. I think we should continue 
exploring this solution space

> o Pull with new database

again, i think this is closely related with the characteristics of the 
identifier namespace. If we have an existnet protocol like the DNS that 
can provide this feature, i don't see the need for this.

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

maybe the push and pull approach could be based on BGP+DNS...

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

something similar like a default route for EIDs?

you may end up with a similar concept of the DFZ but for routers that 
know how to map identifiers...

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

yes, i think this additional stretch could be acceptable for a few 
initial packets

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

imho, established well known protocols that have already been tested 
and are stable are better choice than new protocols, that need to 
mature. Of course, this only if we don't overload existent usages. For 
that reason, i think that if we can reuse the protocol but maybe not 
the actual current system, seems the best tradeoff (of course if the 
protocols do provide the required functionality, which is not at all 
clear yet)


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

I would like isps and end site users to reply to this

i mean having a draft describing the needs in term of policy and TE 
from mutlihomed end sites and isps would be a great help in order to 
design a solution that suit their needs...

Regards, marcelo


>  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