Between the simple TTL-mechanism and IPFRR I can imagine many different= =20 mechanisms to deal and cope with loops which require different amounts of=20 complexity. But let me address a different but related aspect.

How big can an OSPF network be? Could it be that its size would require= a=20 larger TTL start value than 255 ?

Given this issue, would it make sense to "define" a diameter being the=20= sum=20 of the distance between the current (root) node and its most dist= ant=20 node X1 plus the distance to its second most distant node X2 which howe= ver=20 must be beyond some root-adjacent link which is not the best for getting to=20= X1=20 ?

If this kind of diameter is smaller than 255 then there is no problem w= ith=20 the TTL size.

Otherwise, no safe statement can be made, further study is required.

Has anyone already made related investigations ?

Heiner

-------------------------------1191503302-- --===============1080695839== 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 --===============1080695839==-- From rtgwg-bounces@ietf.org Thu Oct 04 09:51:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdR5s-0002hz-9O; Thu, 04 Oct 2007 09:50:24 -0400 Received: from rtgwg by megatron.ietf.org with local (Exim 4.43) id 1IdR5r-0002eB-1x for rtgwg-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 09:50:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdR5q-0002dN-M9 for rtgwg@ietf.org; Thu, 04 Oct 2007 09:50:22 -0400 Received: from smtpout.sgsi.ucl.ac.be ([130.104.5.77] helo=smtp3.sgsi.ucl.ac.be) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdR5o-00081C-Gt for rtgwg@ietf.org; Thu, 04 Oct 2007 09:50:22 -0400 Received: from smtp3.sgsi.ucl.ac.be (localhost.localdomain [127.0.0.1]) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTP id 388061C5F46; Thu, 4 Oct 2007 15:50:18 +0200 (CEST) Received: from [130.104.228.94] (unknown [130.104.228.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pifrancois@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTP; Thu, 4 Oct 2007 15:50:18 +0200 (CEST) Message-ID: <4704EF9E.30109@uclouvain.be> Date: Thu, 04 Oct 2007 15:50:22 +0200 From: Pierre Francois User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: HeinerHummel@aol.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: Authenticated, X-SGSI-MailScanner: Found to be clean X-SGSI-From: pierre.francois@uclouvain.be X-SGSI-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: rtgwg@ietf.org Subject: Re: intra-domain diameter X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pierre.francois@uclouvain.be List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtgwg-bounces@ietf.org HeinerHummel@aol.com wrote: > Between the simple TTL-mechanism and IPFRR I can imagine many > different mechanisms to deal and cope with loops which require > different amounts of complexity. But let me address a different but > related aspect. > > How big can an OSPF network be? Could it be that its size would > require a larger TTL start value than 255 ? > Given this issue, would it make sense to "define" a diameter being the > sum of the distance between the current (root) node and its > most distant node X1 plus the distance to its second most distant node > X2 which however must be beyond some root-adjacent link which is not > the best for getting to X1 ? > > If this kind of diameter is smaller than 255 then there is no problem > with the TTL size. > Otherwise, no safe statement can be made, further study is required. > > Has anyone already made related investigations ? What we investigated w.r.t. the TTL is that : Upon IP FRR activation, LFA or Notvia, the end-to-end path are not much longer in terms of number hops than 1. The initial path hop length within the topology 2. The post-convergence path hop length within the topology. This means that if you drop a packet due to TTL expiration when it goes through an IP-FRR protection : 1. There is a significant chance that the packet would have been dropped before the failure anyway. 2. There is a significant chance that a packet sent from the same source to the same destination with the same TTL will be dropped when the network has converged. This has been verified on topologies ranging from small national ISPs to damn huge Tier-1 ISP topologies. The conclusion is that Size doesn't matter, diameter does, BUT this diameter doesn't change much upon a link / node failure. Regards, Pierre. > > Heiner > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Thu Oct 04 12:04:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdTAn-0004cw-Pe; Thu, 04 Oct 2007 12:03:37 -0400 Received: from rtgwg by megatron.ietf.org with local (Exim 4.43) id 1IdTAl-0004bt-Si for rtgwg-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 12:03:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdTAl-0004bl-HG for rtgwg@ietf.org; Thu, 04 Oct 2007 12:03:35 -0400 Received: from imo-d22.mx.aol.com ([205.188.144.208]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdTAk-0004et-NU for rtgwg@ietf.org; Thu, 04 Oct 2007 12:03:35 -0400 Received: from HeinerHummel@aol.com by imo-d22.mx.aol.com (mail_out_v38_r9.3.) id p.d02.1c672124 (30740); Thu, 4 Oct 2007 12:03:10 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Thu, 4 Oct 2007 12:03:10 EDT To: pierre.francois@uclouvain.be MIME-Version: 1.0 X-Mailer: AOL 9.0 VR sub 52 X-Spam-Flag: NO X-Spam-Score: 1.8 (+) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: rtgwg@ietf.org Subject: Re: intra-domain diameter 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="===============0387817018==" Errors-To: rtgwg-bounces@ietf.org --===============0387817018== Content-Type: multipart/alternative; boundary="-----------------------------1191513790" -------------------------------1191513790 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 Thanks for your response. And I totally agree with you.=20 The diamter topic should be considered independent from the re-route issue.=20= =20 Right, a few hops more, cannot be the point. Maybe this is more an =20 ospf-mailinglist topic and it might be useful to do more topology evaluation= in order=20 to relate the size of the network with the available TTL-byte (will say the= =20 TTL-size limits the biggest size of an OSPF-network somehow, right) =20 With respect to the IPFRR topic, I believe (i.e. would know how to do it) =20 that the relative simple TTL-weapon could be re-smithed as to PREVENT endles= s =20 loops instead of reporting the propability of a happened loop. =20 But maybe that this group is interested in a continuation of its current=20 work after the IPRRF-draft is rfc-ed.?! At some point in time later. It would be for sure a bigger but interesting =20 work. Therefore, keep in mind, whichever argument some of you may like to br= ing=20 up against it, may already be a positive constructive contribution :-) =20 Heiner =20 =20 =20 In einer eMail vom 04.10.2007 15:50:45 Westeurop=E4ische Normalzeit schreibt= =20 pierre.francois@uclouvain.be: HeinerHummel@aol.com wrote: > Between the simple TTL-mechanism and IPFRR I can imagine many=20 > different mechanisms to deal and cope with loops which require=20 > different amounts of complexity. But let me address a different but=20 > related aspect. =20 > =20 > How big can an OSPF network be? Could it be that its size would=20 > require a larger TTL start value than 255 ? > Given this issue, would it make sense to "define" a diameter being the=20 > sum of the distance between the current (root) node and its =20 > most distant node X1 plus the distance to its second most distant node=20 > X2 which however must be beyond some root-adjacent link which is not=20 > the best for getting to X1 ? > =20 > If this kind of diameter is smaller than 255 then there is no problem=20 > with the TTL size. > Otherwise, no safe statement can be made, further study is required. > =20 > Has anyone already made related investigations ? What we investigated w.r.t. the TTL is that : Upon IP FRR activation, LFA or Notvia, the end-to-end path are not much=20 longer in terms of number hops than 1. The initial path hop length within the topology 2. The post-convergence path hop length within the topology. This means that if you drop a packet due to TTL expiration when it goes=20 through an IP-FRR protection : 1. There is a significant chance that the packet would have been dropped=20 before the failure anyway. 2. There is a significant chance that a packet sent from the same source=20 to the same destination with the same TTL will be dropped when the network has converged. This has been verified on topologies ranging from small national ISPs to=20 damn huge Tier-1 ISP topologies. The conclusion is that Size doesn't matter, diameter does, BUT this diameter doesn't change=20 much upon a link / node failure. Regards, Pierre. > =20 > Heiner =20 > ------------------------------------------------------------------------ > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www1.ietf.org/mailman/listinfo/rtgwg > =20 =20 -------------------------------1191513790 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks for your response. And I totally agree with you.

The diamter topic should be considered independent from the re-route is= sue.=20 Right, a few hops more, cannot be the point. Maybe this is more an=20 ospf-mailinglist topic and it might be useful to do more topology evaluation= in=20 order to relate the size of the network with the available TTL-byte (will sa= y=20 the TTL-size limits the biggest size of an OSPF-network somehow, right)

With respect to the IPFRR topic, I believe (i.e. would know how to do i= t)=20 that the relative simple TTL-weapon could be re-smithed as to PREVENT endles= s=20 loops instead of reporting the propability of a happened loop.

But maybe that this group is interested in a continuation of its=20 current work after the IPRRF-draft is rfc-ed.?!

At some point in time later. It would be for sure a bigger but interest= ing=20 work. Therefore, keep in mind, whichever argument some of you may like to br= ing=20 up against it, may already be a positive constructive contribution :-)

Heiner

In einer eMail vom 04.10.2007 15:50:45 Westeurop=E4ische Normalzeit sch= reibt=20 pierre.francois@uclouvain.be:

<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20 size=3D2>HeinerHummel@aol.com wrote:
> Between the simple TTL-mechan= ism=20 and IPFRR I can imagine many
> different mechanisms to deal and cop= e=20 with loops which require
> different amounts of complexity. But let= me=20 address a different but
> related aspect.
>
= >=20 How big can an OSPF network be? Could it be that its size would
>=20 require a larger TTL start value than 255 ?
> Given this issue, woul= d it=20 make sense to "define" a diameter being the
> sum of the distance=20 between the current (root) node and its
> most distant node X= 1=20 plus the distance to its second most distant node
> X2 which howeve= r=20 must be beyond some root-adjacent link which is not
> the best for=20 getting to X1 ?
>
> If this kind of diameter is smaller= =20 than 255 then there is no problem
> with the TTL size.
>=20 Otherwise, no safe statement can be made, further study is=20 required.
>
> Has anyone already made related=20 investigations ?

What we investigated w.r.t. the TTL is that :
U= pon=20 IP FRR activation, LFA or Notvia, the end-to-end path are not much
lon= ger=20 in terms of number hops than
1. The initial path hop length within the=20 topology
2. The post-convergence path hop length within the=20 topology.

This means that if you drop a packet due to TTL expiratio= n=20 when it goes
through an IP-FRR protection :
1. There is a significa= nt=20 chance that the packet would have been dropped
before the failure=20 anyway.
2. There is a significant chance that a packet sent from the sa= me=20 source
to the same destination with the same TTL will be dropped=20 when
the network has converged.

This has been verified on topolo= gies=20 ranging from small national ISPs to
damn huge Tier-1 ISP=20 topologies.

The conclusion is that
Size doesn't matter, =20 diameter does, BUT this diameter doesn't change
much upon a link / nod= e=20 failure.

Regards,

Pierre.

>
> Heiner=20
>=20 ------------------------------------------------------------------------>
>=20 _______________________________________________
> rtgwg mailing=20 list
> rtgwg@ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/rtgwg
> =20

-------------------------------1191513790-- --===============0387817018== 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 --===============0387817018==-- From rtgwg-bounces@ietf.org Mon Oct 08 10:12:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IetIw-0002pt-RZ; Mon, 08 Oct 2007 10:09:54 -0400 Received: from rtgwg by megatron.ietf.org with local (Exim 4.43) id 1IetIw-0002pW-1H for rtgwg-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 10:09:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IetIv-0002pO-Md for rtgwg@ietf.org; Mon, 08 Oct 2007 10:09:53 -0400 Received: from imo-d21.mx.aol.com ([205.188.144.207]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IetIv-0001lN-7I for rtgwg@ietf.org; Mon, 08 Oct 2007 10:09:53 -0400 Received: from HeinerHummel@aol.com by imo-d21.mx.aol.com (mail_out_v38_r9.3.) id c.c9b.1c0c18b4 (41809); Mon, 8 Oct 2007 10:09:46 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Mon, 8 Oct 2007 10:09:46 EDT To: mshand@cisco.com MIME-Version: 1.0 X-Mailer: AOL 9.0 VR sub 52 X-Spam-Flag: NO X-Spam-Score: 1.8 (+) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: rtgwg@ietf.org Subject: Re: "Basic Specification for IP Fast-Reroute: Loop-free Alternates" 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="===============0500282903==" Errors-To: rtgwg-bounces@ietf.org --===============0500282903== Content-Type: multipart/alternative; boundary="-----------------------------1191852586" -------------------------------1191852586 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit (1) Now that I have become familiar with the notvia node solution I must say: Yes that is an excellent solution. (2) Nevertheless, it should be made clear: each node along the notvia-path must precisely select its notvia-nexthop link i.e. no respective ECMP hop ! Otherwise a deja vu with the failing node may happen. Let me just repeat that there alternatives which allow "multipath" along the notvia route (which however take more efforts to avoid any loop). (3) I think it is ( unnessecarily ) too much protection centric. Why not just saying AVOID a particular node and/or link? Protection seems to be used just like in soccer defense.Who protects whom? For specifying this subject it is not sufficient to reduce the diagram to just two paths( a protecting one and a protected one). There may be more (not shown) paths which may protect resp. which may need to be protected. Also, there may be other reasons than failures why to tour around a particular node/link. (4) I also hope that this WG considers this draft just as a beginning. The better and the more of good results, the smaller the phantom angst of a loop. Yes crankback is a loop, but it could be made perfectly i.e. with successful delivery (although I think I read something about back tracking that shouldn't bother) Heiner -------------------------------1191852586 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

(1)

Now that I have become familiar with the notvia node solution I must sa= y:=20 Yes that is an excellent solution.

(2)

Nevertheless, it should be made clear: each node along the notvia-path=20= must=20 precisely select its notvia-nexthop link i.e. no respective ECMP hop ! Other= wise=20 a deja vu with the failing node may happen. Let me just repeat that there=20 alternatives which allow "multipath" along the notvia route (which however t= ake=20 more efforts to avoid any loop).

(3)

I think it is ( unnessecarily ) too much protection centric. Why not=20 just saying AVOID a particular node and/or link?

Protection seems to be used just like in soccer defense.Who protects=20 whom? For specifying this subject it is not sufficient to reduce the=20 diagram to just two paths( a protecting one and a protected one). There may=20= be=20 more (not shown) paths which may protect resp. which may need to be protecte= d.=20 Also, there may be other reasons than failures why to tour around a particul= ar=20 node/link.

(4)

I also hope that this WG considers this draft just as a beginning. The=20 better and the more of good results, the smaller the phantom angst of a loop= .=20 Yes crankback is a loop, but it could be made perfectly i.e. with successful= =20 delivery (although I think I read something about back tracking that shouldn= 't=20 bother)

Heiner

-------------------------------1191852586-- --===============0500282903== 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 --===============0500282903==-- From rtgwg-bounces@ietf.org Thu Oct 11 14:14:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig2Ws-0000Dx-D7; Thu, 11 Oct 2007 14:13:02 -0400 Received: from rtgwg by megatron.ietf.org with local (Exim 4.43) id 1Ig2Wr-0000Cl-B6 for rtgwg-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 14:13:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig2Wq-00005F-Vj for rtgwg@ietf.org; Thu, 11 Oct 2007 14:13:01 -0400 Received: from imo-m22.mx.aol.com ([64.12.137.3] helo=imo-m22.mail.aol.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig2Wc-0005ok-VG for rtgwg@ietf.org; Thu, 11 Oct 2007 14:12:53 -0400 Received: from HeinerHummel@aol.com by imo-m22.mx.aol.com (mail_out_v38_r9.3.) id l.c43.1b9794e2 (33856) for ; Thu, 11 Oct 2007 14:11:58 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Thu, 11 Oct 2007 14:11:58 EDT To: rtgwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="part1_c43.1b9794e2.343fc16e_boundary" X-Mailer: AOL 9.0 VR sub 52 X-Spam-Flag: NO X-Spam-Score: 1.8 (+) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Subject: "Basic Specification for IP Fast-Reroute: Loop-free Alternates" 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 --part1_c43.1b9794e2.343fc16e_boundary Content-Type: multipart/alternative; boundary="-----------------------------1192126317" -------------------------------1192126317 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 In einer eMail vom 08.10.2007 16:09:46 Westeurop=E4ische Normalzeit schreibt= =20 HeinerHummel: (1) Now that I have become familiar with the notvia node solution I must say: =20 Yes that is an excellent solution. I am afraid, I have praised this solution too early. a) why should S have any (failure) suspicion on P if S is not immediate =20 neighbor of P ? b) why should a direct neighbor of P be the appropriate intermediate =20 destination ? The immediate neighbor of P should rather start a detour towards some=20 intermediate destination somewhere in the network such that best as well as= =20 equally best hops towards it won't hit P ! =20 Heiner =20 =20 =20 -------------------------------1192126317 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

In einer eMail vom 08.10.2007 16:09:46 Westeurop=E4ische Normalzeit sch= reibt=20 HeinerHummel:

<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>

(1)

Now that I have become familiar with the notvia node solution I must=20= say:=20 Yes that is an excellent solution.

I am afraid, I have praised this solution too early.

a) why should S have any (failure) suspicion on P if S is not immediate= =20 neighbor of P ?

b) why should a direct neighbor of P be the appropriate intermediate=20 destination ?

The immediate neighbor of P should rather start a detour=20 towards some intermediate destination somewhere in the network such th= at=20 best as well as equally best hops towards it won't hit P !

Heiner

-------------------------------1192126317-- --part1_c43.1b9794e2.343fc16e_boundary Content-Type: message/rfc822 Content-Disposition: inline Return-path: From: HeinerHummel@aol.com Full-name: HeinerHummel Message-ID: Date: Mon, 8 Oct 2007 10:09:46 EDT Subject: Re: "Basic Specification for IP Fast-Reroute: Loop-free Alternates" To: mshand@cisco.com CC: rtgwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1191852586" X-Mailer: AOL 9.0 VR sub 52 -------------------------------1191852586 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit (1) Now that I have become familiar with the notvia node solution I must say: Yes that is an excellent solution. (2) Nevertheless, it should be made clear: each node along the notvia-path must precisely select its notvia-nexthop link i.e. no respective ECMP hop ! Otherwise a deja vu with the failing node may happen. Let me just repeat that there alternatives which allow "multipath" along the notvia route (which however take more efforts to avoid any loop). (3) I think it is ( unnessecarily ) too much protection centric. Why not just saying AVOID a particular node and/or link? Protection seems to be used just like in soccer defense.Who protects whom? For specifying this subject it is not sufficient to reduce the diagram to just two paths( a protecting one and a protected one). There may be more (not shown) paths which may protect resp. which may need to be protected. Also, there may be other reasons than failures why to tour around a particular node/link. (4) I also hope that this WG considers this draft just as a beginning. The better and the more of good results, the smaller the phantom angst of a loop. Yes crankback is a loop, but it could be made perfectly i.e. with successful delivery (although I think I read something about back tracking that shouldn't bother) Heiner -------------------------------1191852586 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

(1)

Now that I have become familiar with the notvia node solution I must sa= y:=20 Yes that is an excellent solution.

(2)

(3)

I think it is ( unnessecarily ) too much protection centric. Why not=20 just saying AVOID a particular node and/or link?

(4)

Heiner

-------------------------------1191852586-- --part1_c43.1b9794e2.343fc16e_boundary 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 --part1_c43.1b9794e2.343fc16e_boundary-- From rtgwg-bounces@ietf.org Fri Oct 12 04:18:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgFfI-0004qH-89; Fri, 12 Oct 2007 04:14:36 -0400 Received: from rtgwg by megatron.ietf.org with local (Exim 4.43) id 1IgFfF-0004hI-FE for rtgwg-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 04:14:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgFfA-0004Zs-Up for rtgwg@ietf.org; Fri, 12 Oct 2007 04:14:28 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgFf4-0000tm-HF for rtgwg@ietf.org; Fri, 12 Oct 2007 04:14:28 -0400 X-IronPort-AV: E=Sophos;i="4.21,265,1188770400"; d="scan'208,217";a="155606233" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2007 10:14:15 +0200 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 l9C8EEW5010917; Fri, 12 Oct 2007 10:14:14 +0200 Received: from [10.61.65.160] (ams3-vpn-dhcp416.cisco.com [10.61.65.160]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9C8ECSO025772; Fri, 12 Oct 2007 08:14:12 GMT Message-ID: <470F2CD0.8070707@cisco.com> Date: Fri, 12 Oct 2007 09:14:08 +0100 From: mike shand User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: HeinerHummel@aol.com References: In-Reply-To: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6753; t=1192176854; x=1193040854; 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=20=22Basic=20Specification=20for=20IP=20Fast-Reroute=3A =20Loop-free=20Alternates=22 |Sender:=20; bh=mTrWuzFAKuxOXU/MD9Qqmu+b+OUUolN3ZtDHxv/H0OA=; b=ZP1yIkahpnqAoAk91lMDXUNghmTws+B1as6l8pnYRoTC5G3q1uQnzFqXrqGsNzIO8A9u8Olk ESYfcB+fV6mwF1WZlAIL984XVw8D1qA1Bkb1joUPBlf3fYatPtJvLMVU; Authentication-Results: ams-dkim-1; header.From=mshand@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 1.7 (+) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: rtgwg@ietf.org Subject: Re: "Basic Specification for IP Fast-Reroute: Loop-free Alternates" 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="===============1526515622==" Errors-To: rtgwg-bounces@ietf.org --===============1526515622== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit HeinerHummel@aol.com wrote:

In einer eMail vom 08.10.2007 16:09:46 Westeuropäische Normalzeit schreibt HeinerHummel:

(1)

Now that I have become familiar with the notvia node solution I must say: Yes that is an excellent solution.

I am afraid, I have praised this solution too early.

a) why should S have any (failure) suspicion on P if S is not immediate neighbor of P ?

Why do you think it should? It doesn't and can't (unless it is a member of an SRLG, in which case its failure is implied by the failure of the immediate neighbor/link). It seems you have misundestood the spec.

b) why should a direct neighbor of P be the appropriate intermediate destination ?

