Les,
> On Nov 5, 2019, at 12:55 AM, Les Ginsberg (ginsberg) <[email protected]> > 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
