Re: Tsvart last call review of draft-ietf-lisp-gpe-05

Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx> · Thu, 20 Sep 2018 10:14:18 +0200



    Hi,
    On 9/19/2018 11:17 PM, BRUNGARD,
      DEBORAH A wrote:

    
        Thanks
            Magnus for your careful review!
         
        Fabio, on
            your suggested text below, it is not needed to duplicate
            this in the IANA section. The IANA section provides
            guidelines on assignment for IANA, not to future authors -
            it would not be for IANA to ensure requests for registration
            provide the proper analysis.
      
    
    Deborah I am disagreeing about this. The IANA section may contain
      requirements on the registration that further entries are required
      to fulfill. This becomes especially important in expert review
      registries. And in this case as a Standards Action registry,
      making explicit the expectations on new registries from the
      creators of the registries are very appropriate. It helps ensure
      that future extensions do think about important things. 

    
    So I would really like to see the text stay in. 

    
    Cheers
    Magnus

    
        Thanks,
        Deborah
         
         
            From: Fabio Maino
                <fmaino@xxxxxxxxx>
                

                Sent: Tuesday, September 18, 2018 3:53 PM

                To: Magnus Westerlund
                <magnus.westerlund@xxxxxxxxxxxx>; tsv-art@xxxxxxxx

                Cc: lisp@xxxxxxxx; ietf@xxxxxxxx;
                draft-ietf-lisp-gpe.all@xxxxxxxx

                Subject: Re: Tsvart last call review of
                draft-ietf-lisp-gpe-05
          
        
          Hi Magnus, 

            thanks for your comments. 

            
            I think I see the points you are making. 

            
            I'll add the section 3.1 below to specify the general
            transport requirements for the registration of new LISP-GPE
            payloads, and I will introduce two subsections to
            instantiate those requirements for Ethernet and NSH (section
            4.2 and 4.3 will be moved here). In the "IANA
            Considerations" section I'll refer to this new section 3.1
            as a requirement for registration of new encapsulated
            payload.
            

            "3.1 Payload Specific Transport Interactions

            
            To ensure that protocols that are encapsulated in LISP-GPE
            will work well from a transport interaction perspective, the
            specification of a new encapsulated payload MUST contain an
            analysis of how LISP-GPE SHOULD deal with outer UDP
            Checksum, DSCP mapping, and Explicit Congestion Notification
            (ECN) bits whenever they apply to the new encapsulated
            payload.

            
            For IP payloads, section 5.3 of [draft-ietf-lisp-rfc6830bis]
            specifies how to handle UDP Checksums encouraging
            implementors to consider UDP checksum usage guidelines in
            section 3.4 of [RFC8085] when it is desirable to protect UDP
            and LISP headers against corruption. Each new encapsulated
            payloads, when registered with LISP-GPE, MUST be accompanied
            by a similar analysis.

            
            Encapsulated payloads may have a priority field that may or
            may not be mapped to the DSCP field of the outer IP header
            (part of Type of Service in IPv4 or Traffic Class in IPv6).
            Such new encapsulated payloads, when registered with
            LISP-GPE, MUST be accompanied by an analysis similar to the
            one performed in Section 3.1.1 of this document for Ethernet
            payloads.
            

            Encapsulated payloads may have Explicit Congestion
            Notification mechanisms that may or may not be mapped to the
            outer IP header ECN field. Such new encapsulated payolads,
            when registered with LISP-GPE, MUST  be accompanied by a set
            of guidelines derived from
            [draft-ietf-tsvwg-ecn-encap-guidelines] and [RFC6040]. 

            
            The rest of this section specifies payload specific
            transport interactions considerations for the two new
            LISP-GPE encapsulated payloads specified in this document:
            Ethernet and NSH.
            

            3.1.1 Payload Specific Transport Interactions for Ethernet
            Encapsulated Payloads

            
            The UDP Checksum considerations specified in section 5.3 of
            [draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated
            Payloads. Implementors are encouraged to consider the UDP
            checksum usage guidelines in section 3.4 of [RFC8085] when
            it is desirable to protect UDP, LISP and Ethernet headers
            against corruption.

            
            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 as per guidelines provided by
            [RFC8325].

            
            When a LISP-GPE router performs Ethernet encapsulation, the
            inner header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be
            mapped to, or used to determine the LISP Instance ID field.

            
            3.1.2 Payload Specific Transport Interactions for NSH
            Encapsulated Payloads 

            
            The UDP Checksum considerations specified in section 5.3 of
            [draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated
            Payloads. Implementors are encouraged to consider the UDP
            checksum usage guidelines in section 3.4 of [RFC8085] when
            it is desirable to protect UDP, LISP, and NSH headers
            against corruption.

            
            When a LISP-GPE router performs an NSH encapsulation, DSCP
            and ECN values MAY be mapped as specified for the Next
            Protocol encapsulated by NSH (namely IPv4, IPv6 and
            Ethernet)." 
            

            I will also add a paragraph to "Iana Considerations" that
            says: 

            
            "To ensure that protocols that are encapsulated in LISP-GPE
            will work well from a transport interaction perspective, the
            registration of a new encapsulated payload MUST contain an
            analysis of how LISP-GPE SHOULD deal with outer UDP
            Checksum, DSCP mapping, and Explicit Congestion Notification
            (ECN) bits whenever they apply to the new encapsulated
            payload. The analysis for the new encapsulated payload
            registered in this document is in section 3.1."

            
            Please, let me know if this address your comments. 

            
            Thanks,

            Fabio

            
            On 8/29/18 2:17 AM, Magnus Westerlund wrote:
        
        
          Reviewer: Magnus Westerlund
          Review result: Not Ready
           
          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@xxxxxxxx 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.
           
           
    -- 

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx
----------------------------------------------------------------------
  

<<attachment: smime.p7s>>