Hi Nagendra, yes, you're correct and I was not, thank you for pointing that out. Indeed, Echo mode, whether BFD or S-BFD, may be used as the test probe to help with the characterization of the defect. But such use of Echo will increase the load on the sender and the network. As that is the price, perhaps going for a complete system based on RFC 8403 will give an operator the localization of the failure. Of course, all modes are optional. What I was pointing out with my comment, that BFD has some advantage, at least by the ability to control the reverse direction of the session.
Regards, Greg On Wed, Oct 24, 2018 at 1:30 PM Nagendra Kumar Nainar (naikumar) < [email protected]> wrote: > Hi Greg, > > > > Thank you for your comments. The section defining controlled return path > is using S-BFD Echo that is defined in section 10 of RFC7880. As you may be > aware, echo packets are self-generated/terminated. It does not mandate to > use YD as SBFDReflector id. Since the echo packet is not > inspected/processed by any nodes other than the Initiator, the details > included such as MD/YD (or any details in the control packet) are a local > implementation matter. A snip from section 10 below: > > > > The following aspects of S-BFD Echo functions are left as > > implementation details and are outside the scope of this document: > > > > o Format of the S-BFD Echo packet (e.g., data beyond UDP header). > > o Procedures on when and how to use the S-BFD Echo function. > > > > Hope this clarifies. > > > > Regards, > > Nagendra > > > > > > *From: *spring <[email protected]> on behalf of Greg Mirsky < > [email protected]> > *Date: *Wednesday, October 24, 2018 at 2:09 PM > *To: *"Zafar Ali (zali)" <[email protected]> > *Cc: *spring <[email protected]> > *Subject: *Re: [spring] FW: New Version Notification for > draft-ali-spring-bfd-sr-policy-02.txt > > > > Hi Ali, > > thank you for your kind consideration of my comments. I've read the new > version and section 3.3 in particular. Please kindly consider my comments: > > - I recall that the idea to construct SR tunnel through the network to > terminate at the sender discussed in RFC 8403; > - if the test probe with the label stack as {B, C, D, C, A} is the > S-BFD control packet, the SBFDInitiator will not receive a single S-BFD > packet. In other words, the proposed approach to control the return path > will break the S-BFD because SBFDReflector does not receive the S-BFD > packet as it passes through until the specified SR tunnel been crossed.. > - Another problem of the proposed solution is that the S-BFD control > packet received by SBFDInitiator has the destination UDP port 7784 and the > value of Your Discriminator is the one advertised, explicitly or > implicitly, by SBFDReflector, not SBFDInitiator. > > In summary, I conclude that the approach proposed in section 3.3 is not > technically viable and cannot address my earlier comments. > > > > Regards, > > Greg > > > > On Mon, Oct 22, 2018 at 9:50 PM Zafar Ali (zali) <[email protected]> wrote: > > Hi Greg and the WG, > > > > We have update draft-ali-spring-bfd-sr-policy to address comments we > received on the list or during WG session presentation. This includes > comment on controlling the return path. > > > > Can you please review the changes and advise of your comments? > > > > Thanks > > > > Regards … Zafar > > > > *From: *"[email protected]" <[email protected]> > *Date: *Monday, October 22, 2018 at 6:19 PM > *To: *"Nagendra Kumar Nainar (naikumar)" <[email protected]>, "Ketan > Talaulikar (ketant)" <[email protected]>, "Zafar Ali (zali)" < > [email protected]>, "Carlos Pignataro (cpignata)" <[email protected]>, > "Clarence Filsfils (cfilsfil)" <[email protected]>, "Nagendra Kumar > Nainar (naikumar)" <[email protected]> > *Subject: *New Version Notification for > draft-ali-spring-bfd-sr-policy-02.txt > > > > > > A new version of I-D, draft-ali-spring-bfd-sr-policy-02.txt > > has been successfully submitted by Nagendra Kumar Nainar and posted to the > > IETF repository. > > > > Name: draft-ali-spring-bfd-sr-policy > > Revision: 02 > > Title: Bidirectional Forwarding Detection (BFD) for > Segment Routing Policies for Traffic Engineering > > Document date: 2018-10-22 > > Group: Individual Submission > > Pages: 11 > > URL: > https://www.ietf.org/internet-drafts/draft-ali-spring-bfd-sr-policy-02.txt > > Status: > https://datatracker.ietf.org/doc/draft-ali-spring-bfd-sr-policy/ > > Htmlized: > https://tools.ietf.org/html/draft-ali-spring-bfd-sr-policy-02 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ali-spring-bfd-sr-policy > > Diff: > https://www.ietf.org/rfcdiff?url2=draft-ali-spring-bfd-sr-policy-02 > > > > Abstract: > > Segment Routing (SR) allows a headend node to steer a packet flow > > along any path using a segment list which is referred to as a SR > > Policy. Intermediate per-flow states are eliminated thanks to source > > routing. The header of a packet steered in an SR Policy is augmented > > with the ordered list of segments associated with that SR Policy. > > Bidirectional Forwarding Detection (BFD) is used to monitor different > > kinds of paths between node. BFD mechanisms can be also used to > > monitor the availability of the path indicated by a SR Policy and to > > detect any failures. Seamless BFD (S-BFD) extensions provide a > > simplified mechanism which is suitable for monitoring of paths that > > are setup dynamically and on a large scale. > > > > This document describes the use of Seamless BFD (S-BFD) mechanism to > > monitor the SR Policies that are used for Traffic Engineering (TE) in > > SR deployments. > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
