Re: WGLC for draft-ietf-bfd-large-packets
Dear WG, My main comment about this draft was in respect to the solution not working well for ECMP paths and the latest version that it still remains to be the issue. I was hoping we could resolve it better (for example just like multipath traceroute does --> Hint: Paris Traceroute or maybe even Dublin Traceroute). None of those need to be implementation specific (like draft says in subsequent paragraph) and IMO BFD would really benefit from standardizing it. Quote from the document: *However, for testing forwarding over multiple hops, there is no such specified general purpose BFD mechanism for exercising all links in an ECMP. This may result in a BFD session being in the Up state while some traffic may be dropped or otherwise negatively impacted along some component links.* However clearly this is not really an issue with this specific document hence *I am supportive of progressing this work fwd.* I am hearing that ECMP support for BFD will be handled separately and that will be very useful (feature/fix). Kind regards, Robert On Thu, May 9, 2024 at 10:18 PM Reshad Rahman wrote: > > > BFD WG, > > This email (re)starts a 2 week Working Group Last Call for "BFD > encapsulated in large packets": > https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ > > > Please take the time to review the document and provide comments by May > 24th. Feedback such as "I believe the document is ready to advance" is also > welcome. > > FYI we did WGLC a few years ago, see previous discussions at > https://mailarchive.ietf.org/arch/msg/rtg-bfd/rjyxii23qp8-EQSZQ7d8631kMwY/ > > There is no known IPR for this document: > https://mailarchive.ietf.org/arch/msg/rtg-bfd/jaAjdrkePSocqvvcxt4ffx0NDg8/ > > https://mailarchive.ietf.org/arch/msg/rtg-bfd/0yfGFB-ywYQMQWledrRRLXhrVYY/ > > > Regards, > Reshad (co-chair). > > > > > >
Re: Progressing BFD unsolicited (failure thereof:-)
Tom, I have personally addressed most if not all of your comments. Do you see in version -07 used "aligned" or "explicitely" ? If something was not addressed it was based on the discussion with co-authors. Many thx, R. On Fri, Nov 26, 2021 at 1:27 PM t petch wrote: > On 15/10/2021 20:18, Jeffrey Haas wrote: > > Working Group, > > > > Now that the BFD YANG work is getting ready to pop out of the RFC > Editor's > > queue, it's an appropriate time to finish the last minor details for the > > BFD Unsolicited draft. > > > > Previously, the draft had exited Working Group Last Call with minor > things > > to be resolved, and a process question about where this draft should be > with > > regards to the standard process. Our conversation with our Area > Director at > > that time and other associated IESG members suggested that Proposed > Standard > > status was appropriate. > > > > Greg Mirsky had made a number of comments, several which have been at > least > > partially addressed in the current version of the draft. Note that the > top > > of the thread corresponds to the Working Group feedback during WGLC. > > > > > https://mailarchive.ietf.org/arch/msg/rtg-bfd/naYc-qtNmf8ZH2sRF8S76DqzgYc/ > > > > I encourage the Working Group to review the draft and the comments to > date. > > After resolving them, I believe we're ready to have a shepherd writeup > and > > send this to the IESG. > > Jeff > > My comments from 28oct21 and thereabouts, some of which were first made > in August 2020, have not been addressed (or are being ignored:-( > > The IANA Considerations registers a different prefix to that in the YANG > module; this is a showstopper. > > The Security Considerations for YANG modules are out-of-date. See the > pointer in YANG Guidelines, RFC8407. Fixing this will cause updates to > the I-D References. > > The reference to bfd-yang is out of date - it is an RFC now. > > YANG import MUST be Normative Reference (eg RFC8349) > > Tom Petch > > > - > > > > Addressing points Greg has raised: > > - "Does this document update RFC 5881?" > > > >In my opinion, we're introducing no procedural changes vs. RFC > 5880/5881. > >The passive mode documented in RFC 5880 is being leveraged. We're > simply > >not explicitly provisioning the session. Others in the WGLC thread > >support not marking this as an update. > > > > - "node-wise configuration" > > > >I believe that has been addressed in the current version of the draft. > > > > - Greg writes: "The fourth paragraph in Section 2 explains the handling > of > >the first BFD control packet with Your Discriminator == 0, i.e., "it > does > >not find an existing session with the same source address". What > happens > >if the matching BFD session has been found?" > > > >This case could use a small amount of normative text. For reference, > here > >is the text from RFC 5880, §6.8.6: > > > >: If the Your Discriminator field is zero, the session MUST be > >: selected based on some combination of other fields, possibly > >: including source addressing information, the My Discriminator > >: field, and the interface over which the packet was received. The > >: exact method of selection is application specific and is thus > >: outside the scope of this specification. If a matching session is > >: not found, a new session MAY be created, or the packet MAY be > >: discarded. This choice is outside the scope of this > >: specification. > > > >One easy possibility is that there is an existing session, or one > that may > >be failing shortly. Discarding the received packets in this > circumstance > >until there is no existing session might be an appropriate response. > > > > - Greg write: "Does that mean that there will be only one session > >with the same source address despite different destination addresses > >listed?" > > > >One point of comparison is that the single-hop BFD YANG module is > indexed > >on interface and destination address and not source address. > > > > - Greg writes: "the local BFD system assigns My Discriminator to the > >session. Though it is standard (RFC 5880) step, it might be useful to > >mention it." > > > >Since I don't think it brings clarity and distracts from "see the base > >RFC", I would suggest not mentioning it. > > > > - Greg asks about what happens to session state for a session that was > >passive and went down. > > > >Much like Greg, I believe this is an implementation detail but it's > one > >that has impact to things like YANG modules. Since single-hop > sessions > >are indexed based on interface and destination address, permitting > them to > >linger for some period of time might be useful with low danger of > being a > >denial of service vs. the operational state. This would permit a YANG > >notification sent for a session that went down to be able to query > >
Re: Minor nit from shepherd writeup to resolve for BFD unsolicted
I did added RFC9127 based on Jeff information (in many places of XML as
comment)
Fixed reference in the YANG to accommodate new number.
Fell free to comment it out so RFC editor can quickly adjust :)
Best,
R.
On Wed, Oct 20, 2021 at 8:19 PM Reshad Rahman wrote:
> Also, starting from rev-04 (I think) we incorrectly have RFC9127 as the
> reference for the revision. I will change it back to .
>
> revision 2021-10-15 {
> description "Initial revision.";
> reference "RFC 9127: A YANG data model for BFD unsolicited";
>}
>
>
> On Wednesday, October 20, 2021, 10:47:05 AM EDT, Jeffrey Haas <
> jh...@pfrc.org> wrote:
>
>
> $ pyang --ietf --max-line-length 69 ietf-bfd-unsolicited\@2021-10-15.yang
> ietf-bfd-unsolici...@2021-10-15.yang:17: warning: imported module
> "ietf-bfd" not used
> ietf-bfd-unsolici...@2021-10-15.yang:22: warning: imported module
> "ietf-bfd-ip-sh" not used
> ietf-bfd-unsolici...@2021-10-15.yang:128: warning: line length 71 exceeds
> 69 characters
>
> The following line needs to be split:
> "BFD IP single-hop interface unsolicited top level container";
>
>
>
Re: IPR attestation for draft-ietf-bfd-unsolicited
I am not aware of any IPR applicable to this draft. Many thx, R. On Wed, Oct 20, 2021 at 4:07 PM Jeffrey Haas wrote: > BFD Unsolicited Authors, > > As part of doing the document shepherd writeup for BFD Unsolicited prior > to sending it to the IESG for publication, I reviewed the archives to find > whether you had done your IPR attestations. > > You haven't, but were asked at the time. :-) > > Please respond to this thread as to whether you're aware of any IPR > applicable to this document. > > (Working Group participants, please do the same.) > > -- Jeff
Re: Progressing BFD unsolicited
Jeff, I have already added that text based on your previous comments. Is what is added not sufficient ? Many thx, R. PS. I will add Greg's suggestions latter today and repost to -05. " When on the passive side Unsolicited BFD sessions goes down an implementation MAY keep such session state for a configurable amount of time. Temporarily keeping such local state may permit retrieving additional operational information of such session which went down. On Tue, Oct 19, 2021 at 3:07 PM Jeffrey Haas wrote: > I have one minor additional tweak suggested to Greg's change. I think > once we converge on this point, I'll do the document shepherd report and > submit to the IESG. > > > On Oct 18, 2021, at 8:47 PM, Greg Mirsky wrote: > > Hi Robert and the Authors, > thank you for your kind consideration of my comments and for addressing > them so thoughtfully. I have two editorial suggestions that can be used, if > you decide so, at a later date: > >- as the text refers to the format of a BFD control message, then it >seems appropriate to s/"Discriminator"/"My Discriminator" >- Minor re-wording: > > OLD TEXT: > When on the passive side Unsolicited BFD sessions goes down an > implementation MAY keep such session state for a configurable amount > of time. Temporarily keeping such local state may permit retrieving > additional operational information of such session which went down. > NEW TEXT: > When a session goes down on the passive side of an Unsolicited BFD, > an implementation MAY keep such a state for a configurable amount of > time. Temporarily keeping such a local state may permit retrieving > additional operational information of such session which went down. > > > When an Unsolicted BFD session goes down, implementations MAY retain > the session state for a period of time, which may be configurable. > Retaining > this state can be useful for operational purposes. > > -- Jeff >
Re: Progressing BFD unsolicited
Hi Jeff & Greg, I have just submitted -04 version. I believe together with co-authors we have addressed all the comments received so far. https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/ Hope that we can move forward with this work. Kind regards, Robert On Fri, Oct 15, 2021 at 9:18 PM Jeffrey Haas wrote: > Working Group, > > Now that the BFD YANG work is getting ready to pop out of the RFC Editor's > queue, it's an appropriate time to finish the last minor details for the > BFD Unsolicited draft. > > Previously, the draft had exited Working Group Last Call with minor things > to be resolved, and a process question about where this draft should be > with > regards to the standard process. Our conversation with our Area Director > at > that time and other associated IESG members suggested that Proposed > Standard > status was appropriate. > > Greg Mirsky had made a number of comments, several which have been at least > partially addressed in the current version of the draft. Note that the top > of the thread corresponds to the Working Group feedback during WGLC. > > https://mailarchive.ietf.org/arch/msg/rtg-bfd/naYc-qtNmf8ZH2sRF8S76DqzgYc/ > > I encourage the Working Group to review the draft and the comments to date. > After resolving them, I believe we're ready to have a shepherd writeup and > send this to the IESG. > > - > > Addressing points Greg has raised: > - "Does this document update RFC 5881?" > > In my opinion, we're introducing no procedural changes vs. RFC 5880/5881. > The passive mode documented in RFC 5880 is being leveraged. We're simply > not explicitly provisioning the session. Others in the WGLC thread > support not marking this as an update. > > - "node-wise configuration" > > I believe that has been addressed in the current version of the draft. > > - Greg writes: "The fourth paragraph in Section 2 explains the handling of > the first BFD control packet with Your Discriminator == 0, i.e., "it does > not find an existing session with the same source address". What happens > if the matching BFD session has been found?" > > This case could use a small amount of normative text. For reference, > here > is the text from RFC 5880, §6.8.6: > > : If the Your Discriminator field is zero, the session MUST be > : selected based on some combination of other fields, possibly > : including source addressing information, the My Discriminator > : field, and the interface over which the packet was received. The > : exact method of selection is application specific and is thus > : outside the scope of this specification. If a matching session is > : not found, a new session MAY be created, or the packet MAY be > : discarded. This choice is outside the scope of this > : specification. > > One easy possibility is that there is an existing session, or one that > may > be failing shortly. Discarding the received packets in this circumstance > until there is no existing session might be an appropriate response. > > - Greg write: "Does that mean that there will be only one session > with the same source address despite different destination addresses > listed?" > > One point of comparison is that the single-hop BFD YANG module is indexed > on interface and destination address and not source address. > > - Greg writes: "the local BFD system assigns My Discriminator to the > session. Though it is standard (RFC 5880) step, it might be useful to > mention it." > > Since I don't think it brings clarity and distracts from "see the base > RFC", I would suggest not mentioning it. > > - Greg asks about what happens to session state for a session that was > passive and went down. > > Much like Greg, I believe this is an implementation detail but it's one > that has impact to things like YANG modules. Since single-hop sessions > are indexed based on interface and destination address, permitting them > to > linger for some period of time might be useful with low danger of being a > denial of service vs. the operational state. This would permit a YANG > notification sent for a session that went down to be able to query > information from the operational state portion of the module. > > If the authors agree, it might be worth a sentence or two mentioning that > session state may linger for an implementation-defined period of time for > management purposes. > > - Session changing from passive to active. > > This isn't a normative MAY. > > - TTL=255 only RECOMMENDED? > > RFC 5881 provides for circumstances where the send-side will always use > TTL 255 but validation on reception is optional. > > I would support Greg's point by suggesting that the text in the current > draft simply be updated to say "follow RFC 5881's GTSM procedures". > > - > > Other notes: > - The BFD YANG module references will be able to be filled out shortly as > RFC 9127. > > - Update dates appropriately
Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)
Hi Les, While shifting to Informational would be perhaps ok protocol wise - isn't it common practice in IETF that any draft (or at least most of them) which define a YANG model is a Standards Track document ? I hope you are not suggesting to split this one into two :). Thx, R. On Tue, Aug 18, 2020 at 5:36 AM Les Ginsberg (ginsberg) wrote: > Sorry to be tardy in responding... > > As I stated almost 2 years ago when this draft was introduced: > > a)The problem the draft is addressing is real and the solution useful > > b)There are implementations which have already addressed this problem with > no interoperability issues > > c)I do not see that any changes have been made to the BFD protocol (e.g. > RFC 5881) > > Therefore, I think this should go forward - but as Informational. > >Les > > > > -Original Message- > > From: Rtg-bfd On Behalf Of Jeffrey Haas > > Sent: Monday, August 17, 2020 1:45 PM > > To: rtg-bfd@ietf.org > > Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited > (ending 16 > > August, 2020) > > > > On Tue, Aug 04, 2020 at 09:21:22AM -0400, Jeffrey Haas wrote: > > > Working Group, > > > > > > https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/ > > > > > > With apologies to the authors of BFD unsolicited, this document is > past due > > > for Working Group Last Call. The primary holdup on the document had > > been > > > last minute interaction with the RFC Editor with regard to its impact > on the > > > BFD Yang model. That work had completed some time ago. (The Yang > > model, > > > however, is still lingering in MISREF state.) > > > > > > This begins a last call period ending on 16 August. > > > > The last call period has ended with a few comments from Greg and Raj that > > should be addressed before we continue. > > > > It'd also be helpful to hear from additional reviewers before we advance > > this document. > > > > -- Jeff > >
Re: [spring] Draft for Node protection of intermediate nodes in SR Paths
On Mon, Dec 2, 2019 at 10:28 AM Andrew Alston < andrew.als...@liquidtelecom.com> wrote: Currently the biggest issue that I see with S-BFD based protection – which > is something we use in production is as follows: > > > > Unless I’m mistaken – there is absolutely no way to tie S-BFD based > protection with BGP injected SR-TE pathing > Well I am not sure what you call " BGP injected SR-TE pathing" but if you are looking for validation of BGP paths that has been supported by some vendors for a lng time. Hint: you allocate different next hop for your SR-TE endpoints and voila. Btw - not an ietf topic, but an implementation request / vendor's feature. Besides, since you are talking about headend what you are describing is path protection ... this draft talks about node protection which is a completely different thing. Cheers, r. > Node validation as defined in the SR-TE drafts is limited to presence in > the IGP > > Since SR-TE path injection may be done through reflectors – using target > communities – the point of communication into the network is not > necessarily the head end of the tunnel and the point of injection may be > entirely unaware of the implications of the path that’s being inserted. > > > > By utilizing what is contained in this draft to build context tables at > the head end of an inserted tunnel on an automated basis – this solves a > problem that currently exists that S-BFD simply cannot solve without > modification to the srte policy insertion drafts that would allow for > automated building of S-BFD checks – which in and of itself could prove > challenging considering the complexity of this. > > > > That is not to say in any way that both s-bfd and potentially other > mechanisms do not have use cases – but as an operator – this draft would > certainly provide a better mechanism for constant path validation than > anything we currently have (which is based on steered packets that leave > the controller and return to the controller through the use of SR packets > and binding sids). > > > > Just my 2c > > > > Thanks > > > > Andrew > > > > > > *From:* spring *On Behalf Of *Shraddha Hegde > *Sent:* Monday, 2 December 2019 10:24 > *To:* Alexander Vainshtein > *Cc:* spr...@ietf.org; rtg-bfd@ietf.org; Robert Raszuk ; > rt...@ietf.org > *Subject:* Re: [spring] Draft for Node protection of intermediate nodes > in SR Paths > > > > Sasha, > > > > We are in agreement on separating the trigger from the protection > mechanism. > > > > > In any case I think that it woyld make sense to separate the protection > scheme proposed in the draft from specific triggers for its activation > >similar to how this has been done in MPLS Egress Protection Framework > draft. > > > > I’ll add text in the next revision for this. > > > > Rgds > > Shraddha > > > > > > *From:* Alexander Vainshtein > *Sent:* Monday, December 2, 2019 12:24 PM > *To:* Shraddha Hegde > *Cc:* spr...@ietf.org; rt...@ietf.org; rtg-bfd@ietf.org; Robert Raszuk < > rob...@raszuk.net> > *Subject:* Re: [spring] Draft for Node protection of intermediate nodes > in SR Paths > > > > Shraddha, > > Lots of thanks for athe tesponse. > > > > I probably did not express myself clearly enough. I will try to fix thst > now, and I apologise in advance for a long email. > > > > I have not been speaking about end-yo-end protecyion, only about local > protection against failure of an intermediate (a.k.a. pinned) node of an SR > path and, specifically, triggers for such protection. This context has been > actually defined by Robert in his original comment. > > > > To the best of my understanding, Robert's concern was that failure of the > link beteeen the pinned node of a SR path and its adjacency (the > penultimate node of the Segment represented by the Node SID of the pinned > node) is not a good enough indication of the pinned node failure. > > > > I agree with this statement even if my understanding of a good indication > differs from Robert's: > > - I think that it is not sufficiently specific and therefore could result > in flapping (local node protection activated and then released) > > -Robert's concern, to the best of my understanding, was that it could miss > some failures (e.g. the Fabric failure). > > > > Therefore I have suggested two possibilities for more specific and more > rrliabke detection of failure of the pinned node by its adjacency: > > > > 1. Run a multi-hop IP BFD session between the peniltimate node ans the > pinned ones using prefixes acting as Node SIDs of this pair. This wiuld >
Re: [spring] Draft for Node protection of intermediate nodes in SR Paths
I encourage you to read those two documents: https://tools.ietf.org/html/draft-akiya-bfd-seamless-sr-04 https://tools.ietf.org/html/draft-ali-spring-bfd-sr-policy-02 Cheers, R. On Mon, Dec 2, 2019 at 11:06 AM Andrew Alston < andrew.als...@liquidtelecom.com> wrote: > Robert – actually I disagree. > > > > Because to protect the paths you need the node protection on intermediate > nodes due to lack of state – the headend has no way to actually protect an > end to end path outside of S-BFD steered over the path to test end to end > reachability and if you get an intermediate node-failure on the path you > could run into a problem > > > > As per draft-ietf-spring-segment-routing-policy-05 a path is valid when: > > > > It is empty > > Its weight is 0 > > It’s headend is unable to perform path resolution for the first SID into > one or more outgoing interface(s) and next-hop(s) > > The headend is unable to perform SID resolution for any non-first SID of > type C through K into an MPLS label or an SRv6 SID > > The headend verification fails for any SID for which verification has been > explicitly requested > > > > Effectively – as of right now – if you read that draft – there is no > mechanism to verify path nodes if you are doing paths based on type A SID’s > – the only way right now to do that – is using S-BFD – however this draft > if my understanding is correct – would allow for node protection that would > in effect protect the paths injected. > > > > Thanks > > Andrew > > > > > > *From:* Robert Raszuk > *Sent:* Monday, 2 December 2019 12:50 > *To:* Andrew Alston > *Cc:* Shraddha Hegde ; Alexander > Vainshtein ; spr...@ietf.org; > rtg-bfd@ietf.org; rt...@ietf.org > *Subject:* Re: [spring] Draft for Node protection of intermediate nodes > in SR Paths > > > > On Mon, Dec 2, 2019 at 10:28 AM Andrew Alston < > andrew.als...@liquidtelecom.com> wrote: > > > > Currently the biggest issue that I see with S-BFD based protection – which > is something we use in production is as follows: > > > > Unless I’m mistaken – there is absolutely no way to tie S-BFD based > protection with BGP injected SR-TE pathing > > > > > > Well I am not sure what you call " BGP injected SR-TE pathing" but if you > are looking for validation of BGP paths that has been supported by some > vendors for a lng time. Hint: you allocate different next hop for your > SR-TE endpoints and voila. > > > > Btw - not an ietf topic, but an implementation request / vendor's feature.. > > > > Besides, since you are talking about headend what you are describing is > path protection ... this draft talks about node protection which is a > completely different thing. > > > > Cheers, > > r. > >
Re: BFD chair response to presentation on draft-mirmin-bfd-extended
Hi Dave, I’ve been quoted in the past that BGP, used as a transport, is “TCP with > beard.” It would have been trivial to split out the minimal semantics the > actual BGP protocol brought to the table. > BGP just because "it is there already" now transports link state database and one SAFI of it is being called a link state protocol. Just because it is there regardless of its p2mp nature is also being used for p2p configuration push including ACLs. It seems that BFD is heading the same way - again on the very same basis - "it is there" - so let's use it. > Part of the issue is that the IETF hasn’t bothered to put together a set > of generic transports to build things like this on top of. Spot on ! Except IETF does not ship router's code :). Vendors do. And till we see a generic transport perhaps ZeroMQ message bus like OpenR uses being shipped across at least few vendors existing protocols will get abused more and more ... Best, R.
Re: WGLC for draft-ietf-bfd-large-packets
Dear WG, Thank you Gyan for your note. It very clearly highlights my primary concern expressed earlier of false assumptions on how engineers may try to (mis)use bfd-large in multihop cases. Below note is a brilliant example of how one may not realize that actual paths BFD packets take can be just a fraction of paths their data plane or even other control plane packets may traverse over a network or set of networks. I am always concerned when protocol extensions being standardized are known to only work in 1 out of 10 deployment scenarios and when chances of such opportunity of incorrect use are evident yet no safety inline fuse exist. Many thx, Robert. On Thu, Oct 17, 2019 at 1:29 AM Gyan Mishra wrote: > All, > > I support this draft as I think this would be very useful for IPv6 use > cases where EH headers are utilized excessively such as for an SRv6 use > case for traffic engineering over the internet and would be a method to > test via BFD multihop the path mtu where pmtud has failed to adjust MSS on > endpoints due to firewalls or other devices dropping ICMP unreachable > packet to big messages resulting in 1280 mtu. >
Re: Rtg-bfd Digest, Vol 163, Issue 25
Hi Jeff, > That said, Robert, there's room for you to work on that if you want to kick > off a draft on the topic. Thx for the hint, but I do not think this extension should be done in BFD for three reasons: Reason 1 - BFD works well to quickly detect failures. Loading on it more stuff compromises it. Moreover other vendors already have shipping tools which already can detect issues due to changes in MTU of the paths: Example: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipsla/configuration/xe-16-6/sla-xe-16-6-book/sla-icmp-pathecho.html Reason 2 - As the draft states that the idea is to automate use of this extension by client protocols. I do not agree with such deployment model of this enhancement. At most if frequency of MTU probing would be 100-1000 times less frequent then up/down link detection it would serve its purpose - yet there is no word in the draft about such option. Essentially instead of replacing current tiny BFD packets one could use bfd-large as different sessions with completely different timers. Maybe even end to end instead of link by link. Reason 3 - As we know BFD is very often used between ASes. How do you signal over p2p link willingness to now encapsulate BFD in stuffed UDP ? Email ? Phone ? Text ? Note that with mentioned icmp pathecho I can seamlessly detect issue with MTU of the link to my peer without telling anyone or asking for support of the other side. Thx, Robert. On Thu, Oct 3, 2019 at 9:34 PM Jeffrey Haas wrote: > On Tue, Oct 01, 2019 at 11:11:13PM -, Albert Fu (BLOOMBERG/ 120 PARK) > wrote: > > There are well known cases, including those you mentioned, where BFD has > > limitations in deterministically detecting data plane issue, and not > > specific with the BFD Large Packet Draft. I am a novice to the IETF > > process, and not sure if we need to mention them here, but shall discuss > > with Jeff if it is worth highlighting them. > > It's reasonable to make note of issues where common operational scenarios > will complicate the solution. But it's not up to a draft carried on top of > an RFC with that core issue to try to solve the issue in that core RFC. > > So, trying to solve "BFD doesn't work perfectly in the presence of LAGs" in > bfd-large is the wrong place to do it. :-) > > That said, Robert, there's room for you to work on that if you want to kick > off a draft on the topic. > > > > We won't have control over how the Provider maps our traffic > (BFD/data). > > > > > Well of course you do :) Just imagine if your BFD packets (in set > equal to configured multiplier) would start > > > using random UDP source port which then would be mapped to different > ECMP buckets along the way in provider's > > > underlay ? > > And that's an example of possible solution space for such a draft on the > underlying issue. > > That said, LAG fan-out issues are a massive operational pain. While it's > likely that varying L3 PDU fields for entropy to distribute traffic across > the LAG may work (and we have any number of customers who rely on this for > UDP especially), it starts getting very problematic when you have multiple > LAGs in a path. I have a vague memory that someone had started some > discussions with IEEE to try to figure out what OAM mechanisms would look > like for such scenarios, but that's very much out of normal BFD scope. > > -- Jeff >
Re: Rtg-bfd Digest, Vol 163, Issue 25
Hi Albert, Thank you for sharing the experience and your use case. However when we make any protocol extension we need to make sure all possible deployment cases are covered and it must be well understood how the proposed extension will operate in basic deployment scenarios I enumerated. I really do not think we should be standardizing extension for single use case based on the behavior someone is reporting as "likely to occur". We all agree that if you have a p2p fiber link between routers there is no issue. The issue surface when you are using emulated circuits as your p2p links. So the solution should allow to detect the problem in all cases it can happen. Perhaps BFD is not the right tool for this. Perhaps we need to go back to BESS WG and report that VPWS or EVPN based p2p emulated circuits were not design right as they exhibit observed issues. > We won't have control over how the Provider maps our traffic (BFD/data). Well of course you do :) Just imagine if your BFD packets (in set equal to configured multiplier) would start using random UDP source port which then would be mapped to different ECMP buckets along the way in provider's underlay ? Kind regards, Robert. On Mon, Sep 30, 2019 at 6:11 AM Albert Fu (BLOOMBERG/ 120 PARK) < af...@bloomberg.net> wrote: > Hi Robert, > > > > Imagine two scenarios which were already highlighted as justification for > > this work: > > > *Scenario 1 -* IGP with nodes interconnected with ECMP links > > > *Scenario 2 -* IGP nodes interconnected with L2 emulated circuits which > in > > turn are riding on telco IP network with ECMPs or LAGs. > > > *Questions Ad 1 - * > > > Is the idea to use in those cases "ECMP-Aware BFD for LDP LSPs" vendor's > > feature to be able to detect MTU issues on any of the L3 paths ? Is there > > feature extension to accomplish the same without LDP just when using ECMP > > with OSPF ? > The draft does not go into the specific use cases. I think most BFD uses > cases (certainly in our case) are on p2p IGP/eBGP links. (btw some vendors > do not support control-plane BFD independence for multihops BFD, making it > unreliable for fast detection). > > > The end to end paths may have multiple multiple-ECMP links/paths. The BFD > sessions on the individual link along the path will detect large packet > issue. > > > > How do you solve this when there is L2 LAG hashing across N links > enabled ? > This is a situation where you need more than standard BFD. It is a reason > why some customers like us prefer not to run LAG on parallel WAN circuits, > so we can diagnose interface issues easily via standard tools like ping. It > is a design compromise. > > > > > *Question Ad 2 - * > > > How do you detect it if your L2 circuit provider maps BFD flows to one > > underlay path and some encapsulated data packets is hashed to traverse > the > > other path(s) ? Clearly running multiple BFD sessions is not going to > help > > much in this scenario For example if someone is using v6 flow label > it > > may be directly copied to the outer service header. > We won't have control over how the Provider maps our traffic (BFD/data). > In my experience, the chances of this happening is prob small based on my > involvement with all of these issues, in that when the issue happened, all > packets > certain size would fail, not some getting through and some > failing. > > > Thanks > > Albert > > >
Re: WGLC for draft-ietf-bfd-large-packets
Hi Jeff, Imagine two scenarios which were already highlighted as justification for this work: *Scenario 1 -* IGP with nodes interconnected with ECMP links *Scenario 2 -* IGP nodes interconnected with L2 emulated circuits which in turn are riding on telco IP network with ECMPs or LAGs. *Questions Ad 1 - * Is the idea to use in those cases "ECMP-Aware BFD for LDP LSPs" vendor's feature to be able to detect MTU issues on any of the L3 paths ? Is there feature extension to accomplish the same without LDP just when using ECMP with OSPF ? How do you solve this when there is L2 LAG hashing across N links enabled ? *Question Ad 2 - * How do you detect it if your L2 circuit provider maps BFD flows to one underlay path and some encapsulated data packets is hashed to traverse the other path(s) ? Clearly running multiple BFD sessions is not going to help much in this scenario For example if someone is using v6 flow label it may be directly copied to the outer service header. Many thx, Robert. On Thu, Sep 26, 2019 at 9:46 PM Jeffrey Haas wrote: > Les, > > On Tue, Sep 24, 2019 at 10:48:51PM +, Les Ginsberg (ginsberg) wrote: > > A few more thoughts - maybe these are more helpful than my previous > comments - maybe not. I am sure you will let me know. > > > > Protocol extensions allowing negotiation and/or advertisement of support > for larger PDUs may well be useful - but let's agree that it is desirable > to deploy this without protocol extensions just to keep the > interoperability bar low. > > > > My primary angst is with the following paragraph in Section 3: > > > > "It is also worthy of note that even if an implementation can function > >with larger transport PDUs, that additional packet size may have > >impact on BFD scaling. Such systems may support a lower transmission > >interval (bfd.DesiredMinTxInterval) when operating in large packet > >mode. This interval may depend on the size of the transport PDU." > > > > Given long experience that CPU use correlates more highly with number of > packets than with number of bytes, the first sentence would seem to be > weakly supported. > > Given the previously mentioned concerns about detection time, the second > sentence seems to compromise the value of the extension. > > My experience is largely identical to yours. > > The motivation for mentioning anything at all here is TANSTAAFL[1], and > we've already had people ask about possible impacts. And, as we discussed > previously in the thread we shall inevitably get asked about it during TSV > review in IESG. > > The primary reason this is a "may" in the non-RFC 2119 sense is that our > experience also suggests that when the scaling impacts are primarily pps > rather than bps that this feature will likely have no major impact on > implementations beyond your valid concerns about exercising bugs. > > I suspect had this not been mentioned at all, you would have been happier. > But you're not the target audience for this weak caveat. > > > What might be better? > > > > 1)Some statement that MTU isn't necessarily a consistent value for all > systems connected to an interface - which can impact the results when large > BFD packets are used. Implementations might then want to consider > supporting "bfd-mtu" configuration and/or iterating across a range of > packet sizes to determine what works and what doesn't. > > I'm not clear what you intend by this statement. > > Are you asking that we emphasize the use case in a different way? The > Introduction currently states: > "However, >some applications may require that the Path MTU [RFC1191] between >those two systems meets a certain minimum criteria. When the Path >MTU decreases below the minimum threshold, those applications may >wish to consider the path unusable." > > I'm also unclear what "Implementations" may refer to here. BFD? An > arbitrary user application? If the latter, the application may not have > strict control over the generation of a given PDU size; e.g. TCP > applications. > > > 2)Use of both padded and unpadded packets in combination with > draft-ietf-bfd-stability to determine whether a BFD failure is due to > padding or a generic forwarding failure. > > > > Either of these suggestions are really "diagnostic modes" which may help > diagnose a problem but aren't meant to be used continuously as part of fast > failure detection. > > We could certainly add a paragraph or two as an application note about > using > this for BFD stability purposes as well. > > -- Jeff > >