Because we are protecting against node failure of P and that is where the traffic WOULD have gone.

The immediate neighbor of P should rather start a detour towards some intermediate destination somewhere in the network such that best as well as equally best hops towards it won't hit P !

I think you are talking about something akin to the original tunnels scheme (aka PQ space), which suffers from all sorts of corner cases. I suggest you read http://www.potaroo.net/ietf/all-ids/draft-bryant-ipfrr-tunnels-00.txt-70928.txt to see the difficulties this approach suffered from. The point about not-via is that it is very simple. We have considered the possibility of exiting the tunnel once Q space has been reached, thus allowing the packet a potentially more direct route, but this is generally regarded as overly complex.

Heiner

Subject:
Re: "Basic Specification for IP Fast-Reroute: Loop-free Alternates"

From:
HeinerHummel@aol.com

Date:
Mon, 8 Oct 2007 10:09:46 EDT

To:
mshand@cisco.com

To:
mshand@cisco.com

CC:
rtgwg@ietf.org

(1)

Now that I have become familiar with the notvia node solution I must say: Yes that is an excellent solution.

(2)

Nevertheless, it should be made clear: each node along the notvia-path must precisely select its notvia-nexthop link i.e. no respective ECMP hop ! Otherwise a deja vu with the failing node may happen. Let me just repeat that there alternatives which allow "multipath" along the notvia route (which however take more efforts to avoid any loop).

(3)

I think it is ( unnessecarily ) too much protection centric. Why not just saying AVOID a particular node and/or link?

Protection seems to be used just like in soccer defense.Who protects whom? For specifying this subject it is not sufficient to reduce the diagram to just two paths( a protecting one and a protected one). There may be more (not shown) paths which may protect resp. which may need to be protected. Also, there may be other reasons than failures why to tour around a particular node/link.

(4)

