Hi Suresh,
> -----Original Message-----
> From: Suresh Krishnan [mailto:[email protected]]
> Sent: Tuesday, May 19, 2015 9:13 PM
> To: Templin, Fred L; Carlos Pignataro (cpignata)
> Cc: Brian Haberman; Ronald P. Bonica; Kathleen Moriarty;
> [email protected]; [email protected]; draft-ietf-intarea-
> [email protected]; [email protected]; The IESG;
> [email protected]
> Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-intarea-gre-mtu-04:
> (with DISCUSS)
>
> Hi Fred,
>
> On 05/19/2015 05:07 PM, Templin, Fred L wrote:
> > The draft is reliant on discovery of the GMTU, which is through PMTUD
> > procedures.
> > That being the case, the draft needs to tell the conditions under which
> > PMTUD can
> > be relied on. Reliable delivery of PTB messages is one necessary condition.
> > Assurance
> > against source address spoofing is another.
> >
> > Also, I have also said many times that probing with 1280 byte packets is
> > insufficient
> > guidance when ECMP or LAG may send data packets along different paths than
> > the
> > probe packets. Hence, "MUST" send probes is not useful guidance unless more
> > is
> > said about the probing procedure and its interactions with multipath.
>
> As we discussed before, this draft just documents an existing solution
> that has been widely deployed.
That would be an informational; this document is being offered as
standards-track. In Section 3.2, it says:
"Before activating a GRE tunnel and periodically thereafter, the GRE
ingress node MUST execute procedures that verify the tunnel's ability
to carry a 1280-byte IPv6 payload packet from ingress to egress,
without fragmenting the payload. Having executed those procedures,
the GRE ingress node MUST activate or deactivate the tunnel
accordingly."
But, the GRE ingress is the source of the encapsulated packets; it is not
the source of the payload packets. So, if the payload packets in any way
color the encapsulated packets (e.g., flow label, DSCP, etc.) there is
opportunity for data packets to take different paths than probe packets.
So, saying" MUST" (twice) is asking for standardization of something that
we already know is not going to work in all cases.
> If you want to bring a better solution to
> the table, that is a fine idea. Please start that discussion in a
> separate thread.
The better solution is to take advantage of standard PMTUD when you
can, and employ fragmentation only when you must. This is why I said:
"That being the case, the draft needs to tell the conditions under which
PMTUD can
be relied on. Reliable delivery of PTB messages is one necessary condition.
Assurance
against source address spoofing is another."
I will have a new version of AERO out later this AM. I would like to present
Section 3.313 of AERO at the next intarea session.
Thanks - Fred
[email protected]
> Thanks
> Suresh
>
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
