Subject: [lisp] Mirja Kühlewind's Discuss on draft-ietf-lisp-rfc6830bis-16: (with DISCUSS and COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 11 Sep 2018 08:17:36 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-lisp-rfc6830bis-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have a couple of smaller discuss points with should be straight-forward to
address and one more high-level discussion point that might not have a solution
(depending on the deployment status of LISP I guess) but I would like to at
least have a discussion. I start with the straight-forward onces:

1) Unfortunately ECN decapsulation is slightly more complicated than described
in section 5.3. Please check section 3.2 in rfc6040 and revise accordingly
(maybe also provide a pointer to rfc6040 instead or in addition to rfc3168)!
(Also it seems like the text on ECN is simply just twice in sec 5.3; not sure
that is helpful).

2) Further, also in sec 5.3:
"The inner-header 'Differentiated Services Code Point' (DSCP) field
      (or the 'Traffic Class' field, in the case of IPv6) SHOULD be
      copied from the outer-header DSCP field ('Traffic Class' field, in
      the case of IPv6) considering the exception listed below."
However, I didn't find any exceptions listed later in the doc. However, setting
the DSCP field might also be matter of local policy. E.g. if DSCP is not used
for a different purpose in the receiver side LISP network, it could make sense
to restore/keep the original value in the inner header.

3) Sec 7.1. only takes about ICMPv6 "Packet Too Big" packets while
"IPv4-encapsulated packet with the DF bit set to 1" should be addressed as well.

4) I would like to see another sentence in section 12 explicitly stating that
the source port SHOULD be the same for all packet belong to the same flow.

5) Sec 5.3 says "Both N- and V-bits MUST NOT be set in the same packet."
What happens if both bits are set? The 'Nonce/Map-Version' is just ignored, or
maybe the packet should be dropped or something? Please clarify in the doc!

6) And now the more-discussion-needed point:
So my underlying concern is the same as brought up by the TSV-ART review that
lisp information are not end-to-end integrity protected or authenticated.
However, while briefly thinking about how this could be eventually realized, I
noticed that there is actually no mechanism to extend the LISP header in any
way. There is no version, no option and the LISP header seems to have a fixed,
implicitly specified length without an explicit length field. This seems too
late to add any kind of extensibility mechanism at this stage of the protocols
lifetime, however, I would still like to discuss if there was any discussion
about extensibility, what was the reason to chose this approach, and potential
if some background about the choice should be given in the doc.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1) In sec 7.1 I would recommend to provide a pointer to RFC4459 and align the
language to more what RFC4459 recommends: OLD "This behavior is performed by
the ITR when the source host originates
   a packet with the 'DF' field of the IP header set to 0."
MAYBE:
"This behavior MAY be performed by the ITR only when the source host originates
   a packet with the 'DF' field of the IP header set to 0.

2) Sec 4: "...this document recommends that a maximum of two
   LISP headers can be prepended to a packet."
MAYBE:
"it is RECOMMENDED that a maximum of two
   LISP headers can be prepended to a packet."
?

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 11 Sep 2018 08:59:53 -0700

> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/

Thanks for your comments Mirja.

Well it doesn’t have to be. I am a bit hesitant to just point to another long complicated RFC. This text has gone through review for quite a long time and many ECN experts decided we should write it this way. And this text did go through IESG review when RFC6830 was made experimental RFC.

> to restore/keep the original value in the inner header.

This is a dangling reference where the “text below” was removed or reworded. So I will remove this reference.

> "IPv4-encapsulated packet with the DF bit set to 1" should be addressed as well.

This is discussed in length. I don’t know how you could have missed this.

> the source port SHOULD be the same for all packet belong to the same flow.

Done.

> maybe the packet should be dropped or something? Please clarify in the doc!

If they are both set, there is text in the docuemnt that already says:

          <t hangText="N:">The N-bit is the nonce-present bit. When             
          this bit is set to 1, the low-order 24 bits of the first 32           
          bits of the LISP header contain a Nonce. See <xref
          target="echo-nonce"/> for details. Both N- and V-bits MUST            
          NOT be set in the same packet. If they are, a decapsulating           
          ETR MUST treat the 'Nonce/Map-Version' field as having a              
          Nonce value present.</t>

