Subject: BFD WG adoption for draft-haas-bfd-large-packets

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 18 Oct 2018 01:06:16 +0000

Hello BFD WG,

We have received an adoption request for “BFD encapsulated in large packets”.

https://datatracker.ietf.org/doc/draft-haas-bfd-large-packets/

The adoption call will end on Friday Nov 9th.

Please send email to the list indicating “yes/support”  or “no/do not support”. If you do not support adoption, please state your reasons.

Regards,
Reshad & Jeff.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 17 Oct 2018 18:57:29 -0700

Support.

> On Oct 17, 2018, at 6:06 PM, Reshad Rahman (rrahman) <[email-masked]> wrote:
> 
> Hello BFD WG,
>  
> https://datatracker.ietf.org/doc/draft-haas-bfd-large-packets/ <https://datatracker.ietf.org/doc/draft-haas-bfd-large-packets/>
>  

Mahesh Jethanandani
[email-masked]

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 17 Oct 2018 19:48:40 -0700

Yes/support

Regards,
Greg

On Wed, Oct 17, 2018, 18:06 Reshad Rahman (rrahman) <[email-masked]>
wrote:

> Please send email to the list indicating “yes/support”  or “no/do not
> support”. If you do not support adoption, please state your reasons.
>
>
>
> Regards,
>
> Reshad & Jeff.
>
>
>
>
>

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Thu, 18 Oct 2018 03:33:39 +0000

Support.

- Naiming

On Oct 17, 2018, at 6:06 PM, Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>> wrote:

Hello BFD WG,

Regards,
Reshad & Jeff.

---

From: Enke Chen <[email-masked]>
Date: Wed, 17 Oct 2018 21:00:09 -0700

Support.

-- Enke

On 10/17/18 6:06 PM, Reshad Rahman (rrahman) wrote:
> The adoption call will end on Friday Nov 9^th .
> 
>  
>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 18 Oct 2018 13:05:28 +0000

Yes/support.

Regards,
Reshad.

From: Rtg-bfd <[email-masked]> on behalf of "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wednesday, October 17, 2018 at 9:06 PM
To: "[email-masked]" <[email-masked]>
Subject: BFD WG adoption for draft-haas-bfd-large-packets

Hello BFD WG,

Regards,
Reshad & Jeff.

---

From: <[email-masked]>
Date: Fri, 19 Oct 2018 14:18:14 +0000

Hello,

I support.
The feature is useful and the solution simple.

Thanks
Regards,
--Bruno

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Reshad Rahman (rrahman)
Sent: Thursday, October 18, 2018 3:06 AM
To: [email-masked]
Subject: BFD WG adoption for draft-haas-bfd-large-packets

Hello BFD WG,

Regards,
Reshad & Jeff.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Fri, 19 Oct 2018 14:36:27 +0000

Support.

Regards,
Nagendra

Hello BFD WG,

Regards,
Reshad & Jeff.

---

From: <[email-masked]>
Date: Sat, 20 Oct 2018 10:09:46 +0800 (CST)

Yes/Support. This draft provides a concise and practical way to perform path mtu detection and verification.

Best Regards,

Xiao Min

原始邮件

发件人：ReshadRahman(rrahman) <[email-masked]>
收件人：[email-masked] <[email-masked]>;
日 期 ：2018年10月18日 09:06
主 题 ：BFD WG adoption for draft-haas-bfd-large-packets

Hello BFD WG,

 

 

 

 

Regards,

Reshad & Jeff.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 21 Oct 2018 00:14:00 +0000

I have some concerns.

It has been stated that there is a need for sub-second detection of this condition – but I really question that requirement.
What I would expect is that MTU changes only occur as a result of some maintenance operation (configuration change, link addition/bringup, insertion of a new box in the physical path etc.). The idea of using a mechanism which is specifically tailored for sub-second detection to monitor something that is only going to change occasionally seems inappropriate. It makes me think that other mechanisms (some form of OAM, enhancements to routing protocols to do what IS-IS already does ☺) could be more appropriate and would still meet the operational requirements.

I have listened to the Montreal recording – and I know there was discussion related to these issues (not sending padded packets all the time, use of BFD echo, etc.) – but I would be interested in more discussion of the need for sub-second detection.

Also, given that a path might be used with a variety of encapsulations, how do you see such a mechanism being used when multiple BFD clients share the same BFD session and their MTU constraints are different?

Thanx.

   Les

