Re: [spring] New Version Notification for draft-ali-spring-bfd-sr-policy-02.txt

["Carlos Pignataro (cpignata)" <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>> 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) <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> on behalf of Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, October 24, 2018 at 2:09 PM
To: "Zafar Ali (zali)" <[e-mail]<mailto:[e-mail]>>
Cc: spring <[e-mail]<mailto:[e-mail]>>
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) <[e-mail]<mailto:[e-mail]>> 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: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Monday, October 22, 2018 at 6:19 PM
To: "Nagendra Kumar Nainar (naikumar)" <[e-mail]<mailto:[e-mail]>>, "Ketan Talaulikar (ketant)" <[e-mail]<mailto:[e-mail]>>, "Zafar Ali (zali)" <[e-mail]<mailto:[e-mail]>>, "Carlos Pignataro (cpignata)" <[e-mail]<mailto:[e-mail]>>, "Clarence Filsfils (cfilsfil)" <[e-mail]<mailto:[e-mail]>>, "Nagendra Kumar Nainar (naikumar)" <[e-mail]<mailto:[e-mail]>>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spring