From aretana@cisco.com Tue Dec 4 07:25:19 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3FA21F8554 for ; Tue, 4 Dec 2012 07:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrgdExqzXbeF for ; Tue, 4 Dec 2012 07:25:18 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8516621F8AA2 for ; Tue, 4 Dec 2012 07:25:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1805; q=dns/txt; s=iport; t=1354634718; x=1355844318; h=from:to:subject:date:message-id:mime-version; bh=ZilSaFpXlab5Ev2S0jBFK6eF1JtX9zQaQj7SWFH96wQ=; b=miaaqWSsFtyokggWIg1YwLaxY7NleQnVk7fe0/v8FHCK6WRVenwkRA3J E4IchJbeg/uzASqOpeoSAU3fA7wrtUfXVcBZte2vQuqbCsEeIeuPm/0UR StGDGbrAsQUoLfDrZyJZWeK8lslnA4ZqRRzRUT2qBzSR+neZZBEcd6aRJ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoULAHUVvlCtJXG9/2dsb2JhbABEgkmDI4FirWSIexZsB4IVCwEEgQsBCwEeVicEGwGIBwygJJEPkFOQF2EDpkqCcoIh X-IronPort-AV: E=McAfee;i="5400,1158,6915"; a="149258479" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 04 Dec 2012 15:25:14 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qB4FPE8I023132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 4 Dec 2012 15:25:14 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.208]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Tue, 4 Dec 2012 09:25:14 -0600 From: "Alvaro Retana (aretana)" To: "rtgwg@ietf.org" Subject: IETF 85 Minutes Posted Thread-Topic: IETF 85 Minutes Posted Thread-Index: AQHN0jONZZh0eYiQwE2emZkI0a0z/Q== Date: Tue, 4 Dec 2012 15:25:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.235.141] Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94EC43CDAxmbalnx15ciscocom_" MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 15:25:20 -0000 --_000_BBD66FD99311804F80324E8139B3C94EC43CDAxmbalnx15ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! I just posted the minutes from the meeting in Atlanta. Thanks for Ignas Ba= gdonas for being our scribe this time around. http://www.ietf.org/proceedings/85/minutes/minutes-85-rtgwg Please send any corrections/changes/additions to the list and I'll update t= he minutes as needed. The deadline is this Friday (Dec/7) at 5pm PT, so I = need any changes before then. Thanks! Alvaro. --_000_BBD66FD99311804F80324E8139B3C94EC43CDAxmbalnx15ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <051FC6CA4F928142B22700325F080841@cisco.com> Content-Transfer-Encoding: quoted-printable
Hi!

I just posted the minutes from the meeting in Atlanta.  Thanks fo= r Ignas Bagdonas for being our scribe this time around.


Please send any corrections/changes/additions to the list and I'll upd= ate the minutes as needed.  The deadline is this Friday (Dec/7) at 5pm= PT, so I need any changes before then.

Thanks!

Alvaro.
--_000_BBD66FD99311804F80324E8139B3C94EC43CDAxmbalnx15ciscocom_-- From hannes@juniper.net Tue Dec 11 02:28:10 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9FBD21F8622 for ; Tue, 11 Dec 2012 02:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMHhk4Wt-KWs for ; Tue, 11 Dec 2012 02:28:10 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF2E21F85F0 for ; Tue, 11 Dec 2012 02:28:10 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUMcKuRxahlugkrjZsskz25mH9cp+vOhC@postini.com; Tue, 11 Dec 2012 02:28:10 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 11 Dec 2012 02:25:54 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Tue, 11 Dec 2012 02:25:54 -0800 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.12) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 11 Dec 2012 02:28:08 -0800 Received: from mail63-va3-R.bigfish.com (10.7.14.249) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 11 Dec 2012 10:25:53 +0000 Received: from mail63-va3 (localhost [127.0.0.1]) by mail63-va3-R.bigfish.com (Postfix) with ESMTP id 03D494A015D for ; Tue, 11 Dec 2012 10:25:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); (null); H:BLUPRD0512HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 0 X-BigFish: PS0(zzzz1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1155h) Received: from mail63-va3 (localhost.localdomain [127.0.0.1]) by mail63-va3 (MessageSwitch) id 1355221550494131_13720; Tue, 11 Dec 2012 10:25:50 +0000 (UTC) Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.250]) by mail63-va3.bigfish.com (Postfix) with ESMTP id 6CF6C300362; Tue, 11 Dec 2012 10:25:50 +0000 (UTC) Received: from BLUPRD0512HT003.namprd05.prod.outlook.com (132.245.1.149) by VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 11 Dec 2012 10:25:50 +0000 Received: from yleteigner-sslvpn-nc.jnpr.net (66.129.224.36) by pod51010.outlook.com (10.255.215.164) with Microsoft SMTP Server (TLS) id 14.16.245.2; Tue, 11 Dec 2012 10:25:48 +0000 From: Hannes Gredler Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: IPR for draft-ietf-rtgwg-remote-lfa-00 ??? Date: Tue, 11 Dec 2012 11:25:41 +0100 Message-ID: <88923A46-BE7D-455C-B0B9-B057711B949F@juniper.net> To: , , , MIME-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Originating-IP: [66.129.224.36] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%TATACOMMUNICATIONS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 10:28:10 -0000 fellow authors of the remote-LFA draft, To date no IPR declaration has been filed for this draft. Can you please declare any IPR you may have (if any) and publish the licensing terms, please. tx, /hannes From stbryant@cisco.com Wed Dec 12 04:09:01 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311BF21F891A for ; Wed, 12 Dec 2012 04:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOKVB+fUml7g for ; Wed, 12 Dec 2012 04:09:00 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 49EA821F890D for ; Wed, 12 Dec 2012 04:09:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2508; q=dns/txt; s=iport; t=1355314140; x=1356523740; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=6eMBZ2RaX5xSeYuI2bK0vIs7PfqOczLT2VcMzXl+PHo=; b=hd3EQYnTzjZ/I6er2YkwVd7QRae7PAhmVYqczHsExKabsHxBJnMwXiZi svz3b90Kkjk/kEV7AOzM57aGiMDXvWDFdz1+LrsNgVKu+otgrJZetvmC1 ZY5wgiPyUtN/k5S0ATJIF8Eo+zNcc/jxYEPslkYemf64cX27t4CKXy1cY c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsIAIlzyFCQ/khR/2dsb2JhbABFg0iITq8sg2AWc4IeAQEBBHgBEAsEARMJFg8JAwIBAgFFBg0BBwEBiA28cYxLC4Q4A5YHkEiCc4Ft X-IronPort-AV: E=Sophos;i="4.84,266,1355097600"; d="scan'208,217";a="10360884" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 12 Dec 2012 12:08:58 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBCC8wIh016360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Dec 2012 12:08:58 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id qBCC8vTP010455; Wed, 12 Dec 2012 12:08:57 GMT Message-ID: <50C873EB.7080503@cisco.com> Date: Wed, 12 Dec 2012 12:09:15 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Hannes Gredler Subject: Re: IPR for draft-ietf-rtgwg-remote-lfa-00 ??? References: <88923A46-BE7D-455C-B0B9-B057711B949F@juniper.net> In-Reply-To: <88923A46-BE7D-455C-B0B9-B057711B949F@juniper.net> Content-Type: multipart/alternative; boundary="------------030000090009030408070903" Cc: "rtgwg-chairs@tools.ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 12:09:01 -0000 This is a multi-part message in MIME format. --------------030000090009030408070903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/12/2012 10:25, Hannes Gredler wrote: > fellow authors of the remote-LFA draft, > > To date no IPR declaration has been filed for this draft. > Can you please declare any IPR you may have (if any) and > publish the licensing terms, please. > > tx, > > /hannes > Hannes Thank you for bringing this to our attention. There was a declaration against draft-shand-remote-lfa-0, but the chairs did not set the replacement status correctly when draft-ietf-rtgwg-remote-lfa-00 was published, so the new draft did not automatically inherit the existing IPR disclosure. Please can the chairs email the secretariat and request that they correct the meta-data so that the WG draft draft picks up IPR disclosure 1770 in the tracker. - Stewart --------------030000090009030408070903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/12/2012 10:25, Hannes Gredler wrote:
fellow authors of the remote-LFA draft,

To date no IPR declaration has been filed for this draft.
Can you please declare any IPR you may have (if any) and
publish the licensing terms, please.

tx,

/hannes

Hannes

Thank you for bringing this to our attention.

There was a declaration against  draft-shand-remote-lfa-0,
but the chairs did not set the replacement status correctly
when draft-ietf-rtgwg-remote-lfa-00 was published, so
the new draft did not automatically inherit the existing
IPR disclosure.

Please can the chairs email the secretariat and request
that they correct the meta-data so that the WG draft draft
picks up IPR disclosure 1770 in the tracker.

- Stewart



--------------030000090009030408070903-- From hannes@juniper.net Wed Dec 12 06:52:32 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A8521F81FF for ; Wed, 12 Dec 2012 06:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OK829D9ve4I for ; Wed, 12 Dec 2012 06:52:23 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 758BE21F8A3E for ; Wed, 12 Dec 2012 06:52:21 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUMiaJCJm+Us97ZmPj32Ahhb5P4KsNptg@postini.com; Wed, 12 Dec 2012 06:52:22 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 12 Dec 2012 06:49:58 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 12 Dec 2012 06:49:57 -0800 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.184) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 12 Dec 2012 06:52:09 -0800 Received: from mail63-ch1-R.bigfish.com (10.43.68.241) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Dec 2012 14:49:56 +0000 Received: from mail63-ch1 (localhost [127.0.0.1]) by mail63-ch1-R.bigfish.com (Postfix) with ESMTP id 826C64A022B for ; Wed, 12 Dec 2012 14:49:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); (null); H:BLUPRD0512HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 0 X-BigFish: PS0(zzzz1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h946hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1155h) Received: from mail63-ch1 (localhost.localdomain [127.0.0.1]) by mail63-ch1 (MessageSwitch) id 1355323794742676_15783; Wed, 12 Dec 2012 14:49:54 +0000 (UTC) Received: from CH1EHSMHS036.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.225]) by mail63-ch1.bigfish.com (Postfix) with ESMTP id A85F530005D; Wed, 12 Dec 2012 14:49:54 +0000 (UTC) Received: from BLUPRD0512HT003.namprd05.prod.outlook.com (132.245.1.149) by CH1EHSMHS036.bigfish.com (10.43.69.245) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Dec 2012 14:49:53 +0000 Received: from yleteigner-sslvpn-nc.jnpr.net (66.129.224.36) by pod51010.outlook.com (10.255.215.164) with Microsoft SMTP Server (TLS) id 14.16.245.2; Wed, 12 Dec 2012 14:49:50 +0000 From: Hannes Gredler Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Subject: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 Date: Wed, 12 Dec 2012 15:49:43 +0100 Message-ID: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> To: , MIME-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Originating-IP: [66.129.224.36] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ORANGE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 14:52:37 -0000 clarence, stewart, In favor of interoperable implementations i feel one should document how = to=20 identify the transport IP address (in lieu of protocols extensions who = would explicitly advertise the transport IP addresses) to the PQ node for the = targeted LDP session. I am proposing to append the following text to 3.2. "Tunnel = requirements": 3.2. Tunnel Requirements [ =85 ] When a failure is detected, it is necessary to immediately redirect traffic to the repair path. Consequently, the repair tunnel used must be provisioned beforehand in anticipation of the failure. Since the location of the repair tunnels is dynamically determined it is necessary to establish the repair tunnels without management action. Multiple repairs may share a tunnel end point. Targeted LDP sessions are brought up using a pair of source (PLR) and = destination (PQ node) loopback addresses. The following heuristics should be applied = for deriving the loopback IP address from a PQ nodes link-state advertisement. for the IS-IS routing protocol: A PLR router should connect to the address traffic-engineering deployments: - reported both in the TE-router ID TLV 134 - and IP Reach TLVs (128,135) given that - the prefix length is /32 or no traffic-engineering deployments: - reported both in the IP interface address TLV 132 - and IP Reach TLVs (128,135), given that - there is only a single interface address advertised per the router - the prefix length is /32 for the OSPF routing protocol: A PLR router should connect to the address traffic-engineering deployments: - reported in the Router Address TLV (Type 10 LSA) and - router (Type 1 LSA) ) stub network advertisement and - the address mask is 255.255.255.255 or non-traffic-engineering deployments: - reported in the router-id field of the Type-1 LSA) - the router (Type 1 LSA) stub network advertisement and - the address mask is 255.255.255.255 tx, /hannes= From ppsenak@cisco.com Wed Dec 12 07:28:20 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB58621F89ED for ; Wed, 12 Dec 2012 07:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBYQzIVDdK0O for ; Wed, 12 Dec 2012 07:28:10 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id A0BF621F8504 for ; Wed, 12 Dec 2012 07:27:54 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBCFRrSh004040 for ; Wed, 12 Dec 2012 16:27:53 +0100 (CET) Received: from Peter-Psenaks-MacBook-Pro.local ([10.148.128.94]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBCFRq6x016088; Wed, 12 Dec 2012 16:27:52 +0100 (CET) Message-ID: <50C8A278.6080203@cisco.com> Date: Wed, 12 Dec 2012 16:27:52 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Hannes Gredler Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> In-Reply-To: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: rtgwg@ietf.org, stbryant@cisco.com X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 15:28:20 -0000 Hi Hannes, please see inline: On 12.12.2012 15:49, Hannes Gredler wrote: > > for the OSPF routing protocol: > > A PLR router should connect to the address > > traffic-engineering deployments: why do we need to distinguish between TE and non-TE deployments? All we need in rLFA context is a reachable IPv4 address advertised by PQ node. That should be independent of TE being deployed or not. > - reported in the Router Address TLV (Type 10 LSA) and > - router (Type 1 LSA) ) stub network advertisement and > - the address mask is 255.255.255.255 > > or > > non-traffic-engineering deployments: > - reported in the router-id field of the Type-1 LSA) > - the router (Type 1 LSA) stub network advertisement and > - the address mask is 255.255.255.255 can we say that the PQ node address used for targeted LDP session is selected in following order of preference: 1. PQ node OSPF router-id, if it is advertised as /32 prefix by the PQ node itself 2. Highest /32 address advertised by PQ node in it's Router LSA thanks, Peter > > > > tx, > > /hannes > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > > From hannes@juniper.net Wed Dec 12 08:11:12 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83CDA21E80C1 for ; Wed, 12 Dec 2012 08:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.097 X-Spam-Level: X-Spam-Status: No, score=-3.097 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vroF095Y6VG1 for ; Wed, 12 Dec 2012 08:11:10 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 65F9B21E80C0 for ; Wed, 12 Dec 2012 08:11:10 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUMisnDr8UgQHOyIYv3avv+1XiJm9iwV4@postini.com; Wed, 12 Dec 2012 08:11:10 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 12 Dec 2012 08:06:13 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 12 Dec 2012 08:06:12 -0800 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.184) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 12 Dec 2012 08:13:46 -0800 Received: from mail110-co1-R.bigfish.com (10.243.78.228) by CO1EHSOBE016.bigfish.com (10.243.66.79) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Dec 2012 16:06:10 +0000 Received: from mail110-co1 (localhost [127.0.0.1]) by mail110-co1-R.bigfish.com (Postfix) with ESMTP id 547993A0269 for ; Wed, 12 Dec 2012 16:06:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.2.21; KIP:(null); UIP:(null); (null); H:BN1PRD0512HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -25 X-BigFish: PS-25(zz98dI9371I168aJ1432Izz1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h946hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1155h) Received: from mail110-co1 (localhost.localdomain [127.0.0.1]) by mail110-co1 (MessageSwitch) id 1355328368391814_25630; Wed, 12 Dec 2012 16:06:08 +0000 (UTC) Received: from CO1EHSMHS025.bigfish.com (unknown [10.243.78.245]) by mail110-co1.bigfish.com (Postfix) with ESMTP id 4D352C8004D; Wed, 12 Dec 2012 16:06:08 +0000 (UTC) Received: from BN1PRD0512HT004.namprd05.prod.outlook.com (132.245.2.21) by CO1EHSMHS025.bigfish.com (10.243.66.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Dec 2012 16:06:02 +0000 Received: from yleteigner-sslvpn-nc.jnpr.net (66.129.224.36) by pod51010.outlook.com (10.255.193.37) with Microsoft SMTP Server (TLS) id 14.16.245.2; Wed, 12 Dec 2012 16:06:00 +0000 Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Hannes Gredler In-Reply-To: <50C8A278.6080203@cisco.com> Date: Wed, 12 Dec 2012 17:05:51 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: <985BF299-1BB7-4B35-9795-842F1781DF12@juniper.net> References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> To: Peter Psenak X-Mailer: Apple Mail (2.1283) X-Originating-IP: [66.129.224.36] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: rtgwg@ietf.org, stbryant@cisco.com X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 16:11:12 -0000 On Dec 12, 2012, at 4:27 PM, Peter Psenak wrote: > Hi Hannes, >=20 > please see inline: >=20 > On 12.12.2012 15:49, Hannes Gredler wrote: >=20 >>=20 >> for the OSPF routing protocol: >>=20 >> A PLR router should connect to the address >>=20 >> traffic-engineering deployments: >=20 > why do we need to distinguish between TE and non-TE deployments? for OSPF things are less ambiguous than for IS-IS, agreed. for IS-IS the advantage of TE extensions is really that it serves as an = explicit identifier of a node, if this router-ID has got IP reachability as well then its usually the = transport IP address; for OSPF we have the router-ID in every type-1 LSA for IS-IS we don't. > All we need in rLFA context is a reachable IPv4 address advertised by = PQ node. That should be independent of TE being deployed or not. by ensuring a deterministic address selection you safe T-LDP sessions: if any source address can connect to any destination address then you = have doubled the overall number of T-LDP by two. however if you ensure that = all nodes agree to use a single IP address then you only need one T-LDP for a given source/destination router pair. >=20 >> - reported in the Router Address TLV (Type 10 LSA) and >> - router (Type 1 LSA) ) stub network advertisement and >> - the address mask is 255.255.255.255 >>=20 >> or >>=20 >> non-traffic-engineering deployments: >> - reported in the router-id field of the Type-1 LSA) >> - the router (Type 1 LSA) stub network advertisement and >> - the address mask is 255.255.255.255 >=20 > can we say that the PQ node address used for targeted LDP session is = selected in following order of preference: >=20 > 1. PQ node OSPF router-id, if it is advertised as /32 prefix by the PQ = node itself >=20 > 2. Highest /32 address advertised by PQ node in it's Router LSA in favor of explicit advertisement, i'd rather do 3 rules here : 1. PQ node OSPF router-id, if it is advertised as /32 prefix by the PQ = node itself 2. PQ node TE adress, if it is advertised as /32 prefix by the PQ node = itself 3. Highest /32 address advertised by PQ node in it's Router LSA >>=20 >> >>=20 >> tx, >>=20 >> /hannes >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg >>=20 >>=20 >=20 >=20 >=20 From ppsenak@cisco.com Wed Dec 12 08:51:19 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD3521E80D7 for ; Wed, 12 Dec 2012 08:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFqmMy-rzDpj for ; Wed, 12 Dec 2012 08:51:17 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD7A21E8050 for ; Wed, 12 Dec 2012 08:51:17 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBCGYEdh010999 for ; Wed, 12 Dec 2012 17:34:14 +0100 (CET) Received: from Peter-Psenaks-MacBook-Pro.local ([10.148.128.94]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBCGYBhF015833; Wed, 12 Dec 2012 17:34:11 +0100 (CET) Message-ID: <50C8B203.2070503@cisco.com> Date: Wed, 12 Dec 2012 17:34:11 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Hannes Gredler Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <985BF299-1BB7-4B35-9795-842F1781DF12@juniper.net> In-Reply-To: <985BF299-1BB7-4B35-9795-842F1781DF12@juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: rtgwg@ietf.org, stbryant@cisco.com X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 16:51:19 -0000 Hannes, On 12.12.2012 17:05, Hannes Gredler wrote: > in favor of explicit advertisement, i'd rather do 3 rules here : > > 1. PQ node OSPF router-id, if it is advertised as /32 prefix by the PQ node itself > 2. PQ node TE adress, if it is advertised as /32 prefix by the PQ node itself > 3. Highest /32 address advertised by PQ node in it's Router LSA ether (1) or (3) is mandatory for the t-LDP session creation. (2) is optional and not sufficient for t-LDP session, so we can not have it before (3). It looks to me we are trying to solve the configuration problem which should not be addressed here. thanks, Peter From stephane.litkowski@orange.com Thu Dec 13 02:51:23 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8C021F89BF for ; Thu, 13 Dec 2012 02:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.331 X-Spam-Level: * X-Spam-Status: No, score=1.331 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_INTEREST=3.579, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPGlPUH1wzJR for ; Thu, 13 Dec 2012 02:51:12 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 869AA21F8990 for ; Thu, 13 Dec 2012 02:51:11 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 5BC1C18C157; Thu, 13 Dec 2012 11:51:10 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 3A78427C066; Thu, 13 Dec 2012 11:51:10 +0100 (CET) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.53]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Thu, 13 Dec 2012 11:51:10 +0100 From: To: Peter Psenak , Hannes Gredler Date: Thu, 13 Dec 2012 11:51:08 +0100 Subject: RE: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 Thread-Topic: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 Thread-Index: Ac3YiOuM3UgWzTMXQyy38Rl821WUPgAlEhSA Message-ID: <28885_1355395870_50C9B31E_28885_2050_1_EEE55384044474429A926C625D0FCC81062DF63B92@PUEXCB2F.nanterre.francetelecom.fr> References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <985BF299-1BB7-4B35-9795-842F1781DF12@juniper.net> <50C8B203.2070503@cisco.com> In-Reply-To: <50C8B203.2070503@cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.13.101518 Cc: "stbryant@cisco.com" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 10:51:23 -0000 Hi all, I would bring the following comment : As far as I know, LDP and IGP are quite independent in term of managing the= ir "addresses". An operator may choose a router ID for ISIS that could be different from LD= P one. Personnally I don't really see an interrest in doing that but it's a= possibility. Moreover I would be more worry on transient situations when y= ou let the router choosing router IDs, you activate ISIS (ISIS choose a rou= ter ID based on IP address available), then you configure a new high addres= s loopback, and then you configure LDP, in this case you will have a high p= robability to have a different router ID for each ... (it's clearly impleme= ntation dependant but the solution must work with all cases) -> we already = had such situation with BGP having a different router-id than ISIS/LDP. Moreover regarding TLDP, I think implementations could be different in the = way they are accepting T-LDP sessions. I don't know if there are some guide= lines in LDP spec for this ... Some may accept TLDP sessions only on LDP r= outer-id, some may accept on all loopbacks ...=20 So is it a good think to rely on IGP router-id or IP address TLV 132 as it = may not reflect how LDP is behaving ? Issue with TLV 135 is that it could transport external redistributed routes= (we have the case ...) It could be good to have some tie breakers as Hannes proposed, the main poi= nt to address would be , how implementation must behave when the TLDP sessi= on cannot establish (for example because we chosen the bad IP address ...) = ? Does it fallback and try another IP, does it fallback to another PQ ? (bu= t problem would be the same with another PQ if problem comes from bad IP ch= oice). I would see two complementary options : - define a spec, as Hannes proposed, where we rely on IGP address infos (ro= uter ID, TLV 132 ...) and give some guidelines to reader on how LDP must be= parametered to ensure that it will work.=20 - permit user to define by himself the addresses rLFA would use as transpor= t address for TLDP (using admin tags for example). =20 Regards, Stephane =20 -----Message d'origine----- De : rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] De la part de P= eter Psenak Envoy=E9 : mercredi 12 d=E9cembre 2012 17:34 =C0 : Hannes Gredler Cc : rtgwg@ietf.org; stbryant@cisco.com Objet : Re: identifying IP address of targeted LDP session in draft-ietf-rt= gwg-remote-lfa-00 Hannes, On 12.12.2012 17:05, Hannes Gredler wrote: > in favor of explicit advertisement, i'd rather do 3 rules here : > > 1. PQ node OSPF router-id, if it is advertised as /32 prefix by the PQ=20 > node itself 2. PQ node TE adress, if it is advertised as /32 prefix by=20 > the PQ node itself 3. Highest /32 address advertised by PQ node in=20 > it's Router LSA ether (1) or (3) is mandatory for the t-LDP session creation. (2) is option= al and not sufficient for t-LDP session, so we can not have it before (3). It looks to me we are trying to solve the configuration problem which shoul= d not be addressed here. thanks, Peter _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From stbryant@cisco.com Thu Dec 13 03:38:38 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B5C21F8AD5 for ; Thu, 13 Dec 2012 03:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6o4ff+GgXXm for ; Thu, 13 Dec 2012 03:38:37 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 253F421F86B9 for ; Thu, 13 Dec 2012 03:38:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2918; q=dns/txt; s=iport; t=1355398717; x=1356608317; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=FUX6VOmha9/8yokB9CiW8yxEPmWslE8X/srT/7OG8d4=; b=Tuz5qD2S+0JMFidu6TTZtHvLxByBgyWqNUqWl+nn10xchmbB0+VFVO30 joaiKR5L3sDm1JNPOe9n+iNSRxSV8X77ZhoMs3W7Y51+8DfesJxa1ArZq uuzrHqXAR62MBJ5cro5gwKLqi0AWewJOv3SLAJi0PgLjmd9Kk214yOMzu M=; X-IronPort-AV: E=Sophos;i="4.84,273,1355097600"; d="scan'208";a="148242544" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 13 Dec 2012 11:38:35 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBDBcYZ4007749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2012 11:38:34 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id qBDBcXJR017298; Thu, 13 Dec 2012 11:38:33 GMT Message-ID: <50C9BE4C.4090103@cisco.com> Date: Thu, 13 Dec 2012 11:38:52 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Hannes Gredler Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> In-Reply-To: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 11:38:38 -0000 Hannes The draft as it stands is not MPLS specific and thus I am not convinced we should add the information you propose to this draft, although perhaps some text could go in a new section. However if we include this text, we need to consider what we should say about IP tunnels. However it might be better if this information were in IGP specific drafts put through the IGP WGs. Certainly I think that we need to specify more than this text since there are for example security and capability considerations. I have some explicit questions inline. On 12/12/2012 14:49, Hannes Gredler wrote: > clarence, stewart, > > In favor of interoperable implementations i feel one should document how to > identify the transport IP address (in lieu of protocols extensions who would > explicitly advertise the transport IP addresses) to the PQ node for the targeted LDP session. > > I am proposing to append the following text to 3.2. "Tunnel requirements": > > 3.2. Tunnel Requirements > [ … ] > > When a failure is detected, it is necessary to immediately redirect > traffic to the repair path. Consequently, the repair tunnel used > must be provisioned beforehand in anticipation of the failure. Since > the location of the repair tunnels is dynamically determined it is > necessary to establish the repair tunnels without management action. > Multiple repairs may share a tunnel end point. > > > > Targeted LDP sessions are brought up using a pair of source (PLR) and destination What does PLR stand for? > (PQ node) loopback addresses. The following heuristics should be applied for deriving the > loopback IP address from a PQ nodes link-state advertisement. > > for the IS-IS routing protocol: > > A PLR router should connect to the address > > traffic-engineering deployments: > - reported both in the TE-router ID TLV 134 > - and IP Reach TLVs (128,135) given that > - the prefix length is /32 > > or > > no traffic-engineering deployments: > - reported both in the IP interface address TLV 132 > - and IP Reach TLVs (128,135), given that > - there is only a single interface address advertised per the router > - the prefix length is /32 > The text above does not scan (nor does the text below) > for the OSPF routing protocol: > > A PLR router should connect to the address > > traffic-engineering deployments: > - reported in the Router Address TLV (Type 10 LSA) and > - router (Type 1 LSA) ) stub network advertisement and > - the address mask is 255.255.255.255 > > or > > non-traffic-engineering deployments: > - reported in the router-id field of the Type-1 LSA) > - the router (Type 1 LSA) stub network advertisement and > - the address mask is 255.255.255.255 > > > > tx, > > /hannes > . > - Stewart From stbryant@cisco.com Thu Dec 13 03:42:45 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A4421F8A76 for ; Thu, 13 Dec 2012 03:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-os-pHbz3me for ; Thu, 13 Dec 2012 03:42:45 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 2B41321F8A75 for ; Thu, 13 Dec 2012 03:42:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1881; q=dns/txt; s=iport; t=1355398965; x=1356608565; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=rPe1oMoVHLUHXQhpF6DkoqEReiIQZPZWQj7VRndx6RM=; b=Y0n6a6jVIcAXz1rWH0aRGT+vZDskNiEk7P8Hcstg8sKWa/VbHEKCYsRl b7t50k1HZFCEbCJdI3bdAefHXGzY04oPKWSGx4nI4SvJZvMonaMJXV1uS gX9nFOeBFKccjMtbmD0KiQIsjFzL28qzn5yRGPulOd6qSmKKoL5AscZGm w=; X-IronPort-AV: E=Sophos;i="4.84,273,1355097600"; d="scan'208";a="10422031" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 13 Dec 2012 11:42:44 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBDBgi3L008576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2012 11:42:44 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id qBDBgguC017559; Thu, 13 Dec 2012 11:42:43 GMT Message-ID: <50C9BF46.4060509@cisco.com> Date: Thu, 13 Dec 2012 11:43:02 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Peter Psenak Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> In-Reply-To: <50C8A278.6080203@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 11:42:46 -0000 On 12/12/2012 15:27, Peter Psenak wrote: > Hi Hannes, > > please see inline: > > On 12.12.2012 15:49, Hannes Gredler wrote: > >> >> for the OSPF routing protocol: >> >> A PLR router should connect to the address >> >> traffic-engineering deployments: > > why do we need to distinguish between TE and non-TE deployments? > All we need in rLFA context is a reachable IPv4 address advertised by > PQ node. That should be independent of TE being deployed or not. Surely "reachable IP address", not "reachable IPv4 address". > > >> - reported in the Router Address TLV (Type 10 LSA) and >> - router (Type 1 LSA) ) stub network advertisement and >> - the address mask is 255.255.255.255 >> >> or >> >> non-traffic-engineering deployments: >> - reported in the router-id field of the Type-1 LSA) >> - the router (Type 1 LSA) stub network advertisement and >> - the address mask is 255.255.255.255 > > can we say that the PQ node address used for targeted LDP session is > selected in following order of preference: > > 1. PQ node OSPF router-id, if it is advertised as /32 prefix by the PQ > node itself > > 2. Highest /32 address advertised by PQ node in it's Router LSA Why do we need (2). What do we do if an interface cycles? Surely the most we should say is that we SHOULD establish a TLDP session with the OSPF router-id, if it is advertised as /32 prefix by the PQ node itself, else any other IP address for the node may be sued. Stewart > > thanks, > Peter > >> >> >> >> tx, >> >> /hannes >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg >> >> > > > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From stbryant@cisco.com Thu Dec 13 03:45:01 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E521C21F8A79 for ; Thu, 13 Dec 2012 03:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzfFS-ze5id2 for ; Thu, 13 Dec 2012 03:45:01 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id BE19C21F8AEA for ; Thu, 13 Dec 2012 03:45:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=938; q=dns/txt; s=iport; t=1355399100; x=1356608700; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=opIbH1a2zDADMnJ2Y2yVzclShVq52M1cth/BHt4Ps28=; b=drHGlkfg8eSAplpv7VzzHZ1cYLIKz8OawbaLjT0UO/rS3CarB0V7qoxT h5iXFp2zA6dG6OGw2qZvTD5LnDmAkRVmNe9Z52Wz999R4eNrsQdVBr/oJ VKScq/1ErfFYLaBsc/6gDrQCsVVjtlmmql00UJ+i09/qjiA/ABYx3aucB 0=; X-IronPort-AV: E=Sophos;i="4.84,273,1355097600"; d="scan'208";a="79073986" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 13 Dec 2012 11:44:54 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBDBirDe009017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2012 11:44:54 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id qBDBiqM9017603; Thu, 13 Dec 2012 11:44:53 GMT Message-ID: <50C9BFC8.1040901@cisco.com> Date: Thu, 13 Dec 2012 11:45:12 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Peter Psenak Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <985BF299-1BB7-4B35-9795-842F1781DF12@juniper.net> <50C8B203.2070503@cisco.com> In-Reply-To: <50C8B203.2070503@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 11:45:02 -0000 On 12/12/2012 16:34, Peter Psenak wrote: > Hannes, > > On 12.12.2012 17:05, Hannes Gredler wrote: > >> in favor of explicit advertisement, i'd rather do 3 rules here : >> >> 1. PQ node OSPF router-id, if it is advertised as /32 prefix by the >> PQ node itself >> 2. PQ node TE adress, if it is advertised as /32 prefix by the PQ >> node itself >> 3. Highest /32 address advertised by PQ node in it's Router LSA > > ether (1) or (3) is mandatory for the t-LDP session creation. (2) is > optional and not sufficient for t-LDP session, so we can not have it > before (3). > > It looks to me we are trying to solve the configuration problem which > should not be addressed here. I am inclined to agree, and note that the draft is tunnel independent. We may want a deployment guidelines document, or some protocol specific text in another document, but this draft can stand alone without this text. Stewart From bruno.decraene@orange.com Thu Dec 13 06:21:42 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAE021F8B1D for ; Thu, 13 Dec 2012 06:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pq9seUEiAkN4 for ; Thu, 13 Dec 2012 06:21:42 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C055E21F8B0F for ; Thu, 13 Dec 2012 06:21:41 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id AC0072DC285; Thu, 13 Dec 2012 15:21:40 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 87FBF35C065; Thu, 13 Dec 2012 15:21:40 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Thu, 13 Dec 2012 15:21:40 +0100 From: To: Peter Psenak Subject: RE: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 Thread-Topic: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 Thread-Index: AQHN2IjrTktN60ofdUyRZ2gXy9yWk5gWwcCQ Date: Thu, 13 Dec 2012 14:21:40 +0000 Message-ID: <712_1355408500_50C9E474_712_170_1_53C29892C857584299CBF5D05346208A117B82@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <985BF299-1BB7-4B35-9795-842F1781DF12@juniper.net> <50C8B203.2070503@cisco.com> In-Reply-To: <50C8B203.2070503@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: "stbryant@cisco.com" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:21:42 -0000 Peter, >From: Peter Psenak > >Hannes, > >On 12.12.2012 17:05, Hannes Gredler wrote: > >> in favor of explicit advertisement, i'd rather do 3 rules here : >> >> 1. PQ node OSPF router-id, if it is advertised as /32 prefix by the PQ n= ode >itself >> 2. PQ node TE adress, if it is advertised as /32 prefix by the PQ node i= tself >> 3. Highest /32 address advertised by PQ node in it's Router LSA > >ether (1) or (3) is mandatory for the t-LDP session creation. (2) is >optional and not sufficient for t-LDP session, so we can not have it >before (3). > >It looks to me we are trying to solve the configuration problem which >should not be addressed here. It looks to me that we are trying to address the network management problem= and deployability/interoperability in a multi-vendor network. May be this can be done by configuration. In this case, could you please el= aborate on what you propose? Given that at least two routers (the PLR and the PQ) must agree on establis= hing the T-LDP session, there is a priori room for coordination. And given = that a PLR (resp. PQ) needs to be able to use (resp. used) "any" PQ (resp. = PLR), it seems useful that the same mechanism be shared by all PQs and PLRs= , rathers than one relying on ISIS tag, another on order of IP addresses, a= nother on static address range... Hannes' request seems a relevant point to discuss on the mailing list and I= MO the R-LFA draft should discuss this. Even if the R-LFA proposition is not specific to a network environment (e.g= . type of tunnels) the goal is to _deploy_ the R-LFA proposition. And that = deployment will be a specific environment, where this is expected to work. = I also think MPLS tunnels (LSPs) established by LDP seems a reasonably popu= lar target deployment. Unless it is believed that a local algorithm, without coordination between = routers/vendor, can work in 100% of the cases. Is this your point? Thanks, Regards, Bruno >thanks, >Peter >_______________________________________________ >rtgwg mailing list >rtgwg@ietf.org >https://www.ietf.org/mailman/listinfo/rtgwg ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From hannes@juniper.net Thu Dec 13 06:24:35 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F32E21F8B2D for ; Thu, 13 Dec 2012 06:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4JUC3cmqK8e for ; Thu, 13 Dec 2012 06:24:34 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id F12F721F8AD9 for ; Thu, 13 Dec 2012 06:24:33 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUMnlIQIkYRNfvx/jsQxkry35reXApexj@postini.com; Thu, 13 Dec 2012 06:24:34 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 13 Dec 2012 06:23:24 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Thu, 13 Dec 2012 06:23:24 -0800 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.13) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 13 Dec 2012 06:30:57 -0800 Received: from mail213-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 13 Dec 2012 14:23:22 +0000 Received: from mail213-va3 (localhost [127.0.0.1]) by mail213-va3-R.bigfish.com (Postfix) with ESMTP id AF5625401A9 for ; Thu, 13 Dec 2012 14:23:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.2.21; KIP:(null); UIP:(null); (null); H:BN1PRD0512HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -5 X-BigFish: PS-5(zz98dI9371I168aJ1432Izz1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h946hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1155h) Received: from mail213-va3 (localhost.localdomain [127.0.0.1]) by mail213-va3 (MessageSwitch) id 1355408494493864_1317; Thu, 13 Dec 2012 14:21:34 +0000 (UTC) Received: from VA3EHSMHS014.bigfish.com (unknown [10.7.14.245]) by mail213-va3.bigfish.com (Postfix) with ESMTP id 62B6A6C021E; Thu, 13 Dec 2012 14:21:34 +0000 (UTC) Received: from BN1PRD0512HT004.namprd05.prod.outlook.com (132.245.2.21) by VA3EHSMHS014.bigfish.com (10.7.99.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 13 Dec 2012 14:21:34 +0000 Received: from evazhang-sslvpn-nc.jnpr.net (66.129.224.36) by pod51010.outlook.com (10.255.193.37) with Microsoft SMTP Server (TLS) id 14.16.245.2; Thu, 13 Dec 2012 14:21:31 +0000 Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Hannes Gredler In-Reply-To: <50C9BF46.4060509@cisco.com> Date: Thu, 13 Dec 2012 15:21:23 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <50C9BF46.4060509@cisco.com> To: X-Mailer: Apple Mail (2.1283) X-Originating-IP: [66.129.224.36] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:24:35 -0000 On Dec 13, 2012, at 12:43 PM, Stewart Bryant wrote: [ =85 ] >> can we say that the PQ node address used for targeted LDP session is = selected in following order of preference: >>=20 >> 1. PQ node OSPF router-id, if it is advertised as /32 prefix by the = PQ node itself >>=20 >> 2. Highest /32 address advertised by PQ node in it's Router LSA > Why do we need (2). What do we do if an interface cycles? >=20 > Surely the most we should say is that we SHOULD establish a TLDP = session with the > OSPF router-id, if it is advertised as /32 prefix by the PQ node = itself, else any > other IP address for the node may be used. other implementations may not be willing to accept T-LDP sessions on = non-loopback adresses. /hannes= From hannes@juniper.net Thu Dec 13 06:28:39 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C54A21F84E4 for ; Thu, 13 Dec 2012 06:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.245 X-Spam-Level: X-Spam-Status: No, score=-3.245 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnWP313lMsIT for ; Thu, 13 Dec 2012 06:28:33 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 587F421F84CF for ; Thu, 13 Dec 2012 06:28:30 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUMnmDWKnqlLwYlSU3O+JOlr6kHrDMP5q@postini.com; Thu, 13 Dec 2012 06:28:30 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 13 Dec 2012 06:20:59 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Thu, 13 Dec 2012 06:20:59 -0800 Received: from CO9EHSOBE040.bigfish.com (207.46.163.26) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 13 Dec 2012 06:28:31 -0800 Received: from mail84-co9-R.bigfish.com (10.236.132.238) by CO9EHSOBE040.bigfish.com (10.236.130.103) with Microsoft SMTP Server id 14.1.225.23; Thu, 13 Dec 2012 14:20:57 +0000 Received: from mail84-co9 (localhost [127.0.0.1]) by mail84-co9-R.bigfish.com (Postfix) with ESMTP id 47837C03D1 for ; Thu, 13 Dec 2012 14:20:57 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.242.197; KIP:(null); UIP:(null); (null); H:BL2PRD0512HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -5 X-BigFish: PS-5(zzbb2dI98dI9371I1432I1418Izz1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h946hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1155h) Received: from mail84-co9 (localhost.localdomain [127.0.0.1]) by mail84-co9 (MessageSwitch) id 1355408346747262_16594; Thu, 13 Dec 2012 14:19:06 +0000 (UTC) Received: from CO9EHSMHS002.bigfish.com (unknown [10.236.132.229]) by mail84-co9.bigfish.com (Postfix) with ESMTP id ABB194203CC; Thu, 13 Dec 2012 14:19:06 +0000 (UTC) Received: from BL2PRD0512HT002.namprd05.prod.outlook.com (157.56.242.197) by CO9EHSMHS002.bigfish.com (10.236.130.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 13 Dec 2012 14:18:12 +0000 Received: from evazhang-sslvpn-nc.jnpr.net (66.129.224.53) by pod51010.outlook.com (10.255.233.35) with Microsoft SMTP Server (TLS) id 14.16.245.2; Thu, 13 Dec 2012 14:18:11 +0000 Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Hannes Gredler In-Reply-To: <50C9BE4C.4090103@cisco.com> Date: Thu, 13 Dec 2012 15:18:04 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: <69427321-F178-4698-888C-652372B62E78@juniper.net> References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C9BE4C.4090103@cisco.com> To: X-Mailer: Apple Mail (2.1283) X-Originating-IP: [66.129.224.53] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ORANGE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:28:42 -0000 On Dec 13, 2012, at 12:38 PM, Stewart Bryant wrote: > The draft as it stands is not MPLS specific and thus I am not = convinced > we should add the information you propose to this draft, although > perhaps some text could go in a new section. However if we include > this text, we need to consider what we should say about IP tunnels. rfc5286 is not MPLS specific either, yet the majority (>90%) of my = customers see it as lightweight alternative to get local-repair protection for = their LDP networks. draft-ietf-rtgwg-remote-lfa-00 is not LDP specific either, however the it will be deployed by a majority of customers who have an LDP/MPLS = background as well.=20 > However it might be better if this information were in IGP specific > drafts put through the IGP WGs. Certainly I think that we need to > specify more than this text since there are for example security > and capability considerations. if we go down the road of explicitly advertising the transport loopback then i agree this work should be done in ospf-wg and isis-wg. the question is wether we can go without protocol extension and identify the loopback IP based on existing protocols. > I have some explicit questions inline. >=20 >=20 > On 12/12/2012 14:49, Hannes Gredler wrote: >> clarence, stewart, >>=20 >> In favor of interoperable implementations i feel one should document = how to >> identify the transport IP address (in lieu of protocols extensions = who would >> explicitly advertise the transport IP addresses) to the PQ node for = the targeted LDP session. >>=20 >> I am proposing to append the following text to 3.2. "Tunnel = requirements": >>=20 >> 3.2. Tunnel Requirements >> [ =85 ] >>=20 >> When a failure is detected, it is necessary to immediately = redirect >> traffic to the repair path. Consequently, the repair tunnel used >> must be provisioned beforehand in anticipation of the failure. = Since >> the location of the repair tunnels is dynamically determined it is >> necessary to establish the repair tunnels without management = action. >> Multiple repairs may share a tunnel end point. >>=20 >> >>=20 >> Targeted LDP sessions are brought up using a pair of source (PLR) and = destination > What does PLR stand for? This is the point of local repair (PLR) -=20 >> (PQ node) loopback addresses. The following heuristics should be = applied for deriving the >> loopback IP address from a PQ nodes link-state advertisement. >>=20 >> for the IS-IS routing protocol: >>=20 >> A PLR router should connect to the address >>=20 >> traffic-engineering deployments: >> - reported both in the TE-router ID TLV 134 >> - and IP Reach TLVs (128,135) given that >> - the prefix length is /32 >>=20 >> or >>=20 >> no traffic-engineering deployments: >> - reported both in the IP interface address TLV 132 >> - and IP Reach TLVs (128,135), given that >> - there is only a single interface address advertised per the = router >> - the prefix length is /32 >>=20 > The text above does not scan (nor does the text below) >=20 >> for the OSPF routing protocol: >>=20 >> A PLR router should connect to the address >>=20 >> traffic-engineering deployments: >> - reported in the Router Address TLV (Type 10 LSA) and >> - router (Type 1 LSA) ) stub network advertisement and >> - the address mask is 255.255.255.255 >>=20 >> or >>=20 >> non-traffic-engineering deployments: >> - reported in the router-id field of the Type-1 LSA) >> - the router (Type 1 LSA) stub network advertisement and >> - the address mask is 255.255.255.255 >>=20 >> >=20 From hannes@juniper.net Thu Dec 13 06:33:23 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488C821F89AE for ; Thu, 13 Dec 2012 06:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.282 X-Spam-Level: X-Spam-Status: No, score=-3.282 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e55gbqMyupfQ for ; Thu, 13 Dec 2012 06:33:22 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 40E5221F86F9 for ; Thu, 13 Dec 2012 06:33:22 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUMnnMhTL5cv95ud4uHs0e+rNPw6edWyT@postini.com; Thu, 13 Dec 2012 06:33:22 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 13 Dec 2012 06:32:11 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Thu, 13 Dec 2012 06:32:11 -0800 Received: from db3outboundpool.messaging.microsoft.com (213.199.154.139) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 13 Dec 2012 06:34:21 -0800 Received: from mail83-db3-R.bigfish.com (10.3.81.227) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Thu, 13 Dec 2012 14:32:08 +0000 Received: from mail83-db3 (localhost [127.0.0.1]) by mail83-db3-R.bigfish.com (Postfix) with ESMTP id A8DC3400583 for ; Thu, 13 Dec 2012 14:32:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -24 X-BigFish: PS-24(zz98dI9371I1432I4015Izz1de0h1202h1e76h1d1ah1d2ahzz8275bh8275dh1033ILz2dh2a8h668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1155h) Received: from mail83-db3 (localhost.localdomain [127.0.0.1]) by mail83-db3 (MessageSwitch) id 1355409110308035_15122; Thu, 13 Dec 2012 14:31:50 +0000 (UTC) Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.242]) by mail83-db3.bigfish.com (Postfix) with ESMTP id 3DC6760215; Thu, 13 Dec 2012 14:31:50 +0000 (UTC) Received: from BY2PRD0512HT002.namprd05.prod.outlook.com (157.56.238.5) by DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 13 Dec 2012 14:31:50 +0000 Received: from evazhang-sslvpn-nc.jnpr.net (66.129.224.54) by pod51010.outlook.com (10.255.243.35) with Microsoft SMTP Server (TLS) id 14.16.245.2; Thu, 13 Dec 2012 14:31:41 +0000 Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="iso-8859-1" From: Hannes Gredler In-Reply-To: <50C9E552.9020100@cisco.com> Date: Thu, 13 Dec 2012 15:31:36 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <985BF299-1BB7-4B35-9795-842F1781DF12@juniper.net> <50C8B203.2070503@cisco.com> <712_1355408500_50C9E474_712_170_1_53C29892C857584299CBF5D05346208A117B82@PEXCVZYM11.corporate.adroot.infra.ftgroup> <50C9E552.9020100@cisco.com> To: Peter Psenak X-Mailer: Apple Mail (2.1283) X-Originating-IP: [66.129.224.54] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ORANGE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "stbryant@cisco.com" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:33:23 -0000 On Dec 13, 2012, at 3:25 PM, Peter Psenak wrote: > Bruno, >=20 > On 13.12.2012 15:21, bruno.decraene@orange.com wrote: >> Peter, >>=20 >>> From: Peter Psenak >>>=20 >>> Hannes, >>>=20 >>> On 12.12.2012 17:05, Hannes Gredler wrote: >>>=20 >>>> in favor of explicit advertisement, i'd rather do 3 rules here : >>>>=20 >>>> 1. PQ node OSPF router-id, if it is advertised as /32 prefix by the = PQ node >>> itself >>>> 2. PQ node TE adress, if it is advertised as /32 prefix by the PQ = node itself >>>> 3. Highest /32 address advertised by PQ node in it's Router LSA >>>=20 >>> ether (1) or (3) is mandatory for the t-LDP session creation. (2) is >>> optional and not sufficient for t-LDP session, so we can not have it >>> before (3). >>>=20 >>> It looks to me we are trying to solve the configuration problem = which >>> should not be addressed here. >>=20 >> It looks to me that we are trying to address the network management = problem and deployability/interoperability in a multi-vendor network. >> May be this can be done by configuration. In this case, could you = please elaborate on what you propose? >> Given that at least two routers (the PLR and the PQ) must agree on = establishing the T-LDP session, there is a priori room for coordination. = And given that a PLR (resp. PQ) needs to be able to use (resp. used) = "any" PQ (resp. PLR), it seems useful that the same mechanism be shared = by all PQs and PLRs, rathers than one relying on ISIS tag, another on = order of IP addresses, another on static address range... >> Hannes' request seems a relevant point to discuss on the mailing list = and IMO the R-LFA draft should discuss this. >> Even if the R-LFA proposition is not specific to a network = environment (e.g. type of tunnels) the goal is to _deploy_ the R-LFA = proposition. And that deployment will be a specific environment, where = this is expected to work. I also think MPLS tunnels (LSPs) established = by LDP seems a reasonably popular target deployment. >>=20 >> Unless it is believed that a local algorithm, without coordination = between routers/vendor, can work in 100% of the cases. Is this your = point? >=20 > local algorithm that picks any of the /32 IP addresses advertised by = PQ node will work in 100% of cases. peter, two questions: 1) how do you know that the other side will be accepting the T-LDP = session at a non loopback IP address ? 2) what is your proposed scheme for minimizing the amount of T-LDP = sessions between a pair of routers ? (is it numerically highest IP ?) /hannes >>=20 >> Thanks, >> Regards, >> Bruno >>=20 >>> thanks, >>> Peter >>> _______________________________________________ >>> rtgwg mailing list >>> rtgwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtgwg >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >> France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or = privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. >> Thank you. >>=20 >>=20 >>=20 >=20 >=20 >=20 From hannes@juniper.net Thu Dec 13 06:33:29 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8849E21F8A56 for ; Thu, 13 Dec 2012 06:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.308 X-Spam-Level: X-Spam-Status: No, score=-3.308 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-T+AJAn7Qkk for ; Thu, 13 Dec 2012 06:33:27 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 1C46721F8A2C for ; Thu, 13 Dec 2012 06:33:27 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUMnnNsnHDL1ShwH9jGfV6lba5IffQEKH@postini.com; Thu, 13 Dec 2012 06:33:27 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 13 Dec 2012 06:26:04 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Thu, 13 Dec 2012 06:26:04 -0800 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.16) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 13 Dec 2012 06:33:37 -0800 Received: from mail273-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE012.bigfish.com (10.7.40.62) with Microsoft SMTP Server id 14.1.225.23; Thu, 13 Dec 2012 14:26:03 +0000 Received: from mail273-va3 (localhost [127.0.0.1]) by mail273-va3-R.bigfish.com (Postfix) with ESMTP id A283FE8009C for ; Thu, 13 Dec 2012 14:26:02 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.2.21; KIP:(null); UIP:(null); (null); H:BN1PRD0512HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -4 X-BigFish: PS-4(zzbb2dI98dI9371I1432Izz1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h946hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1155h) Received: from mail273-va3 (localhost.localdomain [127.0.0.1]) by mail273-va3 (MessageSwitch) id 1355408652794465_17073; Thu, 13 Dec 2012 14:24:12 +0000 (UTC) Received: from VA3EHSMHS010.bigfish.com (unknown [10.7.14.244]) by mail273-va3.bigfish.com (Postfix) with ESMTP id BB23A11002AC; Thu, 13 Dec 2012 14:24:12 +0000 (UTC) Received: from BN1PRD0512HT004.namprd05.prod.outlook.com (132.245.2.21) by VA3EHSMHS010.bigfish.com (10.7.99.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 13 Dec 2012 14:24:11 +0000 Received: from evazhang-sslvpn-nc.jnpr.net (66.129.224.36) by pod51010.outlook.com (10.255.193.37) with Microsoft SMTP Server (TLS) id 14.16.245.2; Thu, 13 Dec 2012 14:24:10 +0000 Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Hannes Gredler In-Reply-To: <50C9BFC8.1040901@cisco.com> Date: Thu, 13 Dec 2012 15:24:04 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <985BF299-1BB7-4B35-9795-842F1781DF12@juniper.net> <50C8B203.2070503@cisco.com> <50C9BFC8.1040901@cisco.com> To: X-Mailer: Apple Mail (2.1283) X-Originating-IP: [66.129.224.36] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:33:29 -0000 On Dec 13, 2012, at 12:45 PM, Stewart Bryant wrote: > On 12/12/2012 16:34, Peter Psenak wrote: >> Hannes, >>=20 >> On 12.12.2012 17:05, Hannes Gredler wrote: >>=20 >>> in favor of explicit advertisement, i'd rather do 3 rules here : >>>=20 >>> 1. PQ node OSPF router-id, if it is advertised as /32 prefix by the = PQ node itself >>> 2. PQ node TE adress, if it is advertised as /32 prefix by the PQ = node itself >>> 3. Highest /32 address advertised by PQ node in it's Router LSA >>=20 >> ether (1) or (3) is mandatory for the t-LDP session creation. (2) is = optional and not sufficient for t-LDP session, so we can not have it = before (3). >>=20 >> It looks to me we are trying to solve the configuration problem which = should not be addressed here. >=20 > I am inclined to agree, and note that the draft is tunnel independent. >=20 > We may want a deployment guidelines document, or some protocol = specific text in another document, but this draft can stand alone = without this text. stewart, do you think that the automated bringup of T-LDP sessions is generic enough to warrant for a new draft ? IMO this problem is specific to R-LFA deployment in LDP networks and hence should be added to the remote-lfa draft. /hannes From ppsenak@cisco.com Thu Dec 13 06:36:12 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C77F21F8960 for ; Thu, 13 Dec 2012 06:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hr2EYnSAqHsn for ; Thu, 13 Dec 2012 06:36:11 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5E80621F88F4 for ; Thu, 13 Dec 2012 06:36:11 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBDEVUqG025690 for ; Thu, 13 Dec 2012 15:31:30 +0100 (CET) Received: from Peter-Psenaks-MacBook-Pro.local ([10.148.128.94]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBDEVSoU002433; Thu, 13 Dec 2012 15:31:28 +0100 (CET) Message-ID: <50C9E6C0.4030607@cisco.com> Date: Thu, 13 Dec 2012 15:31:28 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Hannes Gredler Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <50C9BF46.4060509@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: rtgwg@ietf.org, stbryant@cisco.com X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:36:12 -0000 Hannes, On 13.12.2012 15:21, Hannes Gredler wrote: > > On Dec 13, 2012, at 12:43 PM, Stewart Bryant wrote: > > [ … ] > >>> can we say that the PQ node address used for targeted LDP session is selected in following order of preference: >>> >>> 1. PQ node OSPF router-id, if it is advertised as /32 prefix by the PQ node itself >>> >>> 2. Highest /32 address advertised by PQ node in it's Router LSA >> Why do we need (2). What do we do if an interface cycles? >> >> Surely the most we should say is that we SHOULD establish a TLDP session with the >> OSPF router-id, if it is advertised as /32 prefix by the PQ node itself, else any >> other IP address for the node may be used. > > other implementations may not be willing to accept T-LDP sessions on non-loopback > adresses. how do you suggest to distinguish between /32 belonging to the loopback from /32 belonging to other interface types? thanks, Peter > > /hannes > > From ppsenak@cisco.com Thu Dec 13 06:36:17 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCAD21F88F4 for ; Thu, 13 Dec 2012 06:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZhHUNlUVu4w for ; Thu, 13 Dec 2012 06:36:17 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id CA14E21F8AF9 for ; Thu, 13 Dec 2012 06:36:16 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBDEPPFo024963 for ; Thu, 13 Dec 2012 15:25:26 +0100 (CET) Received: from Peter-Psenaks-MacBook-Pro.local ([10.148.128.94]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBDEPMP3024397; Thu, 13 Dec 2012 15:25:23 +0100 (CET) Message-ID: <50C9E552.9020100@cisco.com> Date: Thu, 13 Dec 2012 15:25:22 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: bruno.decraene@orange.com Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <985BF299-1BB7-4B35-9795-842F1781DF12@juniper.net> <50C8B203.2070503@cisco.com> <712_1355408500_50C9E474_712_170_1_53C29892C857584299CBF5D05346208A117B82@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <712_1355408500_50C9E474_712_170_1_53C29892C857584299CBF5D05346208A117B82@PEXCVZYM11.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "stbryant@cisco.com" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:36:17 -0000 Bruno, On 13.12.2012 15:21, bruno.decraene@orange.com wrote: > Peter, > >> From: Peter Psenak >> >> Hannes, >> >> On 12.12.2012 17:05, Hannes Gredler wrote: >> >>> in favor of explicit advertisement, i'd rather do 3 rules here : >>> >>> 1. PQ node OSPF router-id, if it is advertised as /32 prefix by the PQ node >> itself >>> 2. PQ node TE adress, if it is advertised as /32 prefix by the PQ node itself >>> 3. Highest /32 address advertised by PQ node in it's Router LSA >> >> ether (1) or (3) is mandatory for the t-LDP session creation. (2) is >> optional and not sufficient for t-LDP session, so we can not have it >> before (3). >> >> It looks to me we are trying to solve the configuration problem which >> should not be addressed here. > > It looks to me that we are trying to address the network management problem and deployability/interoperability in a multi-vendor network. > May be this can be done by configuration. In this case, could you please elaborate on what you propose? > Given that at least two routers (the PLR and the PQ) must agree on establishing the T-LDP session, there is a priori room for coordination. And given that a PLR (resp. PQ) needs to be able to use (resp. used) "any" PQ (resp. PLR), it seems useful that the same mechanism be shared by all PQs and PLRs, rathers than one relying on ISIS tag, another on order of IP addresses, another on static address range... > Hannes' request seems a relevant point to discuss on the mailing list and IMO the R-LFA draft should discuss this. > Even if the R-LFA proposition is not specific to a network environment (e.g. type of tunnels) the goal is to _deploy_ the R-LFA proposition. And that deployment will be a specific environment, where this is expected to work. I also think MPLS tunnels (LSPs) established by LDP seems a reasonably popular target deployment. > > Unless it is believed that a local algorithm, without coordination between routers/vendor, can work in 100% of the cases. Is this your point? local algorithm that picks any of the /32 IP addresses advertised by PQ node will work in 100% of cases. thanks, Peter > > Thanks, > Regards, > Bruno > >> thanks, >> Peter >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > > From bruno.decraene@orange.com Thu Dec 13 06:50:16 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAE521F8AA6 for ; Thu, 13 Dec 2012 06:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYo94tPR6iTa for ; Thu, 13 Dec 2012 06:50:15 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 196E221F8A97 for ; Thu, 13 Dec 2012 06:50:15 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 673793B4482; Thu, 13 Dec 2012 15:50:14 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 3AA2A238061; Thu, 13 Dec 2012 15:50:14 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Thu, 13 Dec 2012 15:50:13 +0100 From: To: Peter Psenak Subject: RE: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 Thread-Topic: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 Thread-Index: AQHN2T2yykmOINJBJ0yJfqhi9c5+L5gWzxBQ Date: Thu, 13 Dec 2012 14:50:12 +0000 Message-ID: <21570_1355410214_50C9EB26_21570_746_1_53C29892C857584299CBF5D05346208A117C74@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <985BF299-1BB7-4B35-9795-842F1781DF12@juniper.net> <50C8B203.2070503@cisco.com> <712_1355408500_50C9E474_712_170_1_53C29892C857584299CBF5D05346208A117B82@PEXCVZYM11.corporate.adroot.infra.ftgroup> <50C9E552.9020100@cisco.com> In-Reply-To: <50C9E552.9020100@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: "stbryant@cisco.com" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:50:16 -0000 Peter, >From: Peter Psenak [mailto:ppsenak@cisco.com] >Sent: Thursday, December 13= , 2012 3:25 PM > >Bruno, > >On 13.12.2012 15:21, bruno.decraene@orange.com wrote: >> Peter, >> >>> From: Peter Psenak >>> >>> Hannes, >>> >>> On 12.12.2012 17:05, Hannes Gredler wrote: >>> >>>> in favor of explicit advertisement, i'd rather do 3 rules here : >>>> >>>> 1. PQ node OSPF router-id, if it is advertised as /32 prefix by the PQ= node >>> itself >>>> 2. PQ node TE adress, if it is advertised as /32 prefix by the PQ node >itself >>>> 3. Highest /32 address advertised by PQ node in it's Router LSA >>> >>> ether (1) or (3) is mandatory for the t-LDP session creation. (2) is >>> optional and not sufficient for t-LDP session, so we can not have it >>> before (3). >>> >>> It looks to me we are trying to solve the configuration problem which >>> should not be addressed here. >> >> It looks to me that we are trying to address the network management prob= lem >and deployability/interoperability in a multi-vendor network. >> May be this can be done by configuration. In this case, could you please >elaborate on what you propose? >> Given that at least two routers (the PLR and the PQ) must agree on >establishing the T-LDP session, there is a priori room for coordination. A= nd >given that a PLR (resp. PQ) needs to be able to use (resp. used) "any" PQ >(resp. PLR), it seems useful that the same mechanism be shared by all PQs = and >PLRs, rathers than one relying on ISIS tag, another on order of IP address= es, >another on static address range... >> Hannes' request seems a relevant point to discuss on the mailing list an= d IMO >the R-LFA draft should discuss this. >> Even if the R-LFA proposition is not specific to a network environment (= e.g. >type of tunnels) the goal is to _deploy_ the R-LFA proposition. And that >deployment will be a specific environment, where this is expected to work.= I >also think MPLS tunnels (LSPs) established by LDP seems a reasonably popul= ar >target deployment. >> >> Unless it is believed that a local algorithm, without coordination betwe= en >routers/vendor, can work in 100% of the cases. Is this your point? > >local algorithm that picks any of the /32 IP addresses advertised by PQ >node will work in 100% of cases. Does this include the case of an IS-IS L1/L2 router (ABR) redistributing in= to L2 the loopbacks of the routers in L1? >thanks, >Peter > >> >> Thanks, >> Regards, >> Bruno >> >>> thanks, >>> Peter >>> _______________________________________________ >>> rtgwg mailing list >>> rtgwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtgwg >> >> >__________________________________________________________________________= _____ >__________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu >ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >electroniques etant susceptibles d'alteration, >> France Telecom - Orange decline toute responsabilite si ce message a ete >altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete >this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for mess= ages >that have been modified, changed or falsified. >> Thank you. >> >> >> > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From ppsenak@cisco.com Thu Dec 13 06:57:06 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E1521F853B for ; Thu, 13 Dec 2012 06:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVjCzX97AcgY for ; Thu, 13 Dec 2012 06:57:06 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5B51221F8880 for ; Thu, 13 Dec 2012 06:57:04 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBDEv2XP028567 for ; Thu, 13 Dec 2012 15:57:03 +0100 (CET) Received: from Peter-Psenaks-MacBook-Pro.local ([10.148.128.94]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBDEuxg2000390; Thu, 13 Dec 2012 15:56:59 +0100 (CET) Message-ID: <50C9ECBB.4000303@cisco.com> Date: Thu, 13 Dec 2012 15:56:59 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: bruno.decraene@orange.com Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <985BF299-1BB7-4B35-9795-842F1781DF12@juniper.net> <50C8B203.2070503@cisco.com> <712_1355408500_50C9E474_712_170_1_53C29892C857584299CBF5D05346208A117B82@PEXCVZYM11.corporate.adroot.infra.ftgroup> <50C9E552.9020100@cisco.com> <21570_1355410214_50C9EB26_21570_746_1_53C29892C857584299CBF5D05346208A117C74@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <21570_1355410214_50C9EB26_21570_746_1_53C29892C857584299CBF5D05346208A117C74@PEXCVZYM11.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "stbryant@cisco.com" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:57:07 -0000 Bruno, On 13.12.2012 15:50, bruno.decraene@orange.com wrote: > Peter, >>> Unless it is believed that a local algorithm, without coordination between >> routers/vendor, can work in 100% of the cases. Is this your point? >> >> local algorithm that picks any of the /32 IP addresses advertised by PQ >> node will work in 100% of cases. > > Does this include the case of an IS-IS L1/L2 router (ABR) redistributing into L2 the loopbacks of the routers in L1? ISIS may have a specific problem of not distinguishing between intra/inter/external prefixes. For that case some local policy on the computing node can be used to pick the ones that will work for LDP. thanks, Peter > >> thanks, >> Peter >> >>> >>> Thanks, >>> Regards, >>> Bruno >>> >>>> thanks, >>>> Peter >>>> _______________________________________________ >>>> rtgwg mailing list >>>> rtgwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtgwg >>> >>> >> _______________________________________________________________________________ >> __________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu >> ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >>> France Telecom - Orange decline toute responsabilite si ce message a ete >> altere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >>> they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and delete >> this message and its attachments. >>> As emails may be altered, France Telecom - Orange is not liable for messages >> that have been modified, changed or falsified. >>> Thank you. >>> >>> >>> >> > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > > From akatlas@gmail.com Thu Dec 13 06:58:51 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05BB21F8B23 for ; Thu, 13 Dec 2012 06:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6dgxEMsclLY for ; Thu, 13 Dec 2012 06:58:51 -0800 (PST) Received: from mail-ia0-f176.google.com (mail-ia0-f176.google.com [209.85.210.176]) by ietfa.amsl.com (Postfix) with ESMTP id F0D5221F8B1C for ; Thu, 13 Dec 2012 06:58:50 -0800 (PST) Received: by mail-ia0-f176.google.com with SMTP id y26so2018645iab.21 for ; Thu, 13 Dec 2012 06:58:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LtXdg7IAF7bMBmf1uVbbRAX5cI325qWqRn8cIbAWGQM=; b=O8OQyhNpCEjH2/AbL5vuyHYzDDEEBWMz5EZuhtWfb1z6H6urBOYocfsuQnB9KQfstz zVxD6QeEYIyDfWfnCJU5W7kJ/czSP6tR09dTL+3bnoYIxwsEIhuafGYP2gOmEYwjgptI H6Td8WJip9zI94Oye0jUrGIOVS+RjUIBfM2zq6cYlwp04r0FqUzcRvehDPYnzKxk+WBS OunUzVDdCs7gbuSWnTca54r/GHJwxjB/+qPW8BUpy2c6cmR5DUSA69ARJiReiUqT1J1v Us28Ka/tnr99i1bZYG2X4XUzGaWPcA2JZ9Mg9d5FEvpIQZ7nzqi6Qx+eakR2CDGibXej 6AhA== MIME-Version: 1.0 Received: by 10.50.163.98 with SMTP id yh2mr17062337igb.2.1355410730433; Thu, 13 Dec 2012 06:58:50 -0800 (PST) Received: by 10.50.127.164 with HTTP; Thu, 13 Dec 2012 06:58:50 -0800 (PST) In-Reply-To: <50C9BFC8.1040901@cisco.com> References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <985BF299-1BB7-4B35-9795-842F1781DF12@juniper.net> <50C8B203.2070503@cisco.com> <50C9BFC8.1040901@cisco.com> Date: Thu, 13 Dec 2012 09:58:50 -0500 Message-ID: Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 From: Alia Atlas To: Stewart Bryant Content-Type: multipart/alternative; boundary=e89a8f642ec61cbced04d0bd275f Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:58:51 -0000 --e89a8f642ec61cbced04d0bd275f Content-Type: text/plain; charset=ISO-8859-1 Stewart, I think it would be good to have the remote-LFA draft discuss and recommend what addresses to use, what requirements there are on routers to make it work (for IP or LDP), and what protocol gaps are identified. What is necessary for the PQ node to know to handle terminating an IP tunnel at line rate? What is needed to consistently pick the tLDP address, etc.? Alia On Thu, Dec 13, 2012 at 6:45 AM, Stewart Bryant wrote: > On 12/12/2012 16:34, Peter Psenak wrote: > >> Hannes, >> >> On 12.12.2012 17:05, Hannes Gredler wrote: >> >> in favor of explicit advertisement, i'd rather do 3 rules here : >>> >>> 1. PQ node OSPF router-id, if it is advertised as /32 prefix by the PQ >>> node itself >>> 2. PQ node TE adress, if it is advertised as /32 prefix by the PQ node >>> itself >>> >>> 3. Highest /32 address advertised by PQ node in it's Router LSA >>> >> >> ether (1) or (3) is mandatory for the t-LDP session creation. (2) is >> optional and not sufficient for t-LDP session, so we can not have it before >> (3). >> >> It looks to me we are trying to solve the configuration problem which >> should not be addressed here. >> > > I am inclined to agree, and note that the draft is tunnel independent. > > We may want a deployment guidelines document, or some protocol specific > text in another document, but this draft can stand alone without this text. > > Stewart > > ______________________________**_________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/**listinfo/rtgwg > --e89a8f642ec61cbced04d0bd275f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Stewart,

I think it would be good to have the remote-LFA= draft discuss and recommend what addresses to use, what requirements there= are on routers to make it work (for IP or LDP), and what protocol gaps are= identified. =A0 What is necessary for the PQ node to know to handle termin= ating an IP tunnel at line rate? =A0What is needed to consistently pick the= tLDP address, etc.?

Alia


On Thu, Dec 13, 2012 at 6:45 AM, Stewart Bryant <stbrya= nt@cisco.com> wrote:
On 12/12/2012 16:34, Peter= Psenak wrote:
Hannes,

On 12.12.2012 17:05, Hannes Gredler wrote:

in favor of explicit advertisement, i'd rather do 3 rules here :

1. PQ node OSPF router-id, if it is advertised as /32 prefix by the PQ node= itself
2. PQ node TE adress, if it is advertised as /32 prefix by the PQ node itse= lf

3. =A0Highest /32 address advertised by PQ node in it's Router LSA

ether (1) or (3) is mandatory for the t-LDP session creation. (2) is option= al and not sufficient for t-LDP session, so we can not have it before (3).<= br>
It looks to me we are trying to solve the configuration problem which shoul= d not be addressed here.

I am inclined to agree, and note that the draft is tunnel independent.

We may want a deployment guidelines document, or some protocol specific tex= t in another document, but this draft can stand alone without this text.