From: Rtg-bfd <[email-masked]> On Behalf Of Reshad Rahman (rrahman)
Sent: Wednesday, October 17, 2018 6:06 PM
To: [email-masked]
Subject: BFD WG adoption for draft-haas-bfd-large-packets

Hello BFD WG,

Regards,
Reshad & Jeff.

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Sun, 21 Oct 2018 22:11:55 +0000

It probably should say “the payload size MAY be increased to this value and it is
not recommended for a BFD session to always use the large size packet for padding.
How frequent the large size packet being used is application specific”.

for the variety of encaps, the internal application probably can deduced from a
BFD one into their own as long as we have a number for path MTU.

thanks.
- Naiming

On Oct 20, 2018, at 5:14 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:

I have some concerns.

Thanx.

   Les

From: Rtg-bfd <[email-masked]<mailto:[email-masked]>> On Behalf Of Reshad Rahman (rrahman)
Sent: Wednesday, October 17, 2018 6:06 PM
To: [email-masked]<mailto:[email-masked]>
Subject: BFD WG adoption for draft-haas-bfd-large-packets

Hello BFD WG,

Regards,
Reshad & Jeff.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 21 Oct 2018 22:26:05 +0000

Naiming –

Inline…

From: Naiming Shen (naiming)
Sent: Sunday, October 21, 2018 3:12 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Reshad Rahman (rrahman) <[email-masked]>; [email-masked]
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets

[Les:] This does not address the question as to why we want to use a mechanism specifically designed for sub-second detection for this case.
??? (Note that it does not come for free. ☺ )

[Les:] If “your” MTU requirements are smaller than “mine” – would you want the BFD session to go down even though you could continue to use the link successfully?

   Les

thanks.
- Naiming

I have some concerns.

Thanx.

   Les

Hello BFD WG,

Regards,
Reshad & Jeff.

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Sun, 21 Oct 2018 22:35:46 +0000

Les,

On Oct 21, 2018, at 3:26 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:

Naiming –

Inline…

From: Naiming Shen (naiming)
Sent: Sunday, October 21, 2018 3:12 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets

Since we already have a session between two end-points, a BFD session, why not utilize that
instead of having to explicitly configurae another ‘MTU discovery protocol’ session with burden
of configuration and management.

Since most of the application traffic does not fill the full size of the pipe to reach the MTU, so
this detection does not need to be sub-seconds, unlike normal BFD down we have to switch
the traffic immediately. MTU change can be detected by variing the BFD size say once
every minute (just like the BFD authentication proposal, once a while is sort of ok). Not knowing
the path MTU has changed for days is bad, but got notified in 2 minutes is good:-)

No, I think this document can also specify that, the BFD should not go “DOWN” if MTU has reduced, it should
only to be used as a ‘discovery’ mechanism ontop of the BFD itself. Say I’m sending large packets every 5 minutes
for 10 packets, this can be on top of the existing BFD schedule. It smaller packets still comes back to keep the
session alive. The big packets will give us the “indication” of extra data we have learned,

thanks.
- Naiming

   Les

thanks.
- Naiming

I have some concerns.

Thanx.

   Les

Hello BFD WG,

Regards,
Reshad & Jeff.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 22 Oct 2018 00:36:52 +0000

Naiming -

Thanx for the good discussion. Responses inline.

Sent: Sunday, October 21, 2018 3:36 PM

Les,

Naiming –

Inline…

[Les:] Because it comes with costs and risks and problems of its own.

We do not know how many of the existing BFD implementations will be able to handle this w/o changes. Some may not be able to handle this at all.
The draft already acknowledges that this may affect BFD scaling. It is not much of a leap to think that in order to handle BFD at scale current implementations have made certain assumptions – one of which could be what is the maximum expected size of a BFD packet.
And the user will – of course – have to configure this as a BFD option (I believe this was acknowledged in the Montreal presentation) – so it is not as if no additional config is required.

I am sure we can come up with other risks/costs with a bit more thought.

[Les:] So, this has some implications:

We have both a transmit interval and a multiplier for a BFD session because we allow that some BFD packets may be dropped for reasons which do not represent a true loss of connectivity. Therefore up to N-1 consecutive packets may be dropped w/o triggering a session state change. If large BFD packets are “occasionally” inserted this means there are intervals during which N-2 packets drops (not counting the BFD large packet) would be sufficient to trigger a BFD session state change. Further, if the processing of the large BFD packets makes it more likely that subsequent BFD packets will be dropped (e.g., because the processing of the large BFD packet simply takes longer) then it is possible that a BFD session state change might be triggered simply as a side effect of the insertion of the large packet into the data stream.

