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