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

[Greg Mirsky <[e-mail]>]

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
>
>