> lisp information are not end-to-end integrity protected or authenticated.

I would like you to be more specific. Beacuse there is a lot of security in the protocol and we believe the current drafts, in their entirety, inicdate so.

> noticed that there is actually no mechanism to extend the LISP header in any

Right, by design so it is efficient for hardware AND software forwarding. But we do have the LISP-GPE header that can be used for extensions. But that has limited deployment.

> way. There is no version, no option and the LISP header seems to have a fixed,

We decdied as a working group that the UDP port number would indicate what header follows and therefore what LISP version is used.

> implicitly specified length without an explicit length field. This seems too

That is right, the header is 8 bytes, fixed, by design.

> if some background about the choice should be given in the doc.

Well the original authors didn’t believe in having a lot of options in protocols, otherwise it will cause more un-interoperability. But has time has gone on, I believe we made the right choices, and have discovered that LISP is quite extensible, and even 10 years after the the original design, we can continue to add more LISP use-cases with the same basic protocol.

Changed. Thanks for the suggestion.

>   LISP headers can be prepended to a packet.”

Changed.

Thanks again,
Dino

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 11 Sep 2018 18:28:17 +0200

Hi Dino,

please see below.

> Am 11.09.2018 um 17:59 schrieb Dino Farinacci <[email-masked]>:
> 

Procedere explained in RFC6040 are actually not that complicated. It’s mainly the table provided in section 3.2. Please have a look at the draft. However, I disagree that it „negative“ to point for this part to another RFC. This is not a unique problem, that’s why we have RFC6040 and all approaches that face this problem should point to RFC6040 and implement the same strategy.

However, if you look at RFC6040 you see that the main problem is that if the inner codepoint is Not-ECT, you should just not copy the codepoint, which make sense because that probably means that ECN is not supported by the endpoints. Respectively, packets marked with CE should be drop to preserve the congestion signal. This is pretty straight-forward and should be clear. 

I don’t know how this could have been missed with RFC6830 but that seems to indicate it did not have each review for this aspect and we really need to fix that at least now.

> This is a dangling reference where the “text below” was removed or reworded. So I will remove this reference.

Okay, that makes sense. I still don’t think that always just copying is the right approach as I applied above. I would like to see further text here.

> This is discussed in length. I don’t know how you could have missed this.

I didn't miss that discussion but the text got fixed incorrectly because it doesn’t not address IPv4 through the whole text. Please have a look and fix that as well. I think this is mainly an editorial issue but and important one to fix.
>          ETR MUST treat the 'Nonce/Map-Version' field as having a              

Okay, sorry, I actually missed that. That’s fine. Thanks!

> I would like you to be more specific. Beacuse there is a lot of security in the protocol and we believe the current drafts, in their entirety, inicdate so.

I was thinking about the option to add an authenticated hash, anyway...
> We decdied as a working group that the UDP port number would indicate what header follows and therefore what LISP version is used.

Okay, that needs to be explained in the doc!

Mirja

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 11 Sep 2018 09:45:59 -0700

> Procedere explained in RFC6040 are actually not that complicated. It’s mainly the table provided in section 3.2. Please have a look at the draft. However, I disagree that it „negative“ to point for…

I am just worried it will be ignored because there are implementations out there that do what they already do. If we want to suggest to consider the procedures in RFC6040, I am okay with that, but you need to provide the wording because I certainly don’t want it too strong.

> I didn't miss that discussion but the text got fixed incorrectly because it doesn’t not address IPv4 through the whole text. Please have a look and fix that as well. I think this is mainly an edito…

I am sorry. I don’t know what you think is wrong. Please point to the text specifically.

> I was thinking about the option to add an authenticated hash, anyway…

LISP uses lisp-crypto (RFC8061) which uses AEAD.

> Okay, that needs to be explained in the doc!

The document says that UDP port 4341 is assigned and when so, the LISP header as docmented is used. We shouldn’t just encourage versioning if the philosophy it not to churn often.

Dino

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 12 Sep 2018 12:17:33 +0200

