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
