Unless I am very confused, an ETR can actually provide information that
certain EID sub-blocks are delegated, without even providing the RLOCs.
For taht EID sub-prefix, it sets the locator count to 0, and sets the
ACT bits to Send-Map-Request. (This is useful in a number of other
cases, for example, if a sub-block is used for something with very fine
grain RLOCs.)
So I am still missing what needs to be specified.
The text says taht the ETR needs to know about all sub-blocks.
Yours,
Joel
On 6/23/2011 4:24 PM, Alia Atlas wrote:
On Thu, Jun 23, 2011 at 3:46 PM, Joel M. Halpern<[email protected]> wrote:
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.
Sure - I'm not focused on that specific case. What I'm after is the assumption
that an ETR knows the correct locator-set and statuses for a sub-prefix that
has been delegated away... The locator-status bits make sense when the ETRs
are all in the same IGP; if that isn't the case, additional explicit
work is needed.
What would be useful is capturing the assumptions on knowledge and use-cases.
I know the deployment doc is a start of that, but some of this seems
to me to belong
in the protocol docs. What must an ETR know and with what dynamics to advertise
a prefix and what issues come up with holes and delegation?
Is it a deliberate decision that there is no way for an ETR to say for
a hole that it
doesn't know what do with it - which means that if an ITR hit that
entry, it would need
to query...
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