Hi again,

please see below.

> Am 11.09.2018 um 18:45 schrieb Dino Farinacci <[email-masked]>:
> 
> 

Actually the behavior as currently described in the lisp draft is not even complainant with rfc3138, however, rfc3168 is updated by rfc6040. The encapsulation in the lisp draft behavior is already what RFC6040 described; so that’s good. However, the decapsulation is neither what RFC3168 nor rfc6040 says. Therefore this must be fixed and I guess a bis doc is also the best chance we get to fix these incorrect implementation then. If you are worried that this will be ignored, you should mention it explicitly in section 18 (Changes since RFC 6830).

There is no matter about the wording being too strong or whatever, RFC6040 is very clear about the correct behavior and that is exactly what needs to be implemented. Please go ahead and read RFC6040. If you need further help, please ask an ECN expert for help, e.g. Bob Briscoe who is the author of RFC6040.

Please note that I actually pointer to a wrong section in RFC6040 above. It should of course be 4.2 (and not 3.2).

> I am sorry. I don’t know what you think is wrong. Please point to the text specifically.

Sec 7.2:
"   2.  When an IPv6-encapsulated packet, or an IPv4-encapsulated packet
       with the DF bit set to 1, exceeds what the core network can
       deliver, one of the intermediate routers on the path will send an
       ICMPv6 "Packet Too Big" message to the ITR.  The ITR will parse
       ^^^^^^^^^^^^^^^^^^^^^^
      there will be no ICMPv6 message is the packet was IPv4

       the ICMPv6 message to determine which Locator is affected by the
       effective MTU change and then record the new effective MTU value
       in the Map-Cache entry.

   3.  When a packet is received by the ITR from a source inside of the
       site and the size of the packet is greater than the effective MTU
       stored with the Map-Cache entry associated with the destination
       EID the packet is for, the ITR will send an ICMPv6 "Packet Too
                                                   ^^^^^^^^^^^^^^^^^^^

       Big" message back to the source.  The packet size advertised by
       the ITR in the ICMPv6 message is the effective MTU minus the LISP
       encapsulation length."
> LISP uses lisp-crypto (RFC8061) which uses AEAD.

I think the pity here is that RFC8061 is still a separate optional RFC. I would have expected to have this integrated into rfc6830bis and make it mandatory to implement if not mandatory to use.

> The document says that UDP port 4341 is assigned and when so, the LISP header as docmented is used. We shouldn’t just encourage versioning if the philosophy it not to churn often.

Okay, that is actually not possible based on the recommendation in RFC6335:

"   o  IANA strives to assign only one assigned port number for all
      variants of a service (e.g., for updated versions of a service).“

That means it is not possible to get another port number for a new version of lisp. You need a different version approach.

Mirja

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 12 Sep 2018 14:30:40 -0700

> please see below.

Thanks for the ongoing discussion Mirja. See a new diff file enclosed as a proposed -18 update. Let me know if the text I added to address your comments are sufficient.

I believe (but could be wrong) that this should be the last set of comments to 6830bis. But I have not seen any acks from Alvaro if we addressed all his comments (specifically for 6830bis).

> Actually the behavior as currently described in the lisp draft is not even complainant with rfc3138, however, rfc3168 is updated by rfc6040. The encapsulation in the lisp draft behavior is already…

The working group made this decsision back in 2009 when the LISP WG was formed. Actually earlier when we did the initial work in the IRTF RRG. RFC3168 was published in Sep 2001. But note one of the authors, David Black, offered the text you see in the document rewgarding ECN handling.

So by doing this update, we ARE going to create a implementation incompatibility.

> There is no matter about the wording being too strong or whatever, RFC6040 is very clear about the correct behavior and that is exactly what needs to be implemented. Please go ahead and read RFC604…

Check the diff file to see if you are okay with the new text added. It WAS NOT simple because there are a number of cases that need to be described that doesn’t contradict RFC6040 that I do not want to repeat.

> Please note that I actually pointer to a wrong section in RFC6040 above. It should of course be 4.2 (and not 3.2).

Okay, that makes more sense now. I was confused.
 
