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

From: Fabio Maino <[email-masked]>
Date: Tue, 18 Sep 2018 12:52:56 -0700

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.

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

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.

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 [email-masked]  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.
>
>

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Wed, 19 Sep 2018 21:17:52 +0000

Thanks Magnus for your careful review!

Fabio, on your suggested text below, it is not needed to duplicate this in the IANA section. The IANA section provides guidelines on assignment for IANA, not to future authors - it would not be for IANA to ensure requests for registration provide the proper analysis.

Thanks,
Deborah

From: Fabio Maino <[email-masked]>
Sent: Tuesday, September 18, 2018 3:53 PM
To: Magnus Westerlund <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Tsvart last call review of draft-ietf-lisp-gpe-05

Hi Magnus,

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.

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.

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

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.

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.

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

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

Thanks,
Fabio

Review result: Not Ready

raised.

Please always CC [email-masked]<mailto:[email-masked]> if you reply to or forward this review.

Issue A.

acceptable or not.

B.) 4.2.  Type of Service

   field.

https://datatracker.ietf.org/doc/rfc8325/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_rfc8325_&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=xhv-vipTwtWwg5AcQtMrZCrQA1JAfYXMAgGWqbjj4Aw&s=8gidprIUCfhadFdWi7xlWD0bPsb3dPdfCw9Qf8kdwTI&e=> are relevant in this context.

C. General case of 4.2:

registrations.

D. ECN handling

      header.

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtsvwg-2Decn-2Dencap-2Dguidelines_&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=xhv-vipTwtWwg5AcQtMrZCrQA1JAfYXMAgGWqbjj4Aw&s=eyO4c7D3ShNQhaa8oVDqCidHbEp3mW7AkM51duv8Qw4&e=> Thus,

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Sep 2018 10:14:18 +0200

Hi,

On 9/19/2018 11:17 PM, BRUNGARD, DEBORAH A wrote:
> Fabio, on your suggested text below, it is not needed to duplicate 
> this in the IANA section. The IANA section provides guidelines on 
> assignment for IANA, not to future authors - it would not be for IANA 
> to ensure requests for registration provide the proper analysis.
>

Deborah I am disagreeing about this. The IANA section may contain 
requirements on the registration that further entries are required to 
fulfill. This becomes especially important in expert review registries. 
And in this case as a Standards Action registry, making explicit the 
expectations on new registries from the creators of the registries are 
very appropriate. It helps ensure that future extensions do think about 
important things.

So I would really like to see the text stay in.

Cheers

Magnus

> Thanks,
>
> Deborah
>
> *From:*Fabio Maino <[email-masked]>
> *Sent:* Tuesday, September 18, 2018 3:53 PM
> *To:* Magnus Westerlund <[email-masked]>; [email-masked]
> *Cc:* [email-masked]; [email-masked]; [email-masked]
> *Subject:* Re: Tsvart last call review of draft-ietf-lisp-gpe-05
>
> Hi Magnus,
> 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 
> 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.
>
> 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.
>
> 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].
>
> header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to, or 
> used to determine the LISP Instance ID field.
>
> values MAY be mapped as specified for the Next Protocol encapsulated 
> by NSH (namely IPv4, IPv6 and Ethernet)."
>
>
> 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 always [email-masked]  <mailto:[email-masked]>  if you reply to or forward this review.
>
>     Issue A.
>
>     https://datatracker.ietf.org/doc/rfc8325/  <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_rfc8325_&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=xhv-vipTwtWwg5AcQtMrZCrQA1JAfYXMAgGWqbjj4Aw&s=8gidprIUCfhadFdWi7xlWD0bPsb3dPdfCw9Qf8kdwTI&e=>  are relevant in this context.
>
>     C. General case of 4.2:
>
>     https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/  <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtsvwg-2Decn-2Dencap-2Dguidelines_&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=xhv-vipTwtWwg5AcQtMrZCrQA1JAfYXMAgGWqbjj4Aw&s=eyO4c7D3ShNQhaa8oVDqCidHbEp3mW7AkM51duv8Qw4&e=>  Thus,
>
-- 

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-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Sep 2018 11:39:29 +0200

Hi Fabio,

Most of the below text is excellent. Some comments inline for needed 
clarifications and additions.

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

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

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

