On 5/30/13 9:30 AM, Lori Jakab wrote:
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.
Ok.
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.
I have yet to review that individual draft, but it is possible they are
re-inventing the wheel (STUN, PCP, UPnP, etc.).
[...]
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?
How about "may decrease the need"? That way, you don't have to leave
the reader wondering about the speed of the possible reduction.
Regards,
Brian
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
