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 protected]>: > > 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 protected]> > 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 > > Mirja > > > > Am 18.09.2018 um 18:56 schrieb Dino Farinacci <[email protected]>: > > > > 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 protected]> > >> wrote: > >> > >> Hi Dino, > >> > >> please see below. > >> > >>> Am 17.09.2018 um 19:48 schrieb Dino Farinacci <[email protected]>: > >>> > >>>> 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.“ > >>> > >>> I did not include this text because the last sentence is not formed well. > >>> Please restate. A verb is missing. > >> > >> copy > >> > >>> > >>>> "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.” > >>> > >>> 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. > >> > >>> > >>> > >>>> 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. > >> > >> This is the text in the en-/ and decapsulation lists: > >> > >> "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 '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]. 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." > >> > >> 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 > >> > >> > >>> > >>>> 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 > >>> > >>> > >>> > >>> > >>> > >>> > >> > > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
