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
