The whole point of the text, the way it was written is to NOT DO MTU DISCOVERY between the ITR and ETR. That will lead to more packet loss. Avoid it up front by having hosts configure smaller MTUs or do MTUD inside of the site.
The point was to have less mechanism rather than more. We have been telling you this for years Fred. Dino On Feb 12, 2013, at 2:29 PM, "Templin, Fred L" <[email protected]> wrote: > Hi Dino, > >> -----Original Message----- >> From: Dino Farinacci [mailto:[email protected]] >> Sent: Tuesday, February 12, 2013 2:16 PM >> To: Templin, Fred L >> Cc: [email protected] >> Subject: Re: [lisp] RFC6830 comment >> >>>>> Yes, I understand that. My point is that stateless is not possible >>>>> if a learned effective MTU has to be stored. The stateless section >>>>> should therefore describe the conditions under which it must default >>>>> to stateful. >>>> >>>> Fred, there is stateless and the counter which is stateful. An >>> >>> The ITR is only stateless until which time the network returns >>> a packet too big - then, it is obliged to either do stateful or >>> risk black-holing. >> >> And who says it is obliged? The specification was written in the way it >> was for a reason. You want to change it to something else. > > It's really very simple; modify the next to last paragraph of > section 5.4.1 such as: > > "When the outer-header encapsulation uses an IPv4 header, an > implementation SHOULD set the DF bit to 1 so ETR fragment reassembly > can be avoided. An implementation MAY either set the DF bit in such > headers to 0 or adopt the stateful solution in Section 5.4.2 if it has > good reason to believe there are unresolvable path MTU issues between > the sending ITR and the receiving ETR." > > This also brings home the point that stateless vs stateful can > be on a per-ETR basis rather than all one way or the other. > > Thanks - Fred > [email protected] > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