>       encapsulation length.”

This is now fixed. I now understand your comment. Please check the diff file enclosed.

> I think the pity here is that RFC8061 is still a separate optional RFC. I would have expected to have this integrated into rfc6830bis and make it mandatory to implement if not mandatory to use.

Agree. I don’t know what to tell you. But as you might now, there is a tradeoff between privacy and monitoring/lawful intercept that is being made and we know there are strong camps on each side.

You might have heard me say it at a recent IETF plenary “everything should be encrypted, period”. So you know what camp I’m in.  ;-)

> That means it is not possible to get another port number for a new version of lisp. You need a different version approach.

The working group made this decsision back in 2009 when the LISP WG was formed. Actually earlier when we did the initial work in the IRTF RRG. RFC3168 was published in Aug 2011.

LISP-GPE is a variant of the the LISP data-plane, and it is using the same UDP port 4341. So we actually accomplished the reuse.

Dino

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 17 Sep 2018 18:15:42 +0200

Hi Dino,

unfortunately, I don’t think this is quite there yet. First of all, I have to say that I misread the original text which already says that only the CE should be copied which is at least mostly inline with RFC6040 already. However, I really would like the existing text to be clearer here (instead of just adding additional text).

Also you still need at least one reference to rfc3168 because that’s the spec that defines the mechanism and IP bits.

Let me propose something:

For encapsulation:
OLD
"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.“
PROPOSED
"The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
      of the IPv6 'Traffic Class' field) [RFC3168] requires special treatment in
      order to preserve the use of ECN on the path.
      ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
      header to the outer header, inline with the ’Normal Mode’ in section 4.1 
      of [RFC6040].  Re-encapsulation SHOULD follow the decapsulation as described 
      below and then 2-bit 'ECN' field from the stripped inner header to the 
      new outer header.“

For decapsulation:
OLD
"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].  If
      the 'ECN' field contains a congestion indication codepoint (the
      value is '11', the Congestion Experienced (CE) codepoint), then
      ETR decapsulation MUST copy the 2-bit 'ECN' field from the
      stripped outer header to the surviving inner header that is used
      to forward the packet beyond the ETR.  These requirements preserve
      CE indications when a packet that uses ECN traverses a LISP tunnel
      and becomes marked with a CE indication due to congestion between
      the tunnel endpoints.“
PROPOSED
"The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
      of the IPv6 'Traffic Class' field) requires special treatment on 
      decapsulation in
      order to avoid discarding indications of congestion, 
      inline with section 4.2 of [RFC6040]. If
      the 'ECN‘ field of the outer header contains a congestion indication 	
      codepoint (the
      value is '11', the Congestion Experienced (CE) codepoint) and the inner 
      header indicates ECN support (either ECT(0) or ECT(1) codepoint is set), 
      then ETR decapsulation MUST also set CE field in the inner header that is 
      used
      to forward the packet beyond the ETR. If the inner packet is marked as non-
      ECT but the outer header has the CE mark set, the packet MUST be dropped 
      instead. Any discrepancy between the inner and outer header for non-ECT, 
      ECT(0) and ECT(1) MUST NOT be copied from the outer header. These 
      requirements preserve
      CE indications when a packet that is ECN-capable traverses a LISP tunnel
      and becomes marked with a CE indication due to congestion between
      the tunnel endpoints or transforms an CE into loss if that packet is not 
      ECN-capable conserving the congestion indication towards a non-ECN enables 
      endpoint."

Please also remove the duplicated text after these bullet lists in the draft!

Further I believe my discuss points 2) and 4) are not fully resolved yet. Also I would like to at least see more explanation about the approach for extensibility that was taken in this doc (point 6).

Mirja

> Am 12.09.2018 um 23:30 schrieb Dino Farinacci <[email-masked]>:
> 
>> Hi again,
>> 
>> please see below.
> 
> <rfcdiff-6830bis.html>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 17 Sep 2018 10:48:11 -0700

>      below and then 2-bit 'ECN' field from the stripped inner header to the 

I did not include this text because the last sentence is not formed well. Please restate. A verb is missing.

>      endpoint.”

