> Isn't 153.16.0.0/16 already the de facto ipv4 draft-ietf-lisp-eid-block?
Defacto, but an individual owns it and has been gracious to lend it out. I'm not sure he would agree on global general use. Plus it is only a single /16. Dino > >> -----Original Message----- >> From: Dino Farinacci [mailto:[email protected]] >> Sent: Wednesday, November 07, 2012 10:32 AM >> To: Lori Jakab >> Cc: Paul Vinciguerra; [email protected] >> Subject: Re: [lisp] lisp deployment document >> >> We could request a block of Class B IPv4 prefixes but the working group >> didn't want to do that. >> >> Dino >> >> On Nov 7, 2012, at 7:27 AM, Lori Jakab <[email protected]> wrote: >> >>> On 11/07/12 16:16, Dino Farinacci wrote: >>>> The LISP-only EID-prefix is one use of the draft-ietf-lisp-eid-block draft. >>> >>> Sure, but that's IPv6-only. >>> >>> -Lori >>> >>>> >>>> Dino >>>> >>>> On Nov 7, 2012, at 6:00 AM, Lori Jakab <[email protected]> wrote: >>>> >>>>> Hi Paul, >>>>> >>>>> Thank you for the feedback on the document, it's great having the >>>>> operational community participate. Indeed, the existance of PxTR's >>>>> are making the ping check less meaningful. How about combining the >>>>> ping check with a traceroute? Even if the routers carrying the LISP >>>>> encapsulated packets won't show up on a traceroute, you can see if >>>>> the encapsulation/decapsulation happens at the expected locations >>>>> (xTRs instead of PxTRs) or not. >>>>> >>>>> The LISP-only EID prefix you propose is definitely a good option too. >>>>> But if I understand it correctly, it depends on a third party >>>>> running a known good LISP test site. At the time of writing we >>>>> didn't know of any such service, so it was not included as an possibility. >>>>> >>>>> Regading deployment options, why do you consider the first and >>>>> second one separately? According to the ddt-root.org web site, the >>>>> Beta network is a DDT connected LISP island as well. Sure, it runs >>>>> deeper in the tree, delegating the 153.16/16 further down, but I >>>>> wouldn't look at it as a separate deployment option. >>>>> >>>>> -Lori >>>>> >>>>> On 11/07/12 04:19, Paul Vinciguerra wrote: >>>>>> Jakab, et al. Expires April 23, 2013 [Page 21] >>>>>> >>>>>> Internet-Draft LISP Deployment October 2012 >>>>>> >>>>>> * To verify LISP connectivity, ping LISP connected sites. See >>>>>> >>>>>> http://www.lisp4.net/ and/or http://www.lisp6.net/ for >>>>>> >>>>>> potential candidates. >>>>>> >>>>>> This section seems overly simple. >>>>>> >>>>>> There are three deployment options that I am aware of: >>>>>> >>>>>> *Deployment in the Beta network >>>>>> >>>>>> *Deployment in a separate LISP Island connected via DDT >>>>>> >>>>>> *Deployment in a separate LISP Island not connected via DDT >>>>>> >>>>>> With PxTR's in the mix, pinging LISP sites doesn't assure end-end >>>>>> LISP connectivity. It is our experience that PxTR's just magically >>>>>> make things work, and because of that, it doesn't always flow the >>>>>> way you think it does. >>>>>> >>>>>> There probably needs to be some prefix that doesn't have a coarse >>>>>> aggregate announced into the DFZ for testing end-end LISP >>>>>> connectivity for the first two deployment options listed above. If >>>>>> you're the last deployment case, you're on your own to verify end-end >> LISP connectivity. >>>>>> >>>>>> Paul >>>>>> >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/lisp >>> > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
