Hi Lori,
On 5/27/13 1:06 PM, Lori Jakab wrote:
4. Section 2.1
* s/placing tunnel routers are MTU/placing tunnel routers is MTU/
* The sentence that starts "Since encapsulating packets increases..." is
rather convoluted and hard to parse. I would suggest re-wording it.
How about this wording: "Encapsulation may result in a decrease of the
end-to-end path MTU, if encapsulated packets need to travel over links
with MTU lower than 1500 bytes + LISP encapsulation overhead."
I think that is still confusing for the point you are trying to get
across. If encapsulation is used, it reduces the path MTU, period. Does
this text capture your intent?
"Encapsulation increases the amount of overhead associated with each
packet. This added overhead decreases the effective end-to-end path MTU."
* This section references the lisp-eid-block draft (albeit
informatively). Given the current state of that draft, is the
associated text in this draft really needed (or beneficial)?
We don't object to removing the bullet referencing the draft.
If it is removable, I would suggest taking it out.
8. Section 2.5.1
* The discussion of NAT traversal may benefit from some additional text
that points at PCP as an alternative to static hole-punching.
Is it appropriate to reference individual submission drafts, if there
are plans to have them become IETF WG drafts? In that case we could
reference draft-ermagan-lisp-nat-traversal, which offers a complete
solution to NAT traversal. There are already two implementations of
this drafts that I know of.
I would assume that such a reference would be normative, which would
result in this document be held by the RFC Editor until the referenced
document was published. Is there a reason to build *another* protocol
to do NAT signaling when the IETF is standardizing PCP?
9. Section 2.6
* It would be much clearer if there was some supporting text for the
summary matrix. It is rather confusing to understand what the table is
trying to tell the reader.
How about this introductory text?
"The following table gives a quick overview of the features supported by
each of the deployment scenarios discussed above (marked with an "x") in
the appropriate column: "CE" for customer edge, "PE" for provider edge,
"Split" for split ITR/ETR, and "Recursive" for inter-service provider
traffic engineering."
The above seems reasonable.
Should we explain the features themselves in more detail as well?
A clear, concise description of the features would be good.
10. Section 3
* This section seems to be lacking the level of detail provided in
Section 2.*. Are there any issues with deploying Map Servers/Resolvers
behind NATs? In provider (vs. customer) networks?
Section 3 was structured differently, because Map Servers/Resolvers are
not edge devices as tunnel routers, and the LISP protocol was designed
assuming they will not be deployed behind NAT. Not even the NAT
traversal draft mentioned above introduces support for it. We will make
note of this in section 3.
Such a note would be good to avoid confusion.
11. Section 3.1
* It may be useful to provide a reference for ALT and DDT.
* There is an extraneous "SHOULD" in the second paragraph that needs to
be moved to lower-case.
* The next-to-last paragraph mentions "known mapping system specific
best practices". Are these documented anywhere?
What we intended to say here is that Map Server redundancy is out of
scope for this document, because deployments should take advantage of
the existing knowledge about the technology behind the mapping system.
Since ALT is based on BGP, and DDT was inspired from DNS, deployments
can leverage current industry practices for redundancy in BGP and DNS.
I think the above explanation could be tuned and used in the document.
13. Section 5.1
* I would like to see some justification for the statement that the
increase in LISP deployment will reduce the need for BGP-based TE. I
can envision some scenarios where LISP could increase the BGP-based TE
in order to access the "correct" ETR (or P-ETR). Is there some studies
that back up this claim?
I'm not aware of any conclusive study on this subject, that's why we
worded the statement "may lead to a decrease" and explicitly mentioned
the "late transition phase", when most sites use LISP.
But, it does not say "may lead to a decrease", it says "will slowly
decrease the need..." and that sounds like a definitive claim.
14. Section 5.3
* The second paragraph mentions "additional costs for the PSP". I would
like to see some example costs highlighted.
We will remove the last sentence of the second paragraph.
15. Section 5.4
* The table discussing the potential benefits for DFZ route table size
is interesting. But, that is only one metric and one that end-users
probably don't care about. Is there some data on the overall
routing/forwarding performance? For example, v4/v6 tunneling has been
shown to increase RTT (due to inefficient paths). Will LISP have
similar issues? What about the application-level performance due to
decreased message size from encapsulation?
The focus on DFZ routing table size is due to the charter of the LISP
WG, and the direction set by the chairs when writing the document, since
LISP is one of the proposals designed to address RFC 4984.
If that is the case, then the text should say that the only focus was on
DFZ route table size and that other factors were not considered.
The concerns about routing/forwarding and application-level performance
are legitimate. However, the effects of decreased message size from
encapsulation on application-level performance are not specific to LISP,
so we didn't discuss it in detail.
I don't think you have to discuss them in detail, but it would be
worthwhile to say that these other metrics may be impacted, but have not
been measured as of yet.
We don't have data on RTT increase due to LISP migration yet, since
production deployments are still emerging. Maybe a bis document could
be published one more data will be available?
If one is warranted, it is a possibility. Another approach would be for
the academics involved to do those studies and publish them.
16. Section 6
* This whole section seems out of place compared to the rest of the
document. There is no descriptive text introducing the section and
reads more like a vendor's checklist. How does it relate to the rest of
the document?
In order to help xTR deployments, we offered this section as a
step-by-step guide for the operational community. Should we make it an
appendix in this case?
I think it is more suitable as an appendix. Make sure there is some
descriptive lead-in text. That intro should explicitly state that the
appendix is informative in nature.
* Step 4 talks about verifying that local routers do not filter certain
ICMP messages. What about filtering of those ICMP messages by upstream
ISPs?
While it does happen, it is less common that transit ISPs completely
filter those ICMP messages, since they are necessary for traceroute,
which is a valuable tool for the operational community. Of course, if
issues are detected during operation, the appropriate ISP can be
contacted, like for any other issue today.
* Step 5 : s/provivers/providers/
17. Section 6.2
* Are the URLs in step 2 stable? It is generally bad form to include
such URLs in an RFC since they may become stale/obsolete.
They are offered by the LISP pilot network, and are intended to be kept
stable. However, we don't object to removing that sentence.
The trade-off here is that the use of URLs is discouraged by the RFC
Editor (https://www.rfc-editor.org/policy.html#policy.urls). The
authors need to determine if the inclusion of a reference is beneficial
enough to the document that they are willing to argue for its inclusion.
Regards,
Brian
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
