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
L.
> On 21 Sep 2018, at 07:12, Fabio Maino <[email protected]> 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
> <https://www.ietf.org/id/draft-ietf-lisp-gpe-06.txt>
>
> Here is the diff: 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/
> <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/
>>> <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 CC [email protected] <mailto:[email protected]> 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/
>>>>> <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/
>>>>> <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: [email protected]
>>> <mailto:[email protected]>
>>> ----------------------------------------------------------------------
>>
>
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
