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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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 <[e-mail]>
> Sent: Wednesday, November 06, 2019 8:47 AM
> To: Les Ginsberg (ginsberg) <[e-mail]>
> Cc: [e-mail]
> Subject: Re: draft-ietf-bfd-large-packets-02
> 
> Les,
> 
> 
> > On Nov 5, 2019, at 12:55 AM, Les Ginsberg (ginsberg)
> <[e-mail]> 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