I also hope that this WG considers this draft just as a beginning. The better and the more of good results, the smaller the phantom angst of a loop. Yes crankback is a loop, but it could be made perfectly i.e. with successful delivery (although I think I read something about back tracking that shouldn't bother)

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

--===============1526515622== 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 --===============1526515622==-- From rtgwg-bounces@ietf.org Fri Oct 12 06:59:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgIDc-0004bt-Rf; Fri, 12 Oct 2007 06:58:12 -0400 Received: from rtgwg by megatron.ietf.org with local (Exim 4.43) id 1IgIDb-0004bm-R7 for rtgwg-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 06:58:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgIDb-0004be-HV for rtgwg@ietf.org; Fri, 12 Oct 2007 06:58:11 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgIDa-0007NO-1H for rtgwg@ietf.org; Fri, 12 Oct 2007 06:58:11 -0400 X-IronPort-AV: E=Sophos;i="4.21,266,1188770400"; d="scan'208";a="155628283" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2007 12:58:09 +0200 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 l9CAw9Wl000577; Fri, 12 Oct 2007 12:58:09 +0200 Received: from stewart-bryants-computer.local (ams3-vpn-dhcp729.cisco.com [10.61.66.217]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9CAw8SO001325; Fri, 12 Oct 2007 10:58:08 GMT Message-ID: <470F5341.8030900@cisco.com> Date: Fri, 12 Oct 2007 11:58:09 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8428; t=1192186689; x=1193050689; 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:=20draft-ietf-rtgwg-ipfrr-spec-base-09=20-=20LC=20coments |Sender:=20; bh=uBAz3yOrUPYdGSnPBhNNRp3vLMxK+OnJr3sgr9c36bw=; b=s93aLj1c4vYo38eHF7/vK4mUPFco66p8FFAIrP3s28TIts8EEKhIiaCArJwSN6U7DE9s3jar ESktv9gkHApdY8ifeYcwJRUSkLYXUheotZSEsGi0cxuAVxNaxQvEfgbg; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Subject: draft-ietf-rtgwg-ipfrr-spec-base-09 - LC coments X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stbryant@cisco.com List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtgwg-bounces@ietf.org Basic Specification for IP Fast-Reroute: Loop-free Alternates draft-ietf-rtgwg-ipfrr-spec-base-09 Abstract The goal of this technology is to reduce the micro-looping and packet loss that happens while routers converge after a topology change due to a failure. SB> This draft does not address microlooping - our other drafts do that. SB> There really ought to be a health warning saying that there are SB> other solutions with greater fault coverage, but this one SB> is simple and does not need any co-operation from any other SB> node in the network. 1. Introduction As discussed in [I-D.ietf-rtgwg-ipfrr-framework], SB> We need to ask the question of whether we need to LC the framework SB> draft and whether we need to publish that first to raise the SB> awareness level before we send this to IETF/IESG review? The mechanism also assumes that both the primary path and the alternate path are in the same routing area. SB> I am trying to remember how fundamental to the solution that is. SB> Unlike NV, LFA only uses cost information and we know the costs. SB> There is discussion regarding this restriction for OSPF, but does SB> the constraint also apply to ISIS? <-- +-----+ /------| S |--\ / +-----+ \ / 5 8 \ / \ +-----+ +-----+ | E | | N_1 | +-----+ +-----+ \ / \ \ 4 3 / / \| \ / |/ -+ \ +-----+ / +- \---| D |---/ +-----+ Figure 1: Basic Topology SB> This picture is not too bad, others are worse - particularly SB> the figure in the appendix. Would we help SB> the reader if we published a pdf version of the RFC? A network with this feature experiences less traffic loss and less micro-looping of packets than a network without IPFRR. There are cases where micro-looping is still a possibility since IPFRR coverage varies but in the worst possible situation a network with IPFRR is equivalent with respect to traffic convergence to a network without IPFRR. SB> Surely we are talking repair not uloop here? 1.1. Failure Scenarios The alternate next-hop can protect against a single link failure, a single node failure, one or more shared risk link group failures, or a combination of these. Whenever a failure occurs that is more extensive than what the alternate was intended to protect, there is the possibility of temporarily looping traffic (note again, that such a loop would only last until the next complete SPF calculation). SB> which may be delayed by the loop prevention mechanism. If there are not other protection mechanisms a node failure is still a concern when only using link protection. SB> This sentence seems in the wrong place - or provides too little SB> discussion on the issues concerning node failure. In Figure 2, S would be able to use N as an alternate, but N could not use S; SB> s/alternate/downstream alternate/ therefore N would have no alternate and would discard the traffic, thus avoiding the micro-loop. A micro-loop due to the use of alternates can be avoided by using downstream paths because each succeeding router in the path to the destination must be closer to the destination than its predecessor (according to the topology prior to the failures). Although use of downstream paths ensures that the micro-looping via alternates does not occur, such a restriction can severely limit the coverage of alternates. SB> Might be better to reorder the discussion here a little for SB> clarity. As shown above, the use of either a node protecting LFA or a downstream path provides protection against micro-looping in the event of node failure. SB> I don't think that you have explained NP LFA yet There are topologies where there may be either a node portecting LFA, a downstream path, both or neither. A node may select either a node protecting LFA or a downstream path without risk of causing micro-loops in the event of node failure. SB> neighbor node failure? Since the functionality of link and node protecting LFAs is greater than that of downstream paths, a router SHOULD select a link and node protecting LFA over a downstream path. SB> Should we just say NP LFA as L & NP LFA sounds like we have two SB> protection mechanisms. 3.3. Broadcast and NBMA Links +-----+ 15 | S |-------- +-----+ | | 5 | | | | 0 | /----\ 0 5 +-----+ | PN |-----| N | \----/ +-----+ | 0 | | | 8 | 5 | +-----+ 5 +-----+ | E |----| D | +-----+ +-----+ Figure 3: Loop-Free Alternate that is Link-Protecting In Figure 3, N offers a loop-free alternate which is link-protecting. If the primary next-hop uses a broadcast link, then an alternate SHOULD be loop-free with respect to that link's pseudo-node to provide link protection. This requirement is described in Inequality 4 below. D_opt(N, D) < D_opt(N, pseudo) + D_opt(pseudo, D) SB> The diagram used the term PN, maybe the equation should as well. 4.1. Terminating Use of Alternate An implementation SHOULD continue to use the alternate next-hops for packet forwarding even after the new routing information is available based on the new network topology. The use of the alternate next- hops for packet forwarding SHOULD terminate: a. if the new primary next-hop was loop-free prior to the topology change, or b. if a configured hold-down, which represents a worst-case bound on the length of the network convergence transition, has expired, or c. if notification of an unrelated topological change in the network is received. SB> I think that list list needs to include the case where the network SB> has converged (with or without the uloop prevention as applicable) 6. Routing Aspects 6.1. Multi-Homed Prefixes 5 +---+ 4 +---+ 5 +---+ ------| S |------| A |-----| B | | +---+ +---+ +---+ | | | | 5 | 5 | | | | +---+ 5 +---+ 5 7 +---+ | C |---| E |------ p -------| F | +---+ +---+ +---+ Figure 6: Multi-homed prefix If there exist multiple multi-homed prefixes that share the same connectivity and the difference in metrics to those routers, then a single node can be used to represent the set. For instance, if in Figure 6 there were another prefix X that was connected to E with a metric of 1 and to F with a metric of 3, then that prefix X could use the same alternate next-hop as was computed for prefix p. SB> I do not understand this simplification. I think that you are SB> saying use p as a proxy for p', p'' etc. But if they have SB> different costs don't you have to always use a different proxy? SB> Say p' was connected to E at cost 1, but F at cost 1000, surely SB> the packet would never get to F, or if it did, F would prefer SB> to sent it via E and hence loop. Is there a must sent external SB> assumption (which we considered for the tunnel solutions) that SB> is assumed? - Stewart _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Oct 12 08:07:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgJHK-0007Vy-05; Fri, 12 Oct 2007 08:06:06 -0400 Received: from rtgwg by megatron.ietf.org with local (Exim 4.43) id 1IgJHE-0007S8-G1 for rtgwg-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 08:06:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgJHE-0007S0-26 for rtgwg@ietf.org; Fri, 12 Oct 2007 08:06:00 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgJHD-0001pa-IN for rtgwg@ietf.org; Fri, 12 Oct 2007 08:05:59 -0400 X-IronPort-AV: E=Sophos;i="4.21,266,1188770400"; d="scan'208";a="155636373" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2007 14:05:47 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9CC5lrT031224 for ; Fri, 12 Oct 2007 14:05:47 +0200 Received: from [10.61.65.160] (ams3-vpn-dhcp416.cisco.com [10.61.65.160]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9CC5kSO027176 for ; Fri, 12 Oct 2007 12:05:46 GMT Message-ID: <470F6319.9060508@cisco.com> Date: Fri, 12 Oct 2007 13:05:45 +0100 From: mike shand User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2846; t=1192190747; x=1193054747; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshand@cisco.com; z=From:=20mike=20shand=20 |Subject:=20Comments=20on=20draft-ietf-rtgwg-ipfrr-spec-base-09 |Sender:=20; bh=sc+0rRkI526pbtC5bQ2HYJvaId5G+jIeu2epYefYw4w=; b=eP1ne+FKzzTbiubQGzx4yEcygl796lNK8/8+TvCwcAgT0jUCZJhJ6S+KW0IJHfg7XeTjtNIu SqPvIyG1PuuihX0jZt7Qx+tr+iZtCIqgwLEEmVJ14pxIRKcE3XIq+fER; Authentication-Results: ams-dkim-2; header.From=mshand@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: Comments on draft-ietf-rtgwg-ipfrr-spec-base-09 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 I support the progression of this document, but would like to see the comments Stewart and I made earlier on the algorithm addressed and also the few points below. In addition, I wonder whether there should be something up front which makes clear that this may only provide a partial solution (depending on the topology). I know this is implicit in the body of the text, but I think it would be useful to avoid any misunderstandings if the abstract were a little more explicit on this point. How about adding after "...The goal of this technology is to reduce the micro-looping and packet loss that happens while routers converge after a topology change due to a failure. ..." "The extent to which this goal can be met by this specification is dependant on the topology of the network." Mike 1.1. Failure Scenarios The alternate next-hop can protect against a single link failure, a single node failure, one or more shared risk link group failures, or a combination of these. It might be better to say "failure of one or more links within a shared risk link group". Figure 5: Example where Continued Use of Alternate is Desirable This is an example of a case where the new primary is not a loop-free alternate before the failure and therefore may have been forwarding traffic through S. This will occur when the path via a previously upstream node is shorter than the the path via a loop-free alternate neighbor. In these cases, it is useful to give sufficient time to ensure that the new primary neighbor and other nodes on the new primary path have switched to the new route. I wonder if it should be pointed out that while this is a good strategy to minimize the occurrence of microloops, it does nothing to prevent any microloops which may occur more than one hop away. based on the new network topology. The use of the alternate next- hops for packet forwarding SHOULD terminate: a. if the new primary next-hop was loop-free prior to the topology change, or b. if a configured hold-down, which represents a worst-case bound on the length of the network convergence transition, has expired, or c. if notification of an unrelated topological change in the network is received. We should probably add that if the primary link comes back before any of this has happened then you can just go back to using the primary link as if nothing had happened. That of course pre-supposes that the failure hadn't yet been advertised. If it HAS been advertised, then it requires another advertisement to put it back how it was, but in any case (I think) the old next hop can safely be used. _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Oct 12 11:11:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgM95-0003Cp-37; Fri, 12 Oct 2007 11:09:47 -0400 Received: from rtgwg by megatron.ietf.org with local (Exim 4.43) id 1IgM93-0003A2-Uw for rtgwg-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 11:09:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgM93-000383-Kl for rtgwg@ietf.org; Fri, 12 Oct 2007 11:09:45 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgM8w-00010j-Fd for rtgwg@ietf.org; Fri, 12 Oct 2007 11:09:45 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 9EEF3C3D4 for ; Fri, 12 Oct 2007 17:09:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 92099C3ED for ; Fri, 12 Oct 2007 17:09:22 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 754C0C3D4 for ; Fri, 12 Oct 2007 17:09:21 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id l9CF9Lh11966 for ; Fri, 12 Oct 2007 17:09:21 +0200 Received: from [132.187.106.126] (win3126.informatik.uni-wuerzburg.de [132.187.106.126]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 35A666F591 for ; Fri, 12 Oct 2007 17:02:16 +0200 (CEST) Message-ID: <470F8E19.9000700@informatik.uni-wuerzburg.de> Date: Fri, 12 Oct 2007 17:09:13 +0200 From: =?ISO-8859-1?Q?R=FCdiger_A_Martin?= User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: Comments on draft-ietf-rtgwg-ipfrr-spec-base-09 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 Dear Alia, dear Alex, we have taken a look at your document and would like to add a few=20 comments to the discussion already going on: - The concept of node protecting LFAs is first mentioned on page 6. The=20 definition and explanation follows later. - There are several kinds of loop-free alternates. But the suggested=20 order of preference among those different LFAs does not become clear at=20 all in the draft. So there should be some paragraph where all possible=20 candidate types are listed and described with their pros and cons. That=20 description should include the protected failure types but also the=20 behavior in case of unprotected failures: e.g., I miss a clear statement=20 that downstream LFAs do not create any loops no matter what kind of=20 failures may happen. Based on this, a clear suggestion for an order of=20 preference can be given. - Page 7: "Since the funcionality of link and node protecting LFAs is=20 greater than that of downstream paths, a router SHOULD select a link and=20 node protecting LFA over a downstream path." - That reads like=20 downstream paths are generally worse. But of course a downstream link-=20 and node-protecting LFA is better than a non-downstream link- and=20 node-protecting LFA. So this point is strongly related to the point=20 mentioned earlier concerning the order of preference. - A few comments on the algorithm on page 16 (besides I agree with=20 Stewarts comments): * Step 10: This means, if the router prefers other primary next=20 hops, it prefers them no matter what kind of failures (links or nodes)=20 they protect. So this algorithm prefers a link-protecting primary over a=20 link- and node-protecting downstream LFA. (Depending on the order of the=20 candidates - see below.) * The output of the algorithm depends on the order of the=20 candidate next hops. 1) Imagine that H_1 is a link-protecting primary next hop.=20 H_2 is a link- and node-protecting downstream LFA. Then H_1 will be=20 selected in the first iteration. During the second iteration, step 11=20 selects H2 instead. 2) Now imagine H_1' =3D H_2 and H_2' =3D H_1. Then the first=20 iteration selects H_1'. However, the second iteration selects H_2' as=20 the candidate in step 10. So the final result is H1. I think this problem is due to the missing order of preference. Besides we really appreciate this document and support the progression=20 of the document after consideration of the comments from above. We think=20 that Mike's idea to include explicitly that this may only provide a=20 partial solution is worth considering. But maybe together with the=20 statement that this is a really simple and easy to implement approach=20 since it does not require any support (i.e. signalling) from other router= s. Best regards, R=FCdiger --=20 _______________________________________________________ Dipl.-Inform. R=FCdiger Martin Department of Distributed Systems (Informatik III) Insitute of Computer Science, University of W=FCrzburg Am Hubland, 97074 W=FCrzburg, Germany martin@informatik.uni-wuerzburg.de Tel: +49 931 888-6651 Fax: +49 931 888-6632=20 _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Oct 12 15:44:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQP1-0007nX-S4; Fri, 12 Oct 2007 15:42:31 -0400 Received: from rtgwg by megatron.ietf.org with local (Exim 4.43) id 1IgQP0-0007nS-NJ for rtgwg-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 15:42:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQP0-0007jr-88 for rtgwg@ietf.org; Fri, 12 Oct 2007 15:42:30 -0400 Received: from exprod7og111.obsmtp.com ([64.18.2.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgQOt-0001wV-Va for rtgwg@ietf.org; Fri, 12 Oct 2007 15:42:30 -0400 Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Fri, 12 Oct 2007 12:41:57 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 12:41:56 -0700 Received: from [172.16.13.200] ([172.16.13.200]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id l9CJfun16929 for ; Fri, 12 Oct 2007 12:41:56 -0700 (PDT) (envelope-from jgs@juniper.net) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <0CEB2B4A-3583-4EB4-9332-EF1039B0EFA7@juniper.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: rtgwg@ietf.org From: "John G. Scudder" Date: Fri, 12 Oct 2007 15:41:28 -0400 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Oct 2007 19:41:56.0733 (UTC) FILETIME=[F2ABB2D0:01C80D07] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: agenda topics for IETF-70 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, If you would like an agenda slot for our IETF-70 meeting, please let me know. Please also let me know how much time you think you'll need. --John _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Oct 12 17:34:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgS8R-0003SX-LF; Fri, 12 Oct 2007 17:33:31 -0400 Received: from rtgwg by megatron.ietf.org with local (Exim 4.43) id 1IgS8P-0003SN-Mo for rtgwg-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 17:33:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgS8P-0003SC-CU for rtgwg@ietf.org; Fri, 12 Oct 2007 17:33:29 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgS8J-0005jZ-5c for rtgwg@ietf.org; Fri, 12 Oct 2007 17:33:29 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 94E12C41E for ; Fri, 12 Oct 2007 23:33:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 87571C422 for ; Fri, 12 Oct 2007 23:33:17 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 7476EC41E for ; Fri, 12 Oct 2007 23:33:17 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id l9CLXHh14044; Fri, 12 Oct 2007 23:33:17 +0200 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id B52C76F591; Fri, 12 Oct 2007 23:26:11 +0200 (CEST) Message-ID: <470FE814.70908@informatik.uni-wuerzburg.de> Date: Fri, 12 Oct 2007 23:33:08 +0200 From: =?ISO-8859-1?Q?R=FCdiger_A_Martin?= User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: Re: Comments on draft-ietf-rtgwg-ipfrr-spec-base-09 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, we recently finished a comparison of LFAs and Not-Vias. http://www-info3.informatik.uni-wuerzburg.de/TR/tr432.pdf It provides alternative wording for LFA description, strategies for LFA selection for different resilience requirements, and quantitative results of their impact on protection coverage. It also compares the path prolongation and decapsulation load for various combinations of LFAs and Not-Vias. We plan to extend the analysis to broadcast scenarios and SRLGs. This analysis might be useful when reworking the current draft. Comments=20 are welcome. Regards, R=FCdiger --=20 _______________________________________________________ Dipl.-Inform. R=FCdiger Martin Department of Distributed Systems (Informatik III) Insitute of Computer Science, University of W=FCrzburg Am Hubland, 97074 W=FCrzburg, Germany martin@informatik.uni-wuerzburg.de Tel: +49 931 888-6651 Fax: +49 931 888-6632=20 _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Sat Oct 13 01:25:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgZTk-0000bN-Dg; Sat, 13 Oct 2007 01:24:00 -0400 Received: from rtgwg by megatron.ietf.org with local (Exim 4.43) id 1IgZTi-0000aP-Vt for rtgwg-confirm+ok@megatron.ietf.org; Sat, 13 Oct 2007 01:23:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgZTh-0000VH-Ix for rtgwg@ietf.org; Sat, 13 Oct 2007 01:23:57 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgZTb-0005gT-0t for rtgwg@ietf.org; Sat, 13 Oct 2007 01:23:57 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JPU00CFU4ABTL@szxga04-in.huawei.com> for rtgwg@ietf.org; Sat, 13 Oct 2007 13:22:59 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JPU00JWS4AAKY@szxga04-in.huawei.com> for rtgwg@ietf.org; Sat, 13 Oct 2007 13:22:58 +0800 (CST) Received: from d68733d ([10.111.12.195]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JPU009VK4A98D@szxml04-in.huawei.com> for rtgwg@ietf.org; Sat, 13 Oct 2007 13:22:58 +0800 (CST) Date: Sat, 13 Oct 2007 13:22:38 +0800 From: "Abhay D.S" To: rtgwg@ietf.org Message-id: <045501c80d59$125722d0$c30c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Subject: Cascaded U Turns for IP Unicast FRR X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Abhay D.S" List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0246158142==" Errors-To: rtgwg-bounces@ietf.org This is a multi-part message in MIME format. --===============0246158142== Content-type: multipart/alternative; boundary="Boundary_(ID_1eE4dJEsg9EppwlBn5DbkQ)" This is a multi-part message in MIME format. --Boundary_(ID_1eE4dJEsg9EppwlBn5DbkQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT hi alia and alex, If a neighbor cannot provide a loop free alternate, then a consideration for U turn alternate is made for the same neighbor. Now this U Turn Alternate cannot find a neighbor which can provide a LFA, then we can consider this neighbors -> Neighbor upstream. If this upstream neighbor can support LFA, then how to consider the forwarding from Source -> U-Turn Neighbor -> U-Turns Nbrs Nbr -> U-Turns Nbrs Nbrs Nbrs{ DISTANCE not via Source (This Nbr, Destination) < SPFDist(This Nbr, Src) + SPFDist(Src,Dest) is TRUE at upstream neighbor). Source can determine this and sends packet to U turn Neighbor say X, U turn neighbor X knows that it cannot send the packet to its neighbor Y, since Y cannot provide a Loop Free Alternate but Z , Y's Upstream neighbor can. In my understanding X can be configured to consider more than one hop neighbors can provide LFA, in this case Y's Neighbors Z At Y the primary next hop to reach destination is Z. I think X must signal to Src about its availablity as a U Turn for a Neighbor explicitly for a particular prefix. How do you think ?. Thanks and Regards, Abhay --Boundary_(ID_1eE4dJEsg9EppwlBn5DbkQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT

hi alia and alex,

If a neighbor cannot provide a loop free alternate,

then a consideration for U turn alternate is made for

the same neighbor.

Now this U Turn Alternate cannot find a neighbor which can provide

a LFA, then we can consider this neighbors -> Neighbor upstream.

If this upstream neighbor can support LFA, then how to consider

the forwarding from

Source -> U-Turn Neighbor -> U-Turns Nbrs Nbr -> U-Turns Nbrs Nbrs Nbrs{ DISTANCE not via Source (This Nbr, Destination) < SPFDist(This Nbr, Src) + SPFDist(Src,Dest) is TRUE at upstream

neighbor).

Source can determine this and sends packet to U turn Neighbor say X, U turn neighbor X knows that it cannot send the packet to its neighbor Y, since Y

cannot provide a Loop Free Alternate but Z , Y's Upstream neighbor can.

In my understanding X can be configured to consider more than one hop neighbors can provide LFA, in this case Y's Neighbors Z

At Y the primary next hop to reach destination is Z.

I think X must signal to Src about its availablity as a U Turn for a Neighbor explicitly for a particular prefix.

How do you think ?.

Thanks and Regards,

Abhay

--Boundary_(ID_1eE4dJEsg9EppwlBn5DbkQ)-- --===============0246158142== 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 --===============0246158142==-- From rtgwg-bounces@ietf.org Sat Oct 13 06:22:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ige6C-00021c-PE; Sat, 13 Oct 2007 06:20:00 -0400 Received: from rtgwg by megatron.ietf.org with local (Exim 4.43) id 1Ige6B-00020d-AB for rtgwg-confirm+ok@megatron.ietf.org; Sat, 13 Oct 2007 06:19:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ige6A-0001zQ-Uz for rtgwg@ietf.org; Sat, 13 Oct 2007 06:19:59 -0400 Received: from imo-m23.mx.aol.com ([64.12.137.4]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ige66-0003ua-VW for rtgwg@ietf.org; Sat, 13 Oct 2007 06:19:55 -0400 Received: from HeinerHummel@aol.com by imo-m23.mx.aol.com (mail_out_v38_r9.3.) id c.c2a.18a1ea08 (42809); Sat, 13 Oct 2007 06:19:48 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Sat, 13 Oct 2007 06:19:48 EDT To: mshand@cisco.com MIME-Version: 1.0 X-Mailer: AOL 9.0 VR sub 52 X-Spam-Flag: NO X-Spam-Score: 1.8 (+) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf Cc: rtgwg@ietf.org Subject: Re: "Basic Specification for IP Fast-Reroute: Loop-free Alternates" 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="===============0112207185==" Errors-To: rtgwg-bounces@ietf.org --===============0112207185== Content-Type: multipart/alternative; boundary="-----------------------------1192270788" -------------------------------1192270788 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 Admitted, I have misunderstood the spec. However it is a mutual =20 misunderstanding. While the IETF's IGP routing technology is essentially based on the =20 Dijkstra's SPT (which spans all network nodes) all my thinking is based on a= SPT =20 which spans all network links. While ECMP tree links are certainly an essent= ial =20 part of "my All Links Spanning Tree ALST" they are timidly excused in some=20 IETF draft by saying "it is still a SPT". And yet I am sure that an ALST (as can be seen on my webpage) would be the=20 right base for decades of routing research to come. =20 Heiner =20 www.hummel-research.de =20 =20 In einer eMail vom 12.10.2007 10:14:28 Westeurop=E4ische Normalzeit schreibt= =20 mshand@cisco.com: _HeinerHummel@aol.com_ (mailto:HeinerHummel@aol.com) wrote: =20 =20 In einer eMail vom 08.10.2007 16:09:46 Westeurop=E4ische Normalzeit schreib= t=20 HeinerHummel: (1) Now that I have become familiar with the notvia node solution I must say:=20 Yes that is an excellent solution. I am afraid, I have praised this solution too early. a) why should S have any (failure) suspicion on P if S is not immediate =20 neighbor of P ? Why do you think it should? It doesn't and can't (unless it is a member of=20 an SRLG, in which case its failure is implied by the failure of the immedia= te=20 neighbor/link). It seems you have misundestood the spec. b) why should a direct neighbor of P be the appropriate intermediate =20 destination ? Because we are protecting against node failure of P and that is where the=20 traffic WOULD have gone. The immediate neighbor of P should rather start a detour towards some=20 intermediate destination somewhere in the network such that best as well as= =20 equally best hops towards it won't hit P ! I think you are talking about something akin to the original tunnels scheme= =20 (aka PQ space), which suffers from all sorts of corner cases. I suggest you= =20 read=20 _http://www.potaroo.net/ietf/all-ids/draft-bryant-ipfrr-tunnels-00.txt-70928= .txt_=20 (http://www.potaroo.net/ietf/all-ids/draft-bryant-ipfrr-tunnels-00.txt-70928= .txt) to see the difficulties this approach suffered from. The point=20 about not-via is that it is very simple. We have considered the possibility= of=20 exiting the tunnel once Q space has been reached, thus allowing the packet= =20 a potentially more direct route, but this is generally regarded as overly =20 complex. Heiner =20 =20 =20 ____________________________________ Subject: =20 Re: "Basic Specification for IP Fast-Reroute: Loop-free Alternates" =20 From:=20 _HeinerHummel@aol.com_ (mailto:HeinerHummel@aol.com) =20 Date:=20 Mon, 8 Oct 2007 10:09:46 EDT =20 To:=20 _mshand@cisco.com_ (mailto:mshand@cisco.com) =20 To:=20 _mshand@cisco.com_ (mailto:mshand@cisco.com) =20 CC:=20 _rtgwg@ietf.org_ (mailto:rtgwg@ietf.org)=20 (1) Now that I have become familiar with the notvia node solution I must say:=20 Yes that is an excellent solution. (2) Nevertheless, it should be made clear: each node along the notvia-path must= =20 precisely select its notvia-nexthop link i.e. no respective ECMP hop ! =20 Otherwise a deja vu with the failing node may happen. Let me just repeat th= at there=20 alternatives which allow "multipath" along the notvia route (which however=20 take more efforts to avoid any loop). (3) I think it is ( unnessecarily ) too much protection centric. Why not just=20 saying AVOID a particular node and/or link? Protection seems to be used just like in soccer defense.Who protects whom?=20 For specifying this subject it is not sufficient to reduce the diagram to j= ust=20 two paths( a protecting one and a protected one). There may be more (not=20 shown) paths which may protect resp. which may need to be protected. Also,=20= there=20 may be other reasons than failures why to tour around a particular node/lin= k. (4) I also hope that this WG considers this draft just as a beginning. The =20 better and the more of good results, the smaller the phantom angst of a loo= p. Yes=20 crankback is a loop, but it could be made perfectly i.e. with successful=20 delivery (although I think I read something about back tracking that should= n't=20 bother) =20 =20 Heiner =20 =20 =20 -------------------------------1192270788 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

Admitted, I have misunderstood the spec. However it is a mutual=20 misunderstanding.

