Hi Fred, On 05/20/2015 10:31 AM, Templin, Fred L wrote: > 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.
NACK. The draft is *NOT* being offered as Standards Track. It is Informational as shown on both the title page and the tracker under "Intended RFC Status". https://datatracker.ietf.org/doc/draft-ietf-intarea-gre-mtu/ Does this clarify things? 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. I do not see this text in the draft in question. I think you may be talking about a different draft here. Is this the draft you are talking about? https://tools.ietf.org/html/draft-ietf-intarea-gre-ipv6-07 If so, I suggest leaving the IESG out of further discussions and continue discussion on the list with a proper subject line. > >> 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. Yep. Sounds good. Thanks Suresh _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
