[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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? 

Yes.

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) 

May be adequate in TE-ITRs.

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. 

I realize that. That we can fix. Not worried about it too much.

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. 

I don't understand your point here.

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 way we have been talking about it. Using DNS store mappings.

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

Right.

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 

What will? 128-bits is a lot of addresses. Shouldn't even try.

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 

Okay, sounds good.

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.

How you pull and what you pull don't have to be related. I personally like prefixes where the size of the prefix is based on the number of systems you need assign IDs to.

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

Could.

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?

Yes, I think it is very likely that many ITRs (for ease of management) will have a single EID entry that looks like this:

	0.0.0.0/0 -> {locator1, locator2}

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

Right.

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 

It's the price to pay for scaling.

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)

I've seen it good and bad both ways. But I have found you take the good from the past and leave the bad in the past. ;-)

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

Good idea. Let's see if I can draft some people.

Dino

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