Re: draft-ietf-bfd-large-packets-02

Jeffrey Haas <jhaas@pfrc.org> Wed, 06 November 2019 16:46 UTC

Return-Path: <jhaas@pfrc.org>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF531200B9 for <rtg-bfd@ietfa.amsl.com>; Wed, 6 Nov 2019 08:46:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ji6y7-N2vo50 for <rtg-bfd@ietfa.amsl.com>; Wed, 6 Nov 2019 08:46:42 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAAD120089 for <rtg-bfd@ietf.org>; Wed, 6 Nov 2019 08:46:42 -0800 (PST)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 8C4241E2F2; Wed, 6 Nov 2019 11:50:25 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Subject: Re: draft-ietf-bfd-large-packets-02
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <MWHPR11MB134154282E02EB6116D506D6C17E0@MWHPR11MB1341.namprd11.prod.outlook.com>
Date: Wed, 6 Nov 2019 11:46:41 -0500
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C92B43ED-54EA-47C2-842A-2AB931DBF57A@pfrc.org>
References: <20191101155244.GA30539@pfrc.org> <MWHPR11MB134154282E02EB6116D506D6C17E0@MWHPR11MB1341.namprd11.prod.outlook.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/3xaK6xctAvMFobefl2V8YWJFVBs>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Nov 2019 16:46:44 -0000

Les,


> On Nov 5, 2019, at 12:55 AM, Les Ginsberg (ginsberg) <ginsberg@cisco.com>; wrote:
> 
> Jeff/Albert -
> 
> Thanx for the updated version. This addresses my concerns.
> 
> A couple of modest comments.
> 
> 1)Section 3.4
> 
> s/that balacing/that balancing

Queued for next rev.

> 2)Regarding S-BFD (Section 3.5)
> 
> It would seem difficult to support (for a given discriminator) some sessions using large packets and some not. I  can think of a few options:
> 
> a)Passive end uses large packets only if the Active end does. This assumes MTU is the same in both directions.

Asymmetric MTUs are not only possible, but likely in S-BFD scenarios.  But it's a valid point.

> b)A separate discriminator is used for large packet sessions
> c)Use of large packets is always on (or always off) on the passive side
> 
> Probably there are other choices.
> 
> What did you have in mind? I think adding some guidance in that regard might be useful.

My personal thought on the matter had been roughly:
- By default, respond with the same size IP encapsulation as you receive.
- While S-BFD permits largely non-configured responses to Initiators, there's likely to be SOME configuration present.  If necessary, specific configuration can be given to cover size of packets to respond to.  (Roughly aligning with the ACLs used to manage whom can initiate S-BFD in the first place.)

One way to interpret your questions is that there should be some implied configuration for BFD for Large Packets, not only on the sending side, but on the receiver.

For the receiver, something roughly like "bfd.PaddedPduReceiveMaxSize" as a parameter.  Possibly acting also as a way to enable the feature or not.

For an S-BFD reflector, perhaps parameters to control beyond the receive max size whether it responds with the same size as the iP encapsulation, and whether there's a cap for such a response.

Does the above address your concerns?

-- Jeff