Dear All, I agree and subscribe to the proposal to discuss the problem and the possible solution based on BFD protocol. And adoption of this document, in my view, is a logical step. I may point out that RFC 6423 described the use of the existing BFD session providing connectivity verification over p2p bidirectional MPLS-TP LSP or PW (note that BFD, in fact, provides continuity check, not checking connectivity in transport network sense).
Regards, Greg On Tue, Oct 23, 2018 at 9:31 AM Acee Lindem (acee) <a...@cisco.com> wrote: > Hi Albert, Les, > > > > I tend to agree with Les that BFD doesn’t seem like the right protocol for > this. Note that if you use OSPF as your IGP and flap the interface when the > MTU changes, you’ll detect MTU mismatches immediately due to OSPF’s DB > exchange MTU negotiation. Granted, control plane detection won’t detect > data plane bugs resulting in MTU fluctuations but I don’t see this as a > frequent event. > > > > Thanks, > > Acee > > > > *From: *Rtg-bfd <rtg-bfd-boun...@ietf.org> on behalf of "Albert Fu > (BLOOMBERG/ 120 PARK)" <af...@bloomberg.net> > *Reply-To: *Albert Fu <af...@bloomberg.net> > *Date: *Tuesday, October 23, 2018 at 11:44 AM > *To: *"rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "Les Ginsberg (ginsberg)" < > ginsb...@cisco.com> > *Subject: *RE: BFD WG adoption for draft-haas-bfd-large-packets > > > > Hi Les, > > > > Given that it takes relative lengthy time to troubleshoot the MTU issue, > and the associated impact on customer traffic, it is important to have a > reliable and fast mechanism to detect the issue. > > > > I believe BFD, especially for single hop control-plane independent > situation (btw, this covers majority of our BFD use case), is indeed an > ideal and reliable solution for this purpose. It is also closely tied with > the routing protocols, and enable traffic to be diverted very quickly. > > > > The choice of BFD timer is also one of the design tradeoffs - low BFD > detection timer will cause more network churns. We do not need extremely > aggressive BFD timer to achieve fast convergence. For example, with > protection, we can achieve end to end sub-second convergence by using > relatively high BFD interval of 150ms. > > > > In the case where the path will be used for a variety of encapsulations > (e.g. Pure IP and L3VPN traffic), we would set the BFD padding to cater for > the largest possible payload. So, in our case, our link needs to carry a > mix of pure IP (1500 max payload) and MPLS traffic (1500 + 3 headers), we > would set the padding so that the total padded BFD packet size is 1512 > bytes. > > > > As you rightly pointed out, ISIS routing protocol does support hello > padding, but since this is a control plane process, we can not use > aggressive timer. The lowest hello interval the can be configured is 1s, so > with default multiplier of 3, the best we can achieve is 3s detection time. > > > > What we would like is a simple mechanism to validate that a link can > indeed carry the expected max payload size before we put it into > production. If an issue occurs where this is no longer the case (e.g. due > to outages or re-routing within the Telco circuit), we would like a > reliable mechanism to detect this, and also divert traffic around the link > quickly. I feel BFD is a good method for this purpose. > > > > Thanks > > Albert > > > > From: ginsb...@cisco.com At: 10/23/18 10:45:02 > > To: Albert Fu (BLOOMBERG/ 120 PARK ) <af...@bloomberg.net>, > rtg-bfd@ietf.org > Subject: RE: BFD WG adoption for draft-haas-bfd-large-packets > > Albert – > > > > Please understand that I fully agree with the importance of being able to > detect/report MTU issues. In my own experience this can be a difficult > problem to diagnose. You do not have to convince me that some improvement > in detection/reporting is needed. The question really is whether using BFD > is the best option. > > > > Could you respond to my original questions – particularly why sub-second > detection of this issue is a requirement? > > > > For your convenience: > > > > *<snip>* > > *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 **J) > 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?* > > *<end snip>* > > > > Thanx. > > > > Les > > > > > >
