While I would have liked a solution that completely removed renumbering,
LISP does not cope with all of the cases that cause renumbering. It is
hard to state the tradeoff clearly and concisely, although it is
inherent in teh fact that LISP is site oriented. (Yes, there are some
interesting extension to mobility, but those are out of scope...)
If there are operational issues that need to be consistent, those should
be captured in the deployment document. If they aren't, we need to fix
that. But there are limits. I do not think we need to deal at this
time with describing exactly what has to happen when a LISP site sells
part of its network to another organization, that either is or is not
using LISP.
Yours,
Joel
On 6/23/2011 2:59 PM, Alia Atlas wrote:
Joel,
Certainly I agree that the text in [LISP] addresses some of the basics
of handling overlapping
prefixes. I had thought that one point of LISP was to avoid needing
to renumber; I believe that in
a similar case with IPv4 addresses today, it's not unusual to get the
smaller prefix announced.
However, in response to more detailed questions, I keep hearing back
assumptions or things
that have been discussed on the list and are not captured in a draft.
For a protocol like LISP, there are clearly many operational details
and assumptions to be agreed
upon and that need to be consistent. Last time I looked at the
deployment draft, I didn't notice
them captured anywhere.
Are there plans for such a draft?
Alia
On Wed, Jun 22, 2011 at 6:49 PM, Joel M. Halpern<[email protected]> wrote:
The normal situation is that an EID block is delegated to an administrative
authority (a company). They use it.
They may use the main block, and use some sub-blocks. That produces "holes"
which are overlapping prefixes. The handling of that is described in the
document. The ETRs which are responsible for the covering EID prefix must
know which blocks are allocated elsewhere.
They have to identify those in the response.
THe details are spelled out.
The normal case would be that the division that was sold would be renumbered
into its own or its new parents EID block. After all, they are no longer
part of the original site. The overlapping prefix mechanisms allow for
transition.
The more extreme case is not permitted. You can not have a LISP EID block,
within which there is a hole which is used as IP addresses but not as LISP
EIDs. (The inner portion can be used as both, but it has to be an EID.)
Yours,
Joel
On 6/22/2011 6:32 PM, Alia Atlas wrote:
Dino,
Thanks for your responses - mine are in-line below.
Alia
On Mon, Jun 20, 2011 at 6:19 PM, Dino Farinacci<[email protected]> wrote:
...
If the site has an EID-prefix of the /16 that is the one it Map-Replies
for.
We have rules in section 6.1.5 "EID-to-RLOC UDP Map-Reply Message" on how
to
send Map-Replies when there are overlapping EID-prefixes and there has
been
much discussion on this mailing list about it.
I agree that there's been lots of discussion on the list. Capturing
the decisions made
into the draft would be good practice, IMHO, and ensure it has been
resolved.
Can an ETR have an prefix which has a hole in it? What happens if the
ETR does not
know the correct RLOCs to use for that hole (since it isn't owned)?
I'm thinking of a case where initially there is a LISP site with a
/16. Then, part of that
company is sold along with the /24 that is used in that division.
Now, can the original
site advertise the /16 with a hole? How would it do that?
The problem here is that the ETR does NOT KNOW the correct locator-set
for the /24 hole
that has been sold off.
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