I didn’t include this text because (1) it under states what to do with IPv4, (2) it has too much detail that is already in RFC6040, and (3) it undoes text that other reviewers have offered.

> Please also remove the duplicated text after these bullet lists in the draft!

You have to tell me what text. I am too confused at this point on what you want.

> Further I believe my discuss points 2) and 4) are not fully resolved yet. Also I would like to at least see more explanation about the approach for extensibility that was taken in this doc (point 6…

You are going to have to repeat what they are because too many emails have flown by since your initial post. And for extensibility, we discuss it in RFC8060 and don’t think anything more should be said here otherwise, we will duplicate unnecessary text.

Another new diff file enclosed.

Dino

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 18 Sep 2018 10:14:52 +0200

Dino, Mirja,

a couple of comments inline.

Thanks 

> On 17 Sep 2018, at 18:15, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> 
> Hi Dino,
> 

@Mirja: As Dino pointed out the last sentence is unclear.

>      to forward the packet beyond the ETR.

@Mirja: So far so good. Is the equivalent of what is already there.

> If the inner packet is marked as non-
>      instead.

@ Mirja: How can this happen? As for your text we MUST copy inner CE to outer CE when encapsulating, so if the original packet does not support ECN the outer header will state so and there will not be any CE mark set.

> Any discrepancy between the inner and outer header for non-ECT, 
> Further I believe my discuss points 2)

@ Dino: this point is about the following bullet in section 5.3:

 The outer-header 'Differentiated Services Code Point' (DSCP) field
      (or the 'Traffic Class' field, in the case of IPv6) SHOULD be
      copied from the inner-header DSCP field ('Traffic Class' field, in
      the case of IPv6) considering the exception listed below.

You need to delete the trailing “considering the exception listed below” because there is no exception listed.

> and 4)

@ Mirja: This point is about all packets of the same flow having the same source port number. Version -17 includes the following sentence in section 12:

The source port
   SHOULD be the same for all packets belonging to the same flow.

As you have requested.

> are not fully resolved yet. Also I would like to at least see more explanation about the approach for extensibility that was taken in this doc (point 6).

@Mirja: Would you mind being more explicit? I fail to see the exact point you are trying to make.

Dino already explained the rationale of why LISP is as it is. We can discuss endlessly whether was a good or bad choice, but it is what it is and we cannot change it now.

IMHO, it is not worth to add any discussion on this matter in this document. 
Unless we just keep it to a simple sentence like: 

“Extension to the LISP header described in this document can be achieved using the LISP General Protocol Encapsulation mechanism [draft-ietf-lisp-gpe]." 

Ciao

L.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 18 Sep 2018 12:23:41 +0200

Hi Luigi, hi Dino,

please see below.

> Am 18.09.2018 um 10:14 schrieb Luigi Iannone <[email-masked]>:
> 
> Dino, Mirja,
> 

The word „copy“ got lost... 

> @Mirja: As Dino pointed out the last sentence is unclear.

That was the text that is in the doc.
> @Mirja: So far so good. Is the equivalent of what is already there.

Expect that it is clarified that the CE should only be coped if the inner codepoint is ECT(0) or ETC(1) and not if the codepoint is not-ECT.

> @ Mirja: How can this happen? As for your text we MUST copy inner CE to outer CE when encapsulating, so if the original packet does not support ECN the outer header will state so and there will not…

Yes, this is an error case but that doesn’t mean that it cannot happen. In RFC6040 this would cover a case where some encapsulation boxes would set the ECT flags anyway to benefit from ECN for the tunnel. This might be less a problem for lisp but it still should be cover in the spec to not end up with some unexpected behavior if this case happens anyway. And that also what RFC6040 say which should simply be followed here. I also okay with just pointing at RFC6040 and not use own normative language in this doc.
> You need to delete the trailing “considering the exception listed below” because there is no exception listed.

It’s more then that. Copying DCSP just over might not always be the right behavior. Depending on how DCSP is used in the lisp network otherwise there maybe local policies that either copy the field or e.g bleach it or set it to something else. This should be noted, e.g. „SHOULD be copied […] expect local policies define a different use of DSCP."

