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
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
