Subject: [lisp] Spencer Dawkins' Yes on draft-ietf-lisp-introduction-12: (with COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 03 Mar 2015 22:22:37 -0800

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.

---

From: Albert Cabellos <[email-masked]>
Date: Mon, 9 Mar 2015 13:15:35 +0100

Hi

Thank you very much for your comments, please find below how we plan to
address them:

> http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/
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).

>    part of normal UDP processing.
This is correct, I'll update the paragraph as you suggest, thanks!

Albert

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

---

From: Albert Cabellos <[email-masked]>
Date: Mon, 9 Mar 2015 13:15:35 +0100

Hi

Albert

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 9 Mar 2015 13:37:11 -0500

Hi, Albert,

>    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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 9 Mar 2015 13:37:11 -0500

Hi, Albert,

Spencer