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.
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
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 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
----------------------------------------------------------------------
|
