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
