Re: [Int-area] Kathleen Moriarty's Discuss on draft-ietf-intarea-gre-mtu-04: (with DISCUSS)

[Suresh Krishnan <[e-mail]>]

Hi Fred,

On 05/20/2015 10:31 AM, Templin, Fred L wrote:
> Hi Suresh,
>
>> -----Original Message-----
>> From: Suresh Krishnan [mailto:[e-mail]]
>> Sent: Tuesday, May 19, 2015 9:13 PM
>> To: Templin, Fred L; Carlos Pignataro (cpignata)
>> Cc: Brian Haberman; Ronald P. Bonica; Kathleen Moriarty; [e-mail]; [e-mail]; draft-ietf-intarea-
>> [e-mail]; [e-mail]; The IESG; [e-mail]
>> 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