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

[Fabio Maino <[e-mail]>]

Thanks Magnus,
I'll consolidate the changes we have agreed so far in the next rev that 
I plan to publish later today.

I'll then work on the comments on this email and will send you the 
corresponding actions.

Fabio

On 9/20/18 2:39 AM, Magnus Westerlund wrote:
>
> Hi Fabio,
>
> Most of the below text is excellent. Some comments inline for needed 
> clarifications and additions.
>
> On 9/18/2018 9:52 PM, Fabio Maino wrote:
>> 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.
>
> So this is not the necessary documentation of the analysis that 
> IP/UDP(with zero checksum)/LISP(with GPE)/Ethernet is a safe to use. 
> There needs to be an analysis here to verify that this protocol 
> combination do work. You will actually have to discuss how the 
> Ethernet encapsulation fulfills the requirements listed in Section 4 
> of RFC 6936.
>
> https://datatracker.ietf.org/doc/rfc7510/ is an example where such an 
> analysis was included. I would also note the applicability limitations 
> this has.
>
> Which actually brings up an additional issue for Ethernet 
> encapsulation. For IP the assumption is that the IP traffic that is 
> encapsulated is congestion controlled. This assumption is even less 
> certain when having Ethernet. Thus, some consideration of that issue 
> is likely needed.
>
>
>>
>> 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].
>
> I don't know enough about IEEE and the various versions of Ethernet 
> and WLAN here to be certain that 802.1Q PCP's can be mapped directly 
> to the 802.11 User Priorities discussed in RFC8325. Please investigate 
> if they are the same, and if they are the same priorities, then make a 
> explicit statement that they are applicable.
>
>>
>> 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.
>
> Same as for Ethernet also the NSH header needs to have a documented 
> analsysis of fulfillment of the requirements.
>
>
>>
>> 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 [e-mail]  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  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto:[e-mail]
> ----------------------------------------------------------------------