From rtgwg-bounces@ietf.org Thu Feb 01 19:49:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCmaz-00015l-UG; Thu, 01 Feb 2007 19:48:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVrS9-00065s-9A; Fri, 06 Oct 2006 11:17:33 -0400 Received: from mx2.lvl7.com ([66.192.95.83] helo=lvl7-trend01.lvl7.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVrNO-00012I-0p; Fri, 06 Oct 2006 11:12:39 -0400 Received: from lvl7nc-mail01.lvl7.com ([10.254.2.10]) by lvl7-trend01.lvl7.com with InterScan VirusWall; Fri, 06 Oct 2006 11:12:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Oct 2006 11:12:35 -0400 Message-ID: <1D3670B19825324AA7D02A0513C89E57025E984B@lvl7nc-mail01.lvl7.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DVMRP question Thread-Index: AcbpWdqtlUrP3WROSEKXQLx4/pyk4w== From: "Prakash R" To: , , X-Spam-Score: 0.5 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c X-Mailman-Approved-At: Thu, 01 Feb 2007 19:48:03 -0500 Cc: Subject: DVMRP question X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0971127705==" Errors-To: rtgwg-bounces@ietf.org This is a multi-part message in MIME format. --===============0971127705== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E959.DB08CF1C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E959.DB08CF1C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =0D Sorry I could not get the DVMRP working group, and so I am sending this mail to work groups which are related to this DVMRP. =0D My name is Prakash and I am working on DVMRP.I have a question regarding the prune life time.=0D In section 3.5.4 of the draft "draft-ietf-idmr-dvmrp-v3-10", there is a statement "Determine the prune lifetime. This value should be the minimum of the default prune lifetime (randomized to prevent synchronization) and the remaining prune lifetimes of the downstream neighbors." Interpretation wise I have a doubt over here. I have listed my two interpretations A and B. A) the minimum of the default prune lifetime (randomized to prevent synchronization) plus the remaining prune lifetimes of the downstream neighbors B) the minimum of the default prune lifetime (randomized to prevent synchronization) or the remaining prune lifetimes of the downstream neighbors if the default prune values is considered as X and the minimum value of the remaining prune life times of the downstream neighbors is considered as Y, According to A, prune life time should be X+Y And according to B, prune life time should be X or Y depending on which ever is minimum. So, is my A interpretation correct or B interpretation correct?=0D Regards, Prakash. =0D The information contained in this e-mail is LVL7 confidential. Any use= except that authorized by LVL7 is prohibited. If you get this in error,= please notify the sender and delete this e-mail. ------_=_NextPart_001_01C6E959.DB08CF1C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Sorry I could not get= the DVMRP=0D working group, and so I am sending this mail to work groups which are= related to=0D this DVMRP.

My name is Prakash and I am working on= DVMRP.I=0D have a question regarding the prune life time.=

In section= 3.5.4 of=0D the draft "draft-ietf-idmr-dvmrp-v3-10", there is a statement= "Determine=0D the prune lifetime. This value should be the minimum of the default prune=0D lifetime (randomized to prevent synchronization) and the remaining prune=0D lifetimes of the downstream neighbors."

Interpretation wise= I have=0D a doubt over here. I have listed my two interpretations A and=0D B.

A) the minimum of= the=0D default prune lifetime (randomized to prevent synchronization) plus the=0D remaining prune lifetimes of the downstream neighbors

B) the minimum of= the=0D default prune lifetime (randomized to prevent synchronization) or the= =0D remaining prune lifetimes of the downstream neighbors

if the default prune= values=0D is considered as X and the minimum value of the remaining prune life= times=0D of the downstream neighbors is considered as Y,

According to= A, prune=0D life time should be X+Y

And according= to=0D B, prune life time should be X or Y depending on which ever is=0D minimum.

So, is my A= interpretation=0D correct or B interpretation correct?

Regards,

Prakash.

The information= contained in this e-mail is LVL7 confidential. Any use except that= authorized by LVL7 is prohibited. If you get this in error, please notify= the sender and delete this e-mail.

