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

From: Jeffrey Haas <[email-masked]>
Date: Fri, 1 Nov 2019 11:52:44 -0400

Working Group,

This version attempts to roll up all discussion points to date.  Your
further review is appreciated.

-- Jeff and Albert

----- Forwarded message from [email-masked] -----

Date: Fri, 01 Nov 2019 08:46:00 -0700
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action: draft-ietf-bfd-large-packets-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Bidirectional Forwarding Detection WG of the IETF.

        Title           : BFD Encapsulated in Large Packets
        Authors         : Jeffrey Haas
                          Albert Fu
	Filename        : draft-ietf-bfd-large-packets-02.txt
	Pages           : 7
	Date            : 2019-11-01

Abstract:
   The Bidirectional Forwarding Detection (BFD) protocol is commonly
   used to verify connectivity between two systems.  BFD packets are
   typically very small.  It is desirable in some circumstances to know
   that not only is the path between two systems reachable, but also
   that it is capable of carrying a payload of a particular size.  This
   document discusses thoughts on how to implement such a mechanism
   using BFD in Asynchronous mode.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bfd-large-packets-02
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-large-packets-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-large-packets-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

----- End forwarded message -----

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 1 Nov 2019 15:51:41 +0000

Thanks Jeff and Albert. I will go through the various discussion points and will review the latest rev.

Regards,
Reshad.

On 2019-11-01, 11:49 AM, "Rtg-bfd on behalf of Jeffrey Haas" <[email-masked] on behalf of [email-masked]> wrote:

    Working Group,

    -- Jeff and Albert
    
    ----- Forwarded message from [email-masked] -----

    
    
    Abstract:

    

    
    
    ----- End forwarded message -----

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 5 Nov 2019 05:55:04 +0000

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

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.
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.

   Les

> -----Original Message-----
> From: Rtg-bfd <[email-masked]> On Behalf Of Jeffrey Haas
> Sent: Friday, November 01, 2019 8:53 AM
> To: [email-masked]
> Subject: draft-ietf-bfd-large-packets-02
> 
> Working Group,
>

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 6 Nov 2019 11:46:41 -0500

Les,

> On Nov 5, 2019, at 12:55 AM, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
> Jeff/Albert -
> 

Queued for next rev.

> 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.

> 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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 9 Nov 2019 16:30:09 +0000

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

> From: Jeffrey Haas <[email-masked]>
> Sent: Wednesday, November 06, 2019 8:47 AM
> To: Les Ginsberg (ginsberg) <[email-masked]>
> Cc: [email-masked]
> Subject: Re: draft-ietf-bfd-large-packets-02
> 
> Les,
> 
> 
> > 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:
> >
> - 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.
>