-- 

Magnus Westerlund

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 20 Sep 2018 13:15:23 +0000

Hi Magnus,

Interesting – I haven’t seen it in Routing Area documents – the (technical) advice is given in the applicable sections of the RFC itself. Do you have examples from the Transport Area?

Always open to discussion – let’s take to a smaller list among the working group chairs and IANA – and then can get back to the larger list. I would (hopefully) say when the working group chooses to update (or the RFC’s expert reviewer) the registry, they follow their RFC, not just the IANA section. Not to jump on process to rationalize – RFC8126 is quite clear to keep IANA considerations for IANA. If others feel the same, can always update to clarify. Let’s talk more.

Thanks,
Deborah

From: Magnus Westerlund <[email-masked]>
Sent: Thursday, September 20, 2018 4:14 AM
To: BRUNGARD, DEBORAH A <[email-masked]>; Fabio Maino <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Tsvart last call review of draft-ietf-lisp-gpe-05

Hi,

Deborah I am disagreeing about this. The IANA section may contain requirements on the registration that further entries are required to fulfill. This becomes especially important in expert review registries. And in this case as a Standards Action registry, making explicit the expectations on new registries from the creators of the registries are very appropriate. It helps ensure that future extensions do think about important things.

Cheers

Magnus

Thanks,
Deborah

From: Fabio Maino <[email-masked]><mailto:[email-masked]>
Sent: Tuesday, September 18, 2018 3:53 PM
To: Magnus Westerlund <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Tsvart last call review of draft-ietf-lisp-gpe-05

Hi Magnus,

Thanks,
Fabio

Review result: Not Ready

raised.

Issue A.

acceptable or not.

B.) 4.2.  Type of Service

   field.

C. General case of 4.2:

registrations.

D. ECN handling

      header.

--

Magnus Westerlund

SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Sep 2018 17:23:08 +0200

On 9/20/2018 3:15 PM, BRUNGARD, DEBORAH A wrote:
>
> Hi Magnus,
>
> Interesting – I haven’t seen it in Routing Area documents – the 
> (technical) advice is given in the applicable sections of the RFC 
> itself. Do you have examples from the Transport Area?
>

Yes, varying practices between area is not that uncommon. We have done 
this quite common in ART. This is one example of a registry I an the 
designated expert for. Where

https://tools.ietf.org/html/rfc8285#section-10.1

As you can see the IANA section contains fairly detailed review 
consideration for the expert.

Similar rules but less extensive as the need was less in one of the 
RFC's I have co-authored:

https://tools.ietf.org/html/rfc7826#section-22.9

This IANA section was reviewed multiple times by IANA, including a first 
case when the document was finishing up the WG process due to its 
extensive nature (13 new registries, 22 pages). So IANA appears to have 
no issues with this information.

Even if the requirements are not in the IANA section, there need to be 
an explicit reference from the IANA section to the relevant text in the 
document that provides the requirements, otherwise they are easily 
missed in my experience.

> Always open to discussion – let’s take to a smaller list among the 
> working group chairs and IANA – and then can get back to the larger 
> list. I would (hopefully) say when the working group chooses to update 
> (or the RFC’s expert reviewer) the registry, they follow their RFC, 
> not just the IANA section. Not to jump on process to rationalize – 
> RFC8126 is quite clear to keep IANA considerations for IANA. If others 
> feel the same, can always update to clarify. Let’s talk more.
>

Please consider it, my experience is that having known requirements 
easily found and accessible helps a lot and avoid late surprises.

Cheers

Magnus Westerlund