You also are now defining a “child session” which is embedded within the parent session. BFD large packets are then not meant to influence the parent BFD session state and therefore have to be processed separately. This – in many ways – is equivalent to defining “another protocol”. I’ll grant it might be a bit simpler as it can inherit some things from the parent session – but it certainly is no longer simply a transparent part of existing BFD session operation.

And you still have not fully addressed the differing client MTU requirement – unless you are proposing that BFD report to its clients what set of MTUs are being “tested” and which ones have failed and which have not.

It is conceivable that all of this could be addressed in some way, but it gives me pause as to whether this is the best solution.

   Les

thanks.
- Naiming

   Les

thanks.
- Naiming

I have some concerns.

Thanx.

   Les

Hello BFD WG,

Regards,
Reshad & Jeff.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 22 Oct 2018 11:08:20 -0700

I think it is important to understand the intent of why the large packets are being sent. For example, if the idea is to be able to transport a large size packet without dropping it in the path, then there might be little or no processing of the payload of the packet; just the fact that we received it. I can understand that if we start to process the payload, that that might cause delays in processing the next packet. Do we believe that receiving a large size packet, with little or no processing performed on it, will cause us to drop/not receive another packet?

> On Oct 21, 2018, at 5:36 PM, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
> Naiming -
>  
> To: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]>>
> Cc: Reshad Rahman (rrahman) <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On Oct 21, 2018, at 3:26 PM, Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Naiming –
>  
> Inline…
>  
> To: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]>>
> Cc: Reshad Rahman (rrahman) <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> ??? (Note that it does not come for free. J )
>  
> On Oct 20, 2018, at 5:14 PM, Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]>> wrote:
>  
> I have some concerns.
>  
> What I would expect is that MTU changes only occur as a result of some maintenance operation (configuration change, link addition/bringup, insertion of a new box in the physical path etc.). The idea of using a mechanism which is specifically tailored for sub-second detection to monitor something that is only going to change occasionally seems inappropriate. It makes me think that other mechanisms (some form of OAM, enhancements to routing protocols to do what IS-IS already does J) could be more appropriate and would still meet the operational requirements.
>  
> From: Rtg-bfd <[email-masked] <mailto:[email-masked]>> On Behalf Of Reshad Rahman (rrahman)
> To: [email-masked] <mailto:[email-masked]>

Mahesh Jethanandani
[email-masked]

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Mon, 22 Oct 2018 19:38:18 +0000

Probably just bandwidth increase, and if you need encryption/decryption on the packets,
then large packets will cost more in CPU.

thanks.
- Naiming

On Oct 22, 2018, at 11:08 AM, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>> wrote:

On Oct 21, 2018, at 5:36 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:

Naiming -

Les,

Naiming –

Inline…

   Les

thanks.
- Naiming

   Les

thanks.
- Naiming

I have some concerns.

Thanx.

   Les

Hello BFD WG,

Regards,
Reshad & Jeff.

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 22 Oct 2018 20:01:48 +0000

Hi,

  1.  <chair hat>From Albert’s presentation @ IETF102, the motivation for doing this is to have BFD fail if the expected MTU can not be met, and therefore for traffic to be rerouted as a result. So I think this is the use case we should stick with but I’d like to know if others think otherwise.</chair hat>
  2.  Les, I don’t understand the question regarding client MTU requirement. Are you saying if OSPF and BGP are clients of the same BFD session they might have different MTU requirements? I don’t think this is the problem the solution is trying to solve: the solution is trying to figure out if packets of up to size X can make it to the other end, this is independent of BFD client.
  3.  Les, I agree we need to balance the cost of a new protocol v/s overloading BFD at the risk of “polluting” it. I believe BFD is a good fit for this but we have to be careful, so it’s good to have these discussions.

Regards,
Reshad.

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sunday, October 21, 2018 at 8:36 PM
To: "Naiming Shen (naiming)" <[email-masked]>
Cc: "Reshad Rahman (rrahman)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: BFD WG adoption for draft-haas-bfd-large-packets

Naiming -

Les,

Naiming –

Inline…

   Les

thanks.
- Naiming

   Les

thanks.
- Naiming

I have some concerns.

Thanx.

   Les

Hello BFD WG,

