Greg, The use of an RFC 8403 approach has nothing to do with the protocol used for CC:
https://tools.ietf.org/html/rfc8403#page-5 returning ping or traceroute packets. Packets from a variety of protocols can be used to check continuity. These include Internet Control Message Protocol (ICMP) [RFC0792] [RFC4443] [RFC4884] [RFC4950], Bidirectional Forwarding Detection (BFD) [RFC5884], Seamless Bidirectional Forwarding Detection (S-BFD) [RFC7880] [RFC7881] (see Section 3.4 of [RFC7882]), and MPLS LSP ping [RFC8029]. They can also have any other OAM format supported by the Thanks, — Carlos Pignataro On Oct 25, 2018, at 3:41 PM, Greg Mirsky <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[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]<mailto:[email protected]>> on behalf of Greg Mirsky <[email protected]<mailto:[email protected]>> Date: Wednesday, October 24, 2018 at 2:09 PM To: "Zafar Ali (zali)" <[email protected]<mailto:[email protected]>> Cc: spring <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Monday, October 22, 2018 at 6:19 PM To: "Nagendra Kumar Nainar (naikumar)" <[email protected]<mailto:[email protected]>>, "Ketan Talaulikar (ketant)" <[email protected]<mailto:[email protected]>>, "Zafar Ali (zali)" <[email protected]<mailto:[email protected]>>, "Carlos Pignataro (cpignata)" <[email protected]<mailto:[email protected]>>, "Clarence Filsfils (cfilsfil)" <[email protected]<mailto:[email protected]>>, "Nagendra Kumar Nainar (naikumar)" <[email protected]<mailto:[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<http://tools.ietf.org/>. The IETF Secretariat _______________________________________________ spring mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