>    SHOULD be the same for all packets belonging to the same flow.

As missed that. Okay that’s fine. Thanks!
> “Extension to the LISP header described in this document can be achieved using the LISP General Protocol Encapsulation mechanism [draft-ietf-lisp-gpe].“ 

Yes, that would be sufficient. I’m actually wondering with this draft was not directly included in 6830bis.

Mirja

>>> You might have heard me say it at a recent IETF plenary “everything should be encrypted, period”.. So you know what camp I’m in.  ;-)
>>> 
>>>> 
>>>>> 
>>>>>>>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 18 Sep 2018 12:32:23 +0200

Hi Dino,

please see below.

> Am 17.09.2018 um 19:48 schrieb Dino Farinacci <[email-masked]>:
> 
>> PROPOSED

copy

> I didn’t include this text because (1) it under states what to do with IPv4, (2) it has too much detail that is already in RFC6040, and (3) it undoes text that other reviewers have offered.

I didn’t change the mentioning of IPv6 here. Yes please at IPv4.

You can remove all this text and only point to rfc6040. That would actually my preferred solution. I don’t think it „undoes“ text; it just adds what was missing in compliance with RFC6040. Anyway it doesn’t matter point being that it should specify the same things as RFC6040 does not matter what other have ofter because RFC6040 is the IETF-consensus doc how describing how to handle this.

> You have to tell me what text. I am too confused at this point on what you want.

This is the text in the en-/ and decapsulation lists:

      header."

      order to avoid discarding indications of congestion [RFC6040].  If
      the tunnel endpoints."

And this text comes up right after the list in the same section:

"The Explicit Congestion Notification ('ECN') field occupies bits 6
   and 7 of both the IPv4 'Type of Service' field and the IPv6 'Traffic
   Class' field [RFC6040].  The 'ECN' field requires special treatment
   in order to avoid discarding indications of congestion [RFC6040].  An
   ITR/PITR 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.
   If the 'ECN' field contains a congestion indication codepoint (the
   value is '11', the Congestion Experienced (CE) codepoint), then ETR/
   PETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped
   outer header to the surviving inner header that is used to forward
   the packet beyond the ETR.  These requirements preserve CE
   indications when a packet that uses ECN traverses a LISP tunnel and
   becomes marked with a CE indication due to congestion between the
   tunnel endpoints."

The last text bit does not add any information; it just states all normative requirement twice, even using basically exactly the some words. This can lead to discrepancies and it really not necessary. I’d recommend to just remove the last text block here (and fix the IPv6/IPv4 issue in the other blocks).

Mirja

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 18 Sep 2018 15:46:43 +0200

> On 18 Sep 2018, at 12:32, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> 
> Hi Dino,
> 
> please see below.
> 
> You can remove all this text and only point to rfc6040.

Mirja,

So why not keeping the text as it is (actually with some of the improvement you suggested), but for all the rest we refer to 6040.
See below.

For the encapsulation we keep what you proposed:

     below and then copy the 2-bit 'ECN' field from the stripped inner header to the 
     new outer header.“

For the decapsulation we simply keep the following:

     used to forward the packet beyond the ETR. 
     Further information on how to preserve CE information can be found in RFC6040.”

L.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 18 Sep 2018 09:50:04 -0700

> You need to delete the trailing “considering the exception listed below” because there is no exception listed.

Done. And add “to the outer-header.” Will go in -19.

          <t>The outer-header 'Differentiated Services Code Point'                                                      
           (DSCP) field (or the 'Traffic Class' field, in the case of                                                   
           IPv6) SHOULD be copied from the inner-header DSCP field                                                       
           ('Traffic Class' field, in the case of IPv6) to the                                                           
           outer-header.</t>

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 18 Sep 2018 09:54:50 -0700

> Yes, that would be sufficient. I’m actually wondering with this draft was not directly included in 6830bis.

I thought we (the WG) made a decision to not reference lisp-gpe in 6830bis. It is not referenced now.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 18 Sep 2018 09:56:27 -0700

As I already said, this text is too detailed and repeats what is in other RFCs. And since implementations do what they already do, adding more details that are not implemented, IMO, is not good form.

