Re: New Version Notification for draft-ietf-rtgwg-rlfa-node-protection-04.txt
Levente Csikor <csikor@tmit.bme.hu> Wed, 28 October 2015 09:15 UTC
Return-Path: <csikor@tmit.bme.hu>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA471B370A for <rtgwg@ietfa.amsl.com>; Wed, 28 Oct 2015 02:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.015
X-Spam-Level:
X-Spam-Status: No, score=-1.015 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 u3GusGg4OHZi for <rtgwg@ietfa.amsl.com>; Wed, 28 Oct 2015 02:15:36 -0700 (PDT)
Received: from anubis.tmit.bme.hu (anubis.tmit.bme.hu [152.66.245.198]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE491B370E for <rtgwg@ietf.org>; Wed, 28 Oct 2015 02:15:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by anubis.tmit.bme.hu (Postfix) with ESMTP id 8098949993 for <rtgwg@ietf.org>; Wed, 28 Oct 2015 10:15:32 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at tmit.bme.hu
Received: from anubis.tmit.bme.hu ([127.0.0.1]) by localhost (anubis.tmit.bme.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UllSpa_CCyZD for <rtgwg@ietf.org>; Wed, 28 Oct 2015 10:15:28 +0100 (CET)
Received: from anyo.tmit.bme.hu (anyo.tmit.bme.hu [152.66.246.7]) by anubis.tmit.bme.hu (Postfix) with ESMTPS id 9E1924998A for <rtgwg@ietf.org>; Wed, 28 Oct 2015 10:15:28 +0100 (CET)
Received: from [152.66.244.180] (csikonbr.tmit.bme.hu [152.66.244.180] (may be forged)) (authenticated bits=0) by anyo.tmit.bme.hu (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id t9S9FUdf025559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <rtgwg@ietf.org>; Wed, 28 Oct 2015 10:15:30 +0100
Subject: Re: New Version Notification for draft-ietf-rtgwg-rlfa-node-protection-04.txt
To: rtgwg@ietf.org
References: <FAE6D04E-FBE8-49D3-87F1-95C6E2338B52@juniper.net> <562FC1CB.6080300@gmail.com> <5630915A.1060503@tmit.bme.hu>
From: Levente Csikor <csikor@tmit.bme.hu>
Message-ID: <56309230.1050801@tmit.bme.hu>
Date: Wed, 28 Oct 2015 10:15:28 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <5630915A.1060503@tmit.bme.hu>
Content-Type: multipart/alternative; boundary="------------070608020905080507030603"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/vgd-tJj9QEwP9H9_An709jU8cMI>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Oct 2015 09:15:41 -0000
Sorry, the topology may have fallen into several piecesdue to not setting 'fixed width' when composed the previous message. S-x-E / \ A D---G \ / | B---C |3 \ /2 | F-------H Regards, Levente On 10/28/2015 10:11 AM, Levente Csikor wrote: > Hi, > My problem is something similar. > It's true that instead of calculating rLFAs not as per-prefix, but as > per-link provides backup routes probably for more source-destination > pairs as it was in the case of pure LFA. > If this is the case then Q-space should be defined for the next-hop, > and this need to be emphasized in the document (the text in section > 2.2.3. only talks about primary node E, and link S-E, but reader may > not know whether E is the destination as well). > If the former is true, then the definition should be refined > accordingly, for instance: > > For source s, destination d, and next-hop e, some n ! = s, d is a > node-protecting Remote LFA for *the s − d pair* if and only if > i) there exists a node (V \in neigh(s)) : D_opt(v, n) < D_opt(v, e) + > D_opt(e, n) --- ext.P-space, where neigh(s) is the set of the direct > neighbors of s > ii) D_opt(n, d) < D_opt(n, e) + D_opt(e, d) -- Q-space > (the above definitions are taken from [1], where we always assumed > that remote LFA calculation is done for a given source-destination pair) > > As an example to illustrate the difference between the terms, check > the following example: > > S-x-E > / \ > A D---G > \ / | > B---C |3 > \ /2 | > F-------H > Assume that S wants to send a packet to G and as indicated with 'x', > the link S-E fails, and again all links are of unit costs except F-C > and H-G, where link cost is 2 and 3, respectively. > The shortest path from S to G is clearly S-E-D-G. > > In this case, when we calculate the Q-space of E, then it will > consists of ((E),D,G,C). > However, if we calculate the Q-space of the destination node G itself, > then Q-space will consists of (E, D, (G), C, *B, F* and *H* *as well*). > So, since the simple P-space of S consists of A,B,F,H; while > ext.P-space consists of additionally node C and node G as well, the > set of the PQ-nodes are bigger. > Tell me, if miscalculated something in the example. > > > Regards, > Levente > > > [1] L. Csikor and G. Rétvári, “On Providing Fast Protection with > Remote Loop-Free Alternates – Analyzing and Optimizing Unit Cost > Networks,” Telecommunication Systems Journal, 2015 > > > > > On 10/27/2015 07:26 PM, Mike Shand wrote: >> Hi Pushpasis, >> >> What you say about Q space is not in itself wrong. However, it is >> introducing a definition of Q space which is different, although >> semantically the same, as that previously used, for example in RFC 7490. >> >> Q space has always been thought of as a property of a node (E >> usually) and a link (S-E usually). Hence RFC 7490 defines it as >> The Q-space of a router with respect to a protected link is the >> set of routers from which that specific router can be reached >> without any path (including equal-cost path splits) transiting >> that protected link. >> >> The concept of Q space is then used in fast-reroute techniques where, >> as you rightly describe, we are concerned with >> calculating the Q space of the next-hop node from a particular PLR. >> (i.e. S, typically). >> >> But my feeling is that to introduce this apparently different >> definition will be confusing in the long term. >> >> Mike >> >> >> On 27/10/2015 18:00, Pushpasis Sarkar wrote: >>> Hi Mike, >>> >>> >>> From: Mike Shand <imc.shand@gmail.com> >>> Date: Tuesday, October 27, 2015 at 10:35 PM >>> To: Levente Csikor <csikor@tmit.bme.hu>, "rtgwg@ietf.org >>> <mailto:rtgwg@ietf.org>" <rtgwg@ietf.org <mailto:rtgwg@ietf.org>>, >>> Pushpasis Sarkar <psarkar@juniper.net <mailto:psarkar@juniper.net>> >>> Subject: Re: FW: New Version Notification for >>> draft-ietf-rtgwg-rlfa-node-protection-04.txt >>> >>> >>> Levente, >>> >>> Some good points that I missed in my review. >>> >>> Mike >>> >>> On 27/10/2015 15:56, Levente Csikor wrote: >>>> Dear Pushpasis, >>>> >>>> I've read the new version of the draft, and I find some ambiguous >>>> statements/terms and mistakes. Sorry that I did not read it before >>>> the 4th revision. >>>> >>>> 1)Terms: >>>> To be consistent, in Section 2. first-hop should be named/termed as >>>> next-hop, since in each latter case it is termed as next-hop (or >>>> nexthop). >>>> And later the term primary node also rises the question whether it >>>> means next-hop, or something else. >>> Next-hop is the conventional term >>> *[Pushpasis] Sure I will use the same in next version. * >>>> >>>> 2)Ambiguous things: >>>> On page 4, the Topology 2 introduced in Fig.2., is a bit ambiguous, >>>> since we are talking about (remote) *loop-free* alternates, but >>>> some cells in Table 2's Remote-LFA Back Path column contain loops, >>>> namely S=>N=>E=>R3->E->D1,S=>N=>E=>R3->E. In my opinion, this case >>>> can be understood if I take a look on the topology over and over >>>> again (to find and indentify remote LFAs), but according to RFC >>>> 7490, shouldn't we rely on simple LFA (node N in the topology) in >>>> such cases when they are available? >>>> Probably a better and unambiguous example topology would be better, >>>> or it should be stated that in such case node N could be a pure >>>> link-protecting LFA. >>> Yes, I had already pointed out that this was a poor example, since >>> in fact the node E itself is a valid PQ, point, being in the >>> extended P-space of S w.r.t. S-E and trivially in E's Q-space w.r.t. >>> S-E. >>> >>> And yes, there is no need to use an RLFA tunnel when a simple LFA >>> already exists. >>> >>> I really think a less ambiguous, and perhaps more general, example >>> is required here.. >>> *[Pushpasis] Once again the goal of this example was to show that >>> while the repair tunnel for some PQ-node can traverse through the >>> primary next hop node (and hence cannot be node-protecting) repair >>> tunnel for other PQ-nodes may not traverse the primary next hop node >>> and hence can be considered as a candidate for node-protecting >>> PQ-node. I tried my best to come up with an alternative example that >>> depicts the same, but I could not. If anyone provide me a better >>> example I shall be very thankful.* >>> >>>> >>>> >>>> 3)Mistake: >>>> Section 2.2.1 on page 6 states the following about link protecting >>>> extended P-space: >>>> "A node Y is in link-protecting extended P-space w.r.t to the link >>>> (S-E) being protected, if and only if, there exists at least one >>>> direct neighbor of S, Ni, other than primary nexthop E, that >>>> satisfies the following condition. >>>> D_opt(Ni,Y) < D_opt(Ni,S) + D_opt(S,Y)" >>>> >>>> The document also states that this inequality is already defined in >>>> RFC7490. >>>> However, this inequality seems to be wrong, or it is not properly >>>> prepared. >>>> To me, in essence, this inequality states (assuming that Y is the >>>> neighbor of Ni) is that my neighbor's (Ni) neighbor (Y) is closer >>>> to my neighbor (Ni) than me (S), which is almost every time true, >>>> but what if my neighbor's (Ni) neighbor (Y) is my (S) neighbor as >>>> well? >>>> Consider the topology below, where 'x' denotes only the failure on >>>> link S-E, while all the links are of unit cost except the link >>>> Ni-Y, where the cost is 2: >>>> >>>> Y >>>> 2/ \ >>>> Ni--S--x--E >>>> | / >>>> B D >>>> \ / >>>> \ / >>>> \ / >>>> A >>>> >>>> In this case, Y does not fulfill the inequality stated above, >>>> however, it's in extended P-space, moreover, it's in P-space as >>>> well, and as far as I remember, ext.P-space always consists of the >>>> (smaller) P-space. >>>> I think the main problem here is that there is no cross-reference >>>> to the failed link itself (as it is in node-protecting P-space >>>> inequality). >>>> Therefore, this could be resolved by the following inequality: >>>> D_opt(Ni,Y) < D_opt(Ni,S) + D_opt(S,E) + D_opt(E, Y) >>>> >>> Yes, you are correct. The critical part about traversing the failed >>> link was missing. I always find the cost based formulations of LFA >>> properties error prone, which is why I prefer not to use them. >>> *[Pushpasis] Y is indeed in the P-space of S wrt S-E link. And hence >>> also in Ext-P space of S wrt S-E by definition. And I have shown in >>> my previous response to Levente that Y satisfies the above inequality.* >>> * >>> * >>> >>> >>>> Or, the statement should emphasize in the beginning that node Y is >>>> not in the P-space of S w.r.t. the failed link S-E. >>>> Pls tell me if I'm wrong. >>>> Btw, the inequality for node-protecting extended P-space is valid. >>>> >>>> 4) >>>> Section 2.2.3 >>>> "The Remote-LFA [RFC7490] draft already defines this. The Q-space >>>> for a link S-E being protected is the set of routers that can reach >>>> primary node E,..." >>>> In this case, the term primary node is again equivocal, since if it >>>> means next-hop, then the definition is wrong. RFC7490 defines >>>> Q-spaces for the routers/nodes, however, if we talk about to find a >>>> remote LFA for a given source-destination pair w.r.t. a failed >>>> element, then (ext.) P-space of the source, and the Q-space of the >>>> destination should be evaluated/calculated (w.r.t. the failed element). >>> In my opinion Q space should always be referred to as being the Q >>> space of a node with respect to a link. So we should here talk about >>> the Q space of node E w.r.t. link S-E as being "the set of routers >>> (Y) that can reach E without traversing the link S-E on any of the >>> shortest paths from node Y to node E". Talking about primary node >>> and primary next-hop is superfluous and is indeed confusing. >>> *[Pushpasis] With due respect, I will like to disagree. The node E >>> has a dependency on the S-E link being protected. The node E is >>> being considered here because it is at the other end of the S-E >>> link, and not just another node unrelated to the link being >>> protected. The node E IS the primary node/next-hop since S-E is the >>> primary link being protected here. If S-E would not be the primary >>> link for any destination, what will be the reason for computing P, >>> Ext-P, Q and PQ spaces for it? * >>> * >>> * >>> *To my understanding, the intention of computing Q-space is to find >>> a node also in the Extended-P-Space (so that you can tunnel the >>> backup traffic to it without traversing the S-E link) that will not >>> traverse the S-E link while being hop-by-hop forwarded to the final >>> destination being originally reachable via S-E link (and hence via >>> the node E).* >>> >>>> >>>> Later, in section 2.2.5.: >>>> "A node Y is in candidate node-protecting PQ space w.r.t to the >>>> node(E) being protected, if and only if, *Y is present in both >>>> node-protecting extended P-space and the Q-space for the link being >>>> protected.*" >>>> To me, the term "..Q-space for the link being protected" is again >>>> not properly stated. >>> >>> Agreed. It should reference E. i.e. the Q-space of E w.r.t to S-E >>> *[Pushpasis] Again I think Q-Space is always wrt to node S(the PLR) >>> and S-E link(primary link being considered to be protected).* >>> >>>> >>>> >>>> 5) >>>> My final problem probably remains my problem :), but from section >>>> 2.2.5, there are a lot of reference to the term PQ-space, or >>>> PQ-node, for instance, in section 2.3.1: >>>> "As mentioned in Section 2.2.2, to consider a PQ-node as candidate >>>> node-protecting PQ-node, there must be at least one direct neighbor >>>> Ni of S, such that all shortest paths from Ni to the PQ-node does >>>> not traverse primary nexthop node E." >>>> or >>>> "To determine if a given candidate node-protecting PQ-node provides >>>> node-protecting alternate for a given destination, the primary >>>> nexthop node should not be on any of the shortest paths from the >>>> PQ-node to the given destination." >>>> >>>> and it occurs in many sentences. >>>> >>>> Basically what a bit confusing here is that according to RFC7490, >>>> if a set of routers is termed PQ-nodes, or even PQ-space, then they >>>> already fulfill the inequalities for (ext.) P-space and Q-space. >>>> So, in the above-mentioned sentences, it's a bit confusing why are >>>> we checking Q-space inequality if it's already a PQ-node. Probably >>>> better placements of the word "candidate" could resolve this issue, >>>> or we should rely on "node in P-space" or "node in Q-space" instead >>>> of PQ-node candidate. >>>> On the other hand, if we talk about a PQ-node candidate, then it >>>> means (at least to me) that the node fulfills at least one of the >>>> inequalities, i.e., it is already in the Q-space or the (ext.) >>>> P-space, and therefore we say it's a candidate if it fulfills the >>>> remaining inequality as well. >>> >>> Agreed. It is somewhat tautologous! >>> *[Pushpasis] I will try to remove the confusion in next version.* >>> * >>> * >>> *Thanks and Regards,* >>> *-Pushpasis* >>> >>>> >>>> >>>> >>>> 6) Typo on page 10 >>>> "As seen in the above example above" -> As seen in the example above >>>> >>>> >>>> Thanks, and please don't consider my observations offending, I'm >>>> just try to understand the whole concept of remote LFAs and try to >>>> help and improve the draft itself. >>>> >>>> >>>> Best regards, >>>> Levente >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 10/14/2015 11:51 AM, Pushpasis Sarkar wrote: >>>>> Hi Mike, >>>>> >>>>> I have addressed all the comments I have received so far. Here is the updated version of the draft. >>>>> >>>>> Thanks >>>>> -Pushpasis >>>>> >>>>> >>>>> >>>>> >>>>> On 10/14/15, 3:19 PM,"internet-drafts@ietf.org" <internet-drafts@ietf.org> wrote: >>>>> >>>>>> A new version of I-D, draft-ietf-rtgwg-rlfa-node-protection-04.txt >>>>>> has been successfully submitted by Pushpasis Sarkar and posted to the >>>>>> IETF repository. >>>>>> >>>>>> Name: draft-ietf-rtgwg-rlfa-node-protection >>>>>> Revision: 04 >>>>>> Title: Remote-LFA Node Protection and Manageability >>>>>> Document date: 2015-10-14 >>>>>> Group: rtgwg >>>>>> Pages: 16 >>>>>> URL:https://www.ietf.org/internet-drafts/draft-ietf-rtgwg-rlfa-node-protection-04.txt >>>>>> Status:https://datatracker.ietf.org/doc/draft-ietf-rtgwg-rlfa-node-protection/ >>>>>> Htmlized:https://tools.ietf.org/html/draft-ietf-rtgwg-rlfa-node-protection-04 >>>>>> Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-rlfa-node-protection-04 >>>>>> >>>>>> Abstract: >>>>>> The loop-free alternates computed following the current Remote-LFA >>>>>> [RFC7490] specification guarantees only link-protection. The >>>>>> resulting Remote-LFA nexthops (also called PQ-nodes), may not >>>>>> guarantee node-protection for all destinations being protected by it. >>>>>> >>>>>> This document describes procedures for determining if a given PQ-node >>>>>> provides node-protection for a specific destination or not. The >>>>>> document also shows how the same procedure can be utilised for >>>>>> collection of complete characteristics for alternate paths. >>>>>> Knowledge about the characteristics of all alternate path is >>>>>> precursory to apply operator defined policy for eliminating paths not >>>>>> fitting constraints. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Please note that it may take a couple of minutes from the time of submission >>>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>> _______________________________________________ >>>>> rtgwg mailing list >>>>> rtgwg@ietf.orghttps://www.ietf.org/mailman/listinfo/rtgwg >>>> >>> >> > > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg
- FW: New Version Notification for draft-ietf-rtgwg… Pushpasis Sarkar
- Re: FW: New Version Notification for draft-ietf-r… Levente Csikor
- Re: FW: New Version Notification for draft-ietf-r… Mike Shand
- Re: New Version Notification for draft-ietf-rtgwg… Pushpasis Sarkar
- Re: New Version Notification for draft-ietf-rtgwg… Pushpasis Sarkar
- Re: New Version Notification for draft-ietf-rtgwg… Mike Shand
- Re: New Version Notification for draft-ietf-rtgwg… Pushpasis Sarkar
- Re: New Version Notification for draft-ietf-rtgwg… Levente Csikor
- Re: New Version Notification for draft-ietf-rtgwg… Levente Csikor
- Re: New Version Notification for draft-ietf-rtgwg… Levente Csikor
- Re: New Version Notification for draft-ietf-rtgwg… Pushpasis Sarkar
- Re: New Version Notification for draft-ietf-rtgwg… Mike Shand
- Re: New Version Notification for draft-ietf-rtgwg… Mike Shand
- Re: New Version Notification for draft-ietf-rtgwg… Pushpasis Sarkar
- Re: New Version Notification for draft-ietf-rtgwg… Pushpasis Sarkar
- Re: New Version Notification for draft-ietf-rtgwg… Pushpasis Sarkar
- Re: New Version Notification for draft-ietf-rtgwg… Mike Shand
- Re: New Version Notification for draft-ietf-rtgwg… Stewart Bryant
- Re: New Version Notification for draft-ietf-rtgwg… Pushpasis Sarkar
- Re: New Version Notification for draft-ietf-rtgwg… Mike Shand
- Re: New Version Notification for draft-ietf-rtgwg… Levente Csikor