Hi Ketan,
Thanks for the detailed feedback. > 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? Yes, our pain points are with commercial p2p MetroE circuits that span globally. Our use case is mainly with P2P circuits (eBGP/OSPF). Also, I should qualify that while we have standard 9K interface MTU in our core, we only plan to use this mechanism to detect the largest expected payload, being 1512 (1500 edge payload + up to 3 mpls headers), significantly less than the interface MTU. While our use case is for single hop P2P link (e.g. eBGP/OSPF), there may be potential use cases that are multihop that this draft can be useful. The draft is open ended in that sense, and let the users decide if it makes sense to use it. For example, we have some multi-hop RSVP LSPs that comprises of several p2p links that may not run any IGP protocol, where the BFD large packet could be useful. > 2. 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? It will be the latter, to keep BFD simple, instead of adding additional signaling. The operator will need to have method outside of this draft to determine if BFD large packet feature is supported. We have done similar thing when deploying certain features in our network. For example, we currently enable BFD strict mode on eBGP peers that we know are supported (platform and software version dependent). > 3. 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? I responded similar question not long ago. Our preference is to minimize changes with current BFD behavior with a mix of small and large BFD packets. Users will need to carry out scaling test to determine appropriate transmit rate based on desired packet size. In my use case, my preference will be to bring the link down as soon as we have determined that it is unable to carry the expected packet size, as this causes service impact. > 4. 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? Our use case is quite simple. We have a contract with our providers that their links can carry certain packet size (1512 IP Payload). The link was delivered and tested with this capability. However, the providers may fail to carry the expected payload size without warning due to HW/SW or config issue as current BFD/protocol keepalive packets are small. Application that sends the large packet size over the link would be dropped, causing service impact. It is time consuming to detect this error in a large network with lots of ECMP paths. We would like to use BFD to detect this issue quickly and divert traffic to working link that support the expected large packet size. This feature will help tremendously with minimizing service impact due to this issue. Thanks Albert
