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). -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
