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

From: "Zafar Ali (zali)" <[email-masked]>
Date: Tue, 23 Oct 2018 04:50:21 +0000

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-masked]" <[email-masked]>
Date: Monday, October 22, 2018 at 6:19 PM
To: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>, "Ketan Talaulikar (ketant)" <[email-masked]>, "Zafar Ali (zali)" <[email-masked]>, "Carlos Pignataro (cpignata)" <[email-masked]>, "Clarence Filsfils (cfilsfil)" <[email-masked]>, "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
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

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 24 Oct 2018 11:08:55 -0700

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-masked]> 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.
>
>
>
> *From: *"[email-masked]" <[email-masked]>
> *Date: *Monday, October 22, 2018 at 6:19 PM
> *To: *"Nagendra Kumar Nainar (naikumar)" <[email-masked]>, "Ketan
> Talaulikar (ketant)" <[email-masked]>, "Zafar Ali (zali)" <
> [email-masked]>, "Carlos Pignataro (cpignata)" <[email-masked]>,
> "Clarence Filsfils (cfilsfil)" <[email-masked]>, "Nagendra Kumar
> Nainar (naikumar)" <[email-masked]>
> *Subject: *New Version Notification for
> draft-ali-spring-bfd-sr-policy-02.txt
>
>
>
>
>
> Title:                      Bidirectional Forwarding Detection (BFD) for
> Segment Routing Policies for Traffic Engineering
>
> 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:
>

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Wed, 24 Oct 2018 20:30:09 +0000

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-masked]> on behalf of Greg Mirsky <[email-masked]>
Date: Wednesday, October 24, 2018 at 2:09 PM
To: "Zafar Ali (zali)" <[email-masked]>
Cc: spring <[email-masked]>
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-masked]<mailto:[email-masked]>> wrote:
Hi Greg and the WG,

Thanks

Regards … Zafar

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 22, 2018 at 6:19 PM
To: "Nagendra Kumar Nainar (naikumar)" <[email-masked]<mailto:[email-masked]>>, "Ketan Talaulikar (ketant)" <[email-masked]<mailto:[email-masked]>>, "Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>>, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>, "Clarence Filsfils (cfilsfil)" <[email-masked]<mailto:[email-masked]>>, "Nagendra Kumar Nainar (naikumar)" <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-ali-spring-bfd-sr-policy-02.txt

Abstract:

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

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 25 Oct 2018 12:41:06 -0700

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-masked]> 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:
>
>
>
> *From: *spring <[email-masked]> on behalf of Greg Mirsky <
> [email-masked]>
> *Date: *Wednesday, October 24, 2018 at 2:09 PM
> *To: *"Zafar Ali (zali)" <[email-masked]>
> *Cc: *spring <[email-masked]>
> *Subject: *Re: [spring] FW: New Version Notification for
>    - 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.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 26 Oct 2018 04:18:03 +0000

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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Hope this clarifies.

Regards,
Nagendra

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 24, 2018 at 2:09 PM
To: "Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>>
Cc: spring <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] FW: New Version Notification for draft-ali-spring-bfd-sr-policy-02.txt

Hi Ali,

Regards,
Greg

Thanks

Regards … Zafar

Abstract:

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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring