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

Martin Vigoureux <martin.vigoureux@nokia.com> Thu, 18 August 2016 15:57 UTC

Return-Path: <martin.vigoureux@nokia.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3041E12D1CA; Thu, 18 Aug 2016 08:57:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afaNbynMK-gF; Thu, 18 Aug 2016 08:57:03 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DE2512DA2C; Thu, 18 Aug 2016 08:57:03 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 0E684B1B7545C; Thu, 18 Aug 2016 15:56:58 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u7IFv0id001628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Aug 2016 15:57:01 GMT
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u7IFv0qb009479 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Aug 2016 17:57:00 +0200
Received: from [135.224.206.149] (135.239.27.38) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 18 Aug 2016 17:56:59 +0200
Message-ID: <57B5DAC8.3090308@nokia.com>
Date: Thu, 18 Aug 2016 17:56:56 +0200
From: Martin Vigoureux <martin.vigoureux@nokia.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: adrian@olddog.co.uk, 'Gregory Mirsky' <gregory.mirsky@ericsson.com>, "'Carlos Pignataro (cpignata)'" <cpignata@cisco.com>
References: <57828D0C.6000100@nokia.com> <1BF95C0A-FD5B-4E55-8432-7E52F09FDA11@cisco.com> <7347100B5761DC41A166AC17F22DF11221ADDAB1@eusaamb103.ericsson.se> <3552655D-0CB6-4084-A10B-C0079F440765@cisco.com> <7347100B5761DC41A166AC17F22DF11221AF8BBE@eusaamb103.ericsson.se> <7AF3E8E6-E7A6-40EE-84A8-E29902488027@cisco.com> <7347100B5761DC41A166AC17F22DF11221B06926@eusaamb103.ericsson.se> <BA456845-7D6D-4AB7-A82F-6634DB5AD446@cisco.com> <7347100B5761DC41A166AC17F22DF11221B08A76@eusaamb103.ericsson.se> <07f401d1f938$a13eb060$e3bc1120$@olddog.co.uk>
In-Reply-To: <07f401d1f938$a13eb060$e3bc1120$@olddog.co.uk>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [135.239.27.38]
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/ScgveD2BSt1vCgoeM0-Kdi_3mo4>
Cc: 'mpls' <mpls@ietf.org>, spring-chairs@ietf.org, bfd-chairs@ietf.org
Subject: Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Aug 2016 15:57:08 -0000

Hello Greg,

I have to admit that I am also a bit surprised.

I'd like the technical discussion to continue.

Thank you
martin

Le 18/08/2016 12:09, Adrian Farrel a écrit :
> 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:mpls-bounces@ietf.org] *On Behalf Of *Gregory Mirsky
> *Sent:* 17 August 2016 23:19
> *To:* Carlos Pignataro (cpignata)
> *Cc:* spring-chairs@ietf.org; mpls; bfd-chairs@ietf.org
> *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:cpignata@cisco.com]
> *Sent:* Tuesday, August 16, 2016 10:02 AM
> *To:* Gregory Mirsky <gregory.mirsky@ericsson.com>
> *Cc:* Martin Vigoureux <martin.vigoureux@nokia.com>; mpls
> <mpls@ietf.org>; spring-chairs@ietf.org; bfd-chairs@ietf.org
> *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
>     <gregory.mirsky@ericsson.com <mailto:gregory.mirsky@ericsson.com>>
>     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:cpignata@cisco.com]
>     *Sent:*Tuesday, August 16, 2016 6:14 AM
>     *To:*Gregory Mirsky <gregory.mirsky@ericsson.com
>     <mailto:gregory.mirsky@ericsson.com>>
>     *Cc:*Martin Vigoureux <martin.vigoureux@nokia.com
>     <mailto:martin.vigoureux@nokia.com>>; mpls <mpls@ietf.org
>     <mailto:mpls@ietf.org>>;spring-chairs@ietf.org
>     <mailto:spring-chairs@ietf.org>;bfd-chairs@ietf.org
>     <mailto:bfd-chairs@ietf.org>
>     *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
>         <gregory.mirsky@ericsson.com
>         <mailto:gregory.mirsky@ericsson.com>> 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:cpignata@cisco.com]
>         *Sent:*Tuesday, August 09, 2016 9:14 PM
>         *To:*Gregory Mirsky <gregory.mirsky@ericsson.com
>         <mailto:gregory.mirsky@ericsson.com>>
>         *Cc:*Martin Vigoureux <martin.vigoureux@nokia.com
>         <mailto:martin.vigoureux@nokia.com>>; mpls <mpls@ietf.org
>         <mailto:mpls@ietf.org>>;spring-chairs@ietf.org
>         <mailto:spring-chairs@ietf.org>;bfd-chairs@ietf.org
>         <mailto:bfd-chairs@ietf.org>
>         *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
>             <gregory.mirsky@ericsson.com
>             <mailto:gregory.mirsky@ericsson.com>> wrote:
>
>             Hi Carlos,
>
>             thank you for your comments. Please see my responses in-line
>             and tagged GIM>>.
>
>                              Regards,
>
>                                              Greg
>
>             *From:*mpls [mailto:mpls-bounces@ietf.org]*On Behalf
>             Of*Carlos Pignataro (cpignata)
>             *Sent:*Saturday, July 16, 2016 8:35 AM
>             *To:*Martin Vigoureux <martin.vigoureux@nokia.com
>             <mailto:martin.vigoureux@nokia.com>>
>             *Cc:*mpls <mpls@ietf.org
>             <mailto:mpls@ietf.org>>;spring-chairs@ietf.org
>             <mailto:spring-chairs@ietf.org>;bfd-chairs@ietf.org
>             <mailto:bfd-chairs@ietf.org>
>             *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
>                 <martin.vigoureux@nokia.com
>                 <mailto:martin.vigoureux@nokia.com>> 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
>                 mpls@ietf.org <mailto:mpls@ietf.org>
>                 https://www.ietf.org/mailman/listinfo/mpls
>