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 >
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Jeff Tantsura
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Andrew G. Malis
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Gregory Mirsky
- [mpls] 2nd WG LC on draft-ietf-mpls-bfd-directed Martin Vigoureux
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Carlos Pignataro (cpignata)
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Carlos Pignataro (cpignata)
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Carlos Pignataro (cpignata)
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Carlos Pignataro (cpignata)
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Andrew G. Malis
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… BRUNGARD, DEBORAH A
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Eric Gray
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Gregory Mirsky
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Martin Vigoureux
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Adrian Farrel
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Gregory Mirsky
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Carlos Pignataro (cpignata)
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Gregory Mirsky
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Carlos Pignataro (cpignata)
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Gregory Mirsky
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Carlos Pignataro (cpignata)
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Carlos Pignataro (cpignata)
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Gregory Mirsky
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Gregory Mirsky
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Gregory Mirsky
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Adrian Farrel
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Carlos Pignataro (cpignata)
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Mach Chen
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… David Allan I
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Uma Chunduri
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Loa Andersson
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Greg Mirsky
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Carlos Pignataro (cpignata)
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Greg Mirsky
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Carlos Pignataro (cpignata)
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Reshad Rahman (rrahman)
- Re: [mpls] 2nd WG LC on draft-ietf-mpls-bfd-direc… Greg Mirsky
- [mpls] Closed: 2nd WG LC on draft-ietf-mpls-bfd-d… N.Leymann