Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed

["Andrew G. Malis" <[e-mail]>]

Adrian,

I believe you meant RFC 7110, not 7710, which is a very different beast
indeed. :-)

Cheers,
Andy


On Thu, Aug 18, 2016 at 6:09 AM, Adrian Farrel <[e-mail]> wrote:

> Greg,
>
>
>
> I'm disappointed by the last sentence of your email. This a WG last call:
> its purpose is to determine whether the WG supports the proposed solution.
> IIRC the reason for this second WG last call is that the WG chairs were
> unable to determine consensus from the first call.
>
>
>
> I'm sure it isn't your intention, but your email appears to read, "Let's
> not debate the problem and direction of the solution because they are not
> up for discussion."
>
>
>
> Obviously you and Carlos have a disagreement about the need for this work
> and the way the requirements are expressed. Personally, I've got lost in
> the details of your discussion (not helped by the way the HTML mail
> presents, below). I suspect that a lot of the problem is around scoping of
> the problem because RFC 7710 was generally welcomed by the WG, and the
> fundamentals are surely not so different (although maybe I'm wrong since
> the IPR disclosures are different).
>
>
>
> I also suspect that there are some linguistic confusions between the two
> of you. Sometimes this can be mitigated by rephrasing and using more words.
> As a case in point, Carlos originally objected to "Bidirectional Forwarding
> Detection (BFD) is expected to monitor bi-directional paths," noting that,
> "BFD also is expected to monitor unidirectional paths." The two statements
> are not actually contradictory and one could say (without damaging the
> value of the document), "BFD is designed to monitor unidirectional and
> bidirectional paths."
>
>
>
> In fact, as we discovered while working on RFC 7710, the false negative
> may result precisely from using the reverse (co-routed or not) path. So the
> value of controlling the return path is to help diagnose whether the fault
> is on the outbound path or the return path, and this applies equally to
> unidirectional paths and bidirectional paths.
>
>
>
> Adrian
>
>
>
> *From:* mpls [mailto:[e-mail]] *On Behalf Of *Gregory Mirsky
> *Sent:* 17 August 2016 23:19
> *To:* Carlos Pignataro (cpignata)
> *Cc:* [e-mail]; mpls; [e-mail]
>
> *Subject:* Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed
>
>
>
> Hi Carlos,
>
> I believe that new version of the draft addresses all technical comments
> and now are discussing what each of us believes and how we interpret this
> or that IETF document. While this is very enlightening and I enjoy this
> discussion very much I don’t see that I can change how you see the problem
> this proposal addresses. The MPLS WG had agreed that the problem is real
> and the proposed solution, within the scope defined, is technically sound.
>
>
>
> Regards,
>
>         Greg
>
>
>
>
>
>
>
> *From:* Carlos Pignataro (cpignata) [mailto:[e-mail]]
> *Sent:* Tuesday, August 16, 2016 10:02 AM
> *To:* Gregory Mirsky <[e-mail]>
> *Cc:* Martin Vigoureux <[e-mail]>; mpls <[e-mail]>;
> [e-mail]; [e-mail]
> *Subject:* Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed
>
>
>
> Hi, Greg,
>
>
>
> I think we got to the source of the technical disagreement. Please find
> some closing comments inline.
>
>
>
> On Aug 16, 2016, at 12:22 PM, Gregory Mirsky <[e-mail]>
> wrote:
>
>
>
> Hi Carlos,
>
> thank you for clarification of your concerns. Please find my notes in-line
> and tagged GIM3>>.
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> *From:* Carlos Pignataro (cpignata) [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* Tuesday, August 16, 2016 6:14 AM
> *To:* Gregory Mirsky <[e-mail]>
> *Cc:* Martin Vigoureux <[e-mail]>; mpls <[e-mail]>;
>  [e-mail]; [e-mail]
> *Subject:* Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed
>
>
>
> Hi, Greg,
>
>
>
> Thank you for the follow-ups. Let me explain a couple of the key concerns
> top-posting, with more responses inline.
>
>
>
> One of the main technical concerns that I have is that segment routing
> being a loosely source-routed paradigm, there may not even be a
> bidirectional co-routed path.
>
> GIM3>> I don’t think that your characterization of the Segment Routing as
> mandating use only loosely source-routed paths is entirely accurate. As in
> RSVP-TE, source-routed paths may be loosely or strictly source-routed.
> Excluding option to construct strictly source-routed paths, in my opinion,
> would significantly limit scope of the Source Routing technology.
>
>
>
> Take the extreme case of a stack in the forward direction with a single
> Node SID, PE to PE, and shortest path in-between. Or the case of Parallel
> Link SIDs with varied weights in different links. How are you providing a
> return path?
>
> GIM3>> Authors do not claim that the proposed solution applies to all
> scenarios there could be in source routing. I think that has been already
> clarified in the text and in our discussion.
>
>
>
> Conversely, this potentially seems to apply to a grossly small and limited
> set of scenarios, if any, yet those scenarios are not discussed in the
> document, and are not defined to my knowledge in any SPRING document —
> other than a mention in RFC 7855 of:
>
>
>
>    It is obvious that, in the case of long, strict source-routed paths,
>
>    the deployment is possible if the head-end of the explicit path
>
>    supports the instantiation of long explicit paths.
>
>
>
> which seems to refer to Node strictness and not necessarily Link
> strictness, and there is nothing in draft-ietf-spring-segment-routing-09.
>
>
>
>
>
> Can you please point to a definition of a co-routed path for Segment
> Routing from the segment routing architectural documents?
>
> GIM3>> The proposal does not use bi-directional co-routed Segment Routed
> tunnels as such construct doesn’t yet exists (though in earlier discussions
> there was some interest in investigating use case for it). On the other
> hand, definition of co-routedness can be found in MPLS-TP as “co-routed,
> meaning both directions follow the same path, i.e. traversing the same set
> of nodes and links”.
>
>
>
> There’s no mention of MPLS-TP or SPRING-TP in SPRING docs either that I
> could find.
>
>
>
> If a SPRING stack includes a long set of Node SIDs, each one for each hop,
> still multiple-links between nodes are not specified and therefore it is
> not clear how to provide the exact return path (when the link taken is
> unknown). If the problem space is limited to the case in which for each
> hop, both Node SID and Adj SID are included, no Anycast, no Parallel Link
> SID, etc., then practicality seems to get in the way.
>
>
>
>
>
> The second main concerns has to do with the proposed use of Labels (which
> can change) instead of FECs (like RFC 7110).
>
> GIM3>> Authors believe that this is workable solution and the return path
> for the BFD session identified by BFD Discriminator TLV may be re-signaled
> without affecting state of the session.
>
>
>
>
>
> There could perhaps be a use of specifying a return path in this case.
> However, I believe the use is not the scenario targeted, and it is not
> specifying data plane labels numerically.
>
>
>
> These two seem to be major technical obstacles to the draft.
>
>
>
>
>
> Please note there were some additional comments inline, but centered
> around the same set of topics.
>
>
>
> Thanks,
>
>
>
> — Carlos.
>
>
>
> On Aug 10, 2016, at 3:34 PM, Gregory Mirsky <[e-mail]>
> wrote:
>
>
>
> Hi Carlos,
>
> thank you for your comments. I hope I understand your concerns better and
> am able to address them. Please find my follow up notes in-line tagged
> GIM2>>.
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> *From:* Carlos Pignataro (cpignata) [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* Tuesday, August 09, 2016 9:14 PM
> *To:* Gregory Mirsky <[e-mail]>
> *Cc:* Martin Vigoureux <[e-mail]>; mpls <[e-mail]>;
>  [e-mail]; [e-mail]
> *Subject:* Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed
>
>
>
> Hi Greg,
>
>
>
> Thanks for the response — please find some follow-ups inline.
>
>
>
> On Jul 25, 2016, at 5:06 PM, Gregory Mirsky <[e-mail]>
> wrote:
>
>
>
> Hi Carlos,
>
> thank you for your comments. Please see my responses in-line and tagged
> GIM>>.
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> *From:* mpls [mailto:[e-mail] <[e-mail]>] *On
> Behalf Of *Carlos Pignataro (cpignata)
> *Sent:* Saturday, July 16, 2016 8:35 AM
> *To:* Martin Vigoureux <[e-mail]>
> *Cc:* mpls <[e-mail]>; [e-mail]; [e-mail]
> *Subject:* Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed
>
>
>
> Hi, Martin,
>
>
>
> Admittedly, I had not read or followed this document before. However, I
> just scanned through it, and I Have at best some fundamental questions and
> likely some major issues and concerns. I wonder also if you need to Cc the
> BFD WG, copying the chairs on this response. Copying also SPRING chairs for
> awareness.
>
>
>
> I hope these are useful to this WGLC.
>
>
>
> *Major Concerns:*
>
>
>
> As I said, I just glanced through the document, and found these issues,
> questions, or problems.
>
>
>
> *1. Motivation for the work.*
>
>
>
> Uni or bi-directional? The document starts with a fallacy, setting the
> tone for the document, on the very first sentence:
>
>
>
> *Abstract*
>
>
>
> *   Bidirectional Forwarding Detection (BFD) is expected to monitor bi-*
>
> *   directional paths.*
>
>
>
> This is absolutely not the case, as explained in RFC 5880 Section 2, RFC
> 5883 Section 4.3 (https://tools.ietf.org/html/rfc5883#section-4.3), and
> many other places.
>
> GIM>> I think that you refer to the following text in RFC 5880:
>
>
>
> Not specifically, not only.
>
>
>
> My point is that the very first sentence contradicts standards tracks BFD
> RFCs. BFD also is expected to monitor unidirectional paths.
>
>
> GIM2>> Would the following change address your concern:
>
> OLD
>
> Bidirectional Forwarding Detection (BFD) is expected to monitor bi-
> directional paths. When a BFD session monitors an explicit routed    path
> there is a need to be able to direct egress BFD peer to use specific path
> for the reverse direction of the BFD session.
>
> NEW
>
> Bidirectional Forwarding Detection (BFD) is expected to monitor any kind
> of paths between systems. When a BFD session monitors an explicitly routed
> uni-directional path there may be a need to direct egress BFD peer to use
> specific path for the reverse direction of the BFD session.
>
>
>
>
>
> Since segment routing uses a loose source-routing paradigm, there may not
> be explicitly routed or a reverse direction.
>
>
>
>    BFD can provide failure detection on any kind of path between
>
>    systems, including direct physical links, virtual circuits, tunnels,
>
>    MPLS Label Switched Paths (LSPs), multihop routed paths, and
>
>    unidirectional links (so long as there is some return path, of
>
>    course).
>
> And this is exactly what motivated the work we’re discussing. Consider the
> situation when the return path, though temporarily, is not available.
> Consider scenario when node A sends BFD control packets over an LSP to node
> B and the node B sends its BFD packets over out of band return path, e.g.
> IP network.  If the loss of continuity between B and A lasts long enough to
> will detect failure. Should such failure be interpreted as indication of
> the failure on the monitored LSP or not?
>
>
>
> But this is irrespective of wether the return path is explicit or not, or
> even if the return path is via some out of band channel. A different way,
> this is also the case for BFD multihop over plain IP (on a tunnel one way,
> hop-by-hop routed on the return).
>
>
>
> GIM2>> True, but we’re not solving these other scenarios, only those where
> monitored path is explicitly routed. We can add explicit statement listing
> out of the scope scenarios.
>
>
>
>
>
> See above.
>
>
>
>
>
> The second paragraph in the Introduction section explains the scenario
> when an explicitly routed LSP being monitored while the return path is over
> IP network that is based the shortest path paradigm.
>
>
>
> The fact that the return path goes over the same links as the forward path
> does not mean that the return path is misprogrammed but the forward path is
> correctly programmed.
>
> GIM2>> The purpose of making BFD session use co-routed path is not to
> verify how it is instantiated in LFIB on a LSR. That is the task for defect
> localization, not defect detection OAM. Would you agree?
>
>
>
> I still believe that the motivation and use case is not well defined or
> explained.
>
>
> GIM2>> I’ll keep trying.
>
>
>
> The sentence that follows says:
>
>
>
> *   When a BFD session monitors an explicit routed*
>
> *   path there is a need to be able to direct egress BFD peer to use*
>
> *   specific path for the reverse direction of the BFD session.*
>
>
>
> The question is — why is there that need?
>
> GIM>> Please see my comment above.
>
>
>
>
>
> I still believe this is a bit of a non sequitur. Why does BFD monitoring
> an explicit routed path imply a need to direct the egress on a path for the
> reverse direction? That’s not generally a “need” in all situations.
>
> GIM2>> Please see modified Abstract above. It uses “may be a need”
>
>
>
> I think the passive voice hides precision needed.
>
>
>
> The document then goes on to say:
>
>
>
> *2.  Problem Statement*
>
>
>
> *   BFD is best suited to monitor bi-directional co-routed paths.*
>
>
>
> But: First, why is this the case? the BFD specifications do not say so.
>
> GIM>> If the paths used by forward and return paths are not co-routed that
> may create ambiguous situation when interpreting failure detection on the
> node that sends BFD control packets onto the monitored path, e.g. LSP.
>
>
>
>
>
> First, the same ambiguity exists with bi-directional co-routed paths —
> because links and nodes are not the only resources that need to be common.
> FIBs can be programmed well on one direction and wrongly on the reverse.
>
> GIM2>> BFD, as other continuity check protocols, only performs defect
> detection. Defect localization and characterization usually performed with
> other tools. But having co-routed path for a test session reduces, not
> eliminates but reduces, ambiguity of defects of the reverse path.
>
>
>
> Can you please point to a definition of a co-routed path for Segment
> Routing from the segment routing architectural documents?
>
>
>
> Or are you defining that here?
>
>
>
> Second, again, why “best suited”? If the BFD specs say that BFD can
> monitor unidirectional paths (including MPLS LSPs and unidirectional
> links), seems BFD is not necessarily “best suited to…"
>
> GIM2>> BFD certainly can and being used to monitor uni-directional paths.
> And usually we don’t think of how the reverse path may affect defect
> detection or, in case of PM OAM, measured performance metric. Having test
> session on bi-directional co-routed path makes the test result
> interpretation more certain.
>
>
>
>
>
> See above.
>
>
>
>
>
> And: Second, if there is a co-routed bidirectional path, then there is no
> need to specify the return path! The return path is basically “back on the
> other way on this co-routed bidirectional path”, so there is no need for
> what this document specifies.
>
> GIM>> AFAIK, only MPLS-TP defined p2p bi-directional co-routed LSP. True,
> co-routed bi-directional tunnel may be constructed by using combination of
> RSVP’s RRO and ERO as well. But other than that, AFAIK, all objects
> monitored by multi-hop BFD are not guaranteed to be co-routed.
>
>
>
> If the path *is* bi-directional co-routed (by whichever method), you would
> not need this — the was my point, not that some cases are co-routed and
> others are not.
>
> GIM>> Yes, and the scope of this proposal is not on already bi-directional
> co-routed paths, e.g. MPLS-TP p2p bi-directional co-routed LSP. RSVP-TE LSP
> may be explicitly routed but are unidirectional. And so SR tunnel.
>
>
>
>
> Next sentence:
>
>
>
> *   be co-routed, thus*
>
> *   fulfilling the implicit BFD requirement*
>
>
>
> But BFD never has this requirement, implicit or explicit.
>
> GIM>> If the goal of BFD to ensure reliable detection of failures, then
> co-routed multi-hop path is implied.
>
>
>
> I disagree. Even RFC 5883 says:
>
>
>
>    The Bidirectional Forwarding Detection (BFD) protocol [BFD] defines a
>
>    method for liveness detection of arbitrary paths between systems.
>
>
>
> and
>
>
>
>    BFD can also be useful on arbitrary paths between systems, which may
>
>    span multiple network hops and follow unpredictable paths.
>
>
>
> and
>
>
>
>    Furthermore, a pair of systems may have multiple paths between them
>
>    that may overlap.  This document describes methods for using BFD in
>
>    such scenarios.
>
>
> GIM2>> Will remove “… thus fulfilling the implicit BFD requirement” from
> the document.
>
>
>
>
>
> I am not going to further dissect each sentence, but the point is that if
> there’s something co-routed, there’s no need to explicitly point to the
> return path. If there is not, then why?
>
> GIM>> If there’s no co-routedness between a monitored path and the return
> path, then this draft provides mechanism that may be used to remove
> possible ambiguity in interpretation of failure of the return path.
>
>
>
>
>
> *2. Technical feasibility*
>
>
>
> The second major problem area is the actual technical feasibility. A main
> motivation seems to be “3.1.3.  Segment Routing: MPLS Data Plane Case”.
>
>
>
> However, looking at an SR path, it can be constructed by Node-SIDs and
> Adj-SIDs. Please refer to: https://tools.ietf.org/html/draft-ietf-spring-
> segment-routing-07#section-3.5
>
>
>
> First, Adj-SIDs SHOULD (not MUST) be assigned. This means there is the
> potential of an Adj-SID not assigned to a local Adj. There’s of course also
> the cases in which Adj-SIDs can be assigned to bundles, to ECMP/UCMP
> groups, etc.
>
>
>
> The implication here is that there is a possibility that there is no way
> to exactly explicitly construct a co-routed return path. For example, if
> the forward path is Node A -> Link X -> Node Z, then the return path needs
> to go to the node Z. Then it is a loose path (i.e., NOT co-routed) to the
> adjacent node to A through link X, and then that node needs to have an
> Adj-SID on the same link, which might not.
>
> GIM>> Appreciate your detailed analysis of the Segment Routing use case.
> We didn’t spell it out in such details but will be glad to add
> applicability clarification based on your comment.
>
>
>
>
>
> I do not think it is about Applicability. Given the existence of Adj-SIDs,
> the question is about technical feasibility. What do you do in the example
> I detailed above? Seems like there are potential cases in which it is not
> possible to specify the actual return path desired.
>
>
> GIM2>> There are many scenarios where it is possible and useful to specify
> strict explicit path for SR tunnel. To use strict or loose paths – that we
> leave to the operator to decide. The proposal addresses real scenario,
> though not all possible ones.
>
>
>
>
>
> The document does not seem to include this applicability. Still, can you
> please point to a definition of a co-routed path for Segment Routing from
> the segment routing architectural documents?
>
>
>
> There seems to be a difference between strict explicit routing (RSVP-TE)
> and this capability.
>
> *3. Actual Protocol Mechanics*
>
>
>
> Section 3.1.1.  BFD Reverse Path TLV, uses “Target FEC sub-TLV” to define
> the reverse path. This is consistent with the approach in RFC 7110.
>
>
>
> In fact, Section 3.1.2 uses the RFC 7110 sub-TLVs for “Static and RSVP-TE
> sub-TLVs”.
>
>
>
> However, Section 3.1.3, which seems to be a key motivation (“3.1.3.
> Segment Routing: MPLS Data Plane Case”), uses “Label Entries” to specify
> the Path!
>
>
>
> I believe this is a serious technical issue. Instead of using Label
> values, it should use Target FEC Stacks (as with the few other cases
> above). Labels can change. With labels there is no validation possible that
> what distributed by a given label distribution protocol is what is meant in
> the data plane.
>
> GIM>> I don’t see need to use Target FEC Stacks as the purpose of the BFD
> Reverse Path TLV not to verify mapping between the control and the data
> planes but to provide the remote BFD peer with pre-computed for the reverse
> path.
>
>
>
> It is not about verification of the control and data planes in the return
> path.
>
>
>
> The reason why RFC 7110 uses FECs and not Labels is that the invariant is
> the FEC, while the label numerical value can change. Seems like using
> labels is less robust and more brittle.
>
>
> GIM2>> If label value changes, i.e. label withdrawn, then BFD return path
> for the BFD session may be re-signaled via LSP Ping with the same BFD
> discriminator.
>
>
>
> In fact, Section 5.2 is trying to assign this for the Target FEC Stack:
>
>
>
> *    | X (TBD2) | Segment Routing MPLS Tunnel sub-TLV | This document |*
>
>
>
> But that’s not a Target FEC! It’s a label value!
>
>
>
> This should be done by also using the Target FEC Stack.
>
>
>
> The Target FEC Stack for SR is defined at https://tools.ietf.org/
> html/draft-ietf-mpls-spring-lsp-ping-00, but surprisingly,
> draft-ietf-mpls-spring-lsp-ping (and the SR TFC thereby defined) are not
> even references in this document.
>
> GIM>> We haven’t updated the draft just because
> I-D.kumarkini-mpls-spring-lsp-ping got adopted by the WG. Will certainly
> update the reference in the next version.
>
>
>
> Section 3.3 of this document does include an older version of that draft,
> before WG adoption, and is somehow trying to Update it. Instead of updating
> it from here, it should discuss how to updated it on itself.
>
> GIM>> This document enhances LSP Ping for Segment Routing environment and
> we’ve proposed clarification to use of LSP Ping in Segment Routing when
> bootstrapping BFD session that, hopefully, will be discussed by MPLS WG in
> course of this WGLC and used in draft-ietf-mpls-spring-lsp.
>
>
>
> As an aside, it’s not clear to me why WGLCing this document (twice) before
> moving forward with I-D.kumarkini-mpls-spring-lsp-ping.
>
>
>
>
>
> draft-ietf-mpls-spring-lsp-ping-00 seems to be a dependency to advance
> before this.
>
>
>
> I still do not understand the technical reason to use MPLS labels and not
> FECs. Further, using labels can suffer from misdirection if Label
> assignment changes (for a stable given FEC)
>
> GIM2>> Return path may be re-signaled in such case.
>
>
> The Section that follows is: “3.2.  Segment Routing: IPv6 Data Plane
> Case”, but in this case, I am mostly confused and baffled on how a set of
> IPv6 addresses can be an MPLS Target FEC Stack.
>
> GIM>> Agree, IPv6 case is outside the MPLS WG and I’ll remove it for
> further study.
>
>
>
>
>
> OK.
>
>
>
> The issue about using labels (along with the other ones) still remain.
>
>
>
>
>
>
> *4. IPR*
>
>
>
> This document has IPR with specific licensing terms. I would like to
> understand what parts of the document are potentially covered and
> understand if there’s ways to work around that.
>
>
>
> In summary, browsing through the document, I see high-level problem area
> issues, feasibility issues, technology issues, and others. Happy to be
> shown incorrect if I missed or confused anything.
>
>
>
>
>
> Thanks!
>
>
>
> Carlos.
>
>
>
> Thanks,
>
>
>
> — Carlos.
>
>
>
>
>
> Thanks,
>
>
>
> — Carlos.
>
>
>
> On Jul 10, 2016, at 1:59 PM, Martin Vigoureux <[e-mail]>
> wrote:
>
>
>
> WG,
>
> as said by Ross [1], I have been appointed Document Shepherd for
> draft-ietf-mpls-bfd-directed [2]. As such I am also running the second WG
> LC.
>
> So, this e-mail starts a WG LC which will end on the 31st of July.
>
> I'd like to remind that an IPR disclosure [3] exists against this document.
>
> So it is time to state whether or not you are in favour of progressing the
> document. Please also take the time to review the document and post
> comments on its content.
>
> Please respond to this call.
>
> Thank you
>
> Martin
>
>
> [1]: https://mailarchive.ietf.org/arch/msg/mpls/
> rxnEv4LnUiwhTiZOhowOC6AcHYU
> [2]: https://datatracker.ietf.org/doc/draft-ietf-mpls-bfd-directed/
> [2]: https://datatracker.ietf.org/ipr/2769/
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>
>
>
>
>
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>
>