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!
   
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.


_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp

Reply via email to