Dino

> On Sep 18, 2018, at 3:32 AM, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> 
> Hi Dino,
> 
> please see below.
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 20 Sep 2018 12:51:18 +0200

Hi Dino,

it’s fine with me to leave the details to rfc6040 but then also the details in the current text should be removed (because giving only half the details really doesn’t seem right).

However, I totally disagree with your comment on providing details that are not implemented. If they are not implemented correctly, it might even be more important to spell them out in this document, so implementors have chance to update their (future) implementation to do the correct thing. Having deployed implementations that are non standard-conform always happens and in this case it is probably not specifically problematic as it doesn’t impact interoperability. However, it is important though that the spec is correct.

Mirja

> Am 18.09.2018 um 18:56 schrieb Dino Farinacci <[email-masked]>:
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 20 Sep 2018 08:44:45 -0500

I haven't balloted on this document yet, but since I will, and would love
to ballot No-Objection ...

On Thu, Sep 20, 2018 at 5:58 AM Mirja Kuehlewind (IETF) <[email-masked]>
wrote:

> Hi Dino,
>
> it’s fine with me to leave the details to rfc6040 but then also the
> details in the current text should be removed (because giving only half the
> details really doesn’t seem right).
>
> However, I totally disagree with your comment on providing details that
> are not implemented. If they are not implemented correctly, it might even
> be more important to spell them out in this document, so implementors have
> chance to update their (future) implementation to do the correct thing.
> Having deployed implementations that are non standard-conform always
> happens and in this case it is probably not specifically problematic as it
> doesn’t impact interoperability. However, it is important though that the
> spec is correct.
>

Tl;dr - you're both right. Do the right thing.

If I'm following this conversation correctly, the situation is

- IP fragmentation can be problematic, roughly as a function of the number
of fragments that any given IP packet is fragmented into, but
- most deployed LISP implementations don't do path MTU discovery now

Is that it?

If so, what I'd suggest, is actually saying it that way.

Mirja's right, that we're advising people to do path MTU discovery of some
type (and I'm pretty sure https://tools.ietf.org/html/rfc4821#section-10.3
is what we would recommend in this case).

Dino's right, that putting out a standard that doesn't reflect deployed
implementations won't inspire people to conform to standards.

But do the right thing, of course ...

Spencer

> > As I already said, this text is too detailed and repeats what is in
> other RFCs. And since implementations do what they already do, adding more
> details that are not implemented, IMO, is not good form.
> >
> > Dino
> >
> >>> I didn’t include this text because (1) it under states what to do with
> IPv4, (2) it has too much detail that is already in RFC6040, and (3) it
> undoes text that other reviewers have offered.
> >>
> >> You can remove all this text and only point to rfc6040. That would
> actually my preferred solution. I don’t think it „undoes“ text; it just
> adds what was missing in compliance with RFC6040. Anyway it doesn’t matter
> point being that it should specify the same things as RFC6040 does not
> matter what other have ofter because RFC6040 is the IETF-consensus doc how
> describing how to handle this.
> >>
> >>>
> >>>
> >> The last text bit does not add any information; it just states all
> normative requirement twice, even using basically exactly the some words.
> This can lead to discrepancies and it really not necessary. I’d recommend
> to just remove the last text block here (and fix the IPv6/IPv4 issue in the
> other blocks).
> >>
> >> Mirja
> >>
> >>
> >>>
> >>>> Further I believe my discuss points 2) and 4) are not fully resolved
> yet. Also I would like to at least see more explanation about the approach
> for extensibility that was taken in this doc (point 6).
> >>>
> >>> You are going to have to repeat what they are because too many emails
> have flown by since your initial post. And for extensibility, we discuss it
> in RFC8060 and don’t think anything more should be said here otherwise, we
> will duplicate unnecessary text.
> >>>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 20 Sep 2018 17:03:16 +0200

Hi Spencer,

this conversation was mostly on ECN. For the MTU issue, I think the solution is to restrict the message size of lisp messages such that no PMTU discovery is needed.

Mirja

