Hi Thank you very much for your comments, please find below how we plan to address them:
On Wed, Mar 4, 2015 at 7:22 AM, Spencer Dawkins < [email protected]> wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-lisp-introduction-12: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm a Yes because this draft is helpful to the largely uninitiated (that > would include me), but I was consistently encountering questions that > Adrian's Discuss and Comments answered, so I'd encourage you to work > through his Comments, as well as his Discuss. > > Beyond that: > > In this text: > > 3.3.1. LISP Encapsulation > > ITRs encapsulate data packets towards ETRs. LISP data packets are > encapsulated using UDP (port 4341), the source port is usually > selected by the ITR using a 5-tuple hash of the inner header (so to > be consistent in case of multi-path solutions such as ECMP [RFC2992]) > and ignored on reception. > > would you ever use "virtual xTRs" with the same outermost IP addresses? > If not, fine, but if so, would you need to use different destination > ports to disambiguate them? Or does the Instance ID provide enough > isolation to meet this need? > > I ask because adding virtual hosts to HTTP was a drag, so best for me to > ask early! > > Indeed and as you point out InstanceID should provide enough isolation. Please let me know if the following sentence (section 4.1) clarifies your point: The Map-Cache is indexed by (Instance ID, EID-prefix) and contains basically the set of RLOCs with the associated traffic engineering policies (priorities and weights). Further in the same paragraph, in this text: > > A particularity of LISP is that UDP > packets should include a zero checksum [RFC6935] [RFC6936] that it is > not verified in reception, LISP also supports non-zero checksums that > may be verified. This decision was made because the typical > transport protocols used by the applications already include a > checksum, by neglecting the additional UDP encapsulation checksum > xTRs can forward packets more efficiently. > > I'm wobbling between "should include a zero checksum" and "also supports > non-zero checksums". Is that text saying something like this? > > LISP data packets are often encapsulated in UDP packets that > include a zero checksum [RFC6935] [RFC6936] that is not verified > when it is received, because LISP data packets typically include > an inner transport protocol header with a non-zero checksum. By > omitting the additional outer UDP encapsulation checksum, xTRs > can forward packets more efficiently. If LISP data packets are > encapsulated in UDP packets with non-zero checksums, the outer > UDP checksums are verified when the UDP packets are received, as > part of normal UDP processing. > > This is correct, I'll update the paragraph as you suggest, thanks! Albert > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
