Subject: [lisp] draft-ietf-lisp-deployment review

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Dec 2012 21:02:13 -0500

In conjunction with the WG last call on this document, I performed my 
own review.

It appears that the text in section 3.1 on Map Server deployment asserts 
that (for EIDs outside of an allocated IPv6 block) Map Servers will need 
to be run by the RIRs.  I strongly hope this is not the case.  The RIRs 
have not signed up to run this service.  Given that there are already 
existing ways for sites to prove provenance for PI address blocks, some 
other mechanism would seem achievable.

Minor issues:
     I find the characterization of site edge in section 2.1, "can be 
approximated as the the set of DFZ routers belonging to non-transit 
ASes" To be a weak approximation.  It fails basically because the CE and 
PE routers for many sites are either non-BGP speakers, or use default 
routes.  Also, the BGP properties of the site do not seem relevant to 
the LISP deployment issues, so I wonder why they are even mentioned here.

     Should section 2.3 on split ITR/ETR note that in placing the ITRs 
inside the site, the ITRs will still need global RLOCs, and this may add 
complexity to intra-site routing configuration, and further intra-site 
issues when there is a change of providers?

     In the last sentence of section 2.5.1 on ITR behind NAT, cold we 
add an "only"?  The sentence would become "This setup supports only a 
single ITR behind the NAT device."

     Should sections 5.2 and 5.3 on P-ITR deployment note that there are 
likely to be additional costs involved, to be borne by some party, since 
the P-ITR devices under consideration are handling all 
non-LISP-originated traffic for the customer sites?

Yours,
Joel M. Halpern

---

From: Joel Halpern Direct <[email-masked]>
Date: Mon, 17 Dec 2012 11:30:53 -0500

Thank you.
These resolutions look effective to me.
Yours,
Joel

PS: As mentioned for the security document, I would leave the DDT work 
out of this.  We can deal with DDT deployment impact either in the DDT 
document, or in a companion doc when we get that far.

On 12/17/2012 8:11 AM, Lori Jakab wrote:
> Hi Joel,
>
> Thank you for reviewing.  See inline for answers.
>
> On Dec 13, 2012, at 4:02 AM, Joel M. Halpern wrote:
>
>> In conjunction with the WG last call on this document, I performed my own review.
>>
>>
>> It appears that the text in section 3.1 on Map Server deployment asserts that (for EIDs outside of an allocated IPv6 block) Map Servers will need to be run by the RIRs.  I strongly hope this is not the case.  The RIRs have not signed up to run this service.  Given that there are already existing ways for sites to prove provenance for PI address blocks, some other mechanism would seem achievable.
>
> How about this simplified text for the second paragraph of Section 3.1 (removing the bullets)?
>
> "The Map-Server is provided by a Mapping Service Provider (MSP).  The MSP participates in the global distributed mapping database infrastructure, by setting up connections to other participants, according to the specific mapping system that is employed (e.g., ALT, DDT). Participation in the mapping database, and the storing of EID-to-RLOC mapping data is subject to the policies of the "root" operators, who SHOULD check ownership rights for the EID prefixes stored in the database by participants.  These policies are out of the scope of this document."
>
> I didn't enter too much into specifics, because I think mapping system specific deployment description should go into separate documents, and EID allocation was mentioned as candidate for a separate document too.  However, since we seem to move forward on DDT for the global mapping system, should we have a bit more detail about joining the DDT?  What does the WG think?
>
>>
>>
>> Minor issues:
>>     I find the characterization of site edge in section 2.1, "can be approximated as the the set of DFZ routers belonging to non-transit ASes" To be a weak approximation.  It fails basically because the CE and PE routers for many sites are either non-BGP speakers, or use default routes.  Also, the BGP properties of the site do not seem relevant to the LISP deployment issues, so I wonder why they are even mentioned here.
>
> Well, the document was written with the goals of RFC4984 in mind, to reduce the size of the DFZ, so we focused on stub ASes that are BGP speakers.  Would it address your concern if we replaced
>
>     LISP was designed with deployment at the core-edge boundary in mind,
>     which can be approximated as the set of DFZ routers belonging to non-
>     transit ASes.  For the purposes of this document, we will consider
>     this boundary to be consisting of the routers connecting LISP sites
>     to their upstreams.
>
> with
>
>     The first scenario we discuss is customer edge, when xTR functionality
>     is placed on the router(s) that connect the LISP site to its upstream(s),
>     but are under its control.
>
>>
>>     Should section 2.3 on split ITR/ETR note that in placing the ITRs inside the site, the ITRs will still need global RLOCs, and this may add complexity to intra-site routing configuration, and further intra-site issues when there is a change of providers?
>
> Thanks for this suggestion, I think it's valuable information to the reader.  Will include in the next revision.
>
>>
>>     In the last sentence of section 2.5.1 on ITR behind NAT, cold we add an "only"?  The sentence would become "This setup supports only a single ITR behind the NAT device."
>
> Sure.  Will do.
>
>>
>>     Should sections 5.2 and 5.3 on P-ITR deployment note that there are likely to be additional costs involved, to be borne by some party, since the P-ITR devices under consideration are handling all non-LISP-originated traffic for the customer sites?
>
> Here's suggested text for 5.2:
>
>     Routing all non-LISP ingress traffic through a third party which is
>     not one of its ISPs is only feasible for sites with modest amounts of
>     traffic (like those using the IPv6 tunnel broker services today),
>     especially in the first stage of the transition to LISP, with a
>     significant number of legacy sites.
>                                          This is because the handling of
>     said traffic is likely to result in additional costs, which would be
>     passed down to the client.
>                                 When the LISP/non-LISP site
>     ratio becomes high enough, this approach can prove increasingly
>     attractive.
>
> And 5.3:
>
>     The PSP manages a set of distributed P-ITR(s) that will advertise the
>     corresponding EID prefixes through BGP to the DFZ.  These P-ITR(s)
>     will then encapsulate the traffic they receive for those EIDs towards
>     the RLOCs of the LISP site, ensuring their reachability from non-LISP
>     sites.
>             Note that handling non-LISP-originated traffic may incur
>     additional costs for the PSP, which may be passed down to the client.
>
> Thanks,
> -Lori
>
>>
>> Yours,
>> Joel M. Halpern
>

---

From: Lori Jakab <[email-masked]>
Date: Mon, 17 Dec 2012 15:11:45 +0200

Hi Joel,

with

Sure.  Will do.

And 5.3:

Thanks,
-Lori