> Am 20.09.2018 um 15:44 schrieb Spencer Dawkins at IETF <[email-masked]>:
> 
> I haven't balloted on this document yet, but since I will, and would love to ballot No-Objection ... 
> 
> On Thu, Sep 20, 2018 at 5:58 AM Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> Hi Dino,
> 
> - IP fragmentation can be problematic, roughly as a function of the number of fragments that any given IP packet is fragmented into, but 
> Mirja's right, that we're advising people to do path MTU discovery of some type (and I'm pretty sure https://tools.ietf.org/html/rfc4821#section-10.3 is what we would recommend in this case). 
> 
> Dino's right, that putting out a standard that doesn't reflect deployed implementations won't inspire people to conform to standards. 
> 
> But do the right thing, of course ....
> 
> Spencer
>  
> Mirja
> 
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 20 Sep 2018 11:39:37 -0500

Hi, Mirja,

On Thu, Sep 20, 2018 at 10:04 AM Mirja Kuehlewind (IETF) <
[email-masked]> wrote:

> Hi Spencer,
>
> this conversation was mostly on ECN.

My apologies to all, for helping unhelpfully. I'll do the right thing on my
ballot.

> For the MTU issue, I think the solution is to restrict the message size of
> lisp messages such that no PMTU discovery is needed.

Also works for me.

Spencer, who really can't send comments on documents in IESG evaluation
during QUIC interim meetings, no matter how much he wishes he could.

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 21 Sep 2018 21:52:33 -0700

> However, I totally disagree with your comment on providing details that are not implemented. If they are not implemented correctly, it might even be more important to spell them out in this documen…

And why do you think they are implemented incorrectly? 

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 21 Sep 2018 21:53:41 -0700

> But do the right thing, of course …

And I believe the right thing is the newly added text I put in. We did not ignore the comment, we did try to address it.

Dino

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 24 Sep 2018 14:52:19 +0200

Because they don’t follow RFC6040 and therefore we do something different in some corner cases.

> Am 22.09.2018 um 06:52 schrieb Dino Farinacci <[email-masked]>:
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 24 Sep 2018 10:34:09 -0700

Well, the implementations are out and working. And we said in the latest updates to consider using RFC6040. So not sure we can do much more than that.

Dino

> On Sep 24, 2018, at 5:52 AM, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
>

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 26 Sep 2018 17:27:59 +0200

Hi Mirja,

trying to follow up on this issue.

The ECN text for encapsulation is currently:

      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 <https://tools.ietf.org/html/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.

Can we keep it as it is (updating the reference to 6040)?

The text for decapsulation is:

CURRENT:
      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 [RFC6040 <https://tools.ietf.org/html/rfc6040>].  If
      the 'ECN' field contains a congestion indication codepoint (the
      value is '11', the Congestion Experienced (CE) codepoint), then
      ETR decapsulation MUST copy the 2-bit 'ECN' field from the
      stripped outer header to the surviving inner header that is used
      to forward the packet beyond the ETR.  These requirements preserve
      CE indications when a packet that uses ECN traverses a LISP tunnel
      and becomes marked with a CE indication due to congestion between
      the tunnel endpoints.  Implementations exist that copy the 'ECN'
      field from the outer header to the inner header even though
      [RFC6040 <https://tools.ietf.org/html/rfc6040>] does not recommend this behavior.  It is RECOMMENDED
      that implementations change to support the behavior in [RFC6040 <https://tools.ietf.org/html/rfc6040>].

Which I suggest we shrink to:

NEW:

      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 [RFC6040 <https://tools.ietf.org/html/rfc6040>]. 
      Note that implementations exist that copy the 'ECN'
      field from the outer header to the inner header even though
      [RFC6040 <https://tools.ietf.org/html/rfc6040>] does not recommend such behavior.  It is RECOMMENDED
      that implementations change, so to support the specifications in [RFC6040 <https://tools.ietf.org/html/rfc6040>].

The text above clearly states that implementations should be conform to 6040. 

Is it what you were looking for?

Or am I missing something?

Ciao

L.

> On 24 Sep 2018, at 19:34, Dino Farinacci <[email-masked]> wrote:
>