Hi All, I would like to ask some questions and seek clarifications on this draft.
1. I am aware that this draft originates from practical pain points at a specific operator. During the adoption calls, the scenarios were debated in detail. It was basically a L2 WAN circuit service over a provider network and the challenge was that the PMTU of the underlying path in the SP network changes dynamically. However, from the Enterprise POV, the L2 circuit is seen as a single link and the BFD runs in directly connected mode. The draft however, discusses BFD multi-hop which is an entirely different use-case. When doing multi-hop, the BFD packet could go over entirely different paths in the network with different PMTUs (especially different from the application sending large packets) – this makes things flaky? So shouldn’t this mechanism be actually focussed on the single hop/directly connected mode instead? 1. There are implementations with BFD offload to H/W out there. What happens when a particular implementation cannot handle such large packet sizes (and I am not specifically aware of one such)? Like other aspects of monitoring like the intervals, would there be a value in indicating a support for large packets during the signalling? The draft does raise the need for it but doesn’t seem to do anything about it – why? Either we need it and this draft should define it. Or we don’t need it and it would placing the onus on the operator to enable this when they know both ends support it. Then it is something for operational consideration section perhaps? 1. There was a discussion on the list about whether this needs to be done for every packet or not. I don’t find that discussion or the result captured in the draft. The draft just says that perhaps longer intervals should be applied to BFD when doing large packets – but this will defeat the purpose of fast-detection. What would be good is we have both fast-detection and slow PMTU validation? Perhaps we need some analysis of whether large packets should be used always or intermittently and the pros/cons or guidelines for the same? 1. The draft is missing an operational considerations and manageability considerations sections. Some of this info is placed in sec 3, but would help if things were elaborated in their individual sections. It would provide more insight into how exactly this mechanism in BFD is envisaged to be actually deployed and used. More importantly, perhaps how it should NOT be used? Can the authors and WG discuss the above? I think it seems too rushed to go for WGLC just as yet? Thanks, Ketan From: Rtg-bfd <rtg-bfd-boun...@ietf.org> On Behalf Of Reshad Rahman (rrahman) Sent: 09 September 2019 20:26 To: rtg-bfd@ietf.org Subject: Re: WGLC for draft-ietf-bfd-large-packets BFD WG, reminder that WGLC is ongoing for this document. Regards, Reshad. From: Rtg-bfd <rtg-bfd-boun...@ietf.org<mailto:rtg-bfd-boun...@ietf.org>> on behalf of "Reshad Rahman (rrahman)" <rrah...@cisco.com<mailto:rrah...@cisco.com>> Date: Tuesday, August 27, 2019 at 12:34 PM To: "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>> Subject: WGLC for draft-ietf-bfd-large-packets BFD WG, As was mentioned at IETF105, this document is stable and there was an interop test done between FRR and Junos VMX. Please provide comments/feedback on the document. The deadline for last call is September 13th. Regards, Reshad & Jeff.
