Jeff - I do not have a specific model in mind for S-BFD and large packets - implementations should be free to choose. I think you have covered the options well in your comments below. Mainly I wanted this discussed in the draft.
The only thing that might be troublesome is the notion of using a separate discriminator for large packet S-BFD (yes - I suggested this - not you 😊). This raises the unsolved problem of how does one indicate which discriminator is for which use case. Although the IGP extensions support advertising multiple S-BFD discriminators we never figured out how to indicate how a given discriminator should be used. I only mention it since this draft introduces a possible use case for multiple S-BFD discriminators - but this isn’t a new issue and doesn’t have to be solved by this draft. Les > -----Original Message----- > From: Jeffrey Haas <[email protected]> > Sent: Wednesday, November 06, 2019 8:47 AM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: [email protected] > Subject: Re: draft-ietf-bfd-large-packets-02 > > 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