Regards,
Reshad & Jeff.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 22 Oct 2018 20:40:49 +0000

Reshad –

Inline.

From: Reshad Rahman (rrahman)
Sent: Monday, October 22, 2018 1:02 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; Naiming Shen (naiming) <[email-masked]>
Cc: [email-masked]
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets

Hi,

1)      <chair hat>From Albert’s presentation @ IETF102, the motivation for doing this is to have BFD fail if the expected MTU can not be met, and therefore for traffic to be rerouted as a result. So I think this is the use case we should stick with but I’d like to know if others think otherwise.</chair hat>
2)      Les, I don’t understand the question regarding client MTU requirement. Are you saying if OSPF and BGP are clients of the same BFD session they might have different MTU requirements? I don’t think this is the problem the solution is trying to solve: the solution is trying to figure out if packets of up to size X can make it to the other end, this is independent of BFD client.
[Les:] I don’t think the example of OSPF/BGP is a good one. Think tunneled traffic vs non-tunneled.
I raised the question because different BFD clients can have different MTU limitations and wanted to know how this would be addressed when they shared the same BFD session.
Does BFD use the minimum or the maximum of all the client MTUs?

3)      Les, I agree we need to balance the cost of a new protocol v/s overloading BFD at the risk of “polluting” it. I believe BFD is a good fit for this but we have to be careful, so it’s good to have these discussions.

[Les:] My current feeling is that this isn’t a good fit for BFD. But I agree with you – discussing this at this early stage is a good thing to do.

    Les

Regards,
Reshad.

From: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Date: Sunday, October 21, 2018 at 8:36 PM
To: "Naiming Shen (naiming)" <[email-masked]<mailto:[email-masked]>>
Cc: "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: BFD WG adoption for draft-haas-bfd-large-packets

Naiming -

Les,

Naiming –

Inline…

   Les

thanks.
- Naiming

   Les

thanks.
- Naiming

I have some concerns.

Thanx.

   Les

Hello BFD WG,

Regards,
Reshad & Jeff.

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 23 Oct 2018 14:50:47 +0000

Hi Les,

I still don’t understand what you’re referring to as BFD clients and how they could have different MTU limitations. Are you referring to application data?

Regards,
Reshad (no hat).

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Monday, October 22, 2018 at 4:40 PM
To: "Reshad Rahman (rrahman)" <[email-masked]>, "Naiming Shen (naiming)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: BFD WG adoption for draft-haas-bfd-large-packets

Reshad –

Inline.

Hi,

  1.  Les, I agree we need to balance the cost of a new protocol v/s overloading BFD at the risk of “polluting” it. I believe BFD is a good fit for this but we have to be careful, so it’s good to have these discussions.

    Les

Regards,
Reshad.

Naiming -

Les,

Naiming –

Inline…

   Les

thanks.
- Naiming

   Les

thanks.
- Naiming

I have some concerns.

Thanx.

   Les

Hello BFD WG,

Regards,
Reshad & Jeff.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 23 Oct 2018 14:57:17 +0000

Reshad –

I think there are two cases:

1)A client who uses encapsulation (MPLS is an easy example) and really needs to know if an MTU sized packet plus the encapsulation can be delivered vs a client who does NOT use encap and only cares about Layer 3 sized MTU packets

2)A client which has deliberately limited the max-sized packet they will ever send and really only cares about (MTU –X)

   Les

From: Reshad Rahman (rrahman)
Sent: Tuesday, October 23, 2018 7:51 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; Naiming Shen (naiming) <[email-masked]>
Cc: [email-masked]
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets

Hi Les,

Regards,
Reshad (no hat).

From: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 22, 2018 at 4:40 PM
To: "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>, "Naiming Shen (naiming)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: BFD WG adoption for draft-haas-bfd-large-packets

Reshad –

Inline.

From: Reshad Rahman (rrahman)
Sent: Monday, October 22, 2018 1:02 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets

Hi,

    Les

Regards,
Reshad.

Naiming -

Les,

Naiming –

Inline…

   Les

thanks.
- Naiming

   Les

thanks.
- Naiming

I have some concerns.

Thanx.

   Les

Hello BFD WG,

Regards,
Reshad & Jeff.

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 25 Oct 2018 10:59:59 -0400

Naiming,

A specific comment on the crypto overhead:

> then large packets will cost more in CPU.