Stewart

_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/rtgwg

--e89a8f642ec61cbced04d0bd275f-- From akatlas@gmail.com Thu Dec 13 07:03:30 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4EA621F89AB for ; Thu, 13 Dec 2012 07:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5qf3KskFnBj for ; Thu, 13 Dec 2012 07:03:29 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by ietfa.amsl.com (Postfix) with ESMTP id 95E7E21F88F3 for ; Thu, 13 Dec 2012 07:03:28 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id c10so3966864ieb.25 for ; Thu, 13 Dec 2012 07:03:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OVa5TNAx/fjBytOQw74SUhDlChrX9MHgOiHBHqLJ3JE=; b=XNg4ZvciPvYY38T+hRfvwW4iYVbTKjQbDaKLb367EpteZhK1+A4SzotZRxNIR1ZyoP h784fD9ZVcHAxKMpd6/KVtxjLSEDFY2MBpGJPvg7kItf6PzP+gnBtNg4K1Zq4DcuUQVj 6NBNjnyQxvEMLi9dpaQxOj0RrLxo/OjeiAsZqd6SAzfjwgGMJ8kYU0jFfMltms2kqVrU dASDnikozNz+Di4JaSdwbCue5dYo+MdhMVTpSwkrtixp/s3u2dYJT6LfewhhSu+E3r2z o6G+kixoB5ExNckb6H/L55aLHl75E3YYNI+k/uLrpqt66LB5ERrWdv4Cb70lVXQh6Gg6 3hNA== MIME-Version: 1.0 Received: by 10.50.12.138 with SMTP id y10mr16874292igb.58.1355411008209; Thu, 13 Dec 2012 07:03:28 -0800 (PST) Received: by 10.50.127.164 with HTTP; Thu, 13 Dec 2012 07:03:28 -0800 (PST) In-Reply-To: <50C9ECBB.4000303@cisco.com> References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <985BF299-1BB7-4B35-9795-842F1781DF12@juniper.net> <50C8B203.2070503@cisco.com> <712_1355408500_50C9E474_712_170_1_53C29892C857584299CBF5D05346208A117B82@PEXCVZYM11.corporate.adroot.infra.ftgroup> <50C9E552.9020100@cisco.com> <21570_1355410214_50C9EB26_21570_746_1_53C29892C857584299CBF5D05346208A117C74@PEXCVZYM11.corporate.adroot.infra.ftgroup> <50C9ECBB.4000303@cisco.com> Date: Thu, 13 Dec 2012 10:03:28 -0500 Message-ID: Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 From: Alia Atlas To: Peter Psenak Content-Type: multipart/alternative; boundary=14dae9340517ab421b04d0bd3785 Cc: "rtgwg@ietf.org" , "stbryant@cisco.com" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 15:03:31 -0000 --14dae9340517ab421b04d0bd3785 Content-Type: text/plain; charset=ISO-8859-1 Peter, One of the goals of LFA & remote-LFA is for ease of manageability. Why are you pushing for requiring additional configuration, which I don't see as adding any benefit from the flexibility, instead of documenting the straightforward rules for automatic interoperabiity? Alia On Thu, Dec 13, 2012 at 9:56 AM, Peter Psenak wrote: > Bruno, > > On 13.12.2012 15:50, bruno.decraene@orange.com wrote: > >> Peter, >> >> Unless it is believed that a local algorithm, without coordination >>>> between >>>> >>> routers/vendor, can work in 100% of the cases. Is this your point? >>> >>> local algorithm that picks any of the /32 IP addresses advertised by PQ >>> node will work in 100% of cases. >>> >> >> Does this include the case of an IS-IS L1/L2 router (ABR) redistributing >> into L2 the loopbacks of the routers in L1? >> > > ISIS may have a specific problem of not distinguishing between > intra/inter/external prefixes. For that case some local policy on the > computing node can be used to pick the ones that will work for LDP. > > thanks, > Peter > > > >> thanks, >>> Peter >>> >>> >>>> Thanks, >>>> Regards, >>>> Bruno >>>> >>>> thanks, >>>>> Peter >>>>> ______________________________**_________________ >>>>> rtgwg mailing list >>>>> rtgwg@ietf.org >>>>> https://www.ietf.org/mailman/**listinfo/rtgwg >>>>> >>>> >>>> >>>> ______________________________**______________________________** >>> ___________________ >>> ______________________________**____________ >>> >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> >>> confidentielles ou privilegiees et ne doivent donc >>> >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>>> recu >>>> >>> ce message par erreur, veuillez le signaler >>> >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >>>> >>> electroniques etant susceptibles d'alteration, >>> >>>> France Telecom - Orange decline toute responsabilite si ce message a ete >>>> >>> altere, deforme ou falsifie. Merci. >>> >>>> >>>> This message and its attachments may contain confidential or privileged >>>> >>> information that may be protected by law; >>> >>>> they should not be distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender and >>>> delete >>>> >>> this message and its attachments. >>> >>>> As emails may be altered, France Telecom - Orange is not liable for >>>> messages >>>> >>> that have been modified, changed or falsified. >>> >>>> Thank you. >>>> >>>> >>>> >>>> >>> >> >> ______________________________**______________________________** >> ______________________________**______________________________**_ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >> recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> France Telecom - Orange decline toute responsabilite si ce message a ete >> altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for >> messages that have been modified, changed or falsified. >> Thank you. >> >> >> >> > > ______________________________**_________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/**listinfo/rtgwg > --14dae9340517ab421b04d0bd3785 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Peter,

One of the goals of LFA & remote-LFA is for e= ase of manageability. =A0Why are you pushing for requiring additional confi= guration, which I don't see as adding any benefit from the flexibility,= instead of documenting the straightforward rules for automatic interoperab= iity?

Alia


On Thu, Dec 13, 2012 at 9:56 AM, Peter Psenak <ppsenak@ci= sco.com> wrote:
Bruno,

On 13.12.2012 15:50, bruno.decraene@orange.com wrote:
Peter,

Unless it is believed that a local algorithm, without coordination between<= br>
routers/vendor, can work in 100% of the cases. Is this your point?

local algorithm that picks any of the /32 IP addresses advertised by PQ
node will work in 100% of cases.

Does this include the case of an IS-IS L1/L2 router (ABR) redistributing in= to L2 the loopbacks of the routers in L1?

ISIS may have a specific problem of not distinguishing between intra/inter/= external prefixes. For that case some local policy on the computing node ca= n be used to pick the ones that will work for LDP.

thanks,
Peter



thanks,
Peter


Thanks,
Regards,
Bruno

thanks,
Peter
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/rtgwg


_____________________________________________________________= __________________
__________________________________________

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s
electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete
altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te
this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message= s
that have been modified, changed or falsified.
Thank you.






_____________________________________________________________= ____________________________________________________________<= br>
Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified.
Thank you.





_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/rtgwg

--14dae9340517ab421b04d0bd3785-- From hannes@juniper.net Thu Dec 13 07:04:20 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BA021F8B44 for ; Thu, 13 Dec 2012 07:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uQUXOIJhJgW for ; Thu, 13 Dec 2012 07:04:19 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 899FF21F894D for ; Thu, 13 Dec 2012 07:04:19 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUMnuc0TnsFY4Hc1nsxwil9y1fUetWLF8@postini.com; Thu, 13 Dec 2012 07:04:19 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 13 Dec 2012 07:01:21 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Thu, 13 Dec 2012 07:01:20 -0800 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.186) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 13 Dec 2012 07:08:53 -0800 Received: from mail89-ch1-R.bigfish.com (10.43.68.234) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.23; Thu, 13 Dec 2012 15:01:19 +0000 Received: from mail89-ch1 (localhost [127.0.0.1]) by mail89-ch1-R.bigfish.com (Postfix) with ESMTP id BECAE80219 for ; Thu, 13 Dec 2012 15:01:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.242.197; KIP:(null); UIP:(null); (null); H:BL2PRD0512HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -24 X-BigFish: PS-24(zz98dI9371I1432I4015Izz1de0h1202h1e76h1d1ah1d2ahzz8275bh8275dh1033ILz2dh2a8h668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1155h) Received: from mail89-ch1 (localhost.localdomain [127.0.0.1]) by mail89-ch1 (MessageSwitch) id 1355410844451893_9201; Thu, 13 Dec 2012 15:00:44 +0000 (UTC) Received: from CH1EHSMHS013.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.233]) by mail89-ch1.bigfish.com (Postfix) with ESMTP id 5E1BD10007A; Thu, 13 Dec 2012 15:00:44 +0000 (UTC) Received: from BL2PRD0512HT004.namprd05.prod.outlook.com (157.56.242.197) by CH1EHSMHS013.bigfish.com (10.43.70.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 13 Dec 2012 15:00:42 +0000 Received: from evazhang-sslvpn-nc.jnpr.net (66.129.224.51) by pod51010.outlook.com (10.255.233.37) with Microsoft SMTP Server (TLS) id 14.16.245.2; Thu, 13 Dec 2012 15:00:41 +0000 Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="iso-8859-1" From: Hannes Gredler In-Reply-To: <50C9ECBB.4000303@cisco.com> Date: Thu, 13 Dec 2012 16:00:34 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: <55D2A355-8B4E-460E-9E7C-56B21CC2FEEC@juniper.net> References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <985BF299-1BB7-4B35-9795-842F1781DF12@juniper.net> <50C8B203.2070503@cisco.com> <712_1355408500_50C9E474_712_170_1_53C29892C857584299CBF5D05346208A117B82@PEXCVZYM11.corporate.adroot.infra.ftgroup> <50C9E552.9020100@cisco.com> <21570_1355410214_50C9EB26_21570_746_1_53C29892C857584299CBF5D05346208A117C74@PEXCVZYM11.corporate.adroot.infra.ftgroup> <50C9ECBB.4000303@cisco.com> To: Peter Psenak X-Mailer: Apple Mail (2.1283) X-Originating-IP: [66.129.224.51] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ORANGE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "stbryant@cisco.com" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 15:04:20 -0000 On Dec 13, 2012, at 3:56 PM, Peter Psenak wrote: > Bruno, >=20 > On 13.12.2012 15:50, bruno.decraene@orange.com wrote: >> Peter, >>>> Unless it is believed that a local algorithm, without coordination = between >>> routers/vendor, can work in 100% of the cases. Is this your point? >>>=20 >>> local algorithm that picks any of the /32 IP addresses advertised by = PQ >>> node will work in 100% of cases. >>=20 >> Does this include the case of an IS-IS L1/L2 router (ABR) = redistributing into L2 the loopbacks of the routers in L1? >=20 > ISIS may have a specific problem of not distinguishing between = intra/inter/external prefixes. > For that case some local policy on the computing node can be used to = pick the ones that will work for LDP. that would require explicit configuration and i am sure we can do = smarter than that ;-) >>=20 >>> thanks, >>> Peter >>>=20 >>>>=20 >>>> Thanks, >>>> Regards, >>>> Bruno >>>>=20 >>>>> thanks, >>>>> Peter >>>>> _______________________________________________ >>>>> rtgwg mailing list >>>>> rtgwg@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtgwg >>>>=20 >>>>=20 >>> = __________________________________________________________________________= _____ >>> __________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu >>> ce message par erreur, veuillez le signaler >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages >>> electroniques etant susceptibles d'alteration, >>>> France Telecom - Orange decline toute responsabilite si ce message = a ete >>> altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or = privileged >>> information that may be protected by law; >>>> they should not be distributed, used or copied without = authorisation. >>>> If you have received this email in error, please notify the sender = and delete >>> this message and its attachments. >>>> As emails may be altered, France Telecom - Orange is not liable for = messages >>> that have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >> France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or = privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. >> Thank you. >>=20 >>=20 >>=20 >=20 >=20 >=20 From hannes@juniper.net Thu Dec 13 07:04:21 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE1621F8B4B for ; Thu, 13 Dec 2012 07:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.344 X-Spam-Level: X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrvx1tdpaVGV for ; Thu, 13 Dec 2012 07:04:21 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 02A9F21F8B47 for ; Thu, 13 Dec 2012 07:04:20 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUMnudLZyc8BMgu+Z6lrfaiDuiZnXEhbT@postini.com; Thu, 13 Dec 2012 07:04:21 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 13 Dec 2012 06:58:03 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Thu, 13 Dec 2012 06:58:03 -0800 Received: from db3outboundpool.messaging.microsoft.com (213.199.154.140) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 13 Dec 2012 07:05:36 -0800 Received: from mail84-db3-R.bigfish.com (10.3.81.246) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 13 Dec 2012 14:58:00 +0000 Received: from mail84-db3 (localhost [127.0.0.1]) by mail84-db3-R.bigfish.com (Postfix) with ESMTP id CF271E0244 for ; Thu, 13 Dec 2012 14:58:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); (null); H:BLUPRD0512HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -5 X-BigFish: PS-5(zz98dI9371I168aJ1432Izz1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h946hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1155h) Received: from mail84-db3 (localhost.localdomain [127.0.0.1]) by mail84-db3 (MessageSwitch) id 1355410678902116_17805; Thu, 13 Dec 2012 14:57:58 +0000 (UTC) Received: from DB3EHSMHS016.bigfish.com (unknown [10.3.81.245]) by mail84-db3.bigfish.com (Postfix) with ESMTP id CD93020024E; Thu, 13 Dec 2012 14:57:58 +0000 (UTC) Received: from BLUPRD0512HT001.namprd05.prod.outlook.com (132.245.1.149) by DB3EHSMHS016.bigfish.com (10.3.87.116) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 13 Dec 2012 14:57:58 +0000 Received: from evazhang-sslvpn-nc.jnpr.net (66.129.224.36) by pod51010.outlook.com (10.255.215.162) with Microsoft SMTP Server (TLS) id 14.16.245.2; Thu, 13 Dec 2012 14:57:57 +0000 Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Hannes Gredler In-Reply-To: <50C9E6C0.4030607@cisco.com> Date: Thu, 13 Dec 2012 15:57:51 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <50C9BF46.4060509@cisco.com> <50C9E6C0.4030607@cisco.com> To: Peter Psenak X-Mailer: Apple Mail (2.1283) X-Originating-IP: [66.129.224.36] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: rtgwg@ietf.org, stbryant@cisco.com X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 15:04:21 -0000 On Dec 13, 2012, at 3:31 PM, Peter Psenak wrote: > Hannes, >=20 > On 13.12.2012 15:21, Hannes Gredler wrote: >>=20 >> On Dec 13, 2012, at 12:43 PM, Stewart Bryant wrote: >>=20 >> [ =85 ] >>=20 >>>> can we say that the PQ node address used for targeted LDP session = is selected in following order of preference: >>>>=20 >>>> 1. PQ node OSPF router-id, if it is advertised as /32 prefix by the = PQ node itself >>>>=20 >>>> 2. Highest /32 address advertised by PQ node in it's Router LSA >>> Why do we need (2). What do we do if an interface cycles? >>>=20 >>> Surely the most we should say is that we SHOULD establish a TLDP = session with the >>> OSPF router-id, if it is advertised as /32 prefix by the PQ node = itself, else any >>> other IP address for the node may be used. >>=20 >> other implementations may not be willing to accept T-LDP sessions on = non-loopback >> adresses. >=20 > how do you suggest to distinguish between /32 belonging to the = loopback from /32 belonging to other interface types? for OSPF traffic engineering deployments: - if a /32 stub route advertisement of a type-1 LSA matches the TE = router address TLV in the type-10 LSA for OSPF non-traffic engineering deployments: - if a /32 stub route advertisement of a type-1 LSA matches the = router-id in the LS header for IS-IS traffic-engineering deployments: - if a /32 reported in any IP Reach TLVs (128,135, 235) matches the TE-router ID TLV 134 =20 for non IS-IS traffic-engineering deployments: - if a /32 reported in any IP Reach TLVs (128,135, 235) matches the - IP interface address TLV 132 (and this is the only IP interface = address TLV advertisement) From ppsenak@cisco.com Thu Dec 13 07:10:22 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647EE21F8B5A for ; Thu, 13 Dec 2012 07:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4dx-C5YfslO for ; Thu, 13 Dec 2012 07:10:20 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4E27421F8B54 for ; Thu, 13 Dec 2012 07:10:20 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBDFAJSZ000056 for ; Thu, 13 Dec 2012 16:10:19 +0100 (CET) Received: from Peter-Psenaks-MacBook-Pro.local ([10.148.128.94]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBDFAGfb013245; Thu, 13 Dec 2012 16:10:16 +0100 (CET) Message-ID: <50C9EFD7.8050906@cisco.com> Date: Thu, 13 Dec 2012 16:10:15 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Hannes Gredler Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <985BF299-1BB7-4B35-9795-842F1781DF12@juniper.net> <50C8B203.2070503@cisco.com> <712_1355408500_50C9E474_712_170_1_53C29892C857584299CBF5D05346208A117B82@PEXCVZYM11.corporate.adroot.infra.ftgroup> <50C9E552.9020100@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "stbryant@cisco.com" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 15:10:22 -0000 Hannes, On 13.12.2012 15:31, Hannes Gredler wrote: > peter, > > two questions: > > 1) how do you know that the other side will be accepting the T-LDP session at a non loopback IP address ? I'm proposing to use OSPF router-id as a first choice. In any reasonable deployment, that address belongs to loopback interface. If OSPF router-id can not be used, then there is no way currently to tell which of the /32s advertised by PQ node belong to loopbacks. Operator have two choices: - make sure that the highest /32 address advertised by PQ node is a loopback address - use some local policy on the calculating node to pick the address on the PQ node that work with LDP. > 2) what is your proposed scheme for minimizing the amount of T-LDP sessions between a pair of routers ? I do not see how the IP address used for T-LDP peering makes an impact on the number of LDP sessions used for rLFA between any pair of routers. There should only be one session used for rLFA between any pair of routers. thanks, Peter > (is it numerically highest IP ?) > > /hannes > >>> >>> Thanks, >>> Regards, >>> Bruno >>> >>>> thanks, >>>> Peter >>>> _______________________________________________ >>>> rtgwg mailing list >>>> rtgwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtgwg >>> >>> _________________________________________________________________________________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, >>> France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or privileged information that may be protected by law; >>> they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and delete this message and its attachments. >>> As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >>> Thank you. >>> >>> >>> >> >> >> > > > > From ppsenak@cisco.com Thu Dec 13 07:13:38 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA21121F8B1C for ; Thu, 13 Dec 2012 07:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkOzbosor6x1 for ; Thu, 13 Dec 2012 07:13:38 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 12B1B21F8B12 for ; Thu, 13 Dec 2012 07:13:37 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBDFDUmx000425 for ; Thu, 13 Dec 2012 16:13:30 +0100 (CET) Received: from Peter-Psenaks-MacBook-Pro.local ([10.148.128.94]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBDFDS51016310; Thu, 13 Dec 2012 16:13:28 +0100 (CET) Message-ID: <50C9F098.1020703@cisco.com> Date: Thu, 13 Dec 2012 16:13:28 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Hannes Gredler Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <50C9BF46.4060509@cisco.com> <50C9E6C0.4030607@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: rtgwg@ietf.org, stbryant@cisco.com X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 15:13:39 -0000 Hannes, On 13.12.2012 15:57, Hannes Gredler wrote: > > On Dec 13, 2012, at 3:31 PM, Peter Psenak wrote: > >> Hannes, >> >> On 13.12.2012 15:21, Hannes Gredler wrote: >>> >>> On Dec 13, 2012, at 12:43 PM, Stewart Bryant wrote: >>> >>> [ … ] >>> >>>>> can we say that the PQ node address used for targeted LDP session is selected in following order of preference: >>>>> >>>>> 1. PQ node OSPF router-id, if it is advertised as /32 prefix by the PQ node itself >>>>> >>>>> 2. Highest /32 address advertised by PQ node in it's Router LSA >>>> Why do we need (2). What do we do if an interface cycles? >>>> >>>> Surely the most we should say is that we SHOULD establish a TLDP session with the >>>> OSPF router-id, if it is advertised as /32 prefix by the PQ node itself, else any >>>> other IP address for the node may be used. >>> >>> other implementations may not be willing to accept T-LDP sessions on non-loopback >>> adresses. >> >> how do you suggest to distinguish between /32 belonging to the loopback from /32 belonging to other interface types? > > for OSPF traffic engineering deployments: > - if a /32 stub route advertisement of a type-1 LSA matches the TE router address TLV in the type-10 LSA are we only allowed to advertise loopbacks in the TE TLV? > > for OSPF non-traffic engineering deployments: > - if a /32 stub route advertisement of a type-1 LSA matches the router-id in the LS header does not work if the router-id is not advertised by the node as a stub-link, which is a valid case. thanks, Peter > > for IS-IS traffic-engineering deployments: > - if a /32 reported in any IP Reach TLVs (128,135, 235) matches the > TE-router ID TLV 134 > > for non IS-IS traffic-engineering deployments: > - if a /32 reported in any IP Reach TLVs (128,135, 235) matches the > - IP interface address TLV 132 (and this is the only IP interface address TLV advertisement) > > > > From ppsenak@cisco.com Thu Dec 13 07:18:24 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B369C21F8B52 for ; Thu, 13 Dec 2012 07:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYGWP+Vbl73F for ; Thu, 13 Dec 2012 07:18:24 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 970EE21F86C2 for ; Thu, 13 Dec 2012 07:18:23 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBDFIMTb000913 for ; Thu, 13 Dec 2012 16:18:22 +0100 (CET) Received: from Peter-Psenaks-MacBook-Pro.local ([10.148.128.94]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBDFIJiS020344; Thu, 13 Dec 2012 16:18:19 +0100 (CET) Message-ID: <50C9F1BB.8030300@cisco.com> Date: Thu, 13 Dec 2012 16:18:19 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Alia Atlas Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <985BF299-1BB7-4B35-9795-842F1781DF12@juniper.net> <50C8B203.2070503@cisco.com> <712_1355408500_50C9E474_712_170_1_53C29892C857584299CBF5D05346208A117B82@PEXCVZYM11.corporate.adroot.infra.ftgroup> <50C9E552.9020100@cisco.com> <21570_1355410214_50C9EB26_21570_746_1_53C29892C857584299CBF5D05346208A117C74@PEXCVZYM11.corporate.adroot.infra.ftgroup> <50C9ECBB.4000303@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtgwg@ietf.org" , "stbryant@cisco.com" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 15:18:24 -0000 Alia, On 13.12.2012 16:03, Alia Atlas wrote: > Peter, > > One of the goals of LFA & remote-LFA is for ease of manageability. Why > are you pushing for requiring additional configuration, which I don't > see as adding any benefit from the flexibility, instead of documenting > the straightforward rules for automatic interoperabiity? for most of the deployments, no config is required and picking the router-id or highest /32 address advertised by PQ node will work fine. For those cases where above does not work, there are no magic rules that will make it work in all cases. We would need a protocol extension to guarantee it. thanks, Peter > > Alia > > > On Thu, Dec 13, 2012 at 9:56 AM, Peter Psenak > wrote: > > Bruno, > > On 13.12.2012 15:50, bruno.decraene@orange.com > wrote: > > Peter, > > Unless it is believed that a local algorithm, without > coordination between > > routers/vendor, can work in 100% of the cases. Is this your > point? > > local algorithm that picks any of the /32 IP addresses > advertised by PQ > node will work in 100% of cases. > > > Does this include the case of an IS-IS L1/L2 router (ABR) > redistributing into L2 the loopbacks of the routers in L1? > > > ISIS may have a specific problem of not distinguishing between > intra/inter/external prefixes. For that case some local policy on > the computing node can be used to pick the ones that will work for LDP. > > thanks, > Peter > > > > thanks, > Peter > > > Thanks, > Regards, > Bruno > > thanks, > Peter > _________________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/__listinfo/rtgwg > > > > > ___________________________________________________________________________________ > ____________________________________________ > > > Ce message et ses pieces jointes peuvent contenir des > informations > > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans > autorisation. Si vous avez recu > > ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces > jointes. Les messages > > electroniques etant susceptibles d'alteration, > > France Telecom - Orange decline toute responsabilite si > ce message a ete > > altere, deforme ou falsifie. Merci. > > > This message and its attachments may contain > confidential or privileged > > information that may be protected by law; > > they should not be distributed, used or copied without > authorisation. > If you have received this email in error, please notify > the sender and delete > > this message and its attachments. > > As emails may be altered, France Telecom - Orange is not > liable for messages > > that have been modified, changed or falsified. > > Thank you. > > > > > > > _________________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des > informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si > vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce > message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; > they should not be distributed, used or copied without > authorisation. > If you have received this email in error, please notify the > sender and delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable > for messages that have been modified, changed or falsified. > Thank you. > > > > > > _________________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/__listinfo/rtgwg > > > From akatlas@gmail.com Thu Dec 13 08:04:14 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1638921F8B9F for ; Thu, 13 Dec 2012 08:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KouPnC+MyudS for ; Thu, 13 Dec 2012 08:04:13 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 157BC21F8B18 for ; Thu, 13 Dec 2012 08:04:13 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so4238054ieb.31 for ; Thu, 13 Dec 2012 08:04:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l0yrwfFtaoWvOZEEsE+M463GgtjpOh/OeSt3Mo9ieEo=; b=UQGI0mQQ8S4g+BkFrnlTOnbqo+tkn9DDFL77O4k27A1g0QV6rHXc/ntrWNW1x0Ynyq LuFkdXENyQ3FvHHxjZjOdQMko5QKraA24dhaXcE6A46Q/SHmxKeQ/4II1X0zIRcFQinL GuRalPD+XxVtWOVRcEGx0zAZJXOKwfsLHinfFw9qYXeuL7pmSaleT9nPVE6acDC8rvbf yoiJMpQ1w58whWHjmBPHVgHwX4cu9viHYcYyuilqLPgH2BAymIvqkH4Dk+VrsS57K6sj c9ANK4hFF65ATD2hNp3xVTjeW11lYgwhJpWY/wZ5qCpwZuYBh8LLfAQIf61bue6SXIO5 BabQ== MIME-Version: 1.0 Received: by 10.42.101.66 with SMTP id d2mr1891425ico.11.1355414652659; Thu, 13 Dec 2012 08:04:12 -0800 (PST) Received: by 10.50.127.164 with HTTP; Thu, 13 Dec 2012 08:04:12 -0800 (PST) In-Reply-To: <50C9F1BB.8030300@cisco.com> References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <985BF299-1BB7-4B35-9795-842F1781DF12@juniper.net> <50C8B203.2070503@cisco.com> <712_1355408500_50C9E474_712_170_1_53C29892C857584299CBF5D05346208A117B82@PEXCVZYM11.corporate.adroot.infra.ftgroup> <50C9E552.9020100@cisco.com> <21570_1355410214_50C9EB26_21570_746_1_53C29892C857584299CBF5D05346208A117C74@PEXCVZYM11.corporate.adroot.infra.ftgroup> <50C9ECBB.4000303@cisco.com> <50C9F1BB.8030300@cisco.com> Date: Thu, 13 Dec 2012 11:04:12 -0500 Message-ID: Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 From: Alia Atlas To: Peter Psenak Content-Type: multipart/alternative; boundary=bcaec53143b5e529f904d0be10de Cc: "rtgwg@ietf.org" , "stbryant@cisco.com" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:04:14 -0000 --bcaec53143b5e529f904d0be10de Content-Type: text/plain; charset=ISO-8859-1 Peter, Then the draft should document that & the need for additional protocol extensions if certainty is desired. Then, there is the appropriate clarity & if a protocol extensions draft is needed it can be considered in the correct WG. Alia On Thu, Dec 13, 2012 at 10:18 AM, Peter Psenak wrote: > Alia, > > > On 13.12.2012 16:03, Alia Atlas wrote: > >> Peter, >> >> One of the goals of LFA & remote-LFA is for ease of manageability. Why >> are you pushing for requiring additional configuration, which I don't >> see as adding any benefit from the flexibility, instead of documenting >> the straightforward rules for automatic interoperabiity? >> > > for most of the deployments, no config is required and picking the > router-id or highest /32 address advertised by PQ node will work fine. > > For those cases where above does not work, there are no magic rules that > will make it work in all cases. We would need a protocol extension to > guarantee it. > > thanks, > Peter > > >> Alia >> >> >> On Thu, Dec 13, 2012 at 9:56 AM, Peter Psenak > > wrote: >> >> Bruno, >> >> On 13.12.2012 15:50, bruno.decraene@orange.com >> > >> wrote: >> >> Peter, >> >> Unless it is believed that a local algorithm, without >> coordination between >> >> routers/vendor, can work in 100% of the cases. Is this your >> point? >> >> local algorithm that picks any of the /32 IP addresses >> advertised by PQ >> node will work in 100% of cases. >> >> >> Does this include the case of an IS-IS L1/L2 router (ABR) >> redistributing into L2 the loopbacks of the routers in L1? >> >> >> ISIS may have a specific problem of not distinguishing between >> intra/inter/external prefixes. For that case some local policy on >> the computing node can be used to pick the ones that will work for >> LDP. >> >> thanks, >> Peter >> >> >> >> thanks, >> Peter >> >> >> Thanks, >> Regards, >> Bruno >> >> thanks, >> Peter >> ______________________________**___________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/_**_listinfo/rtgwg >> >> > >> >> >> >> ______________________________** >> ______________________________**_______________________ >> ______________________________**______________ >> >> >> >> Ce message et ses pieces jointes peuvent contenir des >> informations >> >> confidentielles ou privilegiees et ne doivent donc >> >> pas etre diffuses, exploites ou copies sans >> autorisation. Si vous avez recu >> >> ce message par erreur, veuillez le signaler >> >> a l'expediteur et le detruire ainsi que les pieces >> jointes. Les messages >> >> electroniques etant susceptibles d'alteration, >> >> France Telecom - Orange decline toute responsabilite si >> ce message a ete >> >> altere, deforme ou falsifie. Merci. >> >> >> This message and its attachments may contain >> confidential or privileged >> >> information that may be protected by law; >> >> they should not be distributed, used or copied without >> authorisation. >> If you have received this email in error, please notify >> the sender and delete >> >> this message and its attachments. >> >> As emails may be altered, France Telecom - Orange is not >> liable for messages >> >> that have been modified, changed or falsified. >> >> Thank you. >> >> >> >> >> >> >> ______________________________**______________________________** >> ______________________________**______________________________**_________ >> >> >> Ce message et ses pieces jointes peuvent contenir des >> informations confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si >> vous avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les >> messages electroniques etant susceptibles d'alteration, >> France Telecom - Orange decline toute responsabilite si ce >> message a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; >> they should not be distributed, used or copied without >> authorisation. >> If you have received this email in error, please notify the >> sender and delete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable >> for messages that have been modified, changed or falsified. >> Thank you. >> >> >> >> >> >> ______________________________**___________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/_**_listinfo/rtgwg >> >> > >> >> >> > > --bcaec53143b5e529f904d0be10de Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Peter,

Then the draft should document that & the nee= d for additional protocol extensions if certainty is desired.
The= n, there is the appropriate clarity & if a protocol extensions draft is= needed it can be considered in the
correct WG.

Alia


On Thu, Dec 13, 2012 at 10:18 AM, Pe= ter Psenak <ppsenak@cisco.com> wrote:
Alia,


On 13.12.2012 16:03, Alia Atlas wrote:
Peter,

One of the goals of LFA & remote-LFA is for ease of manageability. =A0W= hy
are you pushing for requiring additional configuration, which I don't see as adding any benefit from the flexibility, instead of documenting
the straightforward rules for automatic interoperabiity?

for most of the deployments, no config is required and picking the router-i= d or highest /32 address advertised by PQ node will work fine.

For those cases where above does not work, there are no magic rules that wi= ll make it work in all cases. We would need a protocol extension to guarant= ee it.

thanks,
Peter


Alia


On Thu, Dec 13, 2012 at 9:56 AM, Peter Psenak <ppsenak@cisco.com
<mailto:ppsenak@c= isco.com>> wrote:

=A0 =A0 Bruno,

=A0 =A0 On 13.12.2012 15:50, bruno.decraene@orange.com
=A0 =A0 <mailto:bruno.decraene@orange.com> wrote:

=A0 =A0 =A0 =A0 Peter,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Unless it is believed that a local algorith= m, without
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 coordination between

=A0 =A0 =A0 =A0 =A0 =A0 routers/vendor, can work in 100% of the cases. Is t= his your
=A0 =A0 =A0 =A0 =A0 =A0 point?

=A0 =A0 =A0 =A0 =A0 =A0 local algorithm that picks any of the /32 IP addres= ses
=A0 =A0 =A0 =A0 =A0 =A0 advertised by PQ
=A0 =A0 =A0 =A0 =A0 =A0 node will work in 100% of cases.


=A0 =A0 =A0 =A0 Does this include the case of an IS-IS L1/L2 router (ABR) =A0 =A0 =A0 =A0 redistributing into L2 the loopbacks of the routers in L1?<= br>

=A0 =A0 ISIS may have a specific problem of not distinguishing between
=A0 =A0 intra/inter/external prefixes. For that case some local policy on =A0 =A0 the computing node can be used to pick the ones that will work for = LDP.

=A0 =A0 thanks,
=A0 =A0 Peter



=A0 =A0 =A0 =A0 =A0 =A0 thanks,
=A0 =A0 =A0 =A0 =A0 =A0 Peter


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Regards,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Bruno

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Peter
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 _________________________________________________
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rtgwg mailing list
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rtgwg@ietf.org <mailto:rtgwg@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/_<= /u>_listinfo/rtgwg
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/= listinfo/rtgwg>



=A0 =A0 =A0 =A0 =A0 =A0 ____________________________________________= _______________________________________
=A0 =A0 =A0 =A0 =A0 =A0 ____________________________________________=



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ce message et ses pieces jointes peuvent co= ntenir des
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 informations

=A0 =A0 =A0 =A0 =A0 =A0 confidentielles ou privilegiees et ne doivent donc<= br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pas etre diffuses, exploites ou copies sans=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 autorisation. Si vous avez recu

=A0 =A0 =A0 =A0 =A0 =A0 ce message par erreur, veuillez le signaler

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 a l'expediteur et le detruire ainsi que= les pieces
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 jointes. Les messages

=A0 =A0 =A0 =A0 =A0 =A0 electroniques etant susceptibles d'alteration,<= br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 France Telecom - Orange decline toute respo= nsabilite si
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ce message a ete

=A0 =A0 =A0 =A0 =A0 =A0 altere, deforme ou falsifie. Merci.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 This message and its attachments may contai= n
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 confidential or privileged

=A0 =A0 =A0 =A0 =A0 =A0 information that may be protected by law;

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 they should not be distributed, used or cop= ied without
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 authorisation.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If you have received this email in error, p= lease notify
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the sender and delete

=A0 =A0 =A0 =A0 =A0 =A0 this message and its attachments.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 As emails may be altered, France Telecom - = Orange is not
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 liable for messages

=A0 =A0 =A0 =A0 =A0 =A0 that have been modified, changed or falsified.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thank you.






=A0 =A0 =A0 =A0 ____________________________________________________= _____________________________________________________________= ________________


=A0 =A0 =A0 =A0 Ce message et ses pieces jointes peuvent contenir des
=A0 =A0 =A0 =A0 informations confidentielles ou privilegiees et ne doivent = donc
=A0 =A0 =A0 =A0 pas etre diffuses, exploites ou copies sans autorisation. S= i
=A0 =A0 =A0 =A0 vous avez recu ce message par erreur, veuillez le signaler<= br> =A0 =A0 =A0 =A0 a l'expediteur et le detruire ainsi que les pieces join= tes. Les
=A0 =A0 =A0 =A0 messages electroniques etant susceptibles d'alteration,=
=A0 =A0 =A0 =A0 France Telecom - Orange decline toute responsabilite si ce<= br> =A0 =A0 =A0 =A0 message a ete altere, deforme ou falsifie. Merci.

=A0 =A0 =A0 =A0 This message and its attachments may contain confidential o= r
=A0 =A0 =A0 =A0 privileged information that may be protected by law;
=A0 =A0 =A0 =A0 they should not be distributed, used or copied without
=A0 =A0 =A0 =A0 authorisation.
=A0 =A0 =A0 =A0 If you have received this email in error, please notify the=
=A0 =A0 =A0 =A0 sender and delete this message and its attachments.
=A0 =A0 =A0 =A0 As emails may be altered, France Telecom - Orange is not li= able
=A0 =A0 =A0 =A0 for messages that have been modified, changed or falsified.=
=A0 =A0 =A0 =A0 Thank you.





=A0 =A0 _________________________________________________
=A0 =A0 rtgwg mailing list
=A0 =A0 rtgwg@ietf.org<= /a> <mailto:rtgwg@ie= tf.org>
=A0 =A0 https://www.ietf.org/mailman/__listinfo/rtgwg
=A0 =A0 <https://www.ietf.org/mailman/listinfo/rtgwg>





--bcaec53143b5e529f904d0be10de-- From hannes@juniper.net Thu Dec 13 08:37:36 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134F721F8B3D for ; Thu, 13 Dec 2012 08:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.356 X-Spam-Level: X-Spam-Status: No, score=-3.356 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kk4-y6yNmkje for ; Thu, 13 Dec 2012 08:37:35 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6217121F8B38 for ; Thu, 13 Dec 2012 08:37:35 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUMoET6xv77aXcOa84vRFUSMS2xxY33Ta@postini.com; Thu, 13 Dec 2012 08:37:35 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 13 Dec 2012 08:31:26 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Thu, 13 Dec 2012 08:31:26 -0800 Received: from db3outboundpool.messaging.microsoft.com (213.199.154.139) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 13 Dec 2012 08:33:35 -0800 Received: from mail1-db3-R.bigfish.com (10.3.81.232) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 13 Dec 2012 16:31:24 +0000 Received: from mail1-db3 (localhost [127.0.0.1]) by mail1-db3-R.bigfish.com (Postfix) with ESMTP id 1763D22046A for ; Thu, 13 Dec 2012 16:31:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.2.21; KIP:(null); UIP:(null); (null); H:BN1PRD0512HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -5 X-BigFish: PS-5(zz98dI9371I168aJ1432Izz1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h946hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1155h) Received: from mail1-db3 (localhost.localdomain [127.0.0.1]) by mail1-db3 (MessageSwitch) id 1355416143841098_21997; Thu, 13 Dec 2012 16:29:03 +0000 (UTC) Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.226]) by mail1-db3.bigfish.com (Postfix) with ESMTP id BDA1280089; Thu, 13 Dec 2012 16:28:59 +0000 (UTC) Received: from BN1PRD0512HT004.namprd05.prod.outlook.com (132.245.2.21) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 13 Dec 2012 16:28:56 +0000 Received: from evazhang-sslvpn-nc.jnpr.net (66.129.224.36) by pod51010.outlook.com (10.255.193.37) with Microsoft SMTP Server (TLS) id 14.16.245.2; Thu, 13 Dec 2012 16:28:52 +0000 Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Hannes Gredler In-Reply-To: <50C9F098.1020703@cisco.com> Date: Thu, 13 Dec 2012 17:28:45 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: <4DA651C4-7998-43F9-8782-368246A778E4@juniper.net> References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <50C9BF46.4060509@cisco.com> <50C9E6C0.4030607@cisco.com> <50C9F098.1020703@cisco.com> To: Peter Psenak X-Mailer: Apple Mail (2.1283) X-Originating-IP: [66.129.224.36] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: rtgwg@ietf.org, stbryant@cisco.com X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:37:36 -0000 On Dec 13, 2012, at 4:13 PM, Peter Psenak wrote: > Hannes, >=20 > On 13.12.2012 15:57, Hannes Gredler wrote: >>=20 >> On Dec 13, 2012, at 3:31 PM, Peter Psenak wrote: >>=20 >>> Hannes, >>>=20 >>> On 13.12.2012 15:21, Hannes Gredler wrote: >>>>=20 >>>> On Dec 13, 2012, at 12:43 PM, Stewart Bryant wrote: >>>>=20 >>>> [ =85 ] >>>>=20 >>>>>> can we say that the PQ node address used for targeted LDP session = is selected in following order of preference: >>>>>>=20 >>>>>> 1. PQ node OSPF router-id, if it is advertised as /32 prefix by = the PQ node itself >>>>>>=20 >>>>>> 2. Highest /32 address advertised by PQ node in it's Router LSA >>>>> Why do we need (2). What do we do if an interface cycles? >>>>>=20 >>>>> Surely the most we should say is that we SHOULD establish a TLDP = session with the >>>>> OSPF router-id, if it is advertised as /32 prefix by the PQ node = itself, else any >>>>> other IP address for the node may be used. >>>>=20 >>>> other implementations may not be willing to accept T-LDP sessions = on non-loopback >>>> adresses. >>>=20 >>> how do you suggest to distinguish between /32 belonging to the = loopback from /32 belonging to other interface types? >>=20 >> for OSPF traffic engineering deployments: >> - if a /32 stub route advertisement of a type-1 LSA matches the TE = router address TLV in the type-10 LSA >=20 > are we only allowed to advertise loopbacks in the TE TLV? remember, in lieu of explicit signaling the purpose of this is finding = the "most likely" transport IP for the T-LDP session. Those are heuristics and as such imperfect. If i can cover a high = percentile of the deployed base, then=20 i usually can convince operators to fix their broken configs where the = router-id/TE-router-ID does not match the routable transport loopback IP. >>=20 >> for OSPF non-traffic engineering deployments: >> - if a /32 stub route advertisement of a type-1 LSA matches the = router-id in the LS header >=20 > does not work if the router-id is not advertised by the node as a = stub-link, which is a valid case. perfect, so lets declare this a "broken" configuration for automated = T-LDP bringup w/o explicit signaling. i do sense some discomfort with the suggested heuristics -=20 should be go down and spin off dedicated drafts for OSPF and IS-IS to = explicitly advertise the transport IP address ? >>=20 >> for IS-IS traffic-engineering deployments: >> - if a /32 reported in any IP Reach TLVs (128,135, 235) matches the >> TE-router ID TLV 134 >>=20 >> for non IS-IS traffic-engineering deployments: >> - if a /32 reported in any IP Reach TLVs (128,135, 235) matches the >> - IP interface address TLV 132 (and this is the only IP interface = address TLV advertisement) >>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 From ginsberg@cisco.com Thu Dec 13 12:35:48 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32CE321F898B for ; Thu, 13 Dec 2012 12:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IryYOg-r5N0v for ; Thu, 13 Dec 2012 12:35:47 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5B72421F896B for ; Thu, 13 Dec 2012 12:35:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1178; q=dns/txt; s=iport; t=1355430947; x=1356640547; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nT7f5XQ6kG8cFrugqouJOrAqmLNNf6P1MlW4HqN8cPM=; b=RTYSHTzFnbZGcBEgBwJ1wndjraVcTJJxzbDZEdCoqcMGWF/xt5V4qh21 1/IVrA2NcMV4MRlQgEIadzawR5xu4S32Tw9/T3/MjF77E2e0LSbMcHPXD Ttq6GxT7AfD4jWolWtliSw6XZHLYxYrhgm0gkYwZYo0exn1xi9eEUaEE9 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAM06ylCtJXHB/2dsb2JhbABFvnAWc4IeAQEBAwE6PxACAQgiFBAyJQIEAQ0NiAUGvQKQOWEDplGCc4Ii X-IronPort-AV: E=Sophos;i="4.84,276,1355097600"; d="scan'208";a="152694223" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 13 Dec 2012 20:35:47 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBDKZk17002326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Dec 2012 20:35:46 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.93]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Thu, 13 Dec 2012 14:35:46 -0600 From: "Les Ginsberg (ginsberg)" To: Hannes Gredler , "Peter Psenak (ppsenak)" Subject: RE: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 Thread-Topic: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 Thread-Index: AQHN2HhprJw6StBkNE61jYNkDkrV6pgVriQAgAFTgwCAACw+gIAAAtIAgAAHX4CAAARdAIAAFQiA///eTcA= Date: Thu, 13 Dec 2012 20:35:46 +0000 Message-ID: References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <50C9BF46.4060509@cisco.com> <50C9E6C0.4030607@cisco.com> <50C9F098.1020703@cisco.com> <4DA651C4-7998-43F9-8782-368246A778E4@juniper.net> In-Reply-To: <4DA651C4-7998-43F9-8782-368246A778E4@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.163.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Stewart Bryant \(stbryant\)" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 20:35:48 -0000 Hannes - >=20 > should be go down and spin off dedicated drafts for OSPF and IS-IS to > explicitly advertise the > transport IP address ? >=20 Speaking specifically about IS-IS, why would we need to invent yet another = type of advertisement specifically for remote LFA? Here's a snippet from RF= C 5305 Section 4.3: The router ID TLV contains the 4-octet router ID of the router originating the LSP. This is useful in several regards: For traffic engineering, it guarantees that we have a single stable address that can always be referenced in a path that will be reachable from multiple hops away, regardless of the state of the node's interfaces... If a router does not implement traffic engineering, it MAY add or omit the Traffic Engineering router ID TLV. Does this not provide exactly what is required for remote LFA support? And = the RFC even specifically allows this to be present even if TE is not in us= e. What would your suggested "advertise the transport IP address do" that i= s not already done by TLV 134 (and the matching IP reachability advertiseme= nt)??? Les From rjs@rob.sh Thu Dec 13 13:03:48 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564F821F89A0 for ; Thu, 13 Dec 2012 13:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuW85XoFn4RO for ; Thu, 13 Dec 2012 13:03:47 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 05A0121F87D0 for ; Thu, 13 Dec 2012 13:03:46 -0800 (PST) Received: from [46.65.174.228] (helo=[172.16.1.9]) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1TjFtb-0002DM-JJ; Thu, 13 Dec 2012 21:00:43 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 From: Rob Shakir In-Reply-To: <50C9E552.9020100@cisco.com> Date: Thu, 13 Dec 2012 19:56:02 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3BD75937-F06A-43F1-9164-C7A356B81F4E@rob.sh> References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <985BF299-1BB7-4B35-9795-842F1781DF12@juniper.net> <50C8B203.2070503@cisco.com> <712_1355408500_50C9E474_712_170_1_53C29892C857584299CBF5D05346208A117B82@PEXCVZYM11.corporate.adroot.infra.ftgroup> <50C9E552.9020100@cisco.com> To: Peter Psenak X-Mailer: Apple Mail (2.1499) Cc: "rtgwg@ietf.org" , "stbryant@cisco.com" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 21:03:48 -0000 Hi Peter, On 13 Dec 2012, at 14:25, Peter Psenak wrote: >=20 > local algorithm that picks any of the /32 IP addresses advertised by = PQ node will work in 100% of cases. If there are local filters or control-plane protection ACLs deployed on = the target node to which the T-LDP session is to be established, it is = possible that these drop T-LDP traffic not targeted to a particular = local address. I'm not clear on how this can be determined remotely? It seems to me that we need deterministic behaviour in order to allow = operators to clearly consider this within such policies (or to know that = other protocol/signalling mechanisms are required), and to ensure = inter-operability. I don't see a clear reason why Hannes' suggestions do = not go at least some way to providing this. In the vast majority of = deployments I have seen, a consistent router ID is used for = intra-domain, inter-node session termination and protocol identifier. = This is more common (imho) than the highest /32 being the most suitable = address. r.= From jeff.tantsura@ericsson.com Thu Dec 13 14:16:11 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E1021F8924 for ; Thu, 13 Dec 2012 14:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzKgqs0KrCG5 for ; Thu, 13 Dec 2012 14:16:11 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2B00B21F880D for ; Thu, 13 Dec 2012 14:16:11 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qBDMQgFJ001413; Thu, 13 Dec 2012 16:26:49 -0600 Received: from EUSAAHC005.ericsson.se (147.117.188.87) by eusaamw0711.eamcs.ericsson.se (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 13 Dec 2012 17:15:59 -0500 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.001; Thu, 13 Dec 2012 17:15:57 -0500 From: Jeff Tantsura To: "Les Ginsberg (ginsberg)" Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 Thread-Topic: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 Thread-Index: AQHN2Hh7p23A2IHkgE2szh2CcFX0R5gVnWAAgAFThACAACw+gIAAAtEAgAAHX4CAAARdAIAAFQmAgABFBAD//8gscA== Date: Thu, 13 Dec 2012 22:15:56 +0000 Message-ID: <8BEC0D1D-91A0-4DB5-B8B2-C45F9C5B9D8B@ericsson.com> References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <50C9BF46.4060509@cisco.com> <50C9E6C0.4030607@cisco.com> <50C9F098.1020703@cisco.com> <4DA651C4-7998-43F9-8782-368246A778E4@juniper.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtgwg@ietf.org" , "Stewart Bryant \(stbryant\)" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:16:11 -0000 Agree with Les, why reinvent the wheel? Regards, Jeff On Dec 13, 2012, at 20:36, "Les Ginsberg (ginsberg)" w= rote: > Hannes - >=20 >>=20 >> should be go down and spin off dedicated drafts for OSPF and IS-IS to >> explicitly advertise the >> transport IP address ? >=20 > Speaking specifically about IS-IS, why would we need to invent yet anothe= r type of advertisement specifically for remote LFA? Here's a snippet from = RFC 5305 Section 4.3: >=20 > > The router ID TLV contains the 4-octet router ID of the router > originating the LSP. This is useful in several regards: >=20 > For traffic engineering, it guarantees that we have a single > stable address that can always be referenced in a path that will > be reachable from multiple hops away, regardless of the state of > the node's interfaces... >=20 > If a router does not implement traffic engineering, it MAY add or > omit the Traffic Engineering router ID TLV. > >=20 > Does this not provide exactly what is required for remote LFA support? An= d the RFC even specifically allows this to be present even if TE is not in = use. What would your suggested "advertise the transport IP address do" that= is not already done by TLV 134 (and the matching IP reachability advertise= ment)??? >=20 > Les >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From saku@ytti.fi Thu Dec 13 14:19:03 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F2221F88DA for ; Thu, 13 Dec 2012 14:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAeBrf8uPuy3 for ; Thu, 13 Dec 2012 14:19:03 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id F144A21F88D1 for ; Thu, 13 Dec 2012 14:19:02 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so2536683iaz.31 for ; Thu, 13 Dec 2012 14:19:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=sByv50PmiaLOonEA1SMDrajk+9dzP9z6RcUBt6cdwjg=; b=O/E2ItVX8C8zFcNsEevGB9HTjGkxHdxLdyIEtLFWzY6C2m9rNTIF0NUD/EOcPVjsX0 jSeGp4qHwgnqGhGrz7mevn1hweYASHixqujM2nwt1tB0wH1mS2cWK3v9J49i9lU76A1G eTafDOoix76SjM5+Izgb1U7xFagV0C0QeTGqrAnRU8XGw0NBdltPQDBTpZsZ+IfzQGuj MretvbyZH5iDb/bz202IgZF2ykq3ekBQA/O6rgg/7Xb4ojzlhwYzDBIbCfTszN+Hsagy QVSkPlYX9rCAb3f4aX49JsgdLiVzlJwvw8idE+VdVZj2juImNgvBjszmaMKhX2FOVKr1 O76Q== MIME-Version: 1.0 Received: by 10.43.110.132 with SMTP id ek4mr2905552icc.32.1355437141870; Thu, 13 Dec 2012 14:19:01 -0800 (PST) Received: by 10.64.65.199 with HTTP; Thu, 13 Dec 2012 14:19:01 -0800 (PST) In-Reply-To: <3BD75937-F06A-43F1-9164-C7A356B81F4E@rob.sh> References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <985BF299-1BB7-4B35-9795-842F1781DF12@juniper.net> <50C8B203.2070503@cisco.com> <712_1355408500_50C9E474_712_170_1_53C29892C857584299CBF5D05346208A117B82@PEXCVZYM11.corporate.adroot.infra.ftgroup> <50C9E552.9020100@cisco.com> <3BD75937-F06A-43F1-9164-C7A356B81F4E@rob.sh> Date: Fri, 14 Dec 2012 00:19:01 +0200 Message-ID: Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 From: Saku Ytti To: Rob Shakir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkVPBNiOgYLjwJiGe0HOqsaSOugGYnF5UGRsAl49jz3S3T82v4CcrRvJItKm1j0P4El8VQk Cc: "stbryant@cisco.com" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:19:03 -0000 On 13 December 2012 21:56, Rob Shakir wrote: > It seems to me that we need deterministic behaviour in order to allow ope= rators to clearly consider this within such policies (or to know that other= protocol/signalling mechanisms are required), and to ensure inter-operabil= ity. I don't see a clear reason why Hannes' suggestions do not go at least = some way to providing this. In the vast majority of deployments I have seen= , a consistent router ID is used for intra-domain, inter-node session termi= nation and protocol identifier. This is more common (imho) than the highest= /32 being the most suitable address. In our ~1500 or so flat L2 ISIS network TLV 132 is always correct for tLDP, mixed collection of various IOS and JunOS devices. However I know people who run unlabeled INET4 in loop0 and labeled VPNv4 for loop1 and desirable LDP is loop1. I would guess TLV 132 is still loop0 for these people, it's probably their router-id as well. No matter what you specify it, some people will be unhappy. But I wonder if there any production network where TLV 132 would fail, after allowing it in control-plane protection? (Also hell with tLDP, give me global label TLV in ISIS, and we get rLFA without any LDP, not even link LDP) -- ++ytti From ginsberg@cisco.com Thu Dec 13 14:33:38 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E80421F88EC for ; Thu, 13 Dec 2012 14:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sR0w7k7q4t9l for ; Thu, 13 Dec 2012 14:33:37 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6616021F88CE for ; Thu, 13 Dec 2012 14:33:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2713; q=dns/txt; s=iport; t=1355438017; x=1356647617; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Kn5VlythJQs5G+WdfNZBTTa3RcvRZWd9waZq9nrU5nk=; b=igdtMbH6IilHyINYw1XIGqsIRYTPrzTSM19osoUR60wT42l/2fImBzrL TwmwMXQdRbh1zFz9i36Oic0vmkeJ6/BPKWjVyU1Ua6e3lRFte2A6gITPy lmxtLFQ3KSGpwM0hY9gyk2TrQGuEyu1Gpy3uFUS+5czSv60ySKJj1fiL0 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABhXylCtJXG+/2dsb2JhbAA/Br5wFnOCHgEBAQQBAQE3NAsMBAIBCA4DBAEBAQoUCQcnCxQJCAIEAQ0FCIgLDL0DBIxXJ4M7YQOSVpN7gnOCIg X-IronPort-AV: E=Sophos;i="4.84,276,1355097600"; d="scan'208";a="149752036" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 13 Dec 2012 22:33:37 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBDMXbol003090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Dec 2012 22:33:37 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.91]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Thu, 13 Dec 2012 16:33:36 -0600 From: "Les Ginsberg (ginsberg)" To: Rob Shakir , "Peter Psenak (ppsenak)" Subject: RE: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 Thread-Topic: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 Thread-Index: AQHN2HhprJw6StBkNE61jYNkDkrV6pgVriQAgAAKnYCAAAfqgIABbU8AgAABCACAAFxkAP//wu3g Date: Thu, 13 Dec 2012 22:33:35 +0000 Message-ID: References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <985BF299-1BB7-4B35-9795-842F1781DF12@juniper.net> <50C8B203.2070503@cisco.com> <712_1355408500_50C9E474_712_170_1_53C29892C857584299CBF5D05346208A117B82@PEXCVZYM11.corporate.adroot.infra.ftgroup> <50C9E552.9020100@cisco.com> <3BD75937-F06A-43F1-9164-C7A356B81F4E@rob.sh> In-Reply-To: <3BD75937-F06A-43F1-9164-C7A356B81F4E@rob.sh> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.163.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Stewart Bryant \(stbryant\)" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:33:38 -0000 Rob - I haven't seen anyone on this thread suggest that if a router ID is availab= le/reachable that it should not be preferred/used. Local policies could mak= e any particular address unusable, but it would seem unusual for a customer= to configure a box to advertise a /32 which it also prevents from being us= ed. So I think Peter's point is that it is not unreasonable to consider the= set of all reachable /32 which a node has advertised as being viable candi= dates.=20 Frankly, I find the discussion of a preference algorithm in selecting the e= ndpoint address as useful/interesting - but much more appropriate for a ven= dor deployment guide than a normative specification. Vendors often are face= d with idiosyncratic deployment constraints from their customers which need= to be accommodated. In which case responsive vendors will provide various = knobs to allow override of default behavior - while retaining the ease of "= zero config" for the majority of customers. This is simply good business. W= e should not attempt to "standardize" this. Les > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of= Rob > Shakir > Sent: Thursday, December 13, 2012 11:56 AM > To: Peter Psenak (ppsenak) > Cc: rtgwg@ietf.org; Stewart Bryant (stbryant) > Subject: Re: identifying IP address of targeted LDP session in draft-ietf= - > rtgwg-remote-lfa-00 >=20 > Hi Peter, >=20 > On 13 Dec 2012, at 14:25, Peter Psenak wrote: > > > > local algorithm that picks any of the /32 IP addresses advertised by PQ > node will work in 100% of cases. >=20 > If there are local filters or control-plane protection ACLs deployed on t= he > target node to which the T-LDP session is to be established, it is possib= le > that these drop T-LDP traffic not targeted to a particular local address.= I'm > not clear on how this can be determined remotely? >=20 > It seems to me that we need deterministic behaviour in order to allow > operators to clearly consider this within such policies (or to know that > other protocol/signalling mechanisms are required), and to ensure inter- > operability. I don't see a clear reason why Hannes' suggestions do not go= at > least some way to providing this. In the vast majority of deployments I h= ave > seen, a consistent router ID is used for intra-domain, inter-node session > termination and protocol identifier. This is more common (imho) than the > highest /32 being the most suitable address. >=20 > r. > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From ppsenak@cisco.com Fri Dec 14 01:01:16 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A3821F8717 for ; Fri, 14 Dec 2012 01:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ig64WEVWgUj7 for ; Fri, 14 Dec 2012 01:01:16 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id C531621F870A for ; Fri, 14 Dec 2012 01:01:15 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBE91Ecq013946 for ; Fri, 14 Dec 2012 10:01:14 +0100 (CET) Received: from Peter-Psenaks-MacBook-Pro.local ([10.148.128.94]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBE91BxD013221; Fri, 14 Dec 2012 10:01:11 +0100 (CET) Message-ID: <50CAEAD7.6000508@cisco.com> Date: Fri, 14 Dec 2012 10:01:11 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Rob Shakir Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <985BF299-1BB7-4B35-9795-842F1781DF12@juniper.net> <50C8B203.2070503@cisco.com> <712_1355408500_50C9E474_712_170_1_53C29892C857584299CBF5D05346208A117B82@PEXCVZYM11.corporate.adroot.infra.ftgroup> <50C9E552.9020100@cisco.com> <3BD75937-F06A-43F1-9164-C7A356B81F4E@rob.sh> In-Reply-To: <3BD75937-F06A-43F1-9164-C7A356B81F4E@rob.sh> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtgwg@ietf.org" , "stbryant@cisco.com" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 09:01:16 -0000 Rob, On 13.12.2012 20:56, Rob Shakir wrote: > Hi Peter, > > On 13 Dec 2012, at 14:25, Peter Psenak wrote: >> >> local algorithm that picks any of the /32 IP addresses advertised by PQ node will work in 100% of cases. > > If there are local filters or control-plane protection ACLs deployed on the target node to which the T-LDP session is to be established, it is possible that these drop T-LDP traffic not targeted to a particular local address. I'm not clear on how this can be determined remotely? > > It seems to me that we need deterministic behaviour in order to allow operators to clearly consider this within such policies (or to know that other protocol/signalling mechanisms are required), and to ensure inter-operability. I don't see a clear reason why Hannes' suggestions do not go at least some way to providing this. In the vast majority of deployments I have seen, a consistent router ID is used for intra-domain, inter-node session termination and protocol identifier. This is more common (imho) than the highest /32 being the most suitable address. my suggestion was to use rtr-id of the PQ node as a first choice and fallback to highest /32 address as a last resort. Peter > > r. > > From stbryant@cisco.com Fri Dec 14 02:12:44 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8313821F8695 for ; Fri, 14 Dec 2012 02:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.564 X-Spam-Level: X-Spam-Status: No, score=-110.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8VwZ82I53G4 for ; Fri, 14 Dec 2012 02:12:43 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 74C0B21F8689 for ; Fri, 14 Dec 2012 02:12:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1575; q=dns/txt; s=iport; t=1355479963; x=1356689563; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=jZ1i6WoxOHmd+vwHQ8JaiFk1ljExsFRdQP6OCInrSds=; b=MpDrn+eteSet5utN5ju4Je+htaiaBwPANmmxGFdoyWQawg71LbeFOvT3 o8w+V0XPLscMyXSbiMTs5X5/oE+7ahJ3QpCF0leptyzxg7g3EiAnTV9r8 GMP/pmmnCUgbO2x6NicnPT5QBnH2L0E5wEG6ZDDMZKevUq+JLF55j0VaK U=; X-IronPort-AV: E=Sophos;i="4.84,279,1355097600"; d="scan'208";a="10452246" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 14 Dec 2012 10:12:39 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBEACc1a028441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Dec 2012 10:12:39 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id qBEACXko020074; Fri, 14 Dec 2012 10:12:34 GMT Message-ID: <50CAFBA5.5000906@cisco.com> Date: Fri, 14 Dec 2012 10:12:53 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Les Ginsberg (ginsberg)" Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <50C9BF46.4060509@cisco.com> <50C9E6C0.4030607@cisco.com> <50C9F098.1020703@cisco.com> <4DA651C4-7998-43F9-8782-368246A778E4@juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 10:12:44 -0000 On 13/12/2012 20:35, Les Ginsberg (ginsberg) wrote: > Hannes - > >> should be go down and spin off dedicated drafts for OSPF and IS-IS to >> explicitly advertise the >> transport IP address ? >> > Speaking specifically about IS-IS, why would we need to invent yet another type of advertisement specifically for remote LFA? Here's a snippet from RFC 5305 Section 4.3: > > > The router ID TLV contains the 4-octet router ID of the router > originating the LSP. This is useful in several regards: > > For traffic engineering, it guarantees that we have a single > stable address that can always be referenced in a path that will > be reachable from multiple hops away, regardless of the state of > the node's interfaces... > > If a router does not implement traffic engineering, it MAY add or > omit the Traffic Engineering router ID TLV. > > > Does this not provide exactly what is required for remote LFA support? And the RFC even specifically allows this to be present even if TE is not in use. What would your suggested "advertise the transport IP address do" that is not already done by TLV 134 (and the matching IP reachability advertisement)??? > > Les > > . > OK, so let's work up some text based on that and I will create a new Section IGP Address considerations with an ISIS and an OSPF section. I plan to get a new version out next week. Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From stbryant@cisco.com Fri Dec 14 08:16:43 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9071A21F88BC for ; Fri, 14 Dec 2012 08:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.57 X-Spam-Level: X-Spam-Status: No, score=-110.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlxbU2YxVudG for ; Fri, 14 Dec 2012 08:16:42 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 6B81D21F88B6 for ; Fri, 14 Dec 2012 08:16:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3776; q=dns/txt; s=iport; t=1355501802; x=1356711402; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=MgQq5wgQpd5UTopGpoQaONywK/M4pA6uOaq5jJJXZvc=; b=JVKw+UmGlB4LqDjZAXbcPHQbs4Zr5SsyMZs8HOk7pVYJTGHF0ACMfv2d j4XXvixxd/B+e/4dmouTDGM1hYnDgPj5bm9T3XGwGuit7xJVM6Uf1JJAg 5E8fnI5nEGtFX14mk9/H3WSQZvPmdvUg0xUgzKc90uiL1vHnkEG+3gpu1 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicHAG5Qy1CQ/khL/2dsb2JhbABFg0i7PRZzgh4BAQEEAQEBGhs2CgEQCxgJFg8JAwIBAgEVMBMBBQIBAYgPDLx+jFeEQwOWCZBIgnM X-IronPort-AV: E=Sophos;i="4.84,282,1355097600"; d="scan'208";a="10450025" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 14 Dec 2012 16:16:41 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBEGGfx8005748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Dec 2012 16:16:41 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id qBEGGciA011750; Fri, 14 Dec 2012 16:16:39 GMT Message-ID: <50CB50FA.7080701@cisco.com> Date: Fri, 14 Dec 2012 16:16:58 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: adrian@olddog.co.uk Subject: Re: AD review of draft-ietf-rtgwg-ipfrr-notvia-addresses References: <05f201cdac19$72ac3260$58049720$@olddog.co.uk> In-Reply-To: <05f201cdac19$72ac3260$58049720$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-rtgwg-ipfrr-notvia-addresses.all@tools.ietf.org, rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 16:16:43 -0000 Adrian How about if we add a new first section that says: "This document describes a method of providing fast re-route in an IP or MPLS network based on the use of an IP address known to avoid the failure. At the time of publication there is no immediate demand to deploy this technology, however in view of the subtleties involved in the design of routing protocol extensions to provide IP Fast Reroute it was considered desirable to publish this document to place on record the design consideration of the not-via address approach." Stewart On 17/10/2012 04:42, Adrian Farrel wrote: > Hi, > > I've done my usual AD review of your draft prior to issuing IETF last > call and passing the I-D for IESG evaluation. The main purpose of the > review is to catch issues that might come up in later reviews and to > ensure that the document is ready for publication as and RFC. > > I only have a small point that needs to be resolved in a new revision of > the document, so I will put it into "Revised I-D Needed" state in the > data tracker and wait to hear from you. > > But I would also like the document shepherd to make an update to the > write-up as described below. > > As always, all my comments are up for discussion and negotiation. > > Thanks for the work, > Adrian > > === > > The Shepherd write-up says... > >> There is consensus in the WG to proceed with publication. > Looking at the mailing list, I see no comments positive or negative > during WG last call. What is more, I see no discussion of the I-D > going back four years (at which point I lost the will to search > further). How do you justify there being WG consensus for this document? > > I think this issue can be resolved by a revision to the write-up with > some explanation of the justification for publishing this as a WG > document. I would also like the write-up to explain the purpose of the > document as discussed in the following point. > > --- > > I was also unclear why you want to publish the document at all. I see a > note from Alvaro (extending the WG last call for an extra week) that > says: > >> this document is being published as an Informational RFC for >> completeness purposes...as has been discussed in the mailing list and >> live meetings. > So I think that gives me the intended purpose: completeness. But I don't > know what that means, and the document doesn't help me at all. > > Furthermore, I couldn't find the discussion of this intention to publish > on the mailing list. > > Based on some conversations with Stewart, I understand that the idea > here is to capture the current state of discussions in the WG so that > they are not lost. But I also assume that the WG has no interest in > pursuing these ideas further. So it would be reasonable to add a > significant note to the Abstract and the Introduction about the > purpose. This would say something along the lines of... > > The idea is to capture the current state of discussions in the WG so > that they are not lost, can be referenced, and might be picked up > again later. The WG currently has no interest in pursuing these ideas > further. It is not intended that this document as currently written > should form the basis of an implementation or deployment. > > With this in mind, my review is considerably lighter than it would be > for a standards track protocol specification, and I think the document > will be fine for advancement. > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From adrian@olddog.co.uk Fri Dec 14 09:25:27 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4255E21F89AF for ; Fri, 14 Dec 2012 09:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ukp2z2dAUeNS for ; Fri, 14 Dec 2012 09:25:26 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 296C821F89A9 for ; Fri, 14 Dec 2012 09:25:25 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBEHPL2w031580; Fri, 14 Dec 2012 17:25:21 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBEHPK9q031564 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Dec 2012 17:25:20 GMT From: "Adrian Farrel" To: References: <05f201cdac19$72ac3260$58049720$@olddog.co.uk> <50CB50FA.7080701@cisco.com> In-Reply-To: <50CB50FA.7080701@cisco.com> Subject: RE: AD review of draft-ietf-rtgwg-ipfrr-notvia-addresses Date: Fri, 14 Dec 2012 17:25:18 -0000 Message-ID: <012301cdda1f$fd661720$f8324560$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKMOahqsbpvmEHaRx2w74LqSAffqAHA4LJIlo3D4FA= Content-Language: en-gb Cc: draft-ietf-rtgwg-ipfrr-notvia-addresses.all@tools.ietf.org, rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 17:25:27 -0000 Hi Stewart, > How about if we add a new first section that says: > > "This document describes a method of providing fast re-route > in an IP or MPLS network based on the use of an IP address > known to avoid the failure. At the time of publication there is no > immediate demand to deploy this technology, however in view > of the subtleties involved in the design of routing protocol > extensions to provide IP Fast Reroute it was considered desirable > to publish this document to place on record the design > consideration of the not-via address approach." Your proposed text captures some important information. Thanks. But it misses some things I wanted included: - Who considered it desirable? - How should the reader process this document wrt implementation and deployment? - Is the method described here "complete" or is more work needed? Additionally: what does "no immediate demand" mean? Probably "no demand". Would you like me to have a stab at this (I did suggest text before)? Adrian PS - Document shepherd: don't forget you have an action as well. > Stewart > > > On 17/10/2012 04:42, Adrian Farrel wrote: > > Hi, > > > > I've done my usual AD review of your draft prior to issuing IETF last > > call and passing the I-D for IESG evaluation. The main purpose of the > > review is to catch issues that might come up in later reviews and to > > ensure that the document is ready for publication as and RFC. > > > > I only have a small point that needs to be resolved in a new revision of > > the document, so I will put it into "Revised I-D Needed" state in the > > data tracker and wait to hear from you. > > > > But I would also like the document shepherd to make an update to the > > write-up as described below. > > > > As always, all my comments are up for discussion and negotiation. > > > > Thanks for the work, > > Adrian > > > > === > > > > The Shepherd write-up says... > > > >> There is consensus in the WG to proceed with publication. > > Looking at the mailing list, I see no comments positive or negative > > during WG last call. What is more, I see no discussion of the I-D > > going back four years (at which point I lost the will to search > > further). How do you justify there being WG consensus for this document? > > > > I think this issue can be resolved by a revision to the write-up with > > some explanation of the justification for publishing this as a WG > > document. I would also like the write-up to explain the purpose of the > > document as discussed in the following point. > > > > --- > > > > I was also unclear why you want to publish the document at all. I see a > > note from Alvaro (extending the WG last call for an extra week) that > > says: > > > >> this document is being published as an Informational RFC for > >> completeness purposes...as has been discussed in the mailing list and > >> live meetings. > > So I think that gives me the intended purpose: completeness. But I don't > > know what that means, and the document doesn't help me at all. > > > > Furthermore, I couldn't find the discussion of this intention to publish > > on the mailing list. > > > > Based on some conversations with Stewart, I understand that the idea > > here is to capture the current state of discussions in the WG so that > > they are not lost. But I also assume that the WG has no interest in > > pursuing these ideas further. So it would be reasonable to add a > > significant note to the Abstract and the Introduction about the > > purpose. This would say something along the lines of... > > > > The idea is to capture the current state of discussions in the WG so > > that they are not lost, can be referenced, and might be picked up > > again later. The WG currently has no interest in pursuing these ideas > > further. It is not intended that this document as currently written > > should form the basis of an implementation or deployment. > > > > With this in mind, my review is considerably lighter than it would be > > for a standards track protocol specification, and I think the document > > will be fine for advancement. > > > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg > > . > > > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html From asmirnov@cisco.com Fri Dec 14 09:42:33 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A2C21F8A3B for ; Fri, 14 Dec 2012 09:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvqK7OMGIlyn for ; Fri, 14 Dec 2012 09:42:33 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id AB6F321F8A2C for ; Fri, 14 Dec 2012 09:42:32 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBEHgUru012384; Fri, 14 Dec 2012 18:42:30 +0100 (CET) Received: from asm-lnx.cisco.com (ams-asmirnov-8712.cisco.com [10.55.140.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBEHgUPP003940; Fri, 14 Dec 2012 18:42:30 +0100 (CET) Message-ID: <50CB6505.9060705@cisco.com> Date: Fri, 14 Dec 2012 18:42:29 +0100 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121025 Thunderbird/16.0.2 MIME-Version: 1.0 To: Hannes Gredler Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> In-Reply-To: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 17:42:33 -0000 Hi Hannes, I saw this [lively] thread only today. I am not sure concerns which you brought up are really that big. You mentioned concerns of: - interoperability - efficiency (multiple LDP sessions) - security What happens with MPLS if Remote LFA chose 'wrong' IP address to terminate the tunnel: - IGP asks LDP to open targeted session to computed IP address - LDP sends targeted Hello (UDP) - Remote router responds with its ID and its transport address (which generally speaking is different than IP address where targeted Hello was received) - TCP session is established between transport addresses. So, after Hello exchange LDP has enough information to uniquely identify peer router and avoid duplicated TCP sessions. Transport address is always selected by receiving router and rLFA does not have control over it. I do not see room for interoperability issues even if rLFA routers follow different selection algorithms. The only requirement is that rLFA selects /32 address belonging to the remote end router. There are no efficiency compromises - label exchange will happen over single TCP session. Security considerations - selection of address to terminate TCP session is controlled by LDP configuration of a router, not by rLFA. The only thing left is that tunnel tailend router must not block LDP targeted Hellos on IP address selected by rLFA of computing router. This is achievable even if rLFA algorithm of selecting termination IP address is unknown (because there is finite number of /32 addresses advertised by the router via IGP). With little help of vendor's documentation it should be easy. So it's good if authors add to the draft a possible algorithm but I do not see a need for it to be too complex or truly standardized. Anton On 12/12/2012 03:49 PM, Hannes Gredler wrote: > clarence, stewart, > > In favor of interoperable implementations i feel one should document how to > identify the transport IP address (in lieu of protocols extensions who would > explicitly advertise the transport IP addresses) to the PQ node for the targeted LDP session. > > I am proposing to append the following text to 3.2. "Tunnel requirements": > > 3.2. Tunnel Requirements > [ … ] > > When a failure is detected, it is necessary to immediately redirect > traffic to the repair path. Consequently, the repair tunnel used > must be provisioned beforehand in anticipation of the failure. Since > the location of the repair tunnels is dynamically determined it is > necessary to establish the repair tunnels without management action. > Multiple repairs may share a tunnel end point. > > > > Targeted LDP sessions are brought up using a pair of source (PLR) and destination > (PQ node) loopback addresses. The following heuristics should be applied for deriving the > loopback IP address from a PQ nodes link-state advertisement. > > for the IS-IS routing protocol: > > A PLR router should connect to the address > > traffic-engineering deployments: > - reported both in the TE-router ID TLV 134 > - and IP Reach TLVs (128,135) given that > - the prefix length is /32 > > or > > no traffic-engineering deployments: > - reported both in the IP interface address TLV 132 > - and IP Reach TLVs (128,135), given that > - there is only a single interface address advertised per the router > - the prefix length is /32 > > > for the OSPF routing protocol: > > A PLR router should connect to the address > > traffic-engineering deployments: > - reported in the Router Address TLV (Type 10 LSA) and > - router (Type 1 LSA) ) stub network advertisement and > - the address mask is 255.255.255.255 > > or > > non-traffic-engineering deployments: > - reported in the router-id field of the Type-1 LSA) > - the router (Type 1 LSA) stub network advertisement and > - the address mask is 255.255.255.255 > > > > tx, > > /hannes > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > From bruno.decraene@orange.com Mon Dec 17 02:07:28 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F0221F895C for ; Mon, 17 Dec 2012 02:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, SARE_LWSHORTT=1.24, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7hM9UWPd54C for ; Mon, 17 Dec 2012 02:07:27 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id D727921F84CD for ; Mon, 17 Dec 2012 02:07:26 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id E41542DC2C6; Mon, 17 Dec 2012 11:07:25 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id B457B35C0E6; Mon, 17 Dec 2012 11:07:25 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Mon, 17 Dec 2012 11:07:25 +0100 From: To: Anton Smirnov , Hannes Gredler Subject: RE: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 Thread-Topic: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 Thread-Index: AQHN2iJjTktN60ofdUyRZ2gXy9yWk5gcxgtg Date: Mon, 17 Dec 2012 10:07:24 +0000 Message-ID: <11030_1355738845_50CEEEDD_11030_8731_1_53C29892C857584299CBF5D05346208A11931F@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50CB6505.9060705@cisco.com> In-Reply-To: <50CB6505.9060705@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.17.70017 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 10:07:28 -0000 In LDP networks, I see 2 problems and 2 goals. 2 problems: - T-LDP (TL): finding an IP address of the PQ to set up the T-LDP session - TUnnel end point (TU): finding an IP address of the PQ useable as tunnel = end point. And 2 goals: - A short term goal is to maximize (>80% ?) the ability of the PLR/S/R-LFA = to get the right IP address of the PQ, while the PQ is not compliant with R= -LFA. To keep LFA deployments properties, it would be nice if the PLR would= work out of the box, without requiring change (software/configuration) on = other routers. This is the ingress (i) issue in current networks. One could= say that this is a local issue that does not need standardization. However= , this requires taking into account existing PQ implementations/capabilitie= s. Hence RTGWG seems a useful place for discussing this, versus a full mesh= of bi-lateral discussion between vendors which besides would not include S= P. This does not prohibit an implementation to use a smarter solution. - A long term goal is to guaranty (100%) the ability of the PLR/S/R-LFA to = get the right IP address of the PQ, when the PQ is compliant with R-LFA. Th= is is the egress (e) issue/requirements in future networks. This point requ= ires standardization. When combining, this gives 4 points to consider. Eventually, there will be = some overlap between the solutions. =3D=3DTL=3D=3D Regarding TL (T-LDP): =3De=3D: for the egress long term, 2 solutions have been suggested - advertise the TLV 124 (TE Router ID) and accept T-LDP hello from this = address. Then either advertise LDP Transport Address optional object or acc= ept LDP session from this address. (Hannes) - accept T-LDP hello from all its /32 address advertise in the IGP. Then= either advertise LDP Transport Address optional object or accept LDP sessi= on from these addresses. (Anton) =3Di=3D: for the ingress short term, 2 solutions: - TE-router ID TLV 134, alternatively the /32 IP interface address TLV 1= 32 (both needs also be advertised in any IP Reach TLVs (128,135, 235)) (Han= nes) - idem but trying all /32 IP interface in address TLV 132, or possibly a= ll /32 advertised in any IP reach if the number of reach /32 if below a thr= eshold (e.g. 5) or matching a configured prefix. =3D=3DTU=3D=3D regarding TUnnel end point: TU may be different than TL, for example in a network using multiple loopba= cks addresses, one being advertised as FEC in LDP for MPLS traffic and one = not being advertised for IP traffic routed hop-by-hop. So far this point ha= s not been discussed. =3Di=3D for the ingress short term: - one could use TL if there is an LSP toward this FEC. Alternatively, a = FEC received over the T-LDP session with a null label (explicit or implicit= ). =3De=3D for the egress short term: - requiring the TL to be advertised in LDP may not be possible with exis= ting configuration (e.g. setting both the Router ID and the range of FEC ad= vertised in LDP). Seems a priori hard to me to require the change of the co= nfiguration (changing the loopback advertised in LDP is not an option. Chan= ging the TE-router ID to prefer the one advertised in LDP seems easier. Sho= uld we require this by default? However, that does not seem to me like a lo= ng term solution when we can change the behavior both on the PLR & the PQ. - advertising all loopbacks in TLV 132 (IP interface address). Then the = ingress intersects this set with the set of FEC advertised in LDP. - finding another existing field? - defining a new field (either in IGP or T-LDP) Thanks, Regards, Bruno >From: Anton Smirnov >Sent: Friday, December 14, 2012 6:42 PM > > Hi Hannes, > I saw this [lively] thread only today. I am not sure concerns which >you brought up are really that big. You mentioned concerns of: >- interoperability >- efficiency (multiple LDP sessions) >- security > > What happens with MPLS if Remote LFA chose 'wrong' IP address to >terminate the tunnel: >- IGP asks LDP to open targeted session to computed IP address >- LDP sends targeted Hello (UDP) >- Remote router responds with its ID and its transport address (which >generally speaking is different than IP address where targeted Hello was >received) >- TCP session is established between transport addresses. > >So, after Hello exchange LDP has enough information to uniquely identify >peer router and avoid duplicated TCP sessions. >Transport address is always selected by receiving router and rLFA does >not have control over it. > > I do not see room for interoperability issues even if rLFA routers >follow different selection algorithms. The only requirement is that rLFA >selects /32 address belonging to the remote end router. > There are no efficiency compromises - label exchange will happen >over single TCP session. > Security considerations - selection of address to terminate TCP >session is controlled by LDP configuration of a router, not by rLFA. > The only thing left is that tunnel tailend router must not block LDP >targeted Hellos on IP address selected by rLFA of computing router. This >is achievable even if rLFA algorithm of selecting termination IP address >is unknown (because there is finite number of /32 addresses advertised >by the router via IGP). With little help of vendor's documentation it >should be easy. > > So it's good if authors add to the draft a possible algorithm but I >do not see a need for it to be too complex or truly standardized. > >Anton > > >On 12/12/2012 03:49 PM, Hannes Gredler wrote: >> clarence, stewart, >> >> In favor of interoperable implementations i feel one should document how= to >> identify the transport IP address (in lieu of protocols extensions who w= ould >> explicitly advertise the transport IP addresses) to the PQ node for the >targeted LDP session. >> >> I am proposing to append the following text to 3.2. "Tunnel requirements= ": >> >> 3.2. Tunnel Requirements >> [ ... ] >> >> When a failure is detected, it is necessary to immediately redirect >> traffic to the repair path. Consequently, the repair tunnel used >> must be provisioned beforehand in anticipation of the failure. Since >> the location of the repair tunnels is dynamically determined it is >> necessary to establish the repair tunnels without management action. >> Multiple repairs may share a tunnel end point. >> >> >> >> Targeted LDP sessions are brought up using a pair of source (PLR) and >destination >> (PQ node) loopback addresses. The following heuristics should be applied= for >deriving the >> loopback IP address from a PQ nodes link-state advertisement. >> >> for the IS-IS routing protocol: >> >> A PLR router should connect to the address >> >> traffic-engineering deployments: >> - reported both in the TE-router ID TLV 134 >> - and IP Reach TLVs (128,135) given that >> - the prefix length is /32 >> >> or >> >> no traffic-engineering deployments: >> - reported both in the IP interface address TLV 132 >> - and IP Reach TLVs (128,135), given that >> - there is only a single interface address advertised per the router >> - the prefix length is /32 >> >> >> for the OSPF routing protocol: >> >> A PLR router should connect to the address >> >> traffic-engineering deployments: >> - reported in the Router Address TLV (Type 10 LSA) and >> - router (Type 1 LSA) ) stub network advertisement and >> - the address mask is 255.255.255.255 >> >> or >> >> non-traffic-engineering deployments: >> - reported in the router-id field of the Type-1 LSA) >> - the router (Type 1 LSA) stub network advertisement and >> - the address mask is 255.255.255.255 >> >> >> >> tx, >> >> /hannes >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg >> >_______________________________________________ >rtgwg mailing list >rtgwg@ietf.org >https://www.ietf.org/mailman/listinfo/rtgwg ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From rjs@rob.sh Tue Dec 18 00:38:08 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1ED21F85E0 for ; Tue, 18 Dec 2012 00:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uI0h9DwEc6BD for ; Tue, 18 Dec 2012 00:38:08 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDD921F85DD for ; Tue, 18 Dec 2012 00:38:08 -0800 (PST) Received: from [109.144.18.127] (helo=pc0044.btbd.btopenzone.com) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1Tksdj-0003DK-US; Tue, 18 Dec 2012 08:35:04 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 From: Rob Shakir In-Reply-To: Date: Tue, 18 Dec 2012 08:38:09 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <9834E26F-02B7-4926-B34A-FE50C44D5C58@rob.sh> References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <985BF299-1BB7-4B35-9795-842F1781DF12@juniper.net> <50C8B203.2070503@cisco.com> <712_1355408500_50C9E474_712_170_1_53C29892C857584299CBF5D05346208A117B82@PEXCVZYM11.corporate.adroot.infra.ftgroup> <50C9E552.9020100@cisco.com> <3BD75937-F06A-43F1-9164-C7A356B81F4E@rob.sh> To: "Les Ginsberg (ginsberg)" X-Mailer: Apple Mail (2.1499) Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 08:38:08 -0000 Hi Les, Apologies for the delay in responding. On 13 Dec 2012, at 22:33, "Les Ginsberg (ginsberg)" = wrote: > Frankly, I find the discussion of a preference algorithm in selecting = the endpoint address as useful/interesting - but much more appropriate = for a vendor deployment guide than a normative specification. Vendors = often are faced with idiosyncratic deployment constraints from their = customers which need to be accommodated. In which case responsive = vendors will provide various knobs to allow override of default behavior = - while retaining the ease of "zero config" for the majority of = customers. This is simply good business. We should not attempt to = "standardize" this. I agree that there are likely to be a variety of requirements, and I am = not saying that we need a MUST in this document - but some guidance to = implementors on this kind of deployment consideration is always useful = from my perspective (some guidance as to what *could* be best practice, = tends to result in a higher probability that different vendor's kit = actually interoperates with each other). Cheers, r.= From internet-drafts@ietf.org Wed Dec 19 07:59:18 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9114821F8B05; Wed, 19 Dec 2012 07:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdU+kdtzTN2p; Wed, 19 Dec 2012 07:59:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2FB21F8A4B; Wed, 19 Dec 2012 07:59:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-remote-lfa-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121219155918.6637.63707.idtracker@ietfa.amsl.com> Date: Wed, 19 Dec 2012 07:59:18 -0800 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 15:59:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Group = of the IETF. Title : Remote LFA FRR Author(s) : Stewart Bryant Clarence Filsfils Stefano Previdi Mike Shand Ning So Filename : draft-ietf-rtgwg-remote-lfa-01.txt Pages : 13 Date : 2012-12-19 Abstract: This draft describes an extension to the basic IP fast re-route mechanism described in RFC 5286 that provides additional backup connectivity when none can be provided by the basic mechanisms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-remote-lfa There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-remote-lfa-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-remote-lfa-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From aretana@cisco.com Wed Dec 19 09:29:16 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8051021F878F for ; Wed, 19 Dec 2012 09:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TL6Owe+S0UsG for ; Wed, 19 Dec 2012 09:29:16 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id EE77621F8615 for ; Wed, 19 Dec 2012 09:29:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3055; q=dns/txt; s=iport; t=1355938156; x=1357147756; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=+v4dyCZ7acwOsAJG5rXE+s30Y60fPqKhZL1rUtmTS/s=; b=Wf1P35bQPKw77s8UbOeuaCOaIPoftV+ep+xFM7j8MKENMFWJuHmJfi+y f/gSwWG+tQQkvpmAlSbZCldDBJ1443yhVXETjWJlxTprRMtxWoftkz9qn yvnO1qiLa+9NeMnkgAYVWKn6wRZ0/bJTtxKCnKrtEengqW3E0pgzKBjSR Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIr40VCtJV2Z/2dsb2JhbABEgkm7PhZzgiABBHkSAQgEHh05FBECBAENBQiIC7gpjFiDV2EDplKCdIFtNQ X-IronPort-AV: E=Sophos;i="4.84,318,1355097600"; d="scan'208,217";a="154716384" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 19 Dec 2012 17:29:14 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBJHTEwN004694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Dec 2012 17:29:14 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.154]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Wed, 19 Dec 2012 11:29:14 -0600 From: "Alvaro Retana (aretana)" To: "Stewart Bryant (stbryant)" , Hannes Gredler Subject: Re: IPR for draft-ietf-rtgwg-remote-lfa-00 ??? Thread-Topic: IPR for draft-ietf-rtgwg-remote-lfa-00 ??? Thread-Index: AQHN3g5dZzgwzUr1VEWYpTHsq/IIrA== Date: Wed, 19 Dec 2012 17:29:13 +0000 Message-ID: In-Reply-To: <50C873EB.7080503@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.238.228] Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94EC7E11Cxmbalnx15ciscocom_" MIME-Version: 1.0 Cc: "rtgwg-chairs@tools.ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 17:29:16 -0000 --_000_BBD66FD99311804F80324E8139B3C94EC7E11Cxmbalnx15ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just to close the loop.. This issue has been fixed and the IPR now shows u= p. Alvaro. On 12/12/12 7:09 AM, "Stewart Bryant (stbryant)" > wrote: There was a declaration against draft-shand-remote-lfa-0, but the chairs did not set the replacement status correctly when draft-ietf-rtgwg-remote-lfa-00 was published, so the new draft did not automatically inherit the existing IPR disclosure. Please can the chairs email the secretariat and request that they correct the meta-data so that the WG draft draft picks up IPR disclosure 1770 in the tracker. --_000_BBD66FD99311804F80324E8139B3C94EC7E11Cxmbalnx15ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <2956782AB49046489E9F921FF069BB05@cisco.com> Content-Transfer-Encoding: quoted-printable
Just to close the loop..  This issue has been fixed and the IPR n= ow shows up.

Alvaro.

On 12/12/12 7:09 AM, "Stewart Bryant (stbryant)" <stbryant@cisco.com> wrote:

There was a declaration against  draft-shand-remote-lfa-0,
but the chairs did not set the replacement status correctly
when draft-ietf-rtgwg-remote-lfa-00 was published, so 
the new draft did not automatically inherit the existing
IPR disclosure.

Please can the chairs email the secretariat and request
that they correct the meta-data so that the WG draft draft 
picks up IPR disclosure 1770 in the tracker.
 --_000_BBD66FD99311804F80324E8139B3C94EC7E11Cxmbalnx15ciscocom_-- From internet-drafts@ietf.org Wed Dec 19 09:33:21 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A6F21F878F; Wed, 19 Dec 2012 09:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNlfmirjmaFZ; Wed, 19 Dec 2012 09:33:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372FA21F882E; Wed, 19 Dec 2012 09:33:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-ipfrr-notvia-addresses-10.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121219173321.21018.2195.idtracker@ietfa.amsl.com> Date: Wed, 19 Dec 2012 09:33:21 -0800 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 17:33:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Group = of the IETF. Title : A Framework for IP and MPLS Fast Reroute Using Not-via A= ddresses Author(s) : Stewart Bryant Stefano Previdi Mike Shand Filename : draft-ietf-rtgwg-ipfrr-notvia-addresses-10.txt Pages : 33 Date : 2012-12-19 Abstract: This document presents a framework for providing fast reroute in an IP or MPLS network through encapsulation and forwarding to "not-via" addresses. The general approach described uses a single level of encapsulation and could be used to protect unicast, multicast, and LDP traffic against link, router, and shared risk group failure, regardless of network topology and metrics. The mechanisms presented in this document are purely illustrative of the general approach and do not constitute a protocol specification. The document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ipfrr-notvia-addresses There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-ipfrr-notvia-addresses-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-ipfrr-notvia-addresses-= 10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ginsberg@cisco.com Thu Dec 20 00:46:07 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F6521F8A57 for ; Thu, 20 Dec 2012 00:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayMzlBbEKQOn for ; Thu, 20 Dec 2012 00:46:06 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id E636321F8838 for ; Thu, 20 Dec 2012 00:46:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1748; q=dns/txt; s=iport; t=1355993166; x=1357202766; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=C7P6pwXk1sOQQwDScKrWOZcrBv6QIFyYPO4IvvYA++o=; b=Qq8iHnZfhL/vkglbL3kURpaEj1rFtdGxXZQ/6IY9hz6WC3vJVpEquhlU TaIgPhAq1g38Y2/79eGdW3ROTzBABDmapKJVGZRyEMp0ZpPMkl+hO7Eyp 3gOwEHyMmXpvKSmYGgHemTmnuci0d8hk0Jn6iDT23OMt75LWVw9CsVOCd Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGrP0lCtJV2Z/2dsb2JhbABEvWkWc4IeAQEBBDo/DAQCAQgOAwQBAQEKFAkHMhQJCAIEDgUIiAu4fYxNg2JhA6ZSgnSCIg X-IronPort-AV: E=Sophos;i="4.84,322,1355097600"; d="scan'208";a="155000941" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 20 Dec 2012 08:45:48 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBK8jmao032253 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Dec 2012 08:45:48 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.159]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Thu, 20 Dec 2012 02:45:48 -0600 From: "Les Ginsberg (ginsberg)" To: Rob Shakir Subject: RE: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 Thread-Topic: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 Thread-Index: AQHN3PsKvHqQTvO58E6YBKTfi80fmZghYkWQ Date: Thu, 20 Dec 2012 08:45:47 +0000 Message-ID: References: <09877446-5980-40C1-A067-8B08A8693D47@juniper.net> <50C8A278.6080203@cisco.com> <985BF299-1BB7-4B35-9795-842F1781DF12@juniper.net> <50C8B203.2070503@cisco.com> <712_1355408500_50C9E474_712_170_1_53C29892C857584299CBF5D05346208A117B82@PEXCVZYM11.corporate.adroot.infra.ftgroup> <50C9E552.9020100@cisco.com> <3BD75937-F06A-43F1-9164-C7A356B81F4E@rob.sh> <9834E26F-02B7-4926-B34A-FE50C44D5C58@rob.sh> In-Reply-To: <9834E26F-02B7-4926-B34A-FE50C44D5C58@rob.sh> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.121.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 08:46:07 -0000 Rob - So long as the WG is in agreement that what we are discussing is simply "be= st practice" - and that there is no interoperability issue - then I think w= e should have little trouble converging on text which is agreeable to every= one. Les > -----Original Message----- > From: Rob Shakir [mailto:rjs@rob.sh] > Sent: Tuesday, December 18, 2012 12:38 AM > To: Les Ginsberg (ginsberg) > Cc: rtgwg@ietf.org > Subject: Re: identifying IP address of targeted LDP session in draft-ietf= - > rtgwg-remote-lfa-00 >=20 > Hi Les, >=20 > Apologies for the delay in responding. >=20 > On 13 Dec 2012, at 22:33, "Les Ginsberg (ginsberg)" > wrote: >=20 > > Frankly, I find the discussion of a preference algorithm in selecting t= he > endpoint address as useful/interesting - but much more appropriate for a > vendor deployment guide than a normative specification. Vendors often are > faced with idiosyncratic deployment constraints from their customers whic= h > need to be accommodated. In which case responsive vendors will provide > various knobs to allow override of default behavior - while retaining the > ease of "zero config" for the majority of customers. This is simply good > business. We should not attempt to "standardize" this. >=20 > I agree that there are likely to be a variety of requirements, and I am n= ot > saying that we need a MUST in this document - but some guidance to > implementors on this kind of deployment consideration is always useful fr= om > my perspective (some guidance as to what *could* be best practice, tends = to > result in a higher probability that different vendor's kit actually > interoperates with each other). >=20 > Cheers, > r. From adrian@olddog.co.uk Fri Dec 21 12:03:12 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C5F21F86A1 for ; Fri, 21 Dec 2012 12:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLL-9FSxDPGE for ; Fri, 21 Dec 2012 12:03:11 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 8094921F869E for ; Fri, 21 Dec 2012 12:03:11 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBLK36Ki003588; Fri, 21 Dec 2012 20:03:06 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBLK35R7003571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Dec 2012 20:03:05 GMT From: "Adrian Farrel" To: Subject: Progressing draft-ietf-rtgwg-ipfrr-notvia-addresses Date: Fri, 21 Dec 2012 20:03:01 -0000 Message-ID: <048a01cddfb6$2e69cce0$8b3d66a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-language: en-gb Thread-index: Ac3ftizWKuJGEL7BQjyw09bLTB8FeA== Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 20:03:12 -0000 Thanks to Stewart for discussions and updates to this document. It is ready to move forward, but needs updates to the Shepherd write-up per my email in October. It should be relatively easy to construct this from my email and the changes Stewart has made to the document. Thanks, Adrian From bharat_joshi@infosys.com Tue Dec 25 02:31:54 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE3A21F86BE for ; Tue, 25 Dec 2012 02:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSuf84HiivOq for ; Tue, 25 Dec 2012 02:31:52 -0800 (PST) Received: from kecgate02.infosys.com (kecgate02.infosys.com [122.98.14.32]) by ietfa.amsl.com (Postfix) with ESMTP id B5DC721F86B4 for ; Tue, 25 Dec 2012 02:31:51 -0800 (PST) X-TM-IMSS-Message-ID: <3101145800078374@infosys.com> Received: from blrkechub04.ad.infosys.com ([10.66.236.44]) by infosys.com ([122.98.14.32]) with ESMTP (TREND IMSS SMTP Service 7.1) id 3101145800078374 ; Tue, 25 Dec 2012 15:57:14 +0530 Received: from BLRKECHUB07.ad.infosys.com (10.66.236.117) by blrkechub04.ad.infosys.com (10.66.236.44) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 25 Dec 2012 16:01:49 +0530 Received: from BLRKECMBX13.ad.infosys.com ([fe80::c43d:ba67:abc0:11c3]) by BLRKECHUB07.ad.infosys.com ([::1]) with mapi id 14.02.0318.004; Tue, 25 Dec 2012 16:01:48 +0530 From: Bharat Joshi To: "rtgwg@ietf.org" Subject: A query on RIPv2 Thread-Topic: A query on RIPv2 Thread-Index: Ac3iiwsWsu05KlXPT+O3nDXOBUFIIQ== Date: Tue, 25 Dec 2012 10:31:47 +0000 Message-ID: <35347FBF2796F94E936EE76C0E6047ED2B643823@BLRKECMBX13.ad.infosys.com> Accept-Language: en-US, en-IN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 27 Dec 2012 07:16:41 -0800 Cc: Bharat Joshi X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 10:31:55 -0000 Hi All, I came across some text in RFC 2453 (RIPv2) which has confused me. I= t would be great if someone can clarify this for me. I searched the net a= nd looked through the errata but could not find any reference to this. In section 3.9.1 of RFC 2453 (http://tools.ietf.org/html/rfc2453#section-= 3.9.1), in second para, following text is available: There is one special case. If there is exactly one entry in the request, and it has an address family identifier of zero and a metric of infinity (i.e., 16), then this is a request to send the entire routing table. In section 4.1 of same RFC (http://tools.ietf.org/html/rfc2453#section-4.= 1), in first para, following text is available: If the Address Family Identifier of the first (and only the first) entry in the message is 0xFFFF, then the remainder of the entry contains the authentication. Now what has confused me is that if a router is configured to use aut= hentication, how should its 'request' message for full routing table look= ? Should it go without authentication information or with authentication = information? If it goes with authentication information then it is not conforming = to the statement of 3.9.1. If it goes without authentication information = then it is not conforming to the user configuration and also there may be= security issues. Regards, Bharat PS: I am currently not subscribed to RTG working group mailing list, so p= lease reply all so that I can get your reply. **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended sol= ely for the use of the addressee(s). If you are not the intended recipient, p= lease notify the sender by e-mail and delete the original message. Further, you= are not to copy, disclose, or distribute this e-mail or its contents to any other= person and any such actions are unlawful. This e-mail may contain viruses. Infosys h= as taken every reasonable precaution to minimize this risk, but is not liable for = any damage you may sustain as a result of any virus in this e-mail. You should carry= out your own virus checks before opening the e-mail or attachment. Infosys reserve= s the right to monitor and review the content of all messages sent to or from t= his e-mail address. Messages sent to or from this e-mail address may be stored on th= e Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS***