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) <ginsb...@cisco.com> > wrote: > > Naiming - > > Thanx for the good discussion. Responses inline. > > From: Naiming Shen (naiming) > Sent: Sunday, October 21, 2018 3:36 PM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com <mailto:ginsb...@cisco.com>> > Cc: Reshad Rahman (rrahman) <rrah...@cisco.com <mailto:rrah...@cisco.com>>; > rtg-bfd@ietf.org <mailto:rtg-bfd@ietf.org> > Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets > > > Les, > > On Oct 21, 2018, at 3:26 PM, Les Ginsberg (ginsberg) <ginsb...@cisco.com > <mailto:ginsb...@cisco.com>> wrote: > > Naiming – > > Inline… > > From: Naiming Shen (naiming) > Sent: Sunday, October 21, 2018 3:12 PM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com <mailto:ginsb...@cisco.com>> > Cc: Reshad Rahman (rrahman) <rrah...@cisco.com <mailto:rrah...@cisco.com>>; > rtg-bfd@ietf.org <mailto:rtg-bfd@ietf.org> > Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets > > > 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”. > > [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. J ) > > 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. > > [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. > > 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:-) > > > 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. > > [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? > > 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, > > [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 > > On Oct 20, 2018, at 5:14 PM, Les Ginsberg (ginsberg) <ginsb...@cisco.com > <mailto:ginsb...@cisco.com>> wrote: > > 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 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? > > Thanx. > > Les > > > From: Rtg-bfd <rtg-bfd-boun...@ietf.org <mailto:rtg-bfd-boun...@ietf.org>> On > Behalf Of Reshad Rahman (rrahman) > Sent: Wednesday, October 17, 2018 6:06 PM > To: rtg-bfd@ietf.org <mailto:rtg-bfd@ietf.org> > Subject: BFD WG adoption for draft-haas-bfd-large-packets > > 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/ > <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. Mahesh Jethanandani mjethanand...@gmail.com
