Hi Brian, On 05/28/2013 04:59 PM, Brian Haberman wrote: > 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."
It captures it very well, thank you. [...] >>> 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. That's why we didn't include it, it is still an individual submission. I will mention PCP as a potential alternative, and not mention this draft. > Is there a reason to build *another* protocol to do NAT signaling when > the IETF is standardizing PCP? I wasn't aware of the PCP standardization effort, and I'm not sure if the authors of the draft mentioned above were. I haven't fully read the protocol, I'm not sure if it would cover all the necessities of LISP. draft-ermagan-lisp-nat-traversal was designed for tight integration with LISP. [...] >>> 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. Would s/will/may/ resolve your concern? [...] We will send a diff with all the changes soon. Thanks, -Lori _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