The BFD protocol has you check the contents over the BFD PDU.  In the case
of an expanded IP payload, this procedure wasn't expected to be modified.
Thus, the crypto load should not increase. 

Covering some of the other comments, the pps of the BFD session need not
increase, alhtough the bps increases.  Scaling is thus a matter of how the
implementation handles scaled bps vs. pps for its BFD implementation.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 25 Oct 2018 11:11:51 -0400

Les,

A brief note, and one worn as a chair:
Despite having strong personal preferences about mail quoting, I realize
that not everyone gets a chance to choose a client of their own choice.
But that said, your responses in this thread have been impossible to parse
out from the surrounding reply in text-plain readers.  This includes the
IETF mailarchive.

Please make adjustments to your mail reply styling so as to be more
readable.  Thanks. :-) 

And now on to non-chair commentary:

> 2)A client which has deliberately limited the max-sized packet they will ever send and really only cares about (MTU –X)

While I agree with your sentiment from the perspective of BFD clients, I
think the use case goes slightly bigger than this.

In the cases driving Albert's original scenario, we're not protecting BGP,
IGPs or other control plane protocols for large packets.  What's really
being protected is user payload.

So, to some extent, the use case piggy-backs on existing protection of a
client to guarantee the path has a sufficient MTU.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 25 Oct 2018 11:38:05 -0400

Les,

I *think* the following text is yours.

> You also are now defining a “child session” which is embedded within the parent session. BFD large packets are then not meant to influence the parent BFD session state and therefore have to be proc…

The draft I had previously worked on with Xiao Min discussing probing using
BFD Echo had the concept of probes that would happen wherein the session is
not torn down.  The example carries similarly with the "send occasional".

I suggest taking a look at a different draft that might help direct this
portion of the discussion:

https://tools.ietf.org/html/draft-ietf-bfd-stability-02

-- Jeff

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 25 Oct 2018 22:28:52 +0000

Jeff -

Inline - hopefully more readable than before...

> -----Original Message-----
> From: Jeffrey Haas <[email-masked]>
> Sent: Thursday, October 25, 2018 8:38 AM
> Cc: Naiming Shen (naiming) <[email-masked]>; Reshad Rahman
> (rrahman) <[email-masked]>; [email-masked]

[Les:] Yes - it is.

> > We have both a transmit interval and a multiplier for a BFD session because
> we allow that some BFD packets may be dropped for reasons which do not
> represent a true loss of connectivity. Therefore up to N-1 consecutive
> packets may be dropped w/o triggering a session state change. If large BFD
> packets are “occasionally” inserted this means there are intervals during
> which N-2 packets drops (not counting the BFD large packet) would be
> sufficient to trigger a BFD session state change. Further, if the processing of
> the large BFD packets makes it more likely that subsequent BFD packets will
> be dropped (e.g., because the processing of the large BFD packet simply
> takes longer) then it is possible that a BFD session state change might be
> triggered simply as a side effect of the insertion of the large packet into the
> data stream.
> >
> > You also are now defining a “child session” which is embedded within the
> parent session. BFD large packets are then not meant to influence the parent
> BFD session state and therefore have to be processed separately. This – in
> many ways – is equivalent to defining “another protocol”. I’ll grant it might be
> a bit simpler as it can inherit some things from the parent session – but it
> certainly is no longer simply a transparent part of existing BFD session
> operation.
> 
> BFD Echo had the concept of probes that would happen wherein the session
> is not torn down.  The example carries similarly with the "send occasional".
> 
> I suggest taking a look at a different draft that might help direct this portion
> of the discussion:
> 

[Les:] I have read this draft - not sure how relevant it is.

Naiming had suggested that MTU sized packets need not be sent all the time but only occasionally - 
and that a failure might not be used to take the BFD session down - 
rather it would be seen as a "soft-failure" and reported separately from the BFD session state.
My response was in that context - which it seems was also in your mind in your BFD Echo proposal.

This, however, seems not to be what Albert has in mind - as he has since commented that he really wants to have sub-second detection of MTU issues and 
he wants traffic rerouted "immediately".

   Les

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 25 Oct 2018 20:57:55 -0400

> [Les:] I have read this draft - not sure how relevant it is.

Mostly, the idea being that it's possible to do probing in BFD without
necessarily having to commit your entire detection resources to it.

> he wants traffic rerouted "immediately".

Right.  This is part of the point I'd made earlier in the thread.  Some
consumers need immediate failover and consistent MTU probe while others
might be satisfied with periodic probing.  