While the IETF's IGP routing technology is essentially based on t= he=20 Dijkstra's SPT (which spans all network nodes) all my thinking is based on a= SPT=20 which spans all network links. While ECMP tree links are certainly an essent= ial=20 part of "my All Links Spanning Tree ALST" they are timidly=20 excused in some IETF draft by saying "it is still a SPT".

And yet I am sure that an ALST (as can be seen on my webpage) woul= d be=20 the right base for decades of routing research to come.

Heiner

www.hummel-research.de

In einer eMail vom 12.10.2007 10:14:28 Westeurop=E4ische Normalzeit sch= reibt=20 mshand@cisco.com:

<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>HeinerHummel@aol.com wrote:=20

In einer eMail vom 08.10.2007 16:09:46 Westeurop=E4ische Normalzeit= =20 schreibt HeinerHummel:

(1)

Now that I have become familiar with the notvia node solution I m= ust=20 say: Yes that is an excellent=20 solution.

I am afraid, I have praised this solution too early.

a) why should S have any (failure) suspicion on P if S is not immed= iate=20 neighbor of P ?

Why do you think it should? It=20 doesn't and can't (unless it is a member of an SRLG, in which case its fai= lure=20 is implied by the failure of the immediate neighbor/link). It seems you ha= ve=20 misundestood the spec.

b) why should a direct neighbor of P be the appropriate intermediat= e=20 destination ?

Because we are protecting against= node=20 failure of P and that is where the traffic WOULD have gone.

The immediate neighbor of P should rather start a detour=20 towards some intermediate destination somewhere in the network suc= h=20 that best as well as equally best hops towards it won't hit P=20 !

I think you are talking about something akin=20= to the=20 original tunnels scheme (aka PQ space), which suffers from all sorts of co= rner=20 cases. I suggest you read http://www.potaroo.net/ietf/all-ids/draft-bryant-ipfrr-tunnel= s-00.txt-70928.txt=20 to see the difficulties this approach suffered from. The point about not-v= ia=20 is that it is very simple. We have considered the possibility of exiting&n= bsp;=20 the tunnel once Q space has been reached, thus allowing the packet a=20 potentially more direct route, but this is generally regarded as overly=20 complex.

Heiner

=

Subject:=20
Re: "Basic Specification for IP Fast-Reroute: Loop-free=20 Alternates"

From: HeinerHummel@aol.com

Date: Mon,=20 8 Oct 2007 10:09:46 EDT

To: mshand@cisco.com

To: mshand@cisco.com

CC: rtgwg@ietf.org

(1)

Now that I have become familiar with the notvia node solution I mus= t=20 say: Yes that is an excellent solution.

(2)

Nevertheless, it should be made clear: each node along the notvia-p= ath=20 must precisely select its notvia-nexthop link i.e. no respective ECMP ho= p !=20 Otherwise a deja vu with the failing node may happen. Let me just repeat= =20 that there alternatives which allow "multipath" along the notvia route=20 (which however take more efforts to avoid any loop).

(3)

I think it is ( unnessecarily ) too much protection centric. Why no= t=20 just saying AVOID a particular node and/or link?

Protection seems to be used just like in soccer defense.Who protect= s=20 whom? For specifying this subject it is not sufficient to reduce th= e=20 diagram to just two paths( a protecting one and a protected one). There=20= may=20 be more (not shown) paths which may protect resp. which may need to be=20 protected. Also, there may be other reasons than failures why to tour ar= ound=20 a particular node/link.

(4)

