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
