As I think Geof pointed out, if we increase the length to /32 we can use existing allocation policies for experimentation.
-Darrel On Nov 3, 2013, at 3:10 PM, Joel M. Halpern <[email protected]> wrote: > I believe (although I do not know for certain) that if we increase the length > as suggested we will have a much easier time getting a block to experiment > with. > > Yours, > Joel > > On 11/3/13 5:30 PM, Luigi Iannone wrote: >> Hi, >> >> I agree with Dino, >> >> if the issue is just the size let’s reduce it and do some experiments. >> >> On the other hand, I do not understand we people here are trying to reach a >> binary conclusion like “EID Block is important and useful” or “EID Block is >> useless” even before doing any experimentation. >> >> IMHO this is not the most logical order. We should first experiment, then we >> will have to know-how to make a decision. >> >> Exactly because there are different and opposite opinions let’s the >> technology itself, through experimentation, make the decision. >> >> Luigi >> >> >> On 2 Nov. 2013, at 11:09 , Dino Farinacci <[email protected]> wrote: >> >>> So it appears that: >>> >>> (1) People are all for experimenting. >>> (2) People may be all for allocating a block if it is not too large. >>> >>> So would it be easier to swallow if we just request a /32 or smaller block. >>> >>> Are we just arguing over size? >>> >>> If the experiment proves we need to do something in production, then we go >>> get larger blocks as Joel indicates. And if the experiment is complete and >>> say we don't need a well-known block, we return the /32. >>> >>> Dino >>> >>> On Nov 2, 2013, at 10:44 AM, Joel M. Halpern <[email protected]> wrote: >>> >>>> On the source side, the ITR had better know what EIDs it is working on >>>> behalf of (otherwise, it is a source for spoofed source address). So none >>>> of those cases seem to be affected by the allocation or non-allocation of >>>> a block. >>>> >>>> If we are going to do anything based on a block, we better make sure it >>>> can handle more than one block. Which means that at most we need a block >>>> for the duration of the test period. We do not need a block for the hoped >>>> for full success of LISP. If we really succeed, we can get an additional >>>> bigger block. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 11/1/13 10:33 AM, Dino Farinacci wrote: >>>>>> I understand the importance of experimenting. But I am having >>>>>> trouble getting my head around the possible value we want to >>>>>> explore. Color me naive and stubborn, but individually so. >>>>>> >>>>>> Thinking about the ITR code path, if there is no block: >>>>> >>>>> Many are thinking in this context. It is one but there are other >>>>> things WE COULD DO if we new a prefix was an EID. See below for some >>>>> rough examples. And please don't ask for detail, because this is >>>>> initial thinking. >>>>> >>>>>> Receive packet check cache for destination failing cache match, >>>>>> query for destination. >>>>> >>>>> And there could be a failed match if the destination address was not >>>>> an EID. Meaning this packet is coming to an ITR destined for a >>>>> non-LISP site (regardless if the source address is an EID or not). So >>>>> the ITR would have to query the mapping database. >>>>> >>>>> So let's break this down. If the source was an EID, one could say, >>>>> "okay since I'm doing the new stuff the delay for a lookup to a >>>>> non-LISP destination is the price I pay for getting multihoming for >>>>> packets that come back to me". If the source was not an EID, then the >>>>> old user that expects to go to a non-LISP site expects the packet >>>>> loss or optimal routing path to continue. And if it does not, then >>>>> the new service hurt existing users. >>>>> >>>>> Please note, this is when a site is bifurcated being a site that has >>>>> some partial EID allocations and partial hosts that have not changed. >>>>> And that either could send to EID or non-EID destinations. >>>>> >>>>> Yes, you could have a default PETR configured in the ITR so there is >>>>> 0 packet loss, but then you may get a suboptimal path. And packets >>>>> from a non-EID source to a non-EID destination could be inadvertently >>>>> encapsulated to the PETR. Then the PETR would decap and deliver the >>>>> packet based on a BGP path. >>>>> >>>>> I for one, would like to solve this problem. And I do not know if >>>>> just a well-known, hard-coded, EID-block will do it. >>>>> >>>>>> And the ITR code path if there is a block: Receive packet check >>>>>> cache for destiantion failing cache match, check for destination in >>>>>> EID block If in EID block, query If not in EID block, query >>>>> >>>>> You are correct, but this box could be configured in way where the >>>>> logic could change: >>>>> >>>>> Receive packet If EID-block strict configured If destination in >>>>> EID-block, send query Else forward natively Else <do what Joel said >>>>> above with no EID-block check> Endif >>>>> >>>>>> Now, if everything is in the EID block, I understand that the last >>>>>> step above becomes "just send". But that appears to be a >>>>>> counter-factual assumption. >>>>>> >>>>>> Yours, Joel >>>>> >>>>> Having an EID block could help us in these scenarios as well: >>>>> >>>>> (1) The block or any more specifics should not have a native-forward >>>>> action in a Map-Reply returned by the mapping system. (2) The block >>>>> or any more specifics should not be injected into BGP without a >>>>> special community indicating that only PITRs should be advertising >>>>> it. (3) If a destination that a NAT box receives has a source in this >>>>> block, that translation should not be done (because it is not >>>>> needed). (4) If the source is in this block we know we cannot build >>>>> RPF trees in the core when the source sends multicast packets. (5) >>>>> Maybe a special EID-block should indicate that this source host can >>>>> only talk IPv6 and that stretched layer-2 subnets are prohibited. So >>>>> if you hit a box that does VXLAN and LISP, that layer 3 LISP is used >>>>> and we don't move MAC frames across the underly and we certainly do >>>>> not forward ARP packet, broadcast frames, and link-local multicast. >>>>> >>>>> Now all these things can be put in the mapping database, and give us >>>>> the same answers but if we could keep load off the mapping database, >>>>> this would be a good thing, a scalability feature. >>>>> >>>>> Dino >>>>> >>>>>> >>>>>> On 10/31/13 7:19 PM, Dino Farinacci wrote: >>>>>>>> >>>>>>>> Actually, that use case is only helped by the EID block if you >>>>>>>> can be sure that ALL the destination EIDs it will see will come >>>>>>>> from the block. >>>>>>> >>>>>>> I don't believe so. It could just an efficiency play for one >>>>>>> versus the other. >>>>>>> >>>>>>>> Which seems to be impossible to ensure in the general case. >>>>>>>> And easy to achieve without an allocated block in many of the >>>>>>>> special cases. >>>>>>> >>>>>>> Well the EID could mean it is behind a NAT and that ITRs should >>>>>>> encapsulate to an RTR. Maybe one that is used by a default >>>>>>> map-cache entry or a distinguished key on the mapping database. >>>>>>> >>>>>>> See there are sorts of things we could try. Again, "try" here >>>>>>> means experimentation. >>>>>>> >>>>>>> Look how the pilot network was easier to debug since we had >>>>>>> 153.16.0.0/16 generically donated by Andrew Partan and how cisco >>>>>>> has been renting 2610:d0::/32. >>>>>>> >>>>>>> Dino >>>>>>> >>>>>> _______________________________________________ lisp mailing list >>>>>> [email protected] https://www.ietf.org/mailman/listinfo/lisp >>>>> >>>>> >>> >>> _______________________________________________ >>> lisp mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lisp >> >> > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
