> On 11/07/12 17:42, Dino Farinacci wrote: >>> 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. > > ...and is advertized in BGP, so it's not EID-only and the PxTR problem > is still there, unless it is broken up into smaller prefixes (which is > probably not what we want).
But it will always be injected in underlying BGP because you need non-LISP sites to talk to this destination prefix. The point is that this prefix is not used as a locator (i.e. it is not the outer address of any LISP encapsulated packet). Dino > > -Lori > >> >> 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
