Michael,
On Fri, Aug 19, 2022 at 08:39:14AM +0000, Scharf, Michael wrote:
> > From: Jeffrey Haas <jh...@pfrc.org>
> >
> > The underlying issue that Camilo is trying to raise isn't so much
> > interface-specific as it is session specific. Consider the following
> > examples:
> >
> > https://www.juniper.net/documentation/us/en/software/junos/bgp/topics
> > /ref/statement/tcp-mss-edit-protocols-bgp.html
> > https://www.cisco.com/c/en/us/td/docs/iosxr/cisco8000/bgp/73x/b-bgp-cg-
> > 8k-73x/implementing-bgp.html#task_sq1_xdk_4jb
>
> Thanks for the pointers. Actually, I have looked at several router operating
> systems (including also Nokia SROS) when preparing the first individual
> versions of this draft.
>
> For what it is worth, an old summary shown during IETF 105 (see
> https://datatracker.ietf.org/meeting/105/materials/slides-105-tcpm-yang-groupings-for-transmission-control-protocol-tcp-configuration-01)
> includes both router and host operating systems as examples.
>
> In addition, I have now also checked the OpenConfig YANG models, and they
> also have ways to set the MSS, for instance:
>
> leaf tcp-mss {
> type uint16;
> description
> "Sets the max segment size for BGP TCP sessions.";
> }
An example above, where a typedef for the uint16 might be helpful.
> leaf mtu-discovery {
> type boolean;
> default false;
> description
> "Turns path mtu discovery for BGP TCP sessions on (true)
> or off (false)";
> }
>
> The details, i.e., whether to configure a maximum value for the MSS as system
> default, per network interface, or per (BGP) neighbor may be specific to the
> system, but in general most router and host operating systems have ways to
> influence the MSS.
And thus a motivation to discuss this in the context of the broader IETF
YANG work. The IETF BGP module similarly covers MSS. GROW is looking to
copy similar patterns.
> So, this clearly shows that the MSS might be relevant. But the reality is a
> bit more complex:
>
> 1/ The MSS value is per direction of a TCP connection, and the effective send
> MSS (called Eff.snd.MSS in RFC 9293) can be different from the receive MSS
> (called RMSS in RFC 9293)
>
> 2/ It is relatively common to also enable/disable PMTU discovery as
> alternative to an explicit MSS configuration (not only in OpenConfig, see
> again e.g. my old survey in
> https://datatracker.ietf.org/meeting/105/materials/slides-105-tcpm-yang-groupings-for-transmission-control-protocol-tcp-configuration-01)
>
> 3/ If a TCP stack allows setting a maximum, the effective MSS may be smaller
> than this configured parameter (config vs. operational state)
>
> None of this is a fundamental problem for a YANG model, and we could figure
> out how to model this specific detail. Both MSS and PMTU discovery was in the
> list of features that were originally discussed in TCPM as potentially in
> scope of this document. But there was no strong interest in this inside TCPM
> without a clear use case.
>
> If the feedback from BGP implementers is that MSS and MTU discovery is a
> MUST-HAVE, that situation could change.
What you're seeing is that interest from the parties working on the modeling
for BGP with similar parties who are realizing similar issues must be dealt
with for other protocols. (In this case, BMP.)
You're also seeing this interest late for the usual reason in IETF modeling
work: YANG module "interwork" efforts have come late in the process.
> > For the first point, it might make sense to expose the effective MSS in the
> > tcp/connections container. Doing so in a typedef defined in this module may
> > be helpful for the second point.
>
> As already pointed out, we would have to understand whether it should be the
> MSS, or also PMTU discovery, or even more.
MSS and PMTUD are certainly reasonable items.
> As the upcoming revision of the draft will have other changes, the authors
> could make a proposal in this space, too. But I'd really be more comfortable
> with this if there was some further list support from the community before
> going down that road.
I think your largest problem is going to be the list of SME on this are few
and thus interest will appear to be low.
Speaking as someone who works at a larger vendor, I'd prefer to see this
work addressed in the main effort. If it isn't, vendors will end up
implementing their own operational state for this as augmentations which
might lead to inconsistencies.
> Thanks for this good discussion!
Thanks for entertaining these late discussions for this work.
-- Jeff
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