------_=_NextPart_001_01C6E959.DB08CF1C-- --===============0971127705== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg --===============0971127705==-- From rtgwg-bounces@ietf.org Fri Feb 16 21:49:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIFce-0001Vd-L3; Fri, 16 Feb 2007 21:48:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIFcd-0001VU-5Q for rtgwg@ietf.org; Fri, 16 Feb 2007 21:48:23 -0500 Received: from audl953.usa.alcatel.com ([143.209.238.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIFcb-00011o-UI for rtgwg@ietf.org; Fri, 16 Feb 2007 21:48:23 -0500 Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl953.usa.alcatel.com (ALCANET) with ESMTP id l1H2mLlk019346; Fri, 16 Feb 2007 20:48:21 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.8]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 16 Feb 2007 20:48:21 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Feb 2007 20:48:20 -0600 Message-ID: <162A2C0C1CEA634AA00E00ACCC9120C6031B89CD@USDALSMBS03.ad3.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for Agenda for IETF-68 Thread-Index: AcdSPhVohwQRS2+VQi6wEtK8VK7tIw== From: "ZININ Alex" To: X-OriginalArrivalTime: 17 Feb 2007 02:48:21.0392 (UTC) FILETIME=[16005900:01C7523E] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: "John G. Scudder" Subject: Call for Agenda for IETF-68 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtgwg-bounces@ietf.org Folks- Another IETF meeting is getting close fast. Please send your discussion topics to John and myself. Thanks. -- Alex Zinin _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Feb 16 21:57:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIFlB-0007xj-Tl; Fri, 16 Feb 2007 21:57:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIFlA-0007xb-Gr for rtgwg@ietf.org; Fri, 16 Feb 2007 21:57:12 -0500 Received: from audl952.usa.alcatel.com ([143.209.238.159]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIFl9-0003lo-7t for rtgwg@ietf.org; Fri, 16 Feb 2007 21:57:12 -0500 Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl952.usa.alcatel.com (ALCANET) with ESMTP id l1H2v6jE013638 for ; Fri, 16 Feb 2007 20:57:06 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.8]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 16 Feb 2007 20:57:06 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Feb 2007 20:57:05 -0600 Message-ID: <162A2C0C1CEA634AA00E00ACCC9120C6031B89CF@USDALSMBS03.ad3.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-ietf-rtgwg-rfc3682bis-09.txt Thread-Index: AcdSP05xEmS/7C++S2ydefE5DulNew== From: "ZININ Alex" To: X-OriginalArrivalTime: 17 Feb 2007 02:57:06.0295 (UTC) FILETIME=[4EDE3070:01C7523F] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: Last Call: draft-ietf-rtgwg-rfc3682bis-09.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtgwg-bounces@ietf.org Folks- This is to start a two-week WG Last Call on the GTSM spec for submission to=20 the IESG for publication as Proposed Standard. The Last Call ends on March 2nd,=20 2007. Please send your comments to the list. The document is available here:=20 http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-rfc3682bis-09.txt Abstract:=20 The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols. This document generalizes this technique. This document obsoletes RFC 3682. -- Alex Zinin _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Feb 23 09:45:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKbeC-0000bs-9F; Fri, 23 Feb 2007 09:43:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKbeA-0000ZC-1y for rtgwg@ietf.org; Fri, 23 Feb 2007 09:43:42 -0500 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKbcL-0004zw-Kl for rtgwg@ietf.org; Fri, 23 Feb 2007 09:41:51 -0500 Received: from S4DE9JSAANO.ost.t-com.de (S4DE9JSAANO.ost.t-com.de [10.125.177.105]) by tcmail21.telekom.de with ESMTP for rtgwg@ietf.org; Fri, 23 Feb 2007 15:41:40 +0100 Received: from S4DE9JSAANL.ost.t-com.de ([10.125.177.226]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 15:41:39 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 23 Feb 2007 15:41:38 +0100 Message-Id: <75404C7727619C4E81A6DABE442E42DDB16C94@S4DE9JSAANL.ost.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question regarding draft-ietf-rtgwg-ipfrr-spec-base-05 Thread-Index: AcdXWLmJLDAp9UoKT2K5OzthtetY+A== From: "Schnitter, Stefan" To: X-OriginalArrivalTime: 23 Feb 2007 14:41:39.0486 (UTC) FILETIME=[BA21BBE0:01C75758] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: Question regarding draft-ietf-rtgwg-ipfrr-spec-base-05 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtgwg-bounces@ietf.org Hi all, [I assume draft-ietf-rtgwg-ipfrr-spec-base-05 - though recently expired - is still state of discussion regarding lfa - otherwise you can ignore the following... ] I was looking into ipfrr opportunities for Deutsche Telekom's internet backbone and implemented the algorithm to calculate LFA's that is given in section 3.6 of draft-ietf-rtgwg-ipfrr-spec-base-05 (mainly to research the different types of coverage) I was wondering why the distance towards the destination is not stated more clearly as a criterion to choose the LFA if there are multiple (e.g. node protecting) candidates available. In Step 15 (page 16) it says "15. Based upon the alternate types, the alternate distances, IP addresses, or other tie-breakers, decide if H_h is preferred to P_i.alt_next_hops. If so, goto Step 18." Having the shortest path towards the destination - also in an ipfrr situation - can be beneficial (within the simulation I found numerous case where long detours occur when the distance would not be considered) but also the distance is a tie-breaker that is easy to evaluate. Otherwise simulations of ipfrr might more difficult (in case of DT's backbone the distance would almost always be sufficient to choose a unique LFA) So - wouldn't it be good to add an "If-condition" between 14. and 15. that explicitly chooses the candidate with minimum distance (and not leave this to the vendors decision)? TIA, Stefan -- Dr. Stefan Schnitter T-Systems Enterprise Services GmbH, Systems Integration, Telco Projects & Design Line Of Business Networks and Processes, Team Traffic Management and Network Optimization Phone: +49 (0) 6151 937-8521 _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Feb 23 12:26:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKeAm-0001aA-01; Fri, 23 Feb 2007 12:25:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKeAk-0001Yu-NB for rtgwg@ietf.org; Fri, 23 Feb 2007 12:25:30 -0500 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKeAi-0000zR-4j for rtgwg@ietf.org; Fri, 23 Feb 2007 12:25:30 -0500 Received: by ug-out-1314.google.com with SMTP id 72so376034ugd for ; Fri, 23 Feb 2007 09:25:27 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ACy93Lc+q1tvcNqkXq1KpFTg9W6kzVibKoo/KHz9NsQ/RqwCEB+7jQSe3lm7SKBJt04R/Ehr3D4X9u/RHz+XV4ODfM10MCs3XJ63GIFvCOmJqudKvOHV9UT9mwQ3gHTPolFxgy1ZJyXGzkLUd1jq8ImGHKxoGq3Wycfya8asXDo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=fi/y8pVnXW2p8XAKMrJtDn8Edbagw4NcPaZZOGZF1hJLoC9TMVXCX2r/trmc0ZpdPPjiKDPsVdOWReqCF1EeqifsYtHTvhC/fgN7th4hlANRAM1QO8SgSrB3oDoM5iKyJTgrm95ylRba/28vNft4R5zlEB6q0aixi6XVJeX4cpQ= Received: by 10.78.205.7 with SMTP id c7mr197144hug.1172251527244; Fri, 23 Feb 2007 09:25:27 -0800 (PST) Received: by 10.78.90.3 with HTTP; Fri, 23 Feb 2007 09:25:27 -0800 (PST) Message-ID: <6280db520702230925s5961c115ke4c2a0e48bd7ab21@mail.gmail.com> Date: Fri, 23 Feb 2007 09:25:27 -0800 From: "Alia Atlas" To: "Schnitter, Stefan" In-Reply-To: <75404C7727619C4E81A6DABE442E42DDB16C94@S4DE9JSAANL.ost.t-com.de> MIME-Version: 1.0 References: <75404C7727619C4E81A6DABE442E42DDB16C94@S4DE9JSAANL.ost.t-com.de> X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: rtgwg@ietf.org Subject: Re: Question regarding draft-ietf-rtgwg-ipfrr-spec-base-05 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1404362051==" Errors-To: rtgwg-bounces@ietf.org --===============1404362051== Content-Type: multipart/alternative; boundary="----=_Part_28288_9748322.1172251527186" ------=_Part_28288_9748322.1172251527186 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, On 2/23/07, Schnitter, Stefan wrote: > > Hi all, > > [I assume draft-ietf-rtgwg-ipfrr-spec-base-05 - though recently expired > - is still state of discussion regarding lfa - otherwise you can ignore > the following... ] Yes, I have a slightly updated version that I'm planning on getting out soon. I was looking into ipfrr opportunities for Deutsche Telekom's internet > backbone and implemented the algorithm to calculate LFA's that is given > in section 3.6 of draft-ietf-rtgwg-ipfrr-spec-base-05 (mainly to > research the different types of coverage) > I was wondering why the distance towards the destination is not stated > more clearly as a criterion to choose the LFA if there are multiple > (e.g. node protecting) candidates available. In Step 15 (page 16) it > says > > "15. Based upon the alternate types, the alternate distances, IP > addresses, or other tie-breakers, decide if H_h is preferred to > P_i.alt_next_hops. If so, goto Step 18." > > Having the shortest path towards the destination - also in an ipfrr > situation - can be beneficial (within the simulation I found numerous > case where long detours occur when the distance would not be considered) > but also the distance is a tie-breaker that is easy to evaluate. > Otherwise simulations of ipfrr might more difficult (in case of DT's > backbone the distance would almost always be sufficient to choose a > unique LFA) > > So - wouldn't it be good to add an "If-condition" between 14. and 15. > that explicitly chooses the candidate with minimum distance (and not > leave this to the vendors decision)? Would you prefer a shorter path over one that provides node protection? That's one of the details hidden in the "depending on alternate type". If there is consensus on what the decision-making should be, I'm certainly willing to modify the draft. Alia TIA, > Stefan > > -- > Dr. Stefan Schnitter > T-Systems Enterprise Services GmbH, Systems Integration, Telco Projects > & Design > Line Of Business Networks and Processes, Team Traffic Management and > Network Optimization > Phone: +49 (0) 6151 937-8521 > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www1.ietf.org/mailman/listinfo/rtgwg > ------=_Part_28288_9748322.1172251527186 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

On 2/23/07, Schnitter, Stefan <Stefan.Schnitter@t-systems.com> wrote:

Hi all,

[I assume draft-ietf-rtgwg-ipfrr-spec-base-05 - though recently expired
- is still state of discussion regarding lfa - otherwise you can ignore
the following... ]

Yes, I have a slightly updated version that I'm planning on getting out soon.

I was looking into ipfrr opportunities for Deutsche Telekom's internet
backbone and implemented the algorithm to calculate LFA's that is given
in section 3.6 of draft-ietf-rtgwg-ipfrr-spec-base-05 (mainly to
research the different types of coverage)
I was wondering why the distance towards the destination is not stated
more clearly as a criterion to choose the LFA if there are multiple
(e.g. node protecting) candidates available. In Step 15 (page 16) it
says

"15.  Based upon the alternate types, the alternate distances, IP
       addresses, or other tie-breakers, decide if H_h is preferred to
       P_i.alt_next_hops.  If so, goto Step 18."

Having the shortest path towards the destination - also in an ipfrr
situation - can be beneficial (within the simulation I found numerous
case where long detours occur when the distance would not be considered)
but also the distance is a tie-breaker that is easy to evaluate.
Otherwise simulations of ipfrr might more difficult (in case of DT's
backbone the distance would almost always be sufficient to choose a
unique LFA)

So - wouldn't it be good to add an "If-condition" between 14. and 15.
that explicitly chooses the candidate with minimum distance (and not
leave this to the vendors decision)?

Would you prefer a shorter path over one that provides node protection?
That's one of the details hidden in the "depending on alternate type".

If there is consensus on what the decision-making should be, I'm certainly
willing to modify the draft.

Alia

TIA,
Stefan

--
Dr. Stefan Schnitter
T-Systems Enterprise Services GmbH, Systems Integration, Telco Projects
& Design
Line Of Business Networks and Processes, Team Traffic Management and
Network Optimization
Phone: +49 (0) 6151 937-8521

_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www1.ietf.org/mailman/listinfo/rtgwg

------=_Part_28288_9748322.1172251527186-- --===============1404362051== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg --===============1404362051==-- From rtgwg-bounces@ietf.org Sat Feb 24 10:48:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKz6K-0006fW-0h; Sat, 24 Feb 2007 10:46:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKz6I-0006fR-Se for rtgwg@ietf.org; Sat, 24 Feb 2007 10:46:18 -0500 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKz6H-0000BZ-E2 for rtgwg@ietf.org; Sat, 24 Feb 2007 10:46:18 -0500 Received: from S4DE9JSAANO.ost.t-com.de (S4DE9JSAANO.ost.t-com.de [10.125.177.105]) by tcmail21.telekom.de with ESMTP; Sat, 24 Feb 2007 16:46:13 +0100 Received: from S4DE9JSAANL.ost.t-com.de ([10.125.177.226]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Feb 2007 16:46:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Date: Sat, 24 Feb 2007 16:46:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-Id: <75404C7727619C4E81A6DABE442E42DDB16C95@S4DE9JSAANL.ost.t-com.de> In-Reply-To: <6280db520702230925s5961c115ke4c2a0e48bd7ab21@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question regarding draft-ietf-rtgwg-ipfrr-spec-base-05 Thread-Index: AcdXfbEE6DszKVF3TlCHJLkJgnbvbQAqXXWw References: <75404C7727619C4E81A6DABE442E42DDB16C94@S4DE9JSAANL.ost.t-com.de> <6280db520702230925s5961c115ke4c2a0e48bd7ab21@mail.gmail.com> From: "Schnitter, Stefan" To: X-OriginalArrivalTime: 24 Feb 2007 15:46:11.0354 (UTC) FILETIME=[E85BA7A0:01C7582A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: rtgwg@ietf.org Subject: RE: Question regarding draft-ietf-rtgwg-ipfrr-spec-base-05 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtgwg-bounces@ietf.org Hi, =09 >>Having the shortest path towards the destination - also in an ipfrr >>situation - can be beneficial (within the simulation I found numerous=20 >>case where long detours occur when the distance would not be considered) >>but also the distance is a tie-breaker that is easy to evaluate. >>Otherwise simulations of ipfrr might more difficult (in case of DT's >>backbone the distance would almost always be sufficient to choose a >>unique LFA) >> >>So - wouldn't it be good to add an "If-condition" between 14. and 15. >>that explicitly chooses the candidate with minimum distance (and not=20 >>leave this to the vendors decision)? > >Would you prefer a shorter path over one that provides node protection? >That's one of the details hidden in the "depending on alternate type".=20 =09 Probably not - I'd prefer the node protection. But my understanding of the procedure was that this is decided already in step 11: "11. If cand_node-protect is TRUE and P_i.alt_node-protect is FALSE, goto Paragraph 18. " (i.e. if I can improve the protection type I prefer the candidate in any case - and step 15 is not relevant) My point was only to ensure that the distance is used as the first tie-breaker for candidates with equal protection type.=20 Stefan. _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Sat Feb 24 11:55:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HL0AZ-0007rc-6V; Sat, 24 Feb 2007 11:54:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HL0AX-0007rR-Sr for rtgwg@ietf.org; Sat, 24 Feb 2007 11:54:45 -0500 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HL0AR-00072Y-2r for rtgwg@ietf.org; Sat, 24 Feb 2007 11:54:45 -0500 Received: by ug-out-1314.google.com with SMTP id 72so507271ugd for ; Sat, 24 Feb 2007 08:54:38 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=YKqaIeiAOjitR27e1OfB1+DoXOlBADu+XV8c2giBUPTmReXaOoaINj/xU1ECMi08PfVyVXTocL17cjgGdwPFChTCE+EFM324WxY2L1GpDqUuS0oHFbnSqy2utbtH9Jir397ZwpstVEwXTl5HDexphxqN9qumr1QdwGwrt7X0PPg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=GCc5CsaigkeZ7y8m9hdyvIvRKyUopww4ZH1LkEt8jZ8jWTp4ki5HA4pOr4ZqBDutOO+VrZCE/+w+WCh0ok7h3PfXwiAvRgQafdZZIX5CqNWcnb8nPXjm9EDiCYqaYBlpYhZu3IlRoMCyXXjbOsKXU9aLsV0Dmi80lGUb3K0VY84= Received: by 10.78.181.13 with SMTP id d13mr291421huf.1172336077193; Sat, 24 Feb 2007 08:54:37 -0800 (PST) Received: by 10.78.90.3 with HTTP; Sat, 24 Feb 2007 08:54:37 -0800 (PST) Message-ID: <6280db520702240854g226916d3t106b82904ea90b1c@mail.gmail.com> Date: Sat, 24 Feb 2007 08:54:37 -0800 From: "Alia Atlas" To: "Schnitter, Stefan" In-Reply-To: <75404C7727619C4E81A6DABE442E42DDB16C95@S4DE9JSAANL.ost.t-com.de> MIME-Version: 1.0 References: <75404C7727619C4E81A6DABE442E42DDB16C94@S4DE9JSAANL.ost.t-com.de> <6280db520702230925s5961c115ke4c2a0e48bd7ab21@mail.gmail.com> <75404C7727619C4E81A6DABE442E42DDB16C95@S4DE9JSAANL.ost.t-com.de> X-Spam-Score: 0.5 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: rtgwg@ietf.org Subject: Re: Question regarding draft-ietf-rtgwg-ipfrr-spec-base-05 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1217465270==" Errors-To: rtgwg-bounces@ietf.org --===============1217465270== Content-Type: multipart/alternative; boundary="----=_Part_36538_26756533.1172336077162" ------=_Part_36538_26756533.1172336077162 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Yes, you're right. I was rereading quickly. The question is more between the type of alternate (LFA, not-via, etc) and the distance. Alia On 2/24/07, Schnitter, Stefan wrote: > > Hi, > > >>Having the shortest path towards the destination - also in an ipfrr > >>situation - can be beneficial (within the simulation I found numerous > >>case where long detours occur when the distance would not be > considered) > >>but also the distance is a tie-breaker that is easy to evaluate. > >>Otherwise simulations of ipfrr might more difficult (in case of DT's > >>backbone the distance would almost always be sufficient to choose a > >>unique LFA) > >> > >>So - wouldn't it be good to add an "If-condition" between 14. and 15. > >>that explicitly chooses the candidate with minimum distance (and not > >>leave this to the vendors decision)? > > > >Would you prefer a shorter path over one that provides node protection? > >That's one of the details hidden in the "depending on alternate type". > > Probably not - I'd prefer the node protection. But my understanding of > the > procedure was that this is decided already in step 11: > > "11. If cand_node-protect is TRUE and P_i.alt_node-protect is FALSE, > goto Paragraph 18. " > > (i.e. if I can improve the protection type I prefer the candidate in any > case - and step 15 is not relevant) > My point was only to ensure that the distance is used as the first > tie-breaker > for candidates with equal protection type. > > Stefan. > ------=_Part_36538_26756533.1172336077162 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Yes, you're right. I was rereading quickly. The question is more between
the type of alternate (LFA, not-via, etc) and the distance.

Alia

On 2/24/07, Schnitter, Stefan <Stefan.Schnitter@t-systems.com> wrote:

Hi,

>>Having the shortest path towards the destination - also in an ipfrr
>>situation - can be beneficial (within the simulation I found numerous
>>case where long detours occur when the distance would not be
considered)
>>but also the distance is a tie-breaker that is easy to evaluate.
>>Otherwise simulations of ipfrr might more difficult (in case of DT's
>>backbone the distance would almost always be sufficient to choose a
>>unique LFA)
>>
>>So - wouldn't it be good to add an "If-condition" between 14. and 15.
>>that explicitly chooses the candidate with minimum distance (and not
>>leave this to the vendors decision)?
>
>Would you prefer a shorter path over one that provides node protection?
>That's one of the details hidden in the "depending on alternate type".

Probably not - I'd prefer the node protection. But my understanding of
the
procedure was that this is decided already in step 11:

"11. If cand_node-protect is TRUE and P_i.alt_node-protect is FALSE,
goto Paragraph 18. "

(i.e. if I can improve the protection type I prefer the candidate in any
case - and step 15 is not relevant)
My point was only to ensure that the distance is used as the first
tie-breaker
for candidates with equal protection type.

Stefan.

------=_Part_36538_26756533.1172336077162-- --===============1217465270== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg --===============1217465270==-- From rtgwg-bounces@ietf.org Sun Feb 25 08:41:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLJbb-0007EV-Qo; Sun, 25 Feb 2007 08:39:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLJba-00073G-59 for rtgwg@ietf.org; Sun, 25 Feb 2007 08:39:58 -0500 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLJbW-00069s-8q for rtgwg@ietf.org; Sun, 25 Feb 2007 08:39:58 -0500 Received: from S4DE9JSAANO.ost.t-com.de (S4DE9JSAANO.ost.t-com.de [10.125.177.105]) by tcmail21.telekom.de with ESMTP; Sun, 25 Feb 2007 14:39:52 +0100 Received: from S4DE9JSAANL.ost.t-com.de ([10.125.177.226]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Feb 2007 14:39:50 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 25 Feb 2007 14:39:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-Id: <75404C7727619C4E81A6DABE442E42DDB16C96@S4DE9JSAANL.ost.t-com.de> In-Reply-To: <6280db520702240854g226916d3t106b82904ea90b1c@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question regarding draft-ietf-rtgwg-ipfrr-spec-base-05 Thread-Index: AcdYTD+tv7CE3e0eScaMthPfBltbAAAlCylQ References: <75404C7727619C4E81A6DABE442E42DDB16C94@S4DE9JSAANL.ost.t-com.de> <6280db520702230925s5961c115ke4c2a0e48bd7ab21@mail.gmail.com> <75404C7727619C4E81A6DABE442E42DDB16C95@S4DE9JSAANL.ost.t-com.de> <6280db520702240854g226916d3t106b82904ea90b1c@mail.gmail.com> From: "Schnitter, Stefan" To: X-OriginalArrivalTime: 25 Feb 2007 13:39:50.0145 (UTC) FILETIME=[6C04B710:01C758E2] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: rtgwg@ietf.org Subject: RE: Question regarding draft-ietf-rtgwg-ipfrr-spec-base-05 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtgwg-bounces@ietf.org =09 >Yes, you're right. I was rereading quickly. The question is more between >the type of alternate (LFA, not-via, etc) and the distance. =09 Not really. Imho the types you introduce (NONE, LFA and PRIMARY) are also considered before and won't break any ties here. Of course, things might change=20 when you introduce new types like not-via (although my understanding was that the relation between different ipfrr implementations would better fit into the framework draft) Stefan. =20 _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Feb 26 04:01:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLbit-0007ME-14; Mon, 26 Feb 2007 04:00:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLbis-0007Ja-9d for rtgwg@ietf.org; Mon, 26 Feb 2007 04:00:42 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLbiq-0005sV-TF for rtgwg@ietf.org; Mon, 26 Feb 2007 04:00:42 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-1.cisco.com with ESMTP; 26 Feb 2007 01:00:39 -0800 X-IronPort-AV: i="4.14,218,1170662400"; d="scan'208"; a="764486402:sNHT44837568" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1Q90cZw002280; Mon, 26 Feb 2007 10:00:38 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1Q90YC8015091; Mon, 26 Feb 2007 10:00:38 +0100 (MET) Received: from mshand-wxp.cisco.com (ams3-vpn-dhcp4687.cisco.com [10.61.82.78]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA18204; Mon, 26 Feb 2007 09:00:31 GMT Message-Id: <200702260900.JAA18204@cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 26 Feb 2007 08:59:44 +0000 To: "Schnitter, Stefan" From: mike shand In-Reply-To: <75404C7727619C4E81A6DABE442E42DDB16C96@S4DE9JSAANL.ost.t-c om.de> References: <75404C7727619C4E81A6DABE442E42DDB16C94@S4DE9JSAANL.ost.t-com.de> <6280db520702230925s5961c115ke4c2a0e48bd7ab21@mail.gmail.com> <75404C7727619C4E81A6DABE442E42DDB16C95@S4DE9JSAANL.ost.t-com.de> <6280db520702240854g226916d3t106b82904ea90b1c@mail.gmail.com> <75404C7727619C4E81A6DABE442E42DDB16C96@S4DE9JSAANL.ost.t-com.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1733; t=1172480438; x=1173344438; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshand@cisco.com; z=From:=20mike=20shand=20 |Subject:=20RE=3A=20Question=20regarding=20draft-ietf-rtgwg-ipfrr-spec-ba se-05 |Sender:=20; bh=nXTTEkD+Y7ZrMJNYHWbpGm7buNnJHkwNf6TB6OfinTs=; b=l8tJKnnMGCHP8E4EeUJ1CEz0diM1P4yZx+VDP+1SV6a3R6CLXY3S3DkWLjGoN9kR6sm90Rtb +usEqE7Nein1/qYmPa5AtLksGAhFrv0Lz6dMhPapTF9WLfyGU+GCF839; Authentication-Results: ams-dkim-1; header.From=mshand@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: rtgwg@ietf.org Subject: RE: Question regarding draft-ietf-rtgwg-ipfrr-spec-base-05 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtgwg-bounces@ietf.org These are interesting questions concerning preference, and I'm not sure there is a "one size fits all "answer. Do you prefer a high metric LFA over a lower metric not-via? It all depends. If the metric were high because the link was very low bandwidth, this might be a very bad choice. On the other hand, the overhead of tunnelling the not-via may sometimes be just what you don't want if you can avoid it. Similarly you may want to choose between a single LFA neighbor which gives LFA protection for all destinations, but is sub-optimal in terms of metric for some of them, as against the extra FIB complexity and memory required for using multiple different LFA neighbors giving a more optimal path for some destinations. There are plenty of other such tradeoffs. Unfortunately this rather points to having lots of knobs to control these preferences. Something I would much rather avoid. One of the advantages of IPFRR in general is that configuration should be straightforward. Mike At 13:39 25/02/2007, Schnitter, Stefan wrote: > > >Yes, you're right. I was rereading quickly. The question is more >between > >the type of alternate (LFA, not-via, etc) and the distance. > >Not really. Imho the types you introduce (NONE, LFA and PRIMARY) are >also >considered before and won't break any ties here. Of course, things might >change >when you introduce new types like not-via (although my understanding was >that >the relation between different ipfrr implementations would better fit >into the >framework draft) > >Stefan. > > >_______________________________________________ >rtgwg mailing list >rtgwg@ietf.org >https://www1.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Feb 26 05:12:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLcpU-00064V-EB; Mon, 26 Feb 2007 05:11:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLcpS-00064F-Q7 for rtgwg@ietf.org; Mon, 26 Feb 2007 05:11:34 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLcpO-0001KZ-E9 for rtgwg@ietf.org; Mon, 26 Feb 2007 05:11:34 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Feb 2007 11:11:30 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1QABTHC000599; Mon, 26 Feb 2007 11:11:29 +0100 Received: from [10.61.64.146] (ams3-vpn-dhcp146.cisco.com [10.61.64.146]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1QABTC8007997; Mon, 26 Feb 2007 11:11:29 +0100 (MET) Message-ID: <45E2B24B.9020207@cisco.com> Date: Mon, 26 Feb 2007 10:11:23 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mike shand References: <75404C7727619C4E81A6DABE442E42DDB16C94@S4DE9JSAANL.ost.t-com.de> <6280db520702230925s5961c115ke4c2a0e48bd7ab21@mail.gmail.com> <75404C7727619C4E81A6DABE442E42DDB16C95@S4DE9JSAANL.ost.t-com.de> <6280db520702240854g226916d3t106b82904ea90b1c@mail.gmail.com> <75404C7727619C4E81A6DABE442E42DDB16C96@S4DE9JSAANL.ost.t-com.de> <200702260900.JAA18204@cisco.com> In-Reply-To: <200702260900.JAA18204@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2584; t=1172484689; x=1173348689; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20Question=20regarding=20draft-ietf-rtgwg-ipfrr-spec-ba se-05 |Sender:=20; bh=KMrD4qqfZqCnkAdC2Z/7rRXNStPMdljHpyQ99rSVdJA=; b=NNjGrrjWukdf9TLTFC9wSajT2pvtUDuyOdebHvVkyGGsQ+Be5TN0TRcCi8sQYqnVscoh+M8F M2DBcXPUDYK6TRYI8Rbg32ef0j1LmzAP0PPnm/sqVNuJ6ikgE1NiLqsb; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: rtgwg@ietf.org Subject: Re: Question regarding draft-ietf-rtgwg-ipfrr-spec-base-05 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtgwg-bounces@ietf.org Unlike the advanced schemes in which more more that one node has to take special action with the packet, LFAs are a local matter and the router can use any criteria it likes to choose between the LFA alternatives. That makes the choice one of implementation/configuration and not a protocol issue. As such I prefer making no comment on the choice, since as Mike suggests one size will not fit all. However we should say that a downstream route is a better choice than an LFA, since a DSR will not loop in the presence of a node-failure, but an LFA pair may. - Stewart mike shand wrote: > These are interesting questions concerning preference, and I'm not sure > there is a "one size fits all "answer. > Do you prefer a high metric LFA over a lower metric not-via? It all > depends. If the metric were high because the link was very low > bandwidth, this might be a very bad choice. On the other hand, the > overhead of tunnelling the not-via may sometimes be just what you don't > want if you can avoid it. > > Similarly you may want to choose between a single LFA neighbor which > gives LFA protection for all destinations, but is sub-optimal in terms > of metric for some of them, as against the extra FIB complexity and > memory required for using multiple different LFA neighbors giving a more > optimal path for some destinations. > > There are plenty of other such tradeoffs. > > Unfortunately this rather points to having lots of knobs to control > these preferences. Something I would much rather avoid. One of the > advantages of IPFRR in general is that configuration should be > straightforward. > > Mike > > > At 13:39 25/02/2007, Schnitter, Stefan wrote: > >> >> >Yes, you're right. I was rereading quickly. The question is more >> between >> >the type of alternate (LFA, not-via, etc) and the distance. >> >> Not really. Imho the types you introduce (NONE, LFA and PRIMARY) are >> also >> considered before and won't break any ties here. Of course, things might >> change >> when you introduce new types like not-via (although my understanding was >> that >> the relation between different ipfrr implementations would better fit >> into the >> framework draft) >> >> Stefan. >> >> >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/rtgwg > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www1.ietf.org/mailman/listinfo/rtgwg > _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg