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

[Greg Mirsky <[e-mail]>]

Hi Carlos,
I think I see that your concern is with the IANA consideration placing the
SR MPLS Tunnel sub-TLV into sub-registry with FEC-based sub-TLVs. I'll
change section 5.2 to request new sub-registry as Sub-TLVs for TLV Type
TBD1 and place the SR MPLS Tunnel sub-TLV in it.
Hope that addresses your concern.

Regards, Greg

On Wed, Sep 7, 2016 at 11:12 AM, Carlos Pignataro (cpignata) <
[e-mail]> wrote:

> Hi, Greg,
>
> It is becoming evident that we are not converging on this. I believe I
> expressed my points, many of which I consider showstoppers, with enough
> clarity. Instead of responding point-by-point, I will let others share
> their opinions, if someone has interest and positions.
>
> Defining a sub-TLV for the MPLS LSP Ping Target FEC Stack (TFS) TLV that
> does not specify a FEC and instead carries label values (S5.2 and S3.1.3 of
> your draft) breaks things.
>
> Thanks,
>
> — Carlos.
>
>
> On Sep 2, 2016, at 9:15 PM, Greg Mirsky <[e-mail]> wrote:
>
> Hi Carlos, et. al,
> please find my answers, comments and notes in-line tagged GIM>>.
>
> Regards, Greg
>
> On Fri, Aug 19, 2016 at 10:10 PM, Carlos Pignataro (cpignata) <
> [e-mail]> wrote:
>
>> Shepherd, Chairs,
>>
>> I do not support this document advancing based on this new revision. I
>> believe there are significant unaddressed major technical concerns. I list
>> again some of these below.
>>
>> Dear Greg,
>>
>> I support the specification of the control/direction of the return path
>> of a BFD session in an MPLS environment. However, this document is neither
>> well scoped nor technically sound. The new revision does not address the
>> concerns I previously shared either.  The new revision does remove the
>> “Segment Routing: IPv6 Data Plane Case”. It is was not clear how the return
>> path of a bidirectional LSP is IPv6 and not MPLS. This was an indication
>> that the document had not received adequate review (to catch that so late)
>>
> GIM>> Greatly appreciate your thorough review.
>
>>
>> Seemingly, I was likely not clear enough before with my descriptions,
>> apologies; I will try again.
>>
>> [Reading your last sentence, I’ll point out though that a WG consensus
>> call is with the shepherd and chairs. There is an inherent contradiction
>> between being enlightened by the discussion and not wanting to listen.]
>>
>>
>> *Major Issues:*
>>
>> 1. Document scope and problem being solved.
>>
>> https://tools.ietf.org/html/draft-ietf-mpls-bfd-directed-03#section-2 describes
>> the problem solved. It says:
>>
>>    BFD is best suited to monitor bi-directional co-routed paths.  In
>>    most cases, given stable environments, the forward and reverse
>>    directions between two nodes are likely to be co-routed.
>>
>> That statement is unsubstantiated, and arguably conjecture. I do not
>> believe that “in most cases the forward and reverse directions between two
>> nodes are likely to be co-routed.”
>> If the document makes that claim, based on which the problem statement is
>> supported, please provide an adequate citation.
>>
> GIM>> Carlos, I agree that this assertion is outside the scope of this
> document. Will remove it in the next version.
>
>>
>> IGP Metrics are not symmetric, very many times!
>>
>>
>> It then goes to describe the problem as:
>>
>>    o  a failure detection by ingress node on the reverse path cannot be
>>       interpreted as bi-directional failure with all the certainty and
>>       thus trigger, for example, protection switchover of the forward
>>       direction without possibility of being a false positive defect
>>       notification.
>>
>> But this mis-describes the problem statement. It really has not to do
>> with co-routedness. In fact, the problem statement is applicable to uni and
>> bidirectional (co-routed or associated).
>>
>> For bidirectional, test both directions, for unidirectional, minimize
>> false negatives.
>>
>> GIM>> I don't agree that the same problem exists for bi-directional LSPs,
> co-routed or associated. According to Section 3.7 of RFC 6428 p2p
> bi-directional LSP can be monitored by single BFD session in coordinated
> mode. In the coordinated mode the egress LSR uses sends BFD control packets
> to ingress without any additional instructions.The independent mode is more
> suitable for the associated bi-directional LSPs as each direction is
> monitored by the dedicated BFD session that, sets bfd.MinRxInterval to zero
> so that the ingress node instructs the egress not to transmit BFD control
> packets. Thus in independent mode the reverse path is not being used at all
> and in coordinated mode the reverse path uses the reverse direction of the
> bi-directional LSP.
>
> Even before the document says:
>>
>>   The fact that BFD control
>>    packets are not guaranteed to cross the same links and nodes in both
>>    forward and reverse directions is a significant factor in producing
>>    false positive defect notifications, i.e. false alarms, if used by
>>    the ingress BFD peer to deduce the state of the forward direction.
>>
>> This is a mischaracterization. A return path going over the same nodes
>> and links as the forward path does not guarantee or maximize the chances of
>> the return path being the best path. A misprograming of LFIB in one
>> direction does not affect the other one, the receive and transmit optics
>> are different, etc.
>>
> GIM>> The document does not state that ensuring co-routedness guarantees
> avoidance of the false negative defects. But the document, as RFC 7110,
> states that ability to control the reverse path is beneficial and improves
> robustness of the OAM tool. If the LFIB is mis-programmed in the forward
> direction after the BFD session reached Up state, the egress LSR, according
> to RFC 5880, will indicate that by setting value of Diag field to Control
> Detection Time Expired (1). Further investigation, perhaps using LSP Ping,
> will be able to localize the defect to the particular node.
>
>>
>> Net-net, sections 1 and 2 require a major rewriting. RFC 7110 is so very
>> much more deliberately scoped.
>>
>> 2. Lack of feasibility of use cases.
>>
>> SR does not work as described in this document, and SR co-routed is most
>> times NOT possible. Most use cases of segment routing do not allow for
>> building a co-routed return path.
>>
>> Take Figure 3 from this document for example:
>>
>>            C---------D
>>            |         |
>>    A-------B         G-----H
>>            |         |
>>            E---------F
>>
>>
>> If a forward direction between “A” and “H” has the following Node SIDs:
>> {G; H}, then it is not possible to know if it’s going ABCDGH or ABEFGH. How
>> is then the return path to be constructed to be co-routed?
>>
>> Now, assume that the link between B and C is actually 3 parallel links,
>> and there’s a Parallel Adj-SID (https://tools.ietf.org/html/d
>> raft-ietf-spring-segment-routing-09#section-3.5.1) with 8% weight on a
>> link and 92% on a second (0% on a third). How is the return path
>> constructed?
>>
> GIM>> Carlos, RFC 5884 suggest to have BFD session per each ECMP path.
> That was further clarified in RFC 7726.
> I believe this is the major issue with this document.I think that methods
> of setting BFD sessions over ECMP are outside the scope of this document.
>
>>
>>
>> As I mentioned already, the sub-TLVs for TFS defined in
>> draft-ietf-mpls-spring-lsp-ping should be used — and not define a
>> sub-TLV that actually does NOT work with LSP Ping.
>>
> GIM>> The draft-ietf-mpls-spring-lsp-ping does not address BFD session
> bootstrapping scenario at all. The proposed BFD Reverse Path TLV does work
> with the LSP Ping as it follows the logic of Reply Path TLV defined in RFC
> 7110. The Segment Routing MPLS Tunnel sub-TLV should not be used for
> verification by the egress LSR but used as-is. If you have alternative
> technical proposal, please present it in the form that we can discuss it
> and compare with the one we have at the moment.
>
>>
>> 3. Lack of practicality also (or at least missing explanation in the
>> document of when things might not work in practice)
>>
>> Further, most cases will NOT specify every node (and every link) as this
>> document seems to expect (otherwise, it’s a very loose source routed return
>> path.
>>
>> RFC 7855 says:
>>
>>    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 grossly limits the real and practical feasibility.
>>
>> GIM>> The proposed solution enables control of the reverse path of the
> BFD session. Whether the reverse path will be specified as strict or loose
> SR MPLS Tunnel is the decision of the operator and network architecture.
>
>>
>> 4. Protocol Constructs.
>>
>> Section 3.1.1 of this document utilizes the same approach as in RFC 7110,
>> which is to include a Target FEC Stack (TFS) from LSP Ping that identifies
>> the return LSP to be used. So does Section 3.1.2, also directly modeling
>> after RFC 7110.
>>
>> However, Section 3.1.3. uses "Label Entry n” (assuming this means “Label
>> Stack Entry”).
>>
>> This is a major and significant departure. Instead of specifying the FEC,
>> it specifies the Label numerically. I believe that the FEC should be used
>> (as defined in the appropriate MPLS LSP Ping for SR document), and NOT the
>> numerical value of a label. Why this departure?
>>
>> Having a Segment Routing section not talk about SIDs, not differentiating
>> Node SIDs vs. Adj-SIDs, and not talking about FECs, is clearly missing
>> something fundamental…
>>
>> GIM>> As noted earlier, the SR MPLS Tunnel sub-TLV specifies SR tunnel
> while other sub-TLVs refer to existing LSP. I don't see rationale to
> provide FEC information for the reverse path since the egress LSR will not
> use it but apply the LSE "as-is".
>
>>
>> 5. Reply-mode-simple?
>>
>> By the way, the approach of RFC 7737 which updates RFC 7110, should be
>> considered. That is, if there;s a “specified return path” element without
>> an actual return path, then the return node injects responses into the
>> return path of a bidirectional LSP. This approach greatly simplifies
>> operations in presence of bidir LSPs.
>>
> GIM>> I've mentioned RFC 6428 earlier. I believe that it sufficiently
> describes two modes of using BFD over bi-directional LSP. Neither
> coordinated, nor independent mode has problem with the reverse path of the
> BFD session.
>
>>
>>
>> 5. Major Conflict created with LSP Ping
>>
>> As just mentioned, somehow, this document defines an “Segment Routing
>> MPLS Tunnel sub-TLV” using Labels.
>>
>> This is defined within an LSP Ping Registry: "Sub-TLVs for TLV Types 1,
>> 16, and 21"
>>
>> However, how this sub-TLV works for LSP Ping with a TLV Type 1 of Target
>> FEC Stack is a mystery. It does NOT.
>>
>> This major conflict is created by specifying an LSP Ping protocol
>> construct outside LSP Ping, and worst yet with an LSE. Instead, I recommend
>> this document for BFD actually uses the MPLS LSP Ping for SR sub-TLVs
>> defined (for TFS for Node-SID, Adj-SID, etc), draft-ietf-mpls-spring-lsp-pin
>> g.
>>
>> GIM>> Carlos, I don't see how you can refer to it as any kind of
> authoritative source when BFD bootstrapping is missing altogether.
>
>>
>>
>> 6. Race Conditions unidentified.
>>
>> This document does not explain what happens if both ends of a
>> bidirectional LSP start the same procedure, and how this disambiguation is
>> done. This is a big gap and source of operational issues.
>>
>> GIM>> Since RFC 5884 every reasonable implementation supports
> Active/Passive role for BFD over MPLS LSP. No difference here. In case both
> BFD peers configured as Active, operator will end up with two BFD sessions
> and, I expect, will remove one once he/she realizes the situation.
>
>
>> 7. BFD Session maintenance unspecified.
>>
>> RFC 7110 does not deal with the maintenance of a long-lived session.
>> However, a BFD session is expected to remain with state maintained for some
>> time (as oppose to an asynchronous LSP Ping). What happens if the return
>> FEC requested suddenly goes down?
>>
> GIM>> In RFC 5884 have been noted:
>         "LSP Ping is used to periodically verify the control plane
>
>          against the data plane by ensuring that the LSP is mapped to
>          the same FEC, at the egress, as the ingress."
>
> Along the same approach, LSP Ping with BFD Reverse Path TLV MAY be used to verify and/or update the egress LSR which reverse path to use.
>
> Will clarify that in the next version.
>
>
>
>
>> This problem gets compounded for the SR case as presented, since its not
>> using a FEC...
>>
>> I’ll stop here because I am running out of ink.
>>
>> Best,
>>
>> — Carlos.
>>
>>
>> On Aug 17, 2016, at 6:19 PM, Gregory Mirsky <[e-mail]>
>> wrote:
>>
>> 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]
>> <[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/htm
>> l/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/rxnEv4LnUiwh
>> TiZOhowOC6AcHYU
>> [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
>>
>>
>>
>>
>>
>>
>> <Mail Attachment.eml>
>>
>>
>>
>> _______________________________________________
>> mpls mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls
>
>
>