Hi, Albert, On Mon, Mar 9, 2015 at 7:15 AM, Albert Cabellos <[email protected]> wrote:
> 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). > Thanks - if I'd seen Instance ID mentioned where this paragraph will appear, I'd have understood what was going on! Spencer > > > 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