>
> Thanks,
>
> Deborah
>
> *From:*Magnus Westerlund <[email-masked]>
> *Sent:* Thursday, September 20, 2018 4:14 AM
> *To:* BRUNGARD, DEBORAH A <[email-masked]>; Fabio Maino 
> <[email-masked]>; [email-masked]
>     assignment for IANA, not to future authors - it would not be for
>     IANA to ensure requests for registration provide the proper analysis.
>
> fulfill. This becomes especially important in expert review 
> registries. And in this case as a Standards Action registry, making 
> explicit the expectations on new registries from the creators of the 
> registries are very appropriate. It helps ensure that future 
> extensions do think about important things.
>
>     *From:*Fabio Maino <[email-masked]> <mailto:[email-masked]>
>     *To:* Magnus Westerlund <[email-masked]>
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     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.
>
>     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
>     accompanied by an analysis similar to the one performed in Section
>     3.1.1 of this document for Ethernet payloads.
>
>     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-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.
>
>     field as per guidelines provided by [RFC8325].
>
>     header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to,
>     or used to determine the LISP Instance ID field.
>
>     guidelines in section 3.4 of [RFC8085] when it is desirable to
>     protect UDP, LISP, and NSH headers against corruption.
>
>     values MAY be mapped as specified for the Next Protocol
>     encapsulated by NSH (namely IPv4, IPv6 and Ethernet)."
>
>
>     "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."
>
> SE-164 80 Stockholm, Sweden | mailto:[email-masked]  <mailto:[email-masked]>

-- 

Magnus Westerlund

---

From: Fabio Maino <[email-masked]>
Date: Thu, 20 Sep 2018 13:03:51 -0700

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:
>> will introduce two subsections to instantiate those requirements for 
>> 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 
>> protect UDP, LISP and Ethernet headers against corruption.
>
> combination do work. You will actually have to discuss how the 
> Ethernet encapsulation fulfills the requirements listed in Section 4 
> of RFC 6936.
>
> 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.
>
>
>>
> 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.
>
>>
> SE-164 80 Stockholm, Sweden | mailto:[email-masked]

---

From: Fabio Maino <[email-masked]>
Date: Thu, 20 Sep 2018 22:12:41 -0700

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

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

D. [Magnus] 3.1.2 Payload Specific Transport Interactions for NSH 
Encapsulated Payloads

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.
>
>>> "IANA Considerations" section I'll refer to this new section 3.1 as 
>>> a requirement for registration of new encapsulated payload.
>>>
>>> well from a transport interaction perspective, the specification of 
>>> a new encapsulated payload MUST contain an analysis of how LISP-GPE 
>>> field. Such new encapsulated payolads, when registered with 
>>> usage guidelines in section 3.4 of [RFC8085] when it is desirable to 
>> analysis was included. I would also note the applicability 
>> limitations this has.
>>
>> 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.
>>
>>>
>>> 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."
>>>

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 21 Sep 2018 11:04:09 +0200

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-masked]> 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>
> 
> 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:
> 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
> 
> 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. 
> 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 
> 
> Same as for Ethernet also the NSH header needs to have a documented analsysis of fulfillment of the requirements.
> 
> 
> Thanks,
> 
> Fabio
> 
> 
> 
> 
> 
>> 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
>> 
>>> Most of the below text is excellent. Some comments inline for needed clarifications and additions. 
>>> 
>>> 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. 
>>> 
>>>> 
>>> 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. 
>>>> 
>>> Same as for Ethernet also the NSH header needs to have a documented analsysis of fulfillment of the requirements.
>>> 
>>> 
>>>> 
>>>>> Please always CC [email-masked] <mailto:[email-masked]> if you reply to or forward this review.
>>>>> 
>>>>> Issue A.
>>>>> 
>>>>> https://datatracker.ietf.org/doc/rfc8325/ <https://datatracker.ietf.org/doc/rfc8325/> are relevant in this context.
>>>>> 
>>>>> C. General case of 4.2:
>>>>> 
>>>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/ <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/> Thus,
>>> SE-164 80 Stockholm, Sweden | mailto: [email-masked] <mailto:[email-masked]>

---

From: Fabio Maino <[email-masked]>
Date: Fri, 28 Sep 2018 13:35:30 -0700

>    implements new data plane functions not supported in the LISP header.

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

Fabio

>
> L.
>
>
>
>> On 21 Sep 2018, at 07:12, Fabio Maino <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> I have incorporated the changes as discussed, so hopefully rev 6. can 
>> be used by reviewers before the telechat: 
>> Here is the diff: goo.gl/tCKD4A <http://goo.gl/tCKD4A>
>>
>>
>> A. [Deborah/Magnus] it is being discussed on a separate private 
>> thread if the following should be added to the IANA section:
>> 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.
>>
>>>> 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.
>>>>
>>>> certain when having Ethernet. Thus, some consideration of that 
>>>> issue is likely needed.
>>>>
>>>>
>>>>>
>>>> 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