Ah - I had seen the negative Map-Replies - but only in the contexts described on p. 37 of [lisp-13] (and quoted below).
I did not realize that what you are suggested was possible in what is specified. That answers a number of my concerns about the overlapping prefixes - and even seems to be able to address the problem of an EID sub-prefix being given away. If a packet hits that EID sub-prefix and does the Map-Request, when the new Map-Reply is received, presumably it replaces the previous entry for the EID sub-prefix. Later, if the original entries time-out and are refreshed - does that also flush the non-negative sub-prefix entry and replace it with the negative Send-Map-Request entry? I don't think doing so is a problem, but I'm trying to clarify the behavior. Would it be possible to describe this very briefly in the section about prefixes? Something like "The third use is when, due to overlapping prefixes, an ETR needs to convey information about a sub-prefix for which it does not have an accurate locator-set or know their associated statuses. In that case, an ETR could include a record for that sub-prefix with an empty locator-set and specifying an ACT of (2) Send-Map-Request." to go at the end of this paragraph on p. 37: "Map-Reply records can have an empty locator-set. A negative Map- Reply is a Map-Reply with an empty locator-set. Negative Map-Replies convey special actions by the sender to the ITR or PTR which have solicited the Map-Reply. There are two primary applications for Negative Map-Replies. The first is for a Map-Resolver to instruct an ITR or PTR when a destination is for a LISP site versus a non-LISP site. And the other is to source quench Map-Requests which are sent for non-allocated EIDs." Thanks, Alia On Thu, Jun 23, 2011 at 4:52 PM, Joel M. Halpern <[email protected]> wrote: > 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
