Hi Darrel, > -----Original Message----- > From: Darrel Lewis (darlewis) [mailto:darle...@cisco.com] > Sent: Thursday, May 30, 2013 10:44 AM > To: Templin, Fred L > Cc: Darrel Lewis (darlewis); Noel Chiappa; lisp@ietf.org > Subject: Re: [lisp] AD Evaluation: draft-ietf-lisp-deployment > > > On May 30, 2013, at 9:59 AM, "Templin, Fred L" > <fred.l.temp...@boeing.com> wrote: > > > > > I agree that reassembly in an egress router that is located somewhere > > in the middle of a large network doesn't scale. For egress routers > > that are close to the destination end systems, however, the scaling > > is bounded. In general, the closer the egress router is to the end > > systems the more practical reassembly becomes - especially if the > > egress router and end system are one and the same. > > > > > > I'm afraid I my personal experience with the statement '... the closer > the egress router is to the end systems the more practical reassembly > becomes' does not align with this statement. In some cases it may be > true, but its certainly not a general statement I would support.
I don't mind revising my statement to something like, "In certain practical deployments, the closer the egress router is to the end systems the more practical reassembly becomes...". We have both SEAL and CAPWAP running internally here today. There is also something else about these schemes that bears mention. They try to avoid segmentation and reassembly whenever possible and only do it when there is no other choice. So, if the true path MTU is (1500+encapsulation_overhead) the schemes will discover this and send whole packets without segmentation and reassembly. So, I am not advocating segmentation/reassembly as a steady-state condition but rather as a last resort. Thanks - Fred fred.l.temp...@boeing.com > -Darrel _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
