Last Call Review of draft-ietf-lisp-gpe-05
review-ietf-lisp-gpe-05-tsvart-lc-westerlund-2018-08-29-00

Request Review of draft-ietf-lisp-gpe
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2018-09-06
Requested 2018-08-23
Draft last updated 2018-08-29
Completed reviews Rtgdir Last Call review of -04 by Adrian Farrel (diff)
Genart Last Call review of -05 by Stewart Bryant (diff)
Tsvart Last Call review of -05 by Magnus Westerlund (diff)
Secdir Last Call review of -05 by Christopher Wood (diff)
Tsvart Telechat review of -06 by Magnus Westerlund
Assignment Reviewer Magnus Westerlund
State Completed
Review review-ietf-lisp-gpe-05-tsvart-lc-westerlund-2018-08-29
Reviewed rev. 05 (document currently at 06)
Review result Not Ready
Review completed: 2018-08-29

Review
review-ietf-lisp-gpe-05-tsvart-lc-westerlund-2018-08-29

This document has been reviewed as part of the transport area directorate's ongoing
effort to review key IETF documents. These comments were written primarily for
the transport area directors, but are copied to the document's authors and WG for
their information and to allow them to address any issues raised.

When done at the time of IETF Last Call, the authors should consider this
review together with any other last-call comments they receive.
Please always CC tsv-art@ietf.org if you reply to or forward this review.

Issue A. 

The reason I state Not Ready has to do with this documents failure to consider the use of zero checksum for IPv6 when tunneling other things than IP. The none GPE version is limited to tunnel IP for which the analysis for use of zero checksum has been done. Each of the new tunneled protocols that are specified in this document, i.e. ethernet and NHS, will need to perform the analysis if they are safe to use zero checksum or not, and if not disallow zero checksum for IPv6/UDP. The documetn also need a requirement in the registration requirements to perform this analysis and defined if zero checksum is acceptable or not. 

Citing Section 5.3 of draft-ietf-lisp-rfc6830bis

   UDP Checksum:  The 'UDP Checksum' field SHOULD be transmitted as zero
      by an ITR for either IPv4 [RFC0768] and IPv6 encapsulation
      [RFC6935] [RFC6936].  When a packet with a zero UDP checksum is
      received by an ETR, the ETR MUST accept the packet for
      decapsulation.  When an ITR transmits a non-zero value for the UDP
      checksum, it MUST send a correctly computed value in this field.
      When an ETR receives a packet with a non-zero UDP checksum, it MAY
      choose to verify the checksum value.  If it chooses to perform
      such verification, and the verification fails, the packet MUST be
      silently dropped.  If the ETR chooses not to perform the
      verification, or performs the verification successfully, the
      packet MUST be accepted for decapsulation.  The handling of UDP
      zero checksums over IPv6 for all tunneling protocols, including
      LISP, is subject to the applicability statement in [RFC6936].

The issue is that when LISP encapsulate other protocols the impact of a missdelivered tunnel packet to the wrong ETR can have different impacts. As well as errors in the headers of the encapsulated packet that may be assumed to be protected by the encapsulating layer. Thus, individual analysis of each protocol that are tunneled are needed. 

B.) 4.2.  Type of Service

   When a LISP-GPE router performs Ethernet encapsulation, the inner
   802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be
   mapped from the encapsulated frame to the Type of Service field in
   the outer IPv4 header, or in the case of IPv6 the 'Traffic Class'
   field.

Any recommendation about how to perform that mapping? Maybe parts of https://datatracker.ietf.org/doc/rfc8325/ are relevant in this context. 

C. General case of 4.2:

I expect other protocols than Ethernet may have a priority field that may or may not be mapped to the DSCP field of the tunnel packet. 

I would expect that for new protocol registration in the LISP-GPE Next Protocol Registry should consider this. Thus, it would be good to note that such considerations are needed and part of what should be evaluated for new registrations. 

D. ECN handling

Section 5.3 of draft-ietf-lisp-rfc6830bis states:

   o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
      of the IPv6 'Traffic Class' field) requires special treatment in
      order to avoid discarding indications of congestion [RFC3168].
      ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
      header to the outer header.  Re-encapsulation MUST copy the 2-bit
      'ECN' field from the stripped outer header to the new outer
      header.

The above rules may not be applicable for all transport protocols. Thus I think it is required that one do protocol specific considerations of ECN. TSVWG are working on recommendations for tunnels handling of  ECN here, see:  https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/ Thus, my expectation would be to ensure that the registered protocols have defined ECN handling, explicitly or by reference. Secondly that registration requirement states the need for this consideration. 

Summary: To ensure that future added protocols that are encapsulated will work well from a transport interaction perspective there need to be a requirement on new registration to consider and define how they use zero checksum, any DSCP mapping and ECN bits. In addition the current document needs to ensure these things are clearly specified for the encapsulated protocols in this document.