I also hope that this WG considers this draft just as a beginning.=20= The=20 better and the more of good results, the smaller the phantom angst of a=20 loop. Yes crankback is a loop, but it could be made perfectly i.e. with=20 successful delivery (although I think I read something about back tracki= ng=20 that shouldn't bother)

Heiner

-------------------------------1192270788-- --===============0112207185== 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 --===============0112207185==-- From rtgwg-bounces@ietf.org Sun Oct 14 21:11:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhESf-0008MY-Pp; Sun, 14 Oct 2007 21:09:37 -0400 Received: from rtgwg by megatron.ietf.org with local (Exim 4.43) id 1IhESe-0008MQ-D8 for rtgwg-confirm+ok@megatron.ietf.org; Sun, 14 Oct 2007 21:09:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhESd-0008MH-JQ for rtgwg@ietf.org; Sun, 14 Oct 2007 21:09:35 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhESb-0007EK-VH for rtgwg@ietf.org; Sun, 14 Oct 2007 21:09:35 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JPX002ZQHUQ51@szxga02-in.huawei.com> for rtgwg@ietf.org; Mon, 15 Oct 2007 09:08:50 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JPX00DD4HUOAB@szxga02-in.huawei.com> for rtgwg@ietf.org; Mon, 15 Oct 2007 09:08:50 +0800 (CST) Received: from d68733d ([10.111.12.195]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JPX001LZHUNJX@szxml03-in.huawei.com> for rtgwg@ietf.org; Mon, 15 Oct 2007 09:08:48 +0800 (CST) Date: Mon, 15 Oct 2007 09:08:29 +0800 From: "Abhay D.S" To: rtgwg@ietf.org Message-id: <04f501c80ec7$e6cd3cb0$c30c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 89ebdf268eceaeaf784b3acb625dc20e Subject: Re: rtgwg Digest, Vol 37, Issue 8 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Abhay D.S" List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtgwg-bounces@ietf.org Not via solution still must consider LFA a) From the algorithm point of view not via is more efficient because when one has calculated the primary next hops, the rest of the not via addresses can be directly inhereted once. And re-attached for every failed node once. b) not via and LFA go together and only U Turn is not considered. ----- Original Message ----- =46rom: To: Sent: Sunday, October 14, 2007 12:00 AM Subject: rtgwg Digest, Vol 37, Issue 8 > Send rtgwg mailing list submissions to > rtgwg@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/rtgwg > or, via email, send a message with subject or body 'help' to > rtgwg-request@ietf.org > > You can reach the person managing the list at > rtgwg-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of rtgwg digest..." > > > Today's Topics: > > 1. agenda topics for IETF-70 (John G. Scudder) > 2. Re: Comments on draft-ietf-rtgwg-ipfrr-spec-base-09 > (R?diger A Martin) > 3. Cascaded U Turns for IP Unicast FRR (Abhay D.S) > 4. Re: "Basic Specification for IP Fast-Reroute: Loop-free > Alternates" (HeinerHummel@aol.com) > > > -------------------------------------------------------------------= --- > > Message: 1 > Date: Fri, 12 Oct 2007 15:41:28 -0400 > From: "John G. Scudder" > Subject: agenda topics for IETF-70 > To: rtgwg@ietf.org > Message-ID: <0CEB2B4A-3583-4EB4-9332-EF1039B0EFA7@juniper.net> > Content-Type: text/plain; charset=3DUS-ASCII; delsp=3Dyes; format= =3Dflowed > > Folks, > > If you would like an agenda slot for our IETF-70 meeting, please le= t > me know. Please also let me know how much time you think you'll ne= ed. > > --John > > > > > ------------------------------ > > Message: 2 > Date: Fri, 12 Oct 2007 23:33:08 +0200 > From: R?diger A Martin > Subject: Re: Comments on draft-ietf-rtgwg-ipfrr-spec-base-09 > To: rtgwg@ietf.org > Message-ID: <470FE814.70908@informatik.uni-wuerzburg.de> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > > Hi all, > > we recently finished a comparison of LFAs and Not-Vias. > http://www-info3.informatik.uni-wuerzburg.de/TR/tr432.pdf > > It provides alternative wording for LFA description, strategies for > LFA selection for different resilience requirements, and quantitati= ve > results of their impact on protection coverage. It also > compares the path prolongation and decapsulation load for various > combinations of LFAs and Not-Vias. We plan to extend the analysis t= o > broadcast scenarios and SRLGs. > > This analysis might be useful when reworking the current draft. Com= ments > are welcome. > > Regards, > > R=FCdiger > > -- > _______________________________________________________ > > Dipl.-Inform. R=FCdiger Martin > Department of Distributed Systems (Informatik III) > Insitute of Computer Science, University of W=FCrzburg > Am Hubland, 97074 W=FCrzburg, Germany > martin@informatik.uni-wuerzburg.de > Tel: +49 931 888-6651 > Fax: +49 931 888-6632 > > > > > > ------------------------------ > > Message: 3 > Date: Sat, 13 Oct 2007 13:22:38 +0800 > From: "Abhay D.S" > Subject: Cascaded U Turns for IP Unicast FRR > To: rtgwg@ietf.org > Message-ID: <045501c80d59$125722d0$c30c6f0a@china.huawei.com> > Content-Type: text/plain; charset=3D"gb2312" > > hi alia and alex, > > If a neighbor cannot provide a loop free alternate, > then a consideration for U turn alternate is made for > the same neighbor. > > Now this U Turn Alternate cannot find a neighbor which can provide > a LFA, then we can consider this neighbors -> Neighbor upstream. > > If this upstream neighbor can support LFA, then how to consider > the forwarding from > > Source -> U-Turn Neighbor -> U-Turns Nbrs Nbr -> U-Turns Nbrs Nbrs = Nbrs{ DISTANCE not via Source (This Nbr, Destination) < SPFDist(This Nbr, S= rc) + SPFDist(Src,Dest) is TRUE at upstream > neighbor). > > Source can determine this and sends packet to U turn Neighbor say X= , U turn neighbor X knows that it cannot send the packet to its neighbor= Y, since Y > cannot provide a Loop Free Alternate but Z , Y's Upstream neighbor = can. > > In my understanding X can be configured to consider more than one h= op neighbors can provide LFA, in this case Y's Neighbors Z > > At Y the primary next hop to reach destination is Z. > > I think X must signal to Src about its availablity as a U Turn for = a Neighbor explicitly for a particular prefix. > > How do you think ?. > > Thanks and Regards, > Abhay > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://www1.ietf.org/pipermail/rtgwg/attachments/20071013/78ea50da/at= tachmen t.html > > ------------------------------ > > Message: 4 > Date: Sat, 13 Oct 2007 06:19:48 EDT > From: HeinerHummel@aol.com > Subject: Re: "Basic Specification for IP Fast-Reroute: Loop-free > Alternates" > To: mshand@cisco.com > Cc: rtgwg@ietf.org > Message-ID: > Content-Type: text/plain; charset=3D"iso-8859-1" > > > Admitted, I have misunderstood the spec. However it is a mutual > misunderstanding. > While the IETF's IGP routing technology is essentially based on th= e > Dijkstra's SPT (which spans all network nodes) all my thinking is b= ased on a SPT > which spans all network links. While ECMP tree links are certainly = an essential > part of "my All Links Spanning Tree ALST" they are timidly excused= in some > IETF draft by saying "it is still a SPT". > And yet I am sure that an ALST (as can be seen on my webpage) would= be the > right base for decades of routing research to come. > > Heiner > > www.hummel-research.de > > > In einer eMail vom 12.10.2007 10:14:28 Westeurop=E4ische Normalzeit= schreibt > mshand@cisco.com: > > _HeinerHummel@aol.com_ (mailto:HeinerHummel@aol.com) wrote: > > In einer eMail vom 08.10.2007 16:09:46 Westeurop=E4ische Normalzeit schreibt > HeinerHummel: > > (1) > Now that I have become familiar with the notvia node solution I mus= t say: > Yes that is an excellent solution. > > > I am afraid, I have praised this solution too early. > a) why should S have any (failure) suspicion on P if S is not immed= iate > neighbor of P ? > > Why do you think it should? It doesn't and can't (unless it is a m= ember of > an SRLG, in which case its failure is implied by the failure of th= e immediate > neighbor/link). It seems you have misundestood the spec. > > > b) why should a direct neighbor of P be the appropriate intermediat= e > destination ? > > Because we are protecting against node failure of P and that is wh= ere the > traffic WOULD have gone. > > The immediate neighbor of P should rather start a detour towards = some > intermediate destination somewhere in the network such that best a= s well as > equally best hops towards it won't hit P ! > > I think you are talking about something akin to the original tunne= ls scheme > (aka PQ space), which suffers from all sorts of corner cases. I su= ggest you > read > _http://www.potaroo.net/ietf/all-ids/draft-bryant-ipfrr-tunnels-00.tx= t-70928 =2Etxt_ > (http://www.potaroo.net/ietf/all-ids/draft-bryant-ipfrr-tunnels-00.tx= t-70928 =2Etxt) to see the difficulties this approach suffered from. The po= int > about not-via is that it is very simple. We have considered the possibility of > exiting the tunnel once Q space has been reached, thus allowing t= he packet > a potentially more direct route, but this is generally regarded as= overly > complex. > > > Heiner > > > > > ____________________________________ > > Subject: > Re: "Basic Specification for IP Fast-Reroute: Loop-free Alternates= " > From: > _HeinerHummel@aol.com_ (mailto:HeinerHummel@aol.com) > Date: > Mon, 8 Oct 2007 10:09:46 EDT > To: > _mshand@cisco.com_ (mailto:mshand@cisco.com) > To: > _mshand@cisco.com_ (mailto:mshand@cisco.com) > CC: > _rtgwg@ietf.org_ (mailto:rtgwg@ietf.org) > (1) > Now that I have become familiar with the notvia node solution I mus= t say: > Yes that is an excellent solution. > (2) > Nevertheless, it should be made clear: each node along the notvia-p= ath must > precisely select its notvia-nexthop link i.e. no respective ECMP ho= p ! > Otherwise a deja vu with the failing node may happen. Let me just r= epeat that there > alternatives which allow "multipath" along the notvia route (which however > take more efforts to avoid any loop). > (3) > I think it is ( unnessecarily ) too much protection centric. Why no= t just > saying AVOID a particular node and/or link? > Protection seems to be used just like in soccer defense.Who protect= s whom? > For specifying this subject it is not sufficient to reduce the dia= gram to just > two paths( a protecting one and a protected one). There may be mor= e (not > shown) paths which may protect resp. which may need to be protecte= d. Also, there > may be other reasons than failures why to tour around a particular node/link. > (4) > I also hope that this WG considers this draft just as a beginning. = The > better and the more of good results, the smaller the phantom angst = of a loop. Yes > crankback is a loop, but it could be made perfectly i.e. with succ= essful > delivery (although I think I read something about back tracking th= at shouldn't > bother) > > > Heiner > > > > > > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://www1.ietf.org/pipermail/rtgwg/attachments/20071013/ebd20798/at= tachmen t.html > > ------------------------------ > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www1.ietf.org/mailman/listinfo/rtgwg > > > End of rtgwg Digest, Vol 37, Issue 8 > ************************************ _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Oct 15 17:56:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhXtn-0003iq-Sv; Mon, 15 Oct 2007 17:54:55 -0400 Received: from rtgwg by megatron.ietf.org with local (Exim 4.43) id 1IhXtm-0003dO-9L for rtgwg-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 17:54:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhXtl-0003Rf-6W for rtgwg@ietf.org; Mon, 15 Oct 2007 17:54:53 -0400 Received: from exprod7og102.obsmtp.com ([64.18.2.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhXtd-0006VT-HY for rtgwg@ietf.org; Mon, 15 Oct 2007 17:54:51 -0400 Received: from source ([66.129.224.36]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Mon, 15 Oct 2007 14:54:20 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Oct 2007 14:54:33 -0700 Received: from [172.23.9.169] ([172.23.9.169]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id l9FLsWn60616; Mon, 15 Oct 2007 14:54:33 -0700 (PDT) (envelope-from jgs@juniper.net) In-Reply-To: <470F5341.8030900@cisco.com> References: <470F5341.8030900@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "John G. Scudder" Date: Mon, 15 Oct 2007 15:53:45 -0600 To: stbryant@cisco.com X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 15 Oct 2007 21:54:33.0621 (UTC) FILETIME=[F895B450:01C80F75] X-Spam-Score: -4.0 (----) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: rtgwg@ietf.org Subject: Re: draft-ietf-rtgwg-ipfrr-spec-base-09 - LC coments 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 Stewart, On Oct 12, 2007, at 4:58 AM, Stewart Bryant wrote: > SB> We need to ask the question of whether we need to LC the framework > SB> draft and whether we need to publish that first to raise the > SB> awareness level before we send this to IETF/IESG review? I think this is a reasonable point. I confess to not having read the framework draft recently, but last time I did I thought it seemed in decent shape. So, let me turn the question back to you: Do you as its author believe the framework draft is ready for LC? If so, let's proceed. --John _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Oct 15 18:03:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhY1t-000445-V6; Mon, 15 Oct 2007 18:03:17 -0400 Received: from rtgwg by megatron.ietf.org with local (Exim 4.43) id 1IhY1q-00041B-Pi for rtgwg-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 18:03:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhY1q-00040H-0g for rtgwg@ietf.org; Mon, 15 Oct 2007 18:03:14 -0400 Received: from exprod7og103.obsmtp.com ([64.18.2.159]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhY1n-0004M8-H1 for rtgwg@ietf.org; Mon, 15 Oct 2007 18:03:11 -0400 Received: from source ([66.129.224.36]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Mon, 15 Oct 2007 15:03:10 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 15:02:20 -0700 Received: from [172.23.9.169] ([172.23.9.169]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id l9FM2Hn63979 for ; Mon, 15 Oct 2007 15:02:19 -0700 (PDT) (envelope-from jgs@juniper.net) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <1BE7AC0C-9229-4BC5-B968-74F8614D4A57@juniper.net> References: <1BE7AC0C-9229-4BC5-B968-74F8614D4A57@juniper.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5D2C268D-1DCA-45E9-9988-1F940B1C5BDA@juniper.net> Content-Transfer-Encoding: 7bit From: "John G. Scudder" Date: Mon, 15 Oct 2007 16:01:29 -0600 To: rtgwg@ietf.org X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 15 Oct 2007 22:02:20.0131 (UTC) FILETIME=[0EA57B30:01C80F77] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: Re: Working Group Last Call for "Basic Specification for IP Fast-Reroute: Loop-free Alternates" 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 The WGLC period is over. The is that the authors are planning to revise the draft to reflect the comments received. We'll revisit this once that's done. If you have any further comments on the draft, please make every effort to send them soon so that they can be taken into consideration when the draft is revised. --John On Sep 26, 2007, at 1:47 PM, John G. Scudder wrote: > Folks, > > The authors have indicated they're ready for WGLC on "Basic > Specification for IP Fast-Reroute: Loop-free Alternates" (draft- > ietf-rtgwg-ipfrr-spec-base-09). You can access the draft at http:// > www.ietf.org/internet-drafts/draft-ietf-rtgwg-ipfrr-spec-base-09.txt. > > Please send comments to the list. The deadline for comments is > October 12. > > --John _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Thu Oct 25 11:27:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il4b3-00015w-JH; Thu, 25 Oct 2007 11:26:09 -0400 Received: from rtgwg by megatron.ietf.org with local (Exim 4.43) id 1Il4b2-00015m-45 for rtgwg-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 11:26:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il4b1-00015c-IK for rtgwg@ietf.org; Thu, 25 Oct 2007 11:26:07 -0400 Received: from rn-out-0910.google.com ([64.233.170.191] helo=rn-out-0102.google.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il4av-0007z6-56 for rtgwg@ietf.org; Thu, 25 Oct 2007 11:26:07 -0400 Received: by rn-out-0102.google.com with SMTP id a46so203997rne for ; Thu, 25 Oct 2007 08:25:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=mGchWUzcogDBdlqNd8lksE4gKaFqM/ynY607kNCOunc=; b=pPd38pR4wHhuRyNa7iONZMvf5eCgKDwtF3fSyPIbmbO7gxSq+PituYfkY9ADGH/Ri5EITrAmrM0QyI598Ae/WNK9RgUdE3oPAOWeONQ3h/2Z58viAPW1PMVpiFoDals1g3abhkxlaMHt+OqnAB7Qq9WwNil4IAzNSHl3H+uwpXs= 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=KSZyHjxQxW4U97zR7VaoX21cNPGu2TF7TEXdygDzJE7HcyZERTLomV5SSGTn6wbDHVf43OwZO4sgxyBGZLURMkR75bJTwoHTDsRRKatB9jO9MmaleaQgHXNuV5n1WzxW1uhWoA9xlJNtEp9Zq/FOFqOEoSl+VJ4mqHMf4rXsGHg= Received: by 10.142.229.4 with SMTP id b4mr540172wfh.1193325932424; Thu, 25 Oct 2007 08:25:32 -0700 (PDT) Received: by 10.143.164.4 with HTTP; Thu, 25 Oct 2007 08:25:32 -0700 (PDT) Message-ID: <6280db520710250825s1762d631n962a0a8fd952591c@mail.gmail.com> Date: Thu, 25 Oct 2007 11:25:32 -0400 From: "Alia Atlas" To: stbryant@cisco.com In-Reply-To: <4703A35E.2080807@cisco.com> MIME-Version: 1.0 References: <4703A35E.2080807@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 Cc: rtgwg@ietf.org Subject: Re: Comments on Algorithm description in draft-ietf-rtgwg-ipfrr-spec-base-09 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="===============0513145084==" Errors-To: rtgwg-bounces@ietf.org --===============0513145084== Content-Type: multipart/alternative; boundary="----=_Part_2902_19566100.1193325932391" ------=_Part_2902_19566100.1193325932391 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Stewart, Thanks for the careful read and good comments; sorry for taking so long to respond - I've been traveling & sick. On 10/3/07, Stewart Bryant wrote: > > Alia > > We have taken a look at the algorithm in section 3.6 of > draft-ietf-rtgwg-ipfrr-spec-base-09, and there are a > number of cases where some clarification is needed to aid > understanding. > > The root problem is that you have an object oriented > description of the algorithm but have not always defined > the objects. > > Please see below. > > We will also provide comments on the draft itself in another email. > > Mike & Stewart > > ======begin===== > > > S is the computing router and has candidate next-hops H_1 through > H_k. > > SB> You need to define a candidate next hop before you can say a router > SB> has them (i.e. move the definition earlier) > > N_i and N_j are used to refer to neighbors of S. For a next-hop > to be a candidate, the next-hop must be associated with a bi- > directional link, as is determined by the IGP. > > SB> I think you want to say: > SB> S is the computing router > SB> S has neighbours N_1 to N_j > SB> The candidate next hops H_1 to H_k are the subset of N that are > SB> bidirectionally connected to S. This is almost correct - a next-hop includes not just the neighbor but also the outgoing interface. There can be multiple candidate next-hops that refer to the same neighbor N_i. SB> Why does H_i have to be bidirectionally connected? Just because bidirectional connectivity is required in OSPF/ISIS for a link to be usable. I think that is more a sanity-check that both ends of the link have the same database - and I see no reason to vary from it here. Do you disagree? For a particular > destination router D, let S have already computed D_opt(S, D), and > for each neighbor N_i, D_opt(N_i, D), D_opt(N_i, S), and D_opt(N_i, > > SB> Why is this N_i and not H_i? A next-hop is the (outgoing interface, N_i) pair. The distance computed is to the neighbor N_i and need not go through the outgoing interface associated with H_i. N_j), the distance from N_i to each other neighbor N_j, and the set > of SRLGs traversed by the path D_opt(N_i, D). S should follow the > below procedure for every primary next-hop selected to reach D. This > set of primary next-hops is represented P_1 to P_p. This procedure > finds the alternate next-hop(s) for P_i. > > SB> In the text so far X_i refers to the node itself, i.e. what you > later > SB> appear to call X_i.neighbor. This is confusing I'm not sure exactly what you mean here (since there aren't any X_i in the text). Is this the confusion between a neighbor N_i and a next-hop H_i that contains (outgoing interface, neighbor)? Does replacing the following paragraph "S is the computing router and has candidate next-hops H_1 through H_k. N_i and N_j are used to refer to neighbors of S. For a next-hop to be a candidate, the next-hop must be associated with a bi- directional link, as is determined by the IGP." with "S is the computing router. S has neighbors N_1 to N_j. A candidate next-hop is indicated by (outgoing link, neighbor) and the outgoing link must be bidirectionally connected, as is determined by the IGP. The candidate next-hops of S are enumerated as H_1 through H_k." help? First, initialize the alternate information for P_i as follows: > > P_i.alt_next_hops = {} > P_i.alt_type = NONE > P_i.alt_link-protect = FALSE > P_i.alt_node-protect = FALSE > P_i.alt_srlg-protect = {} > > For each candidate next-hop H_h, > > 1. Initialize variables as follows: > > cand_type = NONE > cand_link-protect = FALSE > cand_node-protect = FALSE > cand_srlg-protect = {} > > 2. If H_h is P_i, skip it and continue to the next candidate next- > hop. > > 3. If H_h.link is administratively allowed to be used as an > alternate, > > SB> You need to define H_h.link. Do you mean the link > SB> between S and H_h, and can their be multiple links > SB> between S and H? Does explaining that a next-hop is a (outgoing link, neighbor) pair earlier in the modified paragraph help? and the cost of H_h.link is less than the maximum, > and the reverse cost of H_h is less than the maximum, > and H_h.neighbor is not overloaded (for ISIS), > and H_h.link is bi-directional, > > SB> H_h is already defined to be bidirectional - why is this is test > SB> condition? I want the algorithm to capture all the conditions; the other was just the text defining what are valid candidate next-hops. I think it is clearer to have all the conditions in one place rather than scattered; I could remove this condition from the earlier text if that would be preferable. then H_h can be considered as an alternate. Otherwise, skip it > and continue to the next candidate next-hop. > > 4. If D_opt( H_h.neighbor, D) >= D_opt( H_h.neighbor, S) + D_opt(S, > D), then H_h is not loop-free. Skip it and continue to the next > candidate next-hop. > > SB> You need to define H_h.neighbour. Does it just mean the node > SB> H_h? In which case, why is it different from H_h? Again, H_h is a next-hop so (outgoing link, neighbor) 5. cand_type = LOOP-FREE. > > 6. If H_h is a primary next-hop, set cand_type to PRIMARY. > > 7. If H_h.link is not P_i.link, set cand_link-protect to TRUE. > > 8. If D_opt(H_h.neighbor, D) < D_opt(H_h.neighbor, P_i.neighbor) + > D_opt(P_i.neighbor, D), set cand_node-protect to TRUE. > > SB> You need to define P_i.neighbour P_i is a primary next-hop and next-hops are (outgoing link, neighbor). 9. If the router considers SRLGs, then set the cand_srlg-protect to > the set of SRLGs traversed on the path from S via P_i to > > SB> Does this mean S via Pi.link to P_i.neighbour? yes - fixed P_i.neighbor. Remove the set of SRLGs to which H_h belongs from > cand_srlg-protect. Remove from cand_srlg-protect the set of > SRLGs traversed on the path from H_h.neighbor to D. Now > cand_srlg-protect holds the set of SRLGs to which P_i belongs > and that are not traversed on the path from S via H_h to D. > > 10. If cand_type is PRIMARY, the router prefers other primary next- > hops for use as the alternate, and the P_i.alt_type is not > PRIMARY, goto Step 19. > > 11. If cand_node-protect is TRUE and P_i.alt_node-protect is FALSE, > goto Paragraph 19. > > 12. If cand_link-protect is TRUE and P_i.alt_link-protect is FALSE, > goto Step 19. > > 13. If cand_srlg-protect has a better set of SRLGs than > P_i.alt_srlg-protect, goto Step 19. > > 14. If cand_srlg-protect is different from P_i.alt_srlg-protect, > then select between H_h and P_i.alt_next_hops based upon > distance, IP addresses, or any router-local tie-breaker. If H_h > is preferred, then goto Step 19. Otherwise, skip H_h and > continue to the next candidate next-hop. > > SB> The nesting of the IF then ELSE statements in step 14 is not clear. I changed the "Otherwise," to "If P_i.alt_next_hops is preferred," 15. If D_opt(H_h.neighbor, D) < D_opt(P_i.neighbor, D) and > D_opt(P_i.alt_next_hops, D) >= D_opt(P_i.neighbor, D), then H_h > is a downstream alternate and P_i.alt_next_hops is simply an > LFA. Prefer H_h and goto Step 19. > > 16. 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 19. > > 17. Decide if P_i.alt_next_hops is preferred to H_h. If so, then > skip H_h and continue to the next candidate next-hop. > > 18. Add H_h into P_i.alt_next_hops. Set P_i.alt_type to the better > type of H_h.alt_type and P_i.alt_type. Continue to the next > candidate next-hop. > > 19. Replace the P_i alternate next-hop set with H_h as follows: > > P_i.alt_next_hops = {H_h} > P_i.alt_type = cand_type > P_i.alt_link-protect = cand_link-protect > P_i.alt_node-protect = cand_node-protect > P_i.alt_srlg-protect = cand_srlg-protect > > Continue to the next candidate next-hop. > > ========end====== > Alia ------=_Part_2902_19566100.1193325932391 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Stewart,

Thanks for the careful read and good comments; sorry for taking so long to respond - I've been traveling & sick.

On 10/3/07, Stewart Bryant <stbryant@cisco.com> wrote:

Alia

We have taken a look at the algorithm in section 3.6 of
draft-ietf-rtgwg-ipfrr-spec-base-09, and there are a
number of cases where some clarification is needed to aid
understanding.

The root problem is that you have an object oriented
description of the algorithm but have not always defined
the objects.

Please see below.

We will also provide comments on the draft itself in another email.

Mike & Stewart

======begin=====

   S is the computing router and has candidate next-hops H_1 through
   H_k.

SB> You need to define a candidate next hop before you can say a router
SB> has them (i.e. move the definition earlier)

   N_i and N_j are used to refer to neighbors of S. For a next-hop
   to be a candidate, the next-hop must be associated with a bi-
   directional link, as is determined by the IGP.

SB> I think you want to say:
SB> S is the computing router
SB> S has neighbours N_1 to N_j
SB> The candidate next hops H_1 to H_k are the subset of N that are
SB> bidirectionally connected to S.

This is almost correct - a next-hop includes not just the neighbor but also
the outgoing interface. There can be multiple candidate next-hops that refer to
the same neighbor N_i.

SB> Why does H_i have to be bidirectionally connected?

Just because bidirectional connectivity is required in OSPF/ISIS for a link
to be usable. I think that is more a sanity-check that both ends of the link
have the same database - and I see no reason to vary from it here.
Do you disagree?

   For a particular
   destination router D, let S have already computed D_opt(S, D), and
   for each neighbor N_i, D_opt(N_i, D), D_opt(N_i, S), and D_opt(N_i,

SB> Why is this N_i and not H_i?

A next-hop is the (outgoing interface, N_i) pair. The distance computed is to
the neighbor N_i and need not go through the outgoing interface associated with
H_i.

   N_j), the distance from N_i to each other neighbor N_j, and the set
   of SRLGs traversed by the path D_opt(N_i, D).  S should follow the
   below procedure for every primary next-hop selected to reach D. This
   set of primary next-hops is represented P_1 to P_p.  This procedure
   finds the alternate next-hop(s) for P_i.

SB> In the text so far X_i refers  to the node  itself, i.e. what you later
SB> appear to call X_i.neighbor. This is confusing

I'm not sure exactly what you mean here (since there aren't any X_i in the text).
Is this the confusion between a neighbor N_i and a next-hop H_i that contains
(outgoing interface, neighbor)?

Does replacing the following paragraph

"S is the computing router and has candidate next-hops H_1 through
   H_k. N_i and N_j are used to refer to neighbors of S. For a next-hop
   to be a candidate, the next-hop must be associated with a bi-
   directional link, as is determined by the IGP."

with

"S is the computing router. S has neighbors N_1 to N_j. A
candidate next-hop is indicated by (outgoing link, neighbor) and
the outgoing link must be bidirectionally connected, as is
determined by the IGP. The candidate next-hops of S are enumerated as
H_1 through H_k."

help?

   First, initialize the alternate information for P_i as follows:

      P_i.alt_next_hops = {}
      P_i.alt_type = NONE
      P_i.alt_link-protect = FALSE
      P_i.alt_node-protect = FALSE
      P_i.alt_srlg-protect = {}

   For each candidate next-hop H_h,

   1.   Initialize variables as follows:

           cand_type = NONE
           cand_link-protect = FALSE
           cand_node-protect = FALSE
           cand_srlg-protect = {}

   2.   If H_h is P_i, skip it and continue to the next candidate next-
        hop.

   3.   If H_h.link is administratively allowed to be used as an
        alternate,

SB> You need to define H_h.link. Do you mean the link
SB> between S and H_h, and can their be multiple links
SB> between S and H?

Does explaining that a next-hop is a (outgoing link, neighbor) pair earlier in the modified paragraph help?

           and the cost of H_h.link is less than the maximum,
           and the reverse cost of H_h is less than the maximum,
           and H_h.neighbor is not overloaded (for ISIS),
           and H_h.link is bi-directional,

SB> H_h is already defined to be bidirectional - why is this is test
SB> condition?

I want the algorithm to capture all the conditions; the other was just the text
defining what are valid candidate next-hops. I think it is clearer to have all the conditions
in one place rather than scattered; I could remove this condition from the earlier text if that
would be preferable.

        then H_h can be considered as an alternate.  Otherwise, skip it
        and continue to the next candidate next-hop.

   4.   If D_opt( H_h.neighbor, D) >= D_opt( H_h.neighbor, S) + D_opt(S,
        D), then H_h is not loop-free.  Skip it and continue to the next
        candidate next-hop.

SB> You need to define H_h.neighbour. Does it just mean the node
SB> H_h? In which case, why is it different from H_h?

Again, H_h is a next-hop so (outgoing link, neighbor)

   5.   cand_type = LOOP-FREE.

   6.   If H_h is a primary next-hop, set cand_type to PRIMARY.

   7.   If H_h.link is not P_i.link, set cand_link-protect to TRUE.

   8.   If D_opt(H_h.neighbor, D) < D_opt(H_h.neighbor, P_i.neighbor) +
        D_opt(P_i.neighbor, D), set cand_node-protect to TRUE.

SB> You need to define P_i.neighbour

P_i is a primary next-hop and next-hops are (outgoing link, neighbor).

9. If the router considers SRLGs, then set the cand_srlg-protect to
the set of SRLGs traversed on the path from S via P_i to

SB> Does this mean S via Pi.link to P_i.neighbour?

yes - fixed

        P_i.neighbor.  Remove the set of SRLGs to which H_h belongs from
        cand_srlg-protect.  Remove from cand_srlg-protect the set of
        SRLGs traversed on the path from H_h.neighbor to D. Now
        cand_srlg-protect holds the set of SRLGs to which P_i belongs
        and that are not traversed on the path from S via H_h to D.

   10.  If cand_type is PRIMARY, the router prefers other primary next-
        hops for use as the alternate, and the P_i.alt_type is not
        PRIMARY, goto Step 19.

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

   12.  If cand_link-protect is TRUE and P_i.alt_link-protect is FALSE,
        goto Step 19.

   13.  If cand_srlg-protect has a better set of SRLGs than
        P_i.alt_srlg-protect, goto Step 19.

   14.  If cand_srlg-protect is different from P_i.alt_srlg-protect,
        then select between H_h and P_i.alt_next_hops based upon
        distance, IP addresses, or any router-local tie-breaker.  If H_h
        is preferred, then goto Step 19.  Otherwise, skip H_h and
        continue to the next candidate next-hop.

SB> The nesting of the IF then ELSE statements in step 14 is not clear.

I changed the "Otherwise," to "If P_i.alt_next_hops is preferred,"

   15.  If D_opt(H_h.neighbor, D) < D_opt(P_i.neighbor, D) and
        D_opt(P_i.alt_next_hops, D) >= D_opt(P_i.neighbor, D), then H_h
        is a downstream alternate and P_i.alt_next_hops is simply an
        LFA.  Prefer H_h and goto Step 19.

   16.  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 19.

   17.  Decide if P_i.alt_next_hops is preferred to H_h.  If so, then
        skip H_h and continue to the next candidate next-hop.

   18.  Add H_h into P_i.alt_next_hops.  Set P_i.alt_type to the better
        type of H_h.alt_type and P_i.alt_type.  Continue to the next
        candidate next-hop.

   19.  Replace the P_i alternate next-hop set with H_h as follows:

           P_i.alt_next_hops = {H_h}
           P_i.alt_type = cand_type
           P_i.alt_link-protect = cand_link-protect
           P_i.alt_node-protect = cand_node-protect
           P_i.alt_srlg-protect = cand_srlg-protect

        Continue to the next candidate next-hop.

========end======

Alia ------=_Part_2902_19566100.1193325932391-- --===============0513145084== 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 --===============0513145084==-- From rtgwg-bounces@ietf.org Thu Oct 25 11:41:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il4pl-0003ut-Io; Thu, 25 Oct 2007 11:41:21 -0400 Received: from rtgwg by megatron.ietf.org with local (Exim 4.43) id 1Il4pk-0003uj-Bb for rtgwg-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 11:41:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il4pk-0003ub-26 for rtgwg@ietf.org; Thu, 25 Oct 2007 11:41:20 -0400 Received: from rn-out-0910.google.com ([64.233.170.187] helo=rn-out-0102.google.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il4pd-0000Hm-M9 for rtgwg@ietf.org; Thu, 25 Oct 2007 11:41:20 -0400 Received: by rn-out-0102.google.com with SMTP id a46so208677rne for ; Thu, 25 Oct 2007 08:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=Moh81J/xihTdDwZFMlG1lCg140ts9pM+pg+3losEOKk=; b=eZDXpDEqnl4qIC9iR3Ki33pNVyvniVqdhzn1vGXsSyP3cr92bBQ41mZnSSkAgCF5hqio+SiuvrYzwXHNI3hS21qvnY2622odqpqS1UWTClvt6DUtxM7bLcjBBjNRVLWK/niGNYe+ZfJNLsliJ1ewDsj4Q9ryxDnEzvs10/QJ91M= 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=naUmLajESyopw0RkiwqWMxcUDaRsjihdctNeji/kCVCwtOoCWvjKusQoEYMftJk1b12BntFL5d0tOJ7vvQICZ3Qjltu+zt3Py7H0/ZrOzKTKyddo327bn5KM7nEOuBNVMHS6dPXs0hz1ChxtlhnTi54HZ/rGiJZpyGuZcq6NVj0= Received: by 10.143.161.3 with SMTP id n3mr552590wfo.1193326861629; Thu, 25 Oct 2007 08:41:01 -0700 (PDT) Received: by 10.143.164.4 with HTTP; Thu, 25 Oct 2007 08:41:01 -0700 (PDT) Message-ID: <6280db520710250841u69f027e9xd92cbdddaa4c39b5@mail.gmail.com> Date: Thu, 25 Oct 2007 11:41:01 -0400 From: "Alia Atlas" To: "mike shand" In-Reply-To: <470F6319.9060508@cisco.com> MIME-Version: 1.0 References: <470F6319.9060508@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: rtgwg@ietf.org Subject: Re: Comments on draft-ietf-rtgwg-ipfrr-spec-base-09 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="===============1292606133==" Errors-To: rtgwg-bounces@ietf.org --===============1292606133== Content-Type: multipart/alternative; boundary="----=_Part_3003_14815535.1193326861633" ------=_Part_3003_14815535.1193326861633 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Mike, On 10/12/07, mike shand wrote: > > I support the progression of this document, but would like to see the > comments Stewart and I made earlier on the algorithm addressed and also > the few points below. I addressed the comments on the algorithm in a separate email. Here are responses to your points below. In addition, I wonder whether there should be something up front which > makes clear that this may only provide a partial solution (depending on > the topology). I know this is implicit in the body of the text, but I > think it would be useful to avoid any misunderstandings if the abstract > were a little more explicit on this point. > > How about adding after "...The goal of this technology is to reduce the > micro-looping and packet loss that happens while routers converge > after a topology change due to a failure. ..." > > "The extent to which this goal can be met by this specification is > dependant on the topology of the network." Agreed. I've added this. Mike > > > > 1.1. Failure Scenarios > > The alternate next-hop can protect against a single link failure, a > single node failure, one or more shared risk link group failures, > or > a combination of these. > > > It might be better to say "failure of one or more links within a shared > risk link group". yes - changed Figure 5: Example where Continued Use of Alternate is Desirable > > This is an example of a case where the new primary is not a > loop-free > alternate before the failure and therefore may have been forwarding > traffic through S. This will occur when the path via a previously > upstream node is shorter than the the path via a loop-free > alternate > neighbor. In these cases, it is useful to give sufficient time to > ensure that the new primary neighbor and other nodes on the new > primary path have switched to the new route. > > > I wonder if it should be pointed out that while this is a good strategy > to minimize the occurrence of microloops, it does nothing to prevent any > microloops which may occur more than one hop away. Immediately before that figure, the draft discusses how the techniques given in the micro-loop prevention drafts should dictate the convergence rules. I've prefaced the references to those drafts with "There are techniques available to handle the micro-forwarding loops that can occur in a networking during convergence." to give it a bit more context. based on the new network topology. The use of the alternate next- > hops for packet forwarding SHOULD terminate: > > a. if the new primary next-hop was loop-free prior to the topology > change, or > > b. if a configured hold-down, which represents a worst-case bound > on > the length of the network convergence transition, has expired, > or > > c. if notification of an unrelated topological change in the > network > is received. > > We should probably add that if the primary link comes back before any of > this has happened then you can just go back to using the primary link as > if nothing had happened. That of course pre-supposes that the failure > hadn't yet been advertised. If it HAS been advertised, then it requires > another advertisement to put it back how it was, but in any case (I > think) the old next hop can safely be used. Once the failure has been advertised, I don't think we can just go back to using the old next hop. It would depend on what else in the network has already been updated. Can you explain why you don't think that additional micro-loops might be the result? Also, generally, there are hold-down times on links so that they can't just bounce back up before the link change has been advertised. I don't think this is a very useful optimization and I'm a bit concerned about putting it in now without some more thought. Alia _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www1.ietf.org/mailman/listinfo/rtgwg > ------=_Part_3003_14815535.1193326861633 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Mike,

On 10/12/07, mike shand <mshand@cisco.com> wrote:

I support the progression of this document, but would like to see the
comments Stewart and I made earlier on the algorithm addressed and also
the few points below.

I addressed the comments on the algorithm in a separate email. Here are
responses to your points below.

In addition, I wonder whether there should be something up front which
makes clear that this may only provide a partial solution (depending on
the topology). I know this is implicit in the body of the text, but I
think it would be useful to avoid any misunderstandings if the abstract
were a little more explicit on this point.

How about adding after "...The goal of this technology is to reduce the
micro-looping and packet loss that happens while routers converge
after a topology change due to a failure. ..."

"The extent to which this goal can be met by this specification is
dependant on the topology of the network."

Agreed. I've added this.

    Mike

    1.1.  Failure Scenarios

       The alternate next-hop can protect against a single link failure, a
       single node failure, one or more shared risk link group failures, or
       a combination of these.

It might be better to say "failure of one or more links within a shared
risk link group".

yes - changed

          Figure 5: Example where Continued Use of Alternate is Desirable

       This is an example of a case where the new primary is not a loop-free
       alternate before the failure and therefore may have been forwarding
       traffic through S. This will occur when the path via a previously
       upstream node is shorter than the the path via a loop-free alternate
       neighbor.  In these cases, it is useful to give sufficient time to
       ensure that the new primary neighbor and other nodes on the new
       primary path have switched to the new route.

I wonder if it should be pointed out that while this is a good strategy
to minimize the occurrence of microloops, it does nothing to prevent any
microloops which may occur more than one hop away.

Immediately before that figure, the draft discusses how the techniques given
in the micro-loop prevention drafts should dictate the convergence rules.

I've prefaced the references to those drafts with

"There are techniques available to handle the micro-forwarding loops
that can occur in a networking during convergence."
to give it a bit more context.

       based on the new network topology.  The use of the alternate next-
       hops for packet forwarding SHOULD terminate:

       a.  if the new primary next-hop was loop-free prior to the topology
           change, or

       b.  if a configured hold-down, which represents a worst-case bound on
           the length of the network convergence transition, has expired, or

       c.  if notification of an unrelated topological change in the network
           is received.

We should probably add that if the primary link comes back before any of
this has happened then you can just go back to using the primary link as
if nothing had happened. That of course pre-supposes that the failure
hadn't yet been advertised. If it HAS been advertised, then it requires
another advertisement to put it back how it was, but in any case (I
think) the old next hop can safely be used.

Once the failure has been advertised, I don't think we can just go back to using
the old next hop. It would depend on what else in the network has already been
updated. Can you explain why you don't think that additional micro-loops might be
the result?

Also, generally, there are hold-down times on links so that they can't just bounce
back up before the link change has been advertised. I don't think this is a very useful
optimization and I'm a bit concerned about putting it in now without some more thought.

Alia

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

------=_Part_3003_14815535.1193326861633-- --===============1292606133== 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 --===============1292606133==-- From rtgwg-bounces@ietf.org Thu Oct 25 12:12:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il5IP-00073T-LJ; Thu, 25 Oct 2007 12:10:57 -0400 Received: from rtgwg by megatron.ietf.org with local (Exim 4.43) id 1Il5IO-000739-7r for rtgwg-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 12:10:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il5IN-000731-Tb for rtgwg@ietf.org; Thu, 25 Oct 2007 12:10:55 -0400 Received: from wr-out-0506.google.com ([64.233.184.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il5IH-0001gd-BT for rtgwg@ietf.org; Thu, 25 Oct 2007 12:10:55 -0400 Received: by wr-out-0506.google.com with SMTP id 70so530604wra for ; Thu, 25 Oct 2007 09:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=Tqq89S+w5bagbSB1AN+Jzhzm8aR4souwErZE7QLOHmQ=; b=UA8nvgf/+UdBCeUc6mtQZGqNXycYi1acg/efYtwcfDYAC+NLpt7uRldOCW6ol2KvhtgQguEwXVaHTy90Rgc8VNDYzBU2uZhnSPsCgKiHABVkSw1Jeh1Kmdak0Zcneb6oBniu5c6D/08y9Z4NklTIvEehEn9efYYvYOhLt8ju2OU= 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=XwuojHEjFpmN1rKAxizp2WFi4HFgJZkMGKEoDiF/uMQQd1miI0u4KoGEsHJIwNydFZF142aQJf14hFY3dRzSwnWNQyT33YxfMgrvgzG2T/ReXLbdhb+a+gRd2lgQclJ0pDf3yKl5vtpsKhZHYOrMFB71Hx590q/yudkyDE7QVeE= Received: by 10.142.158.17 with SMTP id g17mr579658wfe.1193328618067; Thu, 25 Oct 2007 09:10:18 -0700 (PDT) Received: by 10.143.164.4 with HTTP; Thu, 25 Oct 2007 09:10:17 -0700 (PDT) Message-ID: <6280db520710250910u1cf264e2i11defb011bb84ad7@mail.gmail.com> Date: Thu, 25 Oct 2007 12:10:18 -0400 From: "Alia Atlas" To: stbryant@cisco.com In-Reply-To: <470F5341.8030900@cisco.com> MIME-Version: 1.0 References: <470F5341.8030900@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ce33913643759a19ac4c14fdbab27ca9 Cc: rtgwg@ietf.org Subject: Re: draft-ietf-rtgwg-ipfrr-spec-base-09 - LC coments 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="===============1114517358==" Errors-To: rtgwg-bounces@ietf.org --===============1114517358== Content-Type: multipart/alternative; boundary="----=_Part_3189_30533320.1193328618044" ------=_Part_3189_30533320.1193328618044 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/12/07, Stewart Bryant wrote: > > > > > Basic Specification for IP Fast-Reroute: Loop-free Alternates > draft-ietf-rtgwg-ipfrr-spec-base-09 > > > > Abstract > > The goal of this technology is to reduce the > micro-looping and packet loss that happens while routers converge > after a topology change due to a failure. > > SB> This draft does not address microlooping - our other drafts do that. > SB> There really ought to be a health warning saying that there are > SB> other solutions with greater fault coverage, but this one > SB> is simple and does not need any co-operation from any other > SB> node in the network. I will remove the comment about micro-looping (though part of that is for the micro-loops involving S). I added "The extent to which this goal can be met by this specification is dependent on the topology of the network." to the end of the abstract. 1. Introduction > > > As discussed in [I-D.ietf-rtgwg-ipfrr-framework], > > SB> We need to ask the question of whether we need to LC the framework > SB> draft and whether we need to publish that first to raise the > SB> awareness level before we send this to IETF/IESG review? As John asked, is it ready? I'd like to see that progress as well - though it doesn't discuss multicast IPFRR and that would be good to see in a framework eventually - even if we haven't nailed down many details yet. The mechanism also > assumes that both the primary path and the alternate path are in the > same routing area. > > SB> I am trying to remember how fundamental to the solution that is. > SB> Unlike NV, LFA only uses cost information and we know the costs. > SB> There is discussion regarding this restriction for OSPF, but does > SB> the constraint also apply to ISIS? Even in ISIS, the SPF computation is done per area. IF one didn't want this restriction, then that would have to change. <-- > +-----+ > /------| S |--\ > / +-----+ \ > / 5 8 \ > / \ > +-----+ +-----+ > | E | | N_1 | > +-----+ +-----+ > \ / > \ \ 4 3 / / > \| \ / |/ > -+ \ +-----+ / +- > \---| D |---/ > +-----+ > > Figure 1: Basic Topology > > SB> This picture is not too bad, others are worse - particularly > SB> the figure in the appendix. Would we help > SB> the reader if we published a pdf version of the RFC? I am happy to take others offerings for ASCII art if they are better looking. I don't have the diagrams drawn other than in ASCII at the moment. If you'd like a pdf version (and color can definitely help), perhaps we could work on creating the diagrams. A > network with this feature experiences less traffic loss and less > micro-looping of packets than a network without IPFRR. There are > cases where micro-looping is still a possibility since IPFRR coverage > varies but in the worst possible situation a network with IPFRR is > equivalent with respect to traffic convergence to a network without > IPFRR. > > SB> Surely we are talking repair not uloop here? Replaced the micro-looping in "There are cases where micro-looping is still a possibility..." with "traffic loss". 1.1. Failure Scenarios > > The alternate next-hop can protect against a single link failure, a > single node failure, one or more shared risk link group failures, or > a combination of these. Whenever a failure occurs that is more > extensive than what the alternate was intended to protect, there is > the possibility of temporarily looping traffic (note again, that such > a loop would only last until the next complete SPF calculation). > > SB> which may be delayed by the loop prevention mechanism. But we're not describing the loop prevention mechanism here. If there are not other protection > mechanisms a node failure is still a concern when only using link > protection. > > SB> This sentence seems in the wrong place - or provides too little > SB> discussion on the issues concerning node failure. Changed to "If there are not other protection mechanisms to handle node failure, a node failure is still a concern when only using link protecting LFAs. " It's just pointing out that if your LFA only protects against link failure, then node failures will still cause problems. In Figure 2, S > would be able to use N as an alternate, but N could not use S; > > SB> s/alternate/downstream alternate/ ok therefore N would have no alternate and would discard the traffic, > thus avoiding the micro-loop. A micro-loop due to the use of > alternates can be avoided by using downstream paths because each > succeeding router in the path to the destination must be closer to > the destination than its predecessor (according to the topology prior > to the failures). Although use of downstream paths ensures that the > micro-looping via alternates does not occur, such a restriction can > severely limit the coverage of alternates. > > SB> Might be better to reorder the discussion here a little for > SB> clarity. Reordered to: "Micro-looping of traffic via the alternates caused when a more extensive failure than planned for occurs can be prevented via selection of only downstream paths as alternates. A micro-loop due to the use of alternates can be avoided by using downstream paths because each succeeding router in the path to the destination must be closer to the destination than its predecessor (according to the topology prior to the failures). Although use of downstream paths ensures that the micro-looping via alternates does not occur, such a restriction can severely limit the coverage of alternates. In Figure 2, S would be able to use N as a downstream alternate, but N could not use S; therefore N would have no alternate and would discard the traffic, thus avoiding the micro-loop. " As shown above, the use of either a node protecting LFA or a > downstream path provides protection against micro-looping in the > event of node failure. > > SB> I don't think that you have explained NP LFA yet What needs explanation? The details for node-protecting LFA are given later, it is true, but I think the term is clear enough. There are topologies where there may be > either a node portecting LFA, a downstream path, both or neither. A > node may select either a node protecting LFA or a downstream path > without risk of causing micro-loops in the event of node failure. > > SB> neighbor node failure? clearer - changed Since the functionality of link and node protecting LFAs is greater > than that of downstream paths, a router SHOULD select a link and node > protecting LFA over a downstream path. > > SB> Should we just say NP LFA as L & NP LFA sounds like we have two > SB> protection mechanisms. No, because a node-protecting LFA may not be link-protecting... 3.3. Broadcast and NBMA Links > > > > +-----+ 15 > | S |-------- > +-----+ | > | 5 | > | | > | 0 | > /----\ 0 5 +-----+ > | PN |-----| N | > \----/ +-----+ > | 0 | > | | 8 > | 5 | > +-----+ 5 +-----+ > | E |----| D | > +-----+ +-----+ > > Figure 3: Loop-Free Alternate that is Link-Protecting > > In Figure 3, N offers a loop-free alternate which is link-protecting. > If the primary next-hop uses a broadcast link, then an alternate > SHOULD be loop-free with respect to that link's pseudo-node to > provide link protection. This requirement is described in > Inequality 4 below. > > D_opt(N, D) < D_opt(N, pseudo) + D_opt(pseudo, D) > > SB> The diagram used the term PN, maybe the equation should as well. Sure - changed - and added the clarification in the text associating PN with pseudo-node. "...with respect to that link's pseudo-node (PN) to provide link protection" 4.1. Terminating Use of Alternate > > > An implementation SHOULD continue to use the alternate next-hops for > packet forwarding even after the new routing information is available > based on the new network topology. The use of the alternate next- > hops for packet forwarding SHOULD terminate: > > a. if the new primary next-hop was loop-free prior to the topology > change, or > > b. if a configured hold-down, which represents a worst-case bound on > the length of the network convergence transition, has expired, or > > c. if notification of an unrelated topological change in the network > is received. > > SB> I think that list list needs to include the case where the network > SB> has converged (with or without the uloop prevention as applicable) How, other than the configured hold-down, does a router know that the network has converged? 6. Routing Aspects > > 6.1. Multi-Homed Prefixes > > > > > 5 +---+ 4 +---+ 5 +---+ > ------| S |------| A |-----| B | > | +---+ +---+ +---+ > | | | > | 5 | 5 | > | | | > +---+ 5 +---+ 5 7 +---+ > | C |---| E |------ p -------| F | > +---+ +---+ +---+ > > Figure 6: Multi-homed prefix > > > If there exist multiple multi-homed prefixes that share the same > connectivity and the difference in metrics to those routers, then a > single node can be used to represent the set. For instance, if in > Figure 6 there were another prefix X that was connected to E with a > metric of 1 and to F with a metric of 3, then that prefix X could use > the same alternate next-hop as was computed for prefix p. > > SB> I do not understand this simplification. I think that you are > SB> saying use p as a proxy for p', p'' etc. But if they have > SB> different costs don't you have to always use a different proxy? > SB> Say p' was connected to E at cost 1, but F at cost 1000, surely > SB> the packet would never get to F, or if it did, F would prefer > SB> to sent it via E and hence loop. Is there a must sent external > SB> assumption (which we considered for the tunnel solutions) that > SB> is assumed? Let me try and clarify. Say we have the following defined: D_opt(S, E) and D_opt(S, F) Now, for simplicity, assume that p', p", etc. connect more cheaply to E than to F. So, have diff_p'(E,F) = D(p', F) - D(p', E) So, the cost to a proxy node p would be: D_opt(S,p) = min (D_opt(S,E) + 0, D_opt(S, F) + diff_p'(E,F)) To get the distance to p', you would add D(p', E) to that min D_opt(S, p) - but that wouldn't change the path computation at all because the same constant is being added to both potential paths at the end. ----[ E ] ------- < p > ------ [ F ] / \ / \ ( p') ( p" ) So, if you have a set of prefixes with the same D(x, F) - D(x, E), they can take the same path to p. Does that make sense? Any suggestions on how to phrase it better for the draft? Alia - Stewart > > > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www1.ietf.org/mailman/listinfo/rtgwg > ------=_Part_3189_30533320.1193328618044 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 10/12/07, Stewart Bryant <stbryant@cisco.com> wrote:

     Basic Specification for IP Fast-Rerout= e: Loop-free Alternates
        =           draft-ietf-rtgw= g-ipfrr-spec-base-09

Abstract

  The goal of= this technology is to reduce the
   micro-looping and packet = loss that happens while routers converge
   after a topology change due to a failure.

SB> Th= is draft does not address microlooping - our other drafts do that.
SB>= ; There really ought to be a health warning saying that there are
SB>= other solutions with greater fault coverage, but this one
SB> is simple and does not need any co-operation from any other
S= B> node in the network.

I will remove the comment a= bout micro-looping (though part of that is for
the micro-loops involvin= g S).

I added
"The extent to which this goal can be met by thisspecification is dependent on the topology of the network."
to th= e end of the abstract.

1.  Introduction

   As discussed in [I-D.iet= f-rtgwg-ipfrr-framework],

SB> We need to ask the question of whet= her we need to LC the framework
SB> draft and whether we need to publ= ish that first to raise the
SB> awareness level before we send this to IETF/IESG review?

As John asked, is it ready? I'd like to see that pr= ogress as well - though it
doesn't discuss multicast IPFRR and that = would be good to see in a framework
eventually - even if we haven't nailed down many details yet.

&nb= sp; The mechanism also
   assumes that both the primary path and the alternate path = are in the
   same routing area.

SB> I am trying to = remember how fundamental to the solution that is.
SB> Unlike NV, LFA = only uses cost information and we know the costs.
SB> There is discussion regarding this restriction for OSPF, but doe= s
SB> the constraint also apply to ISIS?

Even in= ISIS, the SPF computation is done per area. IF one didn't want t= his
restriction, then that would have to change.

     =             &nb= sp;        <--
            = ;            &n= bsp;      +-----+
     = ;            &n= bsp;      /------|  S  |-= -\
           &nb= sp;           / &nbs= p;     +-----+   \
    = ;            &n= bsp;     / 5      &n= bsp;        8 \
   &nb= sp;            =      /        &= nbsp;            \
            = ;       +-----+     =            +-----+            &= nbsp;      |  E  |  =             &nb= sp; | N_1 |
         &= nbsp;         +-----+  &n= bsp;            = ; +-----+
         &nb= sp;            = \            &n= bsp;        /
    = ;            &n= bsp; \    \  4    &n= bsp;         3 /  /
            = ;       \|   \   &nb= sp;            = / |/
           =         -+    \ = ;   +-----+    /  +-
=             &nb= sp;            = \---|  D  |---/
      =             &nb= sp;           +-----= +

           =             &nb= sp; Figure 1: Basic Topology

SB> This picture is not too bad, others are worse - particularly=
SB> the figure in the appendix. Would we help
SB> the reader i= f we published a pdf version of the RFC?

I am happy to= take others offerings for ASCII art if they are better
looking. I don't have the diagrams drawn other than in ASCII = at the moment.
If you'd like a pdf version (and color can definitely= help), perhaps we could
work on creating the diagrams.

   A
   network with this feature experiences less t= raffic loss and less
   micro-looping of packets than a networ= k without IPFRR.  There are
   cases where micro-loo= ping is still a possibility since IPFRR coverage
   varies but in the worst possible situation a network with = IPFRR is
   equivalent with respect to traffic convergence to = a network without
   IPFRR.

SB> Surely we are talkin= g repair not uloop here?

Replaced the micro-looping in "There are cases where micro-lo= oping is still a possibility..."
with "traffic loss".
=

1.1.  Failure Scenarios

   The alternate next-ho= p can protect against a single link failure, a
   single node = failure, one or more shared risk link group failures, or
   a = combination of these.  Whenever a failure occurs that is more
   extensive than what the alternate was intended to protect,= there is
   the possibility of temporarily looping traffic (n= ote again, that such
   a loop would only last until the next = complete SPF calculation).

SB> which may be delayed by the loop prevention mechanism.

But we're not describing the loop prevention mech= anism here.

   If there are not other protection
   mechanisms a= node failure is still a concern when only using link
   prote= ction.

SB> This sentence seems in the wrong place - or provides t= oo little
SB> discussion on the issues concerning node failure.

Changed to

"If there are not other protec= tion mechanisms to handle node failure, a node failure is still
a concer= n when only using link protecting LFAs. "

It's just p= ointing out that if your LFA only protects against link failure, then node = failures will
still cause problems.

   In Figure 2, S
   would be able t= o use N as an alternate, but N could not use S;

SB> s/alternate/downstream alternate/

ok

= ; therefore N would have no alternate and would discard the traffic,
   thus avoiding the micro-loop.  A micro-loop due = to the use of
   alternates can be avoided by using downstream= paths because each
   succeeding router in the path to the de= stination must be closer to
   the destination than its predec= essor (according to the topology prior
   to the failures).  Although use of downstream pa= ths ensures that the
   micro-looping via alternates does not = occur, such a restriction can
   severely limit the coverage o= f alternates.

SB> Might be better to reorder the discussion here = a little for
SB> clarity.

Reordered to:

"Micro-l= ooping of traffic via the alternates caused when a more
extensive failur= e than planned for occurs can be prevented via
selection of only downstr= eam paths as alternates. A micro-loop due to
the use of alternates can be avoided by using downstream paths because<= br>each succeeding router in the path to the destination must be closer
= to the destination than its predecessor (according to the topology
prior= to the failures). Although use of downstream paths ensures that
the micro-looping via alternates does not occur, such a restriction
= can severely limit the coverage of alternates. In Figure 2, S would b= e able to use N as a downstream
alternate, but N could not use S; theref= ore N would have no alternate
and would discard the traffic, thus avoiding the micro-loop. "
=

&= nbsp; As shown above, the use of either a node protecting LFA or a
   downstream path provides protection against micro-looping = in the
   event of node failure.

SB> I don't thi= nk that you have explained NP LFA yet

What needs expla= nation? The details for node-protecting LFA are given later, it= is true,
but I think the term is clear enough.

   There are topologies = where there may be
   either a node portecting LFA, a downstream path, both or n= either.  A
   node may select either a node protecti= ng LFA or a downstream path
   without risk of causing micro-l= oops in the event of node failure.

SB> neighbor node failure?

clearer - changed

= ; Since the functionality of link and node protecting LFAs is greater
   than that of downstream paths, a router SHOULD select a li= nk and node
   protecting LFA over a downstream path.

S= B> Should we just say NP LFA as L & NP LFA sounds like we have twoSB> protection mechanisms.

No, because a node-protecting LFA may not be link-pro= tecting...

3.3.  Broadcast and NBMA Links

   &= nbsp;           &nbs= p;       +-----+    15            &n= bsp;          |  S&n= bsp; |--------
        &nbs= p;            &= nbsp; +-----+       |
   &n= bsp;            = ;          | 5  = ;      |
     &nb= sp;            =         |    &n= bsp;     |
            = ;            &n= bsp; | 0        |
&nb= sp;            =           /----\ 0 5 +---= --+
           &n= bsp;            = ;| PN |-----|  N  |
     &n= bsp;            = ;      \----/     +-----+=
            = ;            &n= bsp; | 0        |
            = ;            &n= bsp; |          | 8=
            = ;            &n= bsp; | 5        |
&n= bsp;            = ;          +-----+ 5 = ; +-----+
         &nb= sp;            =   |  E  |----|  D  |
&= nbsp;           &nbs= p;           +-----+=     +-----+

           Figure= 3: Loop-Free Alternate that is Link-Protecting

   In Figu= re 3, N offers a loop-free alternate which is link-protecting.
&nb= sp; If the primary next-hop uses a broadcast link, then an alternate
   SHOULD be loop-free with respect to that link's pseudo= -node to
   provide link protection.  This requireme= nt is described in
   Inequality 4 below.

  &= nbsp;           D_op= t(N, D) < D_opt(N, pseudo) + D_opt(pseudo, D)

SB> The diagram used the term PN, maybe the equation should as w= ell.

Sure - changed - and added the clarification in t= he text associating PN
with pseudo-node.

"...with respect to= that link's pseudo-node (PN) to provide link protection"

4.1= .  Terminating Use of Alternate

   An implem= entation SHOULD continue to use the alternate next-hops for
   packet forwarding even after the new routing information i= s available
   based on the new network topology.  T= he use of the alternate next-
   hops for packet forwarding SH= OULD terminate:

   a.  if the new primary next-h= op was loop-free prior to the topology
       change, or

   b.&= nbsp; if a configured hold-down, which represents a worst-case bound o= n
       the length of the network converg= ence transition, has expired, or

   c.  if notif= ication of an unrelated topological change in the network
       is received.

SB> I think= that list list needs to include the case where the network
SB> has c= onverged (with or without the uloop prevention as applicable)
<= div>
How, other than the configured hold-down, does a router know = that the=20
network has converged?

6.  Routing Aspects

6.1. &nbs= p;Multi-Homed Prefixes

         &= nbsp;           &nbs= p;5   +---+  4   +---+  5 &nbs= p;+---+
          &nbs= p;         ------| S |------| = A |-----| B |
         &nbs= p;          |  =    +---+      +---+  &nbs= p; +---+
         &nb= sp;          |  = ;     |        =             |
            = ;        |     = 5 |            =       5 |
     &n= bsp;            = ;  |       |    = ;            &n= bsp;   |
        =           +---+ 5 +---+&n= bsp; 5       7    += ---+
           &= nbsp;      | C |---| E |------ p -------| F |=
            &nb= sp;     +---+   +---+   &= nbsp;           &nbs= p;+---+

          =              Fi= gure 6: Multi-homed prefix

   If there exist multiple = multi-homed prefixes that share the same
   connectivity and t= he difference in metrics to those routers, then a
   single node can be used to represent the set.  F= or instance, if in
   Figure 6 there were another prefix X tha= t was connected to E with a
   metric of 1 and to F with a met= ric of 3, then that prefix X could use
   the same alternate next-hop as was computed for prefix p.<= br>
SB> I do not understand this simplification. I think that you are=
SB> saying use p as a proxy for p', p'' etc. But if they= have
SB> different costs don't you have to always use a different proxy?<= br>SB> Say p' was connected to E at cost 1, but F at cost 1000, sure= ly
SB> the packet would never get to F, or if it did, F would prefer
SB> to sent it via E and hence loop. Is there a must sent externalSB> assumption (which we considered for the tunnel solutions) that
= SB> is assumed?

Let me try and clarify.
<= br> Say we have the following defined:

D_opt(S, E) and D_opt(S, F)

Now, for simplicity, assume that p', p", etc. connect more= cheaply to E than to F.
So, have diff_p'(E,F) =3D D(p', F) - D(= p', E)

So, the cost to a proxy node p would be:
D_opt(S,p) =3D mi= n (D_opt(S,E) + 0, D_opt(S, F) + diff_p'(E,F))

To get the distan= ce to p', you would add D(p', E) to that min D_opt(S, p) - but that= wouldn't change the
path computation at all because the same constant is being added to bot= h potential paths at the end.

----[ E ] ------- < p > ------ [= F ]
           &= nbsp;          / \
&n= bsp;            = ;       /      \
=             &nb= sp;   ( p')     ( p" )

So, if you have a set of prefixes with the same D(x, F) - D(x, E), = they can take the same path to p.

Does that make sense? Any su= ggestions on how to phrase it better for the draft?

Alia

- Stewart

______________________________________________= _
rtgwg mailing list
rtgwg@ietf.org=
https://ww= w1.ietf.org/mailman/listinfo/rtgwg

------=_Part_3189_30533320.1193328618044-- --===============1114517358== 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 --===============1114517358==-- From rtgwg-bounces@ietf.org Thu Oct 25 12:31:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il5bk-00089y-6z; Thu, 25 Oct 2007 12:30:56 -0400 Received: from rtgwg by megatron.ietf.org with local (Exim 4.43) id 1Il5bj-00089t-Qx for rtgwg-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 12:30:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il5bj-00089g-HD for rtgwg@ietf.org; Thu, 25 Oct 2007 12:30:55 -0400 Received: from an-out-0708.google.com ([209.85.132.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il5bd-0002US-Cn for rtgwg@ietf.org; Thu, 25 Oct 2007 12:30:55 -0400 Received: by an-out-0708.google.com with SMTP id c5so190130anc for ; Thu, 25 Oct 2007 09:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=9U7t7zt/1RG0XcIfwCp9ZJLkUnVrlDiysygdNU4mUDQ=; b=jOEzp/2cIPbifI0t+rY77wKg16dNuzOzF2aZN4tFlqmSMwOJZXaEEKQ9iWFGArT/Y/SCYX8zKfuop43WaoHkn49RNiAkL3orOzaSjwEpRjJX0hkyYrL6Z+pXuJyyOs4v0kEk2Wo7nfR9jWC7ZoY+Mq+tL97qaw8Ukv+EvQENs8A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=f0+p7ODyRdg2VlR87OOQ53z05nZy0F3Wm/GaGnUbTh/Tl1eFrHXptQI9JwYd0nY57umLFqI9rPt2e5PcdJYiJRPIQ0pMBOUw93RRmrDNzm7eh4iiFy3+a3bODlGzspgBQCBDB5po9DySQjn/0pZ8jK6UFhYoL1oUozTHjbpW7/I= Received: by 10.142.128.6 with SMTP id a6mr594278wfd.1193329823303; Thu, 25 Oct 2007 09:30:23 -0700 (PDT) Received: by 10.143.164.4 with HTTP; Thu, 25 Oct 2007 09:30:23 -0700 (PDT) Message-ID: <6280db520710250930m16bab4b1tfe9264890a424b2b@mail.gmail.com> Date: Thu, 25 Oct 2007 12:30:23 -0400 From: "Alia Atlas" To: "John G. Scudder" , rtgwg@ietf.org In-Reply-To: <5D2C268D-1DCA-45E9-9988-1F940B1C5BDA@juniper.net> MIME-Version: 1.0 References: <1BE7AC0C-9229-4BC5-B968-74F8614D4A57@juniper.net> <5D2C268D-1DCA-45E9-9988-1F940B1C5BDA@juniper.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: Re: Working Group Last Call for "Basic Specification for IP Fast-Reroute: Loop-free Alternates" 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="===============0450349340==" Errors-To: rtgwg-bounces@ietf.org --===============0450349340== Content-Type: multipart/alternative; boundary="----=_Part_3259_33023129.1193329823259" ------=_Part_3259_33023129.1193329823259 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/15/07, John G. Scudder wrote: > > The WGLC period is over. The is that the authors are planning to > revise the draft to reflect the comments received. We'll revisit > this once that's done. > > If you have any further comments on the draft, please make every > effort to send them soon so that they can be taken into consideration > when the draft is revised. I've revised the draft based upon the comments received. Please send any additional soon - I'd like to publish the revised version next week. Thanks, Alia ------=_Part_3259_33023129.1193329823259 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/15/07, John G. Scudder <jgs@juniper.net> wrote:

The WGLC period is over. The is that the authors are planning to
revise the draft to reflect the comments received. We'll revisit
this once that's done.

If you have any further comments on the draft, please make every
effort to send them soon so that they can be taken into consideration
when the draft is revised.

I've revised the draft based upon the comments received. Please send
any additional soon - I'd like to publish the revised version next week.

Thanks,
Alia

------=_Part_3259_33023129.1193329823259-- --===============0450349340== 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 --===============0450349340==-- From rtgwg-bounces@ietf.org Thu Oct 25 13:35:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il6bD-0006Ep-FM; Thu, 25 Oct 2007 13:34:27 -0400 Received: from rtgwg by megatron.ietf.org with local (Exim 4.43) id 1Il6bC-0006Ee-3P for rtgwg-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 13:34:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il6bB-0006EW-Q5 for rtgwg@ietf.org; Thu, 25 Oct 2007 13:34:25 -0400 Received: from nz-out-0506.google.com ([64.233.162.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il6ax-0005oQ-61 for rtgwg@ietf.org; Thu, 25 Oct 2007 13:34:25 -0400 Received: by nz-out-0506.google.com with SMTP id n1so533959nzf for ; Thu, 25 Oct 2007 10:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=j8DN/7R9Kn2DTxI87Bd2NUEWaeRUB6UeroT7F7buU9s=; b=ALaLi9uZn975K0yLmf7ow368f5WwUjQ+cEMBGWJ0RrLLjqfKpd6n8EpZHpIJEat1MSAnvvuHR7puxt7iRwycHl1RCGPDo1oUi4PhecYWGMthjuEtfgmhr8a1WoeaB5rgreh7hLNhTamaoXYATRG8hbvOtjbz+Be33dC4BzQMlTA= 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=iXAQSiGWymqbIVbROihJSg0Zl1sYqUOHktlsV57MuTTpBuK/LUCx//F+gdqWMZ4oWQTyUNaIbxpSV9I6gYXGRO+FyewCGTksZRAVD2naMaqeI6gmiyNP4KyeltB/W1fL+qLWKvs7hp89TvsRT6qsgHylNOj04Mkd/7IphNeoKVQ= Received: by 10.142.142.16 with SMTP id p16mr646863wfd.1193333632972; Thu, 25 Oct 2007 10:33:52 -0700 (PDT) Received: by 10.143.164.4 with HTTP; Thu, 25 Oct 2007 10:33:52 -0700 (PDT) Message-ID: <6280db520710251033w21326577ta3620cf01cc8f4f3@mail.gmail.com> Date: Thu, 25 Oct 2007 13:33:52 -0400 From: "Alia Atlas" To: "=?ISO-8859-1?Q?R=FCdiger_A_Martin?=" In-Reply-To: <470F8E19.9000700@informatik.uni-wuerzburg.de> MIME-Version: 1.0 References: <470F8E19.9000700@informatik.uni-wuerzburg.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec Cc: rtgwg@ietf.org Subject: Re: Comments on draft-ietf-rtgwg-ipfrr-spec-base-09 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="===============0224174324==" Errors-To: rtgwg-bounces@ietf.org --===============0224174324== Content-Type: multipart/alternative; boundary="----=_Part_3511_14218605.1193333632957" ------=_Part_3511_14218605.1193333632957 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dear R=FCdiger, On 10/12/07, R=FCdiger A Martin wrote: > > Dear Alia, dear Alex, > > we have taken a look at your document and would like to add a few > comments to the discussion already going on: > > - The concept of node protecting LFAs is first mentioned on page 6. The > definition and explanation follows later. True - The first place a node protecting LFA is mentioned, I've added a reference to the section with the definition. I don't see a clean way of defining it at/before that location. > - There are several kinds of loop-free alternates. But the suggested > order of preference among those different LFAs does not become clear at > all in the draft. So there should be some paragraph where all possible > candidate types are listed and described with their pros and cons. That > description should include the protected failure types but also the > behavior in case of unprotected failures: e.g., I miss a clear statement > that downstream LFAs do not create any loops no matter what kind of > failures may happen. Based on this, a clear suggestion for an order of > preference can be given. Yes, we didn't have consensus about the order of preferences - and it depends on what other types of protection are available in the network. I agree that this would be useful. How does the following added section (after 3.6) sound? "3.7. LFA types and Trade-offs LFAs can provide different amounts of protection and the decision about which type to prefer is dependent upon network topology and other techniques in use in the network. This section describes the different protection levels and the trade-offs associated with each. 1. Primary Next-hop: When there are equal-cost primary next-hops, using one as an alternate is guaranteed to not cause micro-loops involving S. Traffic flows across the paths that the network will converge to, but congestion may be experienced on the primary paths since traffic is sent across fewer. All primary next-hops are downstream paths. 2. Downstream Paths: A downstream path, unlike an LFA, is guaranteed not to cause a micro-loop involving S regardless of the actual failure detected. However, the expected coverage of such alternates in a network is expected to be poor. All downstream paths are LFAs. 3. LFA: An LFA can have good coverage of a network, depending on topology. However, it is possible to get micro-loops involving S if a more severe failure occurs than is protected against. The different types of protection are abbreviated as LP (link- protecting), NP (node-protecting) and SP (SRLG-protecting). a. LP, NP, and SP: If such an alternate exists, it gives protection against all failures. b. LP and NP: Many networks may handle SRLG failures via another method or may focus on node and link failures as being more common. c. LP: A network may handle node failures via a high availability technique and be concerned primarily about protecting the more common link failure case. d. NP: These only exist on interfaces that aren't point-to-point. If link protection is handled in a different layer, then an NP alternate may be acceptable. " I'd welcome suggestions on how to improve this. > - Page 7: "Since the funcionality of link and node protecting LFAs is > greater than that of downstream paths, a router SHOULD select a link and > node protecting LFA over a downstream path." - That reads like > downstream paths are generally worse. But of course a downstream link- > and node-protecting LFA is better than a non-downstream link- and > node-protecting LFA. So this point is strongly related to the point > mentioned earlier concerning the order of preference. Added the clarification of "link-protecting downstream paths". - A few comments on the algorithm on page 16 (besides I agree with > Stewarts comments): > * Step 10: This means, if the router prefers other primary next > hops, it prefers them no matter what kind of failures (links or nodes) > they protect. So this algorithm prefers a link-protecting primary over a > link- and node-protecting downstream LFA. (Depending on the order of the > candidates - see below.) True - this is intended to reflect the behavior for the network once it ha= s converged. I could instead embed the preference at Step 16 - but that flexibility is there already. * The output of the algorithm depends on the order of the > candidate next hops. > 1) Imagine that H_1 is a link-protecting primary next hop. > H_2 is a link- and node-protecting downstream LFA. Then H_1 will be > selected in the first iteration. During the second iteration, step 11 > selects H2 instead. > 2) Now imagine H_1' =3D H_2 and H_2' =3D H_1. Then the first > iteration selects H_1'. However, the second iteration selects H_2' as > the candidate in step 10. So the final result is H1. > I think this problem is due to the missing order of preference. Ah - nope - it is due to a missing step - added between step 10 & 11. "If cand_type is not PRIMARY, P_i.alt_type is PRIMARY and the router prefer= s other primary next- hops for use as the alternate, then continue to the next candidate next-hop" Besides we really appreciate this document and support the progression > of the document after consideration of the comments from above. We think > that Mike's idea to include explicitly that this may only provide a > partial solution is worth considering. But maybe together with the > statement that this is a really simple and easy to implement approach > since it does not require any support (i.e. signalling) from other > routers. Ok - so at the end of the abstract, I've added "This simple approach does not require any support from other routers. The extent to which this goal can be met by this specification is dependent on the topology of the network." Thanks for the comments and suggestions! Alia Best regards, > R=FCdiger > > > -- > _______________________________________________________ > > Dipl.-Inform. R=FCdiger Martin > Department of Distributed Systems (Informatik III) > Insitute of Computer Science, University of W=FCrzburg > Am Hubland, 97074 W=FCrzburg, Germany > martin@informatik.uni-wuerzburg.de > Tel: +49 931 888-6651 > Fax: +49 931 888-6632 > > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www1.ietf.org/mailman/listinfo/rtgwg > ------=_Part_3511_14218605.1193333632957 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dear R=FCdiger,

On 10/12/07, R=FCdiger A Martin <martin@informatik.uni-wuerzburg.de> wr= ote:

Dear Alia, dear A= lex,

we have taken a look at your document and would like to add a f= ew
comments to the discussion already going on:

- The concept of no= de protecting LFAs is first mentioned on page 6. The
definition and expl= anation follows later.

True - The first place a node p= rotecting LFA is mentioned, I've added a reference to the section with = the definition.
I don't see a clean way of defining it at/before that location.
=

- The= re are several kinds of loop-free alternates. But the suggested
order of preference among those different LFAs does not become clear at=
all in the draft. So there should be some paragraph where all possible<= br>candidate types are listed and described with their pros and cons. That
description should include the protected failure types but also the
= behavior in case of unprotected failures: e.g., I miss a clear statementthat downstream LFAs do not create any loops no matter what kind of
failures may happen. Based on this, a clear suggestion for an order of
p= reference can be given.

Yes, we didn't have consen= sus about the order of preferences - and it depends
on what other types = of protection are available in the network. I agree that this
would be useful. How does the following added section (after 3.6)= sound?

"3.7. LFA types and Trade-offs

  = ; LFAs can provide different amounts of protection and the decision
&nbs= p; about which type to prefer is dependent upon network topology and
   other techniques in use in the network. This section= describes the
   different protection levels and the trade-of= fs associated with each.

   1. Primary Next-hop: Whe= n there are equal-cost primary next-hops,
       using one as an alternate is guara= nteed to not cause micro-loops
       invo= lving S. Traffic flows across the paths that the network will
&nbs= p;     converge to, but congestion may be experienced o= n the primary
       paths since traffic is sent across= fewer. All primary next-hops
      = are downstream paths.

   2. Downstream Paths: A dow= nstream path, unlike an LFA, is guaranteed
     = ; not to cause a micro-loop involving S regardless of the actual
       failure detected. However, t= he expected coverage of such
       altern= ates in a network is expected to be poor. All downstream
&nb= sp;     paths are LFAs.

   3. LF= A: An LFA can have good coverage of a network, depending on
       topology. However, it is pos= sible to get micro-loops involving S
      = ; if a more severe failure occurs than is protected against.

&= nbsp; The different types of protection are abbreviated as LP (link-
   protecting), NP (node-protecting) and SP (SRLG-protecting).
   a. LP, NP, and SP: If such an alternate exists, it g= ives protection
       against all failure= s.

   b. LP and NP: Many networks may handle SRLG fa= ilures via another
       method or may fo= cus on node and link failures as being more
       common.

   c.&nbs= p; LP: A network may handle node failures via a high availability
=       technique and be concerned primarily about p= rotecting the more
       common link fail= ure case.

   d. NP: These only exist on interfaces t= hat aren't point-to-point.
       If link protection is handled in a= different layer, then an NP
       altern= ate may be acceptable.
"

I'd welcome suggestions on how = to improve this.

- Page 7: "Since the funcionality of link and node protecting LFAs is<= br>greater than that of downstream paths, a router SHOULD select a link and=
node protecting LFA over a downstream path." - That reads like
downstream paths are generally worse. But of course a downstream link-<= br>and node-protecting LFA is better than a non-downstream link- and
nod= e-protecting LFA. So this point is strongly related to the point
mention= ed earlier concerning the order of preference.

Added the clarification of "link-protecting down= stream paths".

- A few comments on the algorithm on page 16 (besides I agree with
Stewa= rts comments):
* Step 10: This mean= s, if the router prefers other primary next
hops, it prefers them no mat= ter what kind of failures (links or nodes)
they protect. So this algorithm prefers a link-protecting primary over = a
link- and node-protecting downstream LFA. (Depending on the order of t= he
candidates - see below.)

True - this is in= tended to reflect the behavior for the network once it has converged.
I could instead embed the preference at Step 16 - but that flexibility = is there already.

       * The output of the algorithm depends = on the order of the
candidate next hops.
    &nbs= p;        1) Imagine that H_1 is a link-= protecting primary next hop.
H_2 is a link- and node-protecting downstre= am LFA. Then H_1 will be
selected in the first iteration. During the second iteration, step 11selects H2 instead.
        &n= bsp;   2) Now imagine H_1' =3D H_2 and H_2' =3D H_1.= Then the first
iteration selects H_1'. However, the second iteratio= n selects H_2' as
the candidate in step 10. So the final result is H1.
  &nb= sp;       I think this problem is due to= the missing order of preference.

Ah - nope - it is du= e to a missing step - added between step 10 & 11.

"If cand_type is not PRIMARY, P_i.alt_type is PRIMARY and the = router prefers other primary next-
&= nbsp; hops for use as the alternate, then continue to the next candidate ne= xt-hop"

Besides we really appreciate this document and support the progression
o= f the document after consideration of the comments from above. We think
= that Mike's idea to include explicitly that this may only provide a
partial solution is worth considering. But maybe together with the
s= tatement that this is a really simple and easy to implement approach
sin= ce it does not require any support (i.e. signalling) from other routers.

Ok - so at the end of the abstract, I've added
"This simple approach does not require any support from other rou= ters. The
extent to which this goal can be met by this specificati= on is
dependent on the topology of the network."

Thanks for= the comments and suggestions!

Alia

Best regards,
R=FCdiger

--
_______________________________= ________________________

       &= nbsp;     Dipl.-Inform. R=FCdiger Martin
Department= of Distributed Systems (Informatik III)
Insitute of Computer Science, U= niversity of W=FCrzburg
        Am Hubland, 97074 W=FCr= zburg, Germany
         martin@informatik.uni-wuerzb= urg.de
          &= nbsp;   Tel: +49 931 888-6651
    &nb= sp;         Fax: +49 931 888-6= 632

_______________________________________________
rtgwg ma= iling list
rtgwg@ietf.org
https://www1.ietf.org/m= ailman/listinfo/rtgwg

------=_Part_3511_14218605.1193333632957-- --===============0224174324== 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 --===============0224174324==-- From rtgwg-bounces@ietf.org Wed Oct 31 18:55:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMQy-0007P8-Do; Wed, 31 Oct 2007 18:53:12 -0400 Received: from rtgwg by megatron.ietf.org with local (Exim 4.43) id 1InMQt-0007Lg-I8 for rtgwg-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 18:53:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMQs-0007K7-N2; Wed, 31 Oct 2007 18:53:06 -0400 Received: from bosco.isi.edu ([128.9.168.207]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InMQs-0004Yt-8Y; Wed, 31 Oct 2007 18:53:06 -0400 Received: by bosco.isi.edu (Postfix, from userid 70) id E83A0E9EE0; Wed, 31 Oct 2007 15:53:05 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20071031225305.E83A0E9EE0@bosco.isi.edu> Date: Wed, 31 Oct 2007 15:53:05 -0700 (PDT) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: rtgwg@ietf.org, rfc-editor@rfc-editor.org Subject: RFC 5082 on The Generalized TTL Security Mechanism (GTSM) 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 A new Request for Comments is now available in online RFC libraries. RFC 5082 Title: The Generalized TTL Security Mechanism (GTSM) Author: V. Gill, J. Heasley, D. Meyer, P. Savola, Ed., C. Pignataro Status: Standards Track Date: October 2007 Mailbox: vijay@umbc.edu, heas@shrubbery.net, dmm@1-4-5.net, psavola@funet.fi, cpignata@cisco.com Pages: 16 Characters: 36579 Obsoletes: RFC3682 See-Also: I-D Tag: draft-ietf-rtgwg-rfc3682bis-10.txt URL: http://www.rfc-editor.org/rfc/rfc5082.txt 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 Experimental RFC 3682. [STANDARDS TRACK] This document is a product of the Routing Area Working Group Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg