Hi Jeff, Just one comment. See below.
> On Aug 22, 2022, at 9:07 AM, Jeffrey Haas <[email protected]> wrote: > > Michael, > > On Fri, Aug 19, 2022 at 08:39:14AM +0000, Scharf, Michael wrote: >>> From: Jeffrey Haas <[email protected]> >>> >>> 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. Not clear on why you would like to see a typedef rather than a definition for MSS node as suggested by Michael. Or did you mean to put a range for the MSS value? Thanks > >> 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 > Mahesh Jethanandani [email protected]
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