An interesting question for the large-packets draft is whether we want to
support a periodic probing mode, perhaps leveraging the stability draft's
ideas.  Or, should it instead only be consistent?

-- Jeff

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 26 Oct 2018 18:24:56 +0000

I can see how using BFD to detect an MTU failure and doing the reroute can make sense, it's forwarding fault detection after all. But IMO probing MTU should not be done by BFD, unless we're considering rechartering/BFDv2.

Regards,
Reshad (hat on). 

On 2018-10-25, 8:58 PM, "Jeffrey Haas" <[email-masked]> wrote:

    

    
    -- Jeff

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 26 Oct 2018 18:32:26 +0000

Hi,

Inline <RR>.

On 2018-10-25, 11:38 AM, "Jeffrey Haas" <[email-masked]> wrote:

    Les,

    
    The draft I had previously worked on with Xiao Min discussing probing using
    BFD Echo had the concept of probes that would happen wherein the session is
    not torn down.  The example carries similarly with the "send occasional".
<RR> We discussed use of echo at IETF102. The large-packets draft mentions that echo can only be used for single-hop, hence the need for padding the control packets. But isn't single-hop Albert's main use-case? I believe we should add the echo option in the large-packets draft, it has the benefit that you get the desired functionality even if only 1 side of the WAN link supports echo. I realize not all implementations support echo so they might have to do pad control packets instead.

Regards,
Reshad (no hat).

    
    -- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 29 Oct 2018 11:35:34 -0400

Reshad,

On Fri, Oct 26, 2018 at 06:32:26PM +0000, Reshad Rahman (rrahman) wrote:
> <RR> We discussed use of echo at IETF102. The large-packets draft mentions
> that echo can only be used for single-hop, hence the need for padding the
> control packets. But isn't single-hop Albert's main use-case? 

It's Albert's primary use case.  And, I think a common related one is
protecting tunnels of various flavors; e.g. GRE or IPsec.

> I believe we
> should add the echo option in the large-packets draft, it has the benefit
> that you get the desired functionality even if only 1 side of the WAN link
> supports echo. I realize not all implementations support echo so they
> might have to do pad control packets instead.

While I don't think Albert or I would have any objections to adding Echo
discussion in the existing document, we perhaps risk running into one of the
issues Xiao and I had briefly discussed.  Echo is intentionally
under-specified in RFC 5880 et seq.  While it's possible that we can simply
put in a discussion section that says "if you use Echo mode with similar
padding, you can get similar benefit", I think that may be as far as we want
to go.

The related observation is that nothing stops an Echo implementation from
doing this with no changes to the protocol. :-)

-- Jeff

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 29 Oct 2018 16:17:51 +0000

Hi Jeff,

I'd be fine with the text below on BFD echo in the discussion section. 

Regards,
Reshad.

On 2018-10-29, 11:36 AM, "Jeffrey Haas" <[email-masked]> wrote:

    Reshad,

    

    
    -- Jeff

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 29 Oct 2018 16:39:04 +0000

Jeff/Albert -

Given the MTU issue is associated with a link coming up - and the use of Echo would allow the problem to be detected and prevent the BFD session from coming up - 
and you are acknowledging that the protocol allows padded Echo packets today ...

is there really a need to do anything more?

   Les

> Sent: Monday, October 29, 2018 8:36 AM
> To: Reshad Rahman (rrahman) <[email-masked]>
> Cc: Les Ginsberg (ginsberg) <[email-masked]>; Naiming Shen (naiming)
> <[email-masked]>; [email-masked]

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 29 Oct 2018 12:41:45 -0400

> is there really a need to do anything more?

... the fact that the majority of BFD implementations on the planet do not
support Echo mode?

Not to mention my whole comment that BFD Echo is intentionally
under-specified.  The result being that any attempt to specify anything in
it will likely cause interop headaches.

-- Jeff

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 29 Oct 2018 16:55:05 +0000

Jeff -

I note that no one supports "large-packets" today.
So is the gap between supporting echo mode for this purpose any larger than the gap for introducing large packet support?

   Les

> Sent: Monday, October 29, 2018 9:42 AM
> Cc: Reshad Rahman (rrahman) <[email-masked]>; Naiming Shen
> (naiming) <[email-masked]>; [email-masked]
> > Given the MTU issue is associated with a link coming up - and the use of
> Echo would allow the problem to be detected and prevent the BFD session
> from coming up -