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

[Fabio Maino <[e-mail]>]

On 9/21/18 2:04 AM, Luigi Iannone wrote:
> Hi Fabio,
>
> just one comment on the following sentence (section 1)
>
> LISP-GPE MAY also be used to extend the LISP Data-Plane header, that
>    has allocated all by defining a Next Protocol "shim" header that
>    implements new data plane functions not supported in the LISP header.
>
> Something is missing in this sentence.
>
> May be: LISP-GPE MAY also be used to extend the LISP Data-Plane 
> header, **since
>    all of the reserved bits have been allocated, **  by defining a 
> Next Protocol "shim" header that
>    implements new data plane functions not supported in the LISP header.
> Ciao

Thanks for catching this Luigi. It will be addressed in -07.

Fabio

>
> L.
>
>
>
>> On 21 Sep 2018, at 07:12, Fabio Maino <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> I have incorporated the changes as discussed, so hopefully rev 6. can 
>> be used by reviewers before the telechat: 
>> https://www.ietf.org/id/draft-ietf-lisp-gpe-06.txt
>>
>> Here is the diff: goo.gl/tCKD4A <http://goo.gl/tCKD4A>
>>
>>
>> I believe the following comments are still open. I'll work with the 
>> respective authors to address them in the next rev of the document.
>>
>>
>> A. [Deborah/Magnus] it is being discussed on a separate private 
>> thread if the following should be added to the IANA section:
>> "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."
>>
>>
>> B. [Magnus] draft-ietf-tsvwg-ecn-encap-guidelines has expired 
>> yesterday, and cannot be referenced. I'll add it back to section 3.1 
>> as soon as the draft is refreshed.
>>
>> C. [Magnus/Mirja] in 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.
>>
>> D. [Magnus] 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.
>>
>>
>> Thanks,
>>
>> Fabio
>>
>>
>>
>>
>>
>>
>> On 9/20/18 1:03 PM, Fabio Maino wrote:
>>> 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]
>>>> ----------------------------------------------------------------------
>>>
>>>
>>
>