From stephane.litkowski@orange.com Tue Oct 1 01:16:31 2013 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 9DF9721F9AD5 for ; Tue, 1 Oct 2013 01:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.055 X-Spam-Level: X-Spam-Status: No, score=-1.055 tagged_above=-999 required=5 tests=[AWL=1.192, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ie8fl2ZAW4Bo for ; Tue, 1 Oct 2013 01:16:27 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 37C5A21F9C05 for ; Tue, 1 Oct 2013 01:16:23 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 81B9A3746CB; Tue, 1 Oct 2013 10:16:08 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 5E9BE180067; Tue, 1 Oct 2013 10:16:08 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.45]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Tue, 1 Oct 2013 10:16:07 +0200 From: To: Levente Csikor , "rtgwg@ietf.org" Date: Tue, 1 Oct 2013 10:16:06 +0200 Subject: RE: WG Adoption Requested for draft-litkowski-rtgwg-lfa-manageability-01 Thread-Topic: WG Adoption Requested for draft-litkowski-rtgwg-lfa-manageability-01 Thread-Index: Ac694h6ju6NZdszuRou3DH6UEGY9JwAnE+Vg Message-ID: <29996_1380615368_524A84C8_29996_9049_1_EEE55384044474429A926C625D0FCC8109661F9307@PUEXCB2F.nanterre.francetelecom.fr> References: <52497E69.3000801@tmit.bme.hu> In-Reply-To: <52497E69.3000801@tmit.bme.hu> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_EEE55384044474429A926C625D0FCC8109661F9307PUEXCB2Fnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.10.1.50914 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, 01 Oct 2013 08:16:31 -0000 --_000_EEE55384044474429A926C625D0FCC8109661F9307PUEXCB2Fnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks, I will patch it in the next version ... ________________________________ De : Levente Csikor [mailto:csikor@tmit.bme.hu] Envoy=E9 : lundi 30 septembre 2013 15:37 =C0 : rtgwg@ietf.org; LITKOWSKI Stephane DTF/DERX Objet : Re: WG Adoption Requested for draft-litkowski-rtgwg-lfa-manageabili= ty-01 Hi! I've just realized a small typo in http://tools.ietf.org/html/draft-litkows= ki-rtgwg-lfa-manageability-01. In Sec. 2.2, in Figure 2 the path from PE1 to PEx is R9-R8-R7-R10-R6-PEx, h= owever, the text below the figure says: "In the figure 2, let us consider the traffic coming from PE1 to PEx. Nomin= al path is R9-R8-R7-R6-PEx" -> R10 is missing. Every other things seem correct :) Regards, Levente On 04/23/2013 12:48 AM, Alvaro Retana (aretana) wrote: Hi! The period for comments has ended. We received 11 comments supporting the adoption, which included 2 of the 3 = contributors and 3 of the 4 authors. Given that and the support at the las= t meeting, there is consensus to adopt the work. Also, all the authors and contributors have confirmed that they are not awa= re of any IPR related to this draft. Authors: Please republish the draft with the updated name draft-rtgwg-lfa-= manageability. Thanks! Alvaro. On 4/2/13 1:17 PM, "Alvaro Retana (aretana)" > wrote: Hi! The authors of 'Operational management of Loop Free Alternates' (http://too= ls.ietf.org/html/draft-litkowski-rtgwg-lfa-manageability-01) have requested= that rtgwg adopt their draft as a WG document. Authors and Contributors: Please respond indicating whether or not you are = aware of any relevant IPR. The draft will not progress until we have recei= ved a response from each author/contributor. Please send any comments to the list by April 16, 2013. Thanks!! Alvaro. _______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_EEE55384044474429A926C625D0FCC8109661F9307PUEXCB2Fnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks, I will patch it in the next version ...
 

De : Levente Csikor=20 [mailto:csikor@tmit.bme.hu]
Envoy=E9 : lundi 30 septembre= 2013=20 15:37
=C0 : rtgwg@ietf.org; LITKOWSKI Stephane=20 DTF/DERX
Objet : Re: WG Adoption Requested for=20 draft-litkowski-rtgwg-lfa-manageability-01

Hi!
I've just realized a small typo in http://tools.ietf.org/html/draft-litkowski-rtgwg-lfa-manageability-01= .
In=20 Sec. 2.2, in Figure 2 the path from PE1 to PEx is R9-R8-R7-R10-R6-PEx<= /B>,=20 however, the text below the figure says:

"In the figure = 2,=20 let us consider the traffic coming from PE1 to PEx. Nominal path is=20 R9-R8-R7-R6-PEx" -> R10 is missing.

Every other things s= eem=20 correct :)

Regards,
Levente
On 04/23/2013 12:48 AM, Alvaro Retana (areta= na)=20 wrote:
Hi!

The period for comments has ended.

We received 11 comments supporting the adoption, which included 2 = of=20 the 3 contributors and 3 of the 4 authors.  Given that and the sup= port=20 at the last meeting, there is consensus to adopt the work.

Also, all the authors and contributors have confirmed that they ar= e not=20 aware of any IPR related to this draft.

Authors:  Please republish the draft with the updated name=20 draft-rtgwg-lfa-manageability.

Thanks!

Alvaro.

On 4/2/13 1:17 PM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

Hi!

The authors of 'Operational management of Loop Free Alternates' = (http://tools.ietf.org/html/draft-litkowski-r= tgwg-lfa-manageability-01)=20 have requested that rtgwg adopt their draft as a WG document.

Authors and Contributors: Please respond indicating whether or n= ot=20 you are aware of any relevant IPR.  The draft will not progress = until=20 we have received a response from each author/contributor.

Please send any comments to the list by April 16, 2013.

Thanks!!

Alvaro.



_=
______________________________________________
rtgwg mailing list
rtgwg@ie=
tf.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,
Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_EEE55384044474429A926C625D0FCC8109661F9307PUEXCB2Fnante_-- From rsouza.rjo@gmail.com Tue Oct 1 07:31:43 2013 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 5515D11E8143 for ; Tue, 1 Oct 2013 07:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnfOtUHXrxRT for ; Tue, 1 Oct 2013 07:31:38 -0700 (PDT) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by ietfa.amsl.com (Postfix) with ESMTP id AB23711E816F for ; Tue, 1 Oct 2013 07:31:36 -0700 (PDT) Received: from tom.nabble.com ([192.168.236.105]) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1VR0zA-00065v-Cp for rtgwg@ietf.org; Tue, 01 Oct 2013 07:31:36 -0700 Date: Tue, 1 Oct 2013 07:31:36 -0700 (PDT) From: rogeriomariano To: rtgwg@ietf.org Message-ID: <1380637896228-386319.post@n7.nabble.com> In-Reply-To: <20130523205113.6051.94668.idtracker@ietfa.amsl.com> References: <20130523205113.6051.94668.idtracker@ietfa.amsl.com> Subject: Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9449_8711346.1380637896371" X-Mailman-Approved-At: Tue, 01 Oct 2013 07:33:16 -0700 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, 01 Oct 2013 14:31:43 -0000 ------=_Part_9449_8711346.1380637896371 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks,Does anyone know whether the draft deal will be treated in the IETF 88?Regards,Rogerio Mariano -- View this message in context: http://ietf.10.n7.nabble.com/I-D-Action-draft-ietf-rtgwg-remote-lfa-02-txt-tp369816p386319.html Sent from the IETF - Rtgwg mailing list archive at Nabble.com. ------=_Part_9449_8711346.1380637896371 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, Does anyone know whether the draft deal will be treated in the IETF 88? Regards, Rogerio Mariano
View this message in context: Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt
Sent from the IETF - Rtgwg mailing list archive at Nabble.com.
------=_Part_9449_8711346.1380637896371-- From rsouza.rjo@gmail.com Tue Oct 1 07:38:22 2013 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 D1AE811E8129 for ; Tue, 1 Oct 2013 07:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAGl0pO3-F81 for ; Tue, 1 Oct 2013 07:38:17 -0700 (PDT) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7024111E8143 for ; Tue, 1 Oct 2013 07:38:17 -0700 (PDT) Received: from tom.nabble.com ([192.168.236.105]) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1VR15d-0006Op-3M for rtgwg@ietf.org; Tue, 01 Oct 2013 07:38:17 -0700 Date: Tue, 1 Oct 2013 07:38:17 -0700 (PDT) From: rogeriomariano To: rtgwg@ietf.org Message-ID: <1380638297092-386321.post@n7.nabble.com> In-Reply-To: <59B7D431F843564FBE967123924AD2AB0FD6AF2E@BY2PRD0510MB376.namprd05.prod.outlook.com> References: <59B7D431F843564FBE967123924AD2AB0FD6AF2E@BY2PRD0510MB376.namprd05.prod.outlook.com> Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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, 01 Oct 2013 14:38:22 -0000 Folks, Does anyone know whether the draft deal will be treated in the IETF 88? Regards, Rogerio Mariano -- View this message in context: http://ietf.10.n7.nabble.com/Request-for-review-draft-psarkar-rtgwg-rlfa-node-protection-01-txt-tp375714p386321.html Sent from the IETF - Rtgwg mailing list archive at Nabble.com. From aretana@cisco.com Tue Oct 1 07:40:26 2013 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 5D8A511E8129 for ; Tue, 1 Oct 2013 07:40:26 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-QrYXqbvVrr for ; Tue, 1 Oct 2013 07:40:20 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id CAEB011E8143 for ; Tue, 1 Oct 2013 07:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2126; q=dns/txt; s=iport; t=1380638420; x=1381848020; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=HBM2l6F9rfgfKb1E04H1wH2Neof92mS564IyJawnWMs=; b=WJnGtD5J7FEAolVWzEIsLac0UKJUo50+4v2JNJtaIrmnSCixe45BoHgq h2r6pmabsfWcpORIJOiNZ9dhgbq/qFDwmOnvL5iZiHpoJ8p0i4lMjaR/C PCJ9YvMr8UJhVsgdMtW0u1/XNvi4l/WPxwRw59RSm3boKR0tmfi3vg2yB 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFANzdSlKtJV2Y/2dsb2JhbABagkNEgQrBA4EuFnSCJwEEgQsBCAQBHR0oERQRAgQBEgiHbAMPswUNiWqMZoI6OIMfgQMDlhaOLoU1gySCKg X-IronPort-AV: E=Sophos;i="4.90,1013,1371081600"; d="scan'208,217";a="266691273" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 01 Oct 2013 14:40:20 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r91EeKwE019599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Oct 2013 14:40:20 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.229]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Tue, 1 Oct 2013 09:40:19 -0500 From: "Alvaro Retana (aretana)" To: rogeriomariano , "rtgwg@ietf.org" Subject: Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt Thread-Topic: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt Thread-Index: AQHOV/2rktdCDdrRAES2UM9FazhKE5nhCbMA//+/XgA= Date: Tue, 1 Oct 2013 14:40:19 +0000 Message-ID: In-Reply-To: <1380637896228-386319.post@n7.nabble.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.7] Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94E395391D1xmbalnx15ciscoc_" 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, 01 Oct 2013 14:40:26 -0000 --_000_BBD66FD99311804F80324E8139B3C94E395391D1xmbalnx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 10/1/13 10:31 AM, "rogeriomariano" > wrote: Rogerio: Folks, Does anyone know whether the draft deal will be treated in the IETF = 88? We haven't started working on the agenda yet, so it is perhaps too early to= talk about whether this draft will be discussed in Vancouver or not. In the meant time, if you have comments or questions on the draft, please p= ost them to the list. Thanks! Alvaro. --_000_BBD66FD99311804F80324E8139B3C94E395391D1xmbalnx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <773CD397959B7849AA9158C815E5653F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 10/1/13 10:31 AM, "rogeriomariano" <rsouza.rjo@gmail.com> wrote:

Rogerio:

Folks, Does anyone know whether the draft deal will be treated in the = IETF 88?

We haven't started working on the agenda yet, so it is perhaps too ear= ly to talk about whether this draft will be discussed in Vancouver or not.<= /div>

In the meant time, if you have comments or questions on the draft, ple= ase post them to the list.

Thanks!

Alvaro.
--_000_BBD66FD99311804F80324E8139B3C94E395391D1xmbalnx15ciscoc_-- From jeff.tantsura@ericsson.com Tue Oct 1 11:07:50 2013 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 03DDA21E81E9 for ; Tue, 1 Oct 2013 11:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 721glCZgJCKC for ; Tue, 1 Oct 2013 11:07:44 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id A2BBB11E8153 for ; Tue, 1 Oct 2013 11:07:44 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-60-524b0f6eb827 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 6C.F2.03458.E6F0B425; Tue, 1 Oct 2013 20:07:43 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Tue, 1 Oct 2013 14:07:42 -0400 From: Jeff Tantsura To: "rtgwg@ietf.org" Subject: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt Thread-Topic: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt Thread-Index: AQHOvsRIFEnb2veln0K+pQC0UlQWpJngUkIA//+gKQA= Date: Tue, 1 Oct 2013 18:07:42 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C74839947187@eusaamb109.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4703070BEC@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-ID: <62DAFB9916B3EC43AD3537AB26D35A51@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyuXRPoG4+v3eQwe+dQhYX3vxmdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsu5m1kLNrNX7Nw8iaWBcTpbFyMnh4SAicT+5n9QtpjEhXvr gWwuDiGBo4wS5z++Y4dwljFKLLx5G6yKTcBA4v+34ywgtoiAqkTvrFawuLCAr8T7WafYIOIh EudeT2DsYuQAsq0k3n/XBAmzCKhIfJt6mRHE5hXwlph6dj8ziM0p4CexcHIbWCsj0BHfT61h ArGZBcQlbj2ZzwRxnIDEkj3nmSFsUYmXj/+xgtiiAnoSbcfOsEPElSW+z3nEAtGrI7Fg9yc2 kBOYBawl/s2MhQhrSyxb+JoZ4gRBiZMzn7BMYBSbhWTbLCTdsxC6ZyHpnoWkewEj6ypGjtLi 1LLcdCPDTYzAKDkmwea4g3HBJ8tDjNIcLErivF/eOgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi 4JRqYMx/ZKGWwBirWvlSRKZn09UnszwTDxkWXpQ+LrD9nPjcpQeffLKVPrOrV2/tCabY7xMu XDxwZU/q7lnLPY5ndJ6X/vIn6Pg0yU3ztCLTvpu/1Ag63NX/8r/PjavZKmeWz9LoEanaxWjs PCPSdrec+YlsGcGGmTOFpqjpHoy8kL5k57OFr++mvl6lxFKckWioxVxUnAgAHGsqXWACAAA= 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, 01 Oct 2013 18:07:50 -0000 Hi, Question to the authors of the draft about their intentions, obviously the basic node protection equation(D_opt(Npq, Dst) < D_opt(Npq, Np) + Distance_opt(Np, Dst)) is correct, however the rest is more or less implementation details. So if the authors would like to share the details about their implementation should not the Intended Status be Informational? Cheers, Jeff >> >>>Folks, >>> >>>Does anyone know whether the draft deal will be treated in the IETF 88? >>> >>>Regards, >>> >>>Rogerio Mariano >>> >>> >>> >>> >>>-- >>>View this message in context: >>>http://ietf.10.n7.nabble.com/Request-for-review-draft-psarkar-rtgwg-rlfa >>>- >>>n >>>ode-protection-01-txt-tp375714p386321.html >>>Sent from the IETF - Rtgwg mailing list archive at Nabble.com. >>>_______________________________________________ >>>rtgwg mailing list >>>rtgwg@ietf.org >>>https://www.ietf.org/mailman/listinfo/rtgwg >> > From akatlas@gmail.com Tue Oct 1 14:38:44 2013 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 E24A321F9FBF for ; Tue, 1 Oct 2013 14:38:43 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAIX5PlhWEdK for ; Tue, 1 Oct 2013 14:38:36 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id AAA9A21F9F70 for ; Tue, 1 Oct 2013 14:38:14 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id eh20so6372378lab.4 for ; Tue, 01 Oct 2013 14:38:14 -0700 (PDT) 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 :content-type; bh=Qdkud/NElLc6ip9zw/651SPf27HI4fjCXt7BmLMwgYY=; b=sMV5L3iozA9U7C0yByUizkBWPJvZ2C2cZ4Pp+oJR+efpWlDocG0zg2VbtSfDe161pm BjzQuM/yuqb4T/0qY4ZW6lIoWT8BJ3SA6jRWt2uuD8pV96CeLc9y/rhZhHC02pSk5DBo /vJBhSqyTQGHKVVcG/7sgwwXWDeDv/GTBVQsQNl8AoTi99v7zWqfyrIxytC/HCRh7Tua r5PvUNJDXPcwQtlcRz2nOKadfOkVm8dWpALsy44iOY7JDtN8yii0felOVTiUSv1Muypy dpq/mxcCZYiJPIPsOokP+JgFxGrGGUm7kjsEd+x5FCZ3urri5GoFBGJNLVrZMF5xFRBk ZJVQ== MIME-Version: 1.0 X-Received: by 10.112.57.49 with SMTP id f17mr28975585lbq.26.1380663494061; Tue, 01 Oct 2013 14:38:14 -0700 (PDT) Received: by 10.112.139.202 with HTTP; Tue, 1 Oct 2013 14:38:14 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Oct 2013 17:38:14 -0400 Message-ID: Subject: Re: WG Last Call for draft-ietf-rtgwg-cl-requirement-11 From: Alia Atlas To: "rtgwg@ietf.org" , Lou Berger , "draft-ietf-rtgwg-cl-requirement@tools.ietf.org" Content-Type: multipart/alternative; boundary=001a1133eaca1e33c304e7b4c59f 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, 01 Oct 2013 21:38:44 -0000 --001a1133eaca1e33c304e7b4c59f Content-Type: text/plain; charset=ISO-8859-1 This second WG Last Call got absolutely no comments. Does this group of generally opinionated and thoughtful people truly have nothing to say? If so and given the previous WGLC succeeded, then on Oct 9, I will take silence as consent and indicate that on the draft shepherd's write-up... Alia On Fri, Sep 13, 2013 at 1:28 PM, Alia Atlas wrote: > This is to start a second Working Group Last Call on > draft-ietf-rtgwg-cl-requirement-11. As you may recall, we successfully > completed a WGLC on draft-ietf-rtgwg-cl-requirement-10. After that, > there was concern about the use of ITU terminology (composite-link and NPO) > where the draft was not actually using the exact meaning specified by the > ITU. > > Therefore, it was decided to return the draft to the WG for a quick > terminology update (and also to address some other review comments). > > This WGLC will end on September 30. > > Thanks, > Alia > --001a1133eaca1e33c304e7b4c59f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This second WG Last Call got absolutely no comments.
D= oes this group of generally opinionated and thoughtful people truly have no= thing to say?
If so and given the previous WGLC succeeded, then o= n Oct 9, I will take silence as consent and indicate that on the draft shep= herd's write-up...

Alia


On Fri, Sep 13, 2013 at 1:28 PM, Alia Atlas <akatla= s@gmail.com> wrote:
This is to start a second W= orking Group Last Call on draft-ietf-rtgwg-cl-requirement-11.=A0As you may recall, we succ= essfully completed a WGLC on draft-ietf-rtgwg-cl-requirement-10. =A0After that, the= re was concern about the use of ITU terminology (composite-link and NPO) wh= ere the draft was not actually using the exact meaning specified by the ITU= .

Theref= ore, it was decided to return the draft to the WG for a quick terminology u= pdate (and also to address some other review comments).=A0

This W= GLC will end on September 30.

Thanks,
Ali= a

--001a1133eaca1e33c304e7b4c59f-- From aretana@cisco.com Tue Oct 1 14:46:53 2013 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 BFD4C21E818A for ; Tue, 1 Oct 2013 14:46:53 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5BqP6XSRSXW for ; Tue, 1 Oct 2013 14:46:42 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id F19DB21E80C7 for ; Tue, 1 Oct 2013 14:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4921; q=dns/txt; s=iport; t=1380663993; x=1381873593; h=from:to:subject:date:message-id:mime-version; bh=B+FZ8jpeMgqIrLS3aYWH7fCIz+iKMbVe54olz7hOweo=; b=TvvgkrV+IL/c+P1nkd5ug1+dTwegcnTMuaN/UrnFYpjI5gzjBOS9soUt inN2+FTE5B5e+CbKQjYu3IwD72m9lPqbG+zMRCx9CxatjP7dX87AzUSoB FQvQxQX/8XpLkhB8jGc4nrnci24GfDEUJJ6GPPvodT9yg/eScNINf+uQe k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAMhBS1KtJXHA/2dsb2JhbABZgweBCsEKgTIWbQeCJwEEgQsBDB5WJwQbh36cD6FFjyCDV4EDA5QilVeDJIIq X-IronPort-AV: E=Sophos;i="4.90,1015,1371081600"; d="scan'208,217";a="266866466" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 01 Oct 2013 21:46:32 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r91LkWGp018505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 1 Oct 2013 21:46:32 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.229]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Tue, 1 Oct 2013 16:46:31 -0500 From: "Alvaro Retana (aretana)" To: "rtgwg@ietf.org" Subject: IETF 88 Agenda Items Thread-Topic: IETF 88 Agenda Items Thread-Index: AQHOvu+xvvXhYYVgF0uuaDZky93MeA== Date: Tue, 1 Oct 2013 21:46:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.7] Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94E3953FFD0xmbalnx15ciscoc_" 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, 01 Oct 2013 21:46:53 -0000 --_000_BBD66FD99311804F80324E8139B3C94E3953FFD0xmbalnx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! As I'm sure many of you have noticed, the cut-off date for ID submission is= Oct/21 (for all drafts, including -00). You may have also noticed the fol= lowing dates related to WG agendas: 2013-10-23 (Wednesday): Draft Working Group agendas due 2013-10-28 (Monday): Revised Working Group agendas ..resulting in very little time between them. We have requested our usual slot for Vancouver (the preliminary agenda shou= ld come out later this week), and would like you to start thinking about ag= enda items. In order to avoid an avalanche of requests at the last possibl= e minute we want to set some ground rules ahead of time. Please send requests by Monday Oct/21 to be included in the Draft WG Agenda= . Note that the draft MUST have been published already to be considered. = See other considerations below. For a draft to be considered for the final WG agenda: 1. It MUST have been published already. 2. The authors SHOULD start a discussion on the list highlighting the ma= in points of the draft (don't just send a copy of the announcement and/or p= aste the abstract). We will prioritize existing WG items first, followed by work explicitly ide= ntified in the WG charter. For other new work, if time permits, we will sc= hedule it on a first-come basis with preference given to items for which th= ere has already been a discussion on the list. Thanks! Alvaro + Alia. --_000_BBD66FD99311804F80324E8139B3C94E3953FFD0xmbalnx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi!
 
As I'm sure many of you have noticed= , the cut-off date for ID submission is Oct/21 (for all drafts, including -= 00).  You may have also noticed the following dates related to WG agen= das:
 
2013-10-23 (Wednesday): Draft Workin= g Group agendas due
2013-10-28 (Monday): Revised Working= Group agendas
 
..resulting in very little time betw= een them.
 
 
We have requested our usual slot for= Vancouver (the preliminary agenda should come out later this week), and wo= uld like you to start thinking about agenda items.  In order to avoid = an avalanche of requests at the last possible minute we want to set some ground rules ahead of time.

Please send requests by Monday Oct/2= 1 to be included in the Draft WG Agenda.  Note that the draft MUST hav= e been published already to be considered.  See other considerations b= elow.

For a draft to be considered for the= final WG agenda:
  1. It MUST have been published already.<= /font>
  2. The autho= rs SHOULD start a discussion on the list highlighting the main points of th= e draft (don't just send a copy of the announcement and/or paste the abstra= ct).

We will prioritize = existing WG items first, followed by work explicitly identified in the WG c= harter.  For other new work, if time permits, we will schedule it on a= first-come basis with preference given to items for which there has already been a discussion on the list.=
 
Thanks!
 
Alvaro + Alia.
--_000_BBD66FD99311804F80324E8139B3C94E3953FFD0xmbalnx15ciscoc_-- From akatlas@gmail.com Tue Oct 1 18:28:06 2013 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 2BCC811E8211 for ; Tue, 1 Oct 2013 18:28:06 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBzn4JbKNMet for ; Tue, 1 Oct 2013 18:27:59 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 691FC11E8153 for ; Tue, 1 Oct 2013 18:27:58 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id x13so351087ief.29 for ; Tue, 01 Oct 2013 18:27:57 -0700 (PDT) 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=Kq6kDgRQMPL6hqkmRVuMKLxNB2UYEGgcOB5XPV/MAXs=; b=lVKmhOlar8o4Gzci/TTeqkKSZ2/lsjWvLBu0jTxz7GZ+lxzK6+/LAcNM3u2k5D3yMm 4DQlijm2qzllBmTWMTrJ1EMojig89aUAmAxIPxqWAgXWJuIH6GNbEvxISQ/TNwBXVVrm cSob0R6AeECXMqZsrv0fCzyqOiSRwLqS/MTd7hRLSxkWkps5Op05MmEt0Id2lt4DRWZl wKMc14PYyGvOpI5JcRKVW39eo2svEyLRqCfTMURbmgJOY0AyT7tNsRSmRByRiTggex9z 0KwOtUljChF3JaYY/tQ/5wRDNPKkJkSKWy7iM9s3ZDCoi6037Pv49m/2A9daD/0PgruD t0aQ== MIME-Version: 1.0 X-Received: by 10.50.120.104 with SMTP id lb8mr319715igb.22.1380677277572; Tue, 01 Oct 2013 18:27:57 -0700 (PDT) Received: by 10.64.13.145 with HTTP; Tue, 1 Oct 2013 18:27:57 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Oct 2013 21:27:57 -0400 Message-ID: Subject: Re: WG Last Call for draft-ietf-rtgwg-cl-requirement-11 From: Alia Atlas To: Curtis Villamizar Content-Type: multipart/alternative; boundary=047d7bd76bb2ade74b04e7b7fa81 Cc: "draft-ietf-rtgwg-cl-requirement@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, 02 Oct 2013 01:28:06 -0000 --047d7bd76bb2ade74b04e7b7fa81 Content-Type: text/plain; charset=ISO-8859-1 I did that on Sept 13. Alia On Tue, Oct 1, 2013 at 8:59 PM, Curtis Villamizar wrote: > Alia, > > We should send a heads up to MPLS and CCAMP. Would you please do that as > WG chair. > > Curtis > > > Curtis Villamizar > Sent from my tablet so please disregard sloppy typing. > > > Alia Atlas wrote: > > This second WG Last Call got absolutely no comments. > Does this group of generally opinionated and thoughtful people truly have > nothing to say? > If so and given the previous WGLC succeeded, then on Oct 9, I will take > silence as consent and indicate that on the draft shepherd's write-up... > > Alia > > > On Fri, Sep 13, 2013 at 1:28 PM, Alia Atlas wrote: > >> This is to start a second Working Group Last Call on >> draft-ietf-rtgwg-cl-requirement-11. As you may recall, we successfully >> completed a WGLC on draft-ietf-rtgwg-cl-requirement-10. After that, >> there was concern about the use of ITU terminology (composite-link and NPO) >> where the draft was not actually using the exact meaning specified by the >> ITU. >> >> Therefore, it was decided to return the draft to the WG for a quick >> terminology update (and also to address some other review comments). >> >> This WGLC will end on September 30. >> >> Thanks, >> Alia >> > > --047d7bd76bb2ade74b04e7b7fa81 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I did that on Sept 13.

Alia
=


On Tue, Oct 1= , 2013 at 8:59 PM, Curtis Villamizar <curtis@occnc.com> wrote= :
Alia,

We = should send a heads up to MPLS and CCAMP.=A0 Would you please do that as WG= chair.

Curtis


Curtis V= illamizar <curtis@= occnc.com>
Sent from my tablet so please disregard sloppy = typing.


Alia Atlas <akatlas@gmail.com> = wrote:

This second WG Last Call got absolutely no c= omments.
Does this group of generally opinionated and thoughtful people truly have n= othing to say?
If so and given the previous WGLC succeeded, then = on Oct 9, I will take silence as consent and indicate that on the draft she= pherd's write-up...

Alia


On Fri, Sep 13, 2013 at 1:28 PM, Alia Atlas <akatla= s@gmail.com> wrote:
This is to start a second W= orking Group Last Call on draft-ietf-rtgwg-cl-requirement-11.=A0As you may recall, we succ= essfully completed a WGLC on draft-ietf-rtgwg-cl-requirement-10. =A0After that, the= re was concern about the use of ITU terminology (composite-link and NPO) wh= ere the draft was not actually using the exact meaning specified by the ITU= .

Theref= ore, it was decided to return the draft to the WG for a quick terminology u= pdate (and also to address some other review comments).=A0

This W= GLC will end on September 30.

Thanks,
Ali= a


--047d7bd76bb2ade74b04e7b7fa81-- From hannes@juniper.net Wed Oct 2 01:52:20 2013 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 DA03D21E8155 for ; Wed, 2 Oct 2013 01:52:20 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mx5PQA1IEkh9 for ; Wed, 2 Oct 2013 01:52:07 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0250.outbound.messaging.microsoft.com [213.199.154.250]) by ietfa.amsl.com (Postfix) with ESMTP id 2049321E80F1 for ; Wed, 2 Oct 2013 01:52:05 -0700 (PDT) Received: from mail98-db9-R.bigfish.com (10.174.16.236) by DB9EHSOBE037.bigfish.com (10.174.14.100) with Microsoft SMTP Server id 14.1.225.22; Wed, 2 Oct 2013 08:52:04 +0000 Received: from mail98-db9 (localhost [127.0.0.1]) by mail98-db9-R.bigfish.com (Postfix) with ESMTP id E1C9E2E015A; Wed, 2 Oct 2013 08:52:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.2.21; KIP:(null); UIP:(null); IPV:NLI; H:BN1PRD0512HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -18 X-BigFish: VPS-18(zz98dI9371I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h946hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail98-db9: domain of juniper.net designates 132.245.2.21 as permitted sender) client-ip=132.245.2.21; envelope-from=hannes@juniper.net; helo=BN1PRD0512HT001.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail98-db9 (localhost.localdomain [127.0.0.1]) by mail98-db9 (MessageSwitch) id 1380703923179921_7628; Wed, 2 Oct 2013 08:52:03 +0000 (UTC) Received: from DB9EHSMHS016.bigfish.com (unknown [10.174.16.234]) by mail98-db9.bigfish.com (Postfix) with ESMTP id 26F8F42006F; Wed, 2 Oct 2013 08:52:03 +0000 (UTC) Received: from BN1PRD0512HT001.namprd05.prod.outlook.com (132.245.2.21) by DB9EHSMHS016.bigfish.com (10.174.14.26) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 2 Oct 2013 08:52:02 +0000 Received: from hannes-sslvpn-nc.jnpr.net (193.110.54.36) by pod51010.outlook.com (10.255.193.34) with Microsoft SMTP Server (TLS) id 14.16.359.1; Wed, 2 Oct 2013 08:52:00 +0000 Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Hannes Gredler In-Reply-To: <60DEDD93F5E54B4AB55647B8B6C74839947187@eusaamb109.ericsson.se> Date: Wed, 2 Oct 2013 10:51:55 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <7696F762-9478-450F-81EE-55C0611FF5D3@juniper.net> References: <60DEDD93F5E54B4AB55647B8B6C74839947187@eusaamb109.ericsson.se> To: Jeff Tantsura X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.54.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 02 Oct 2013 08:52:21 -0000 hi jeff, the single biggest problem with draft-ietf-rtgwg-remote-lfa is that it leaves a lot of ambiguity how to implement certain functionality - node-protection, manageability among them. 'the right thing'(=99) would be to fix the rlfa spec, which somehow seems not possible, so it remains in the state which it is now =85 what i call 'underspecified'. draft-psarkar-rtgwg-rlfa-node-protection is a contribution coming from a dev-team which had to implement this for OSPF and IS-IS and make it work altogether. we got the impression that customers want to use both node-protection *and* manageability together and as such you need to do things a certain way which is described in the draft. IMO thats a bit more than just 'implementation details' but rather a guidance how to get this right. therefore the intended status is 'proposed standard'. /hannes On Oct 1, 2013, at 8:07 PM, Jeff Tantsura wrote: > Hi, >=20 > Question to the authors of the draft about their intentions, obviously = the > basic node protection equation(D_opt(Npq, Dst) < D_opt(Npq, Np) + > Distance_opt(Np, Dst)) is correct, however the rest is more or less > implementation details. > So if the authors would like to share the details about their > implementation should not the Intended Status be Informational? >=20 > Cheers, > Jeff >=20 >=20 >>>=20 >>>> Folks, >>>>=20 >>>> Does anyone know whether the draft deal will be treated in the IETF = 88? >>>>=20 >>>> Regards, >>>>=20 >>>> Rogerio Mariano >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> View this message in context: >>>> = http://ietf.10.n7.nabble.com/Request-for-review-draft-psarkar-rtgwg-rlfa >>>> - >>>> n >>>> ode-protection-01-txt-tp375714p386321.html >>>> Sent from the IETF - Rtgwg mailing list archive at Nabble.com. >>>> _______________________________________________ >>>> rtgwg mailing list >>>> rtgwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtgwg >>>=20 >>=20 >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg >=20 >=20 From stbryant@cisco.com Wed Oct 2 04:27:58 2013 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 6447121F99FB for ; Wed, 2 Oct 2013 04:27:58 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIDMZkagy0ZZ for ; Wed, 2 Oct 2013 04:27:45 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0E811E81B4 for ; Wed, 2 Oct 2013 04:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4786; q=dns/txt; s=iport; t=1380713179; x=1381922779; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=6j4M2GBQ7qUiHt/j0LQRbk2jtcdiANNRgCRIhi9U7eU=; b=dSobOYRyyM6l5K/ljmoyvWAeWhh0hj13VAUIngkhxs7cp+AR5X45xJ5Q xPQag53WiqElP3HTGbz7487peYEoVmOnynrAfiqgdE2yhS/s5P2MTxbtz L0qJBuE9uOuEO0S7dvR6WdcMUAIS4j7vg6vdbRwbV4puNtZbZk8+lWwp4 E=; X-IronPort-AV: E=Sophos;i="4.90,1018,1371081600"; d="scan'208,217";a="87110371" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 02 Oct 2013 11:26:18 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r92BQCcm031208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Oct 2013 11:26:14 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r92BQBN4011548; Wed, 2 Oct 2013 12:26:11 +0100 (BST) Message-ID: <524C02D3.6050309@cisco.com> Date: Wed, 02 Oct 2013 12:26:11 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Alvaro Retana (aretana)" Subject: Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030106080200050803000201" Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , rogeriomariano , "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, 02 Oct 2013 11:27:58 -0000 This is a multi-part message in MIME format. --------------030106080200050803000201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I will try to get a new version out this week or next. I plan to put in the algorithm text, although having discussed this with Mike, our inclination is to include this as an appendix since it is not required for interoperability that you do the computation that way. I will look at the issues left unresolved and any comments posted in response to this email. I see no reason to request a slot at IETF88 unless there remain technical issues that we are unable to resolve on this list. - Stewart (as duty editor of the draft) On 01/10/2013 15:40, Alvaro Retana (aretana) wrote: > On 10/1/13 10:31 AM, "rogeriomariano" > wrote: > > Rogerio: > > Folks, Does anyone know whether the draft deal will be treated in > the IETF 88? > > > We haven't started working on the agenda yet, so it is perhaps too > early to talk about whether this draft will be discussed in Vancouver > or not. > > In the meant time, if you have comments or questions on the draft, > please post them to the list. > > Thanks! > > Alvaro. > > > _______________________________________________ > 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 --------------030106080200050803000201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I will try to get a new version out this week or next.

I plan to put in the algorithm text, although having discussed
this with Mike, our inclination is to include this as an
appendix since it is not required for interoperability that
you do the computation that way.

I will look at the issues left unresolved and any comments
posted in response to this email.

I see no reason to request a slot at IETF88 unless there remain
technical issues that we are unable to resolve on this list.

- Stewart (as duty editor of the draft)



On 01/10/2013 15:40, Alvaro Retana (aretana) wrote:
On 10/1/13 10:31 AM, "rogeriomariano" <rsouza.rjo@gmail.com> wrote:

Rogerio:

Folks, Does anyone know whether the draft deal will be treated in the IETF 88?

We haven't started working on the agenda yet, so it is perhaps too early to talk about whether this draft will be discussed in Vancouver or not.

In the meant time, if you have comments or questions on the draft, please post them to the list.

Thanks!

Alvaro.


_______________________________________________
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
--------------030106080200050803000201-- From akatlas@gmail.com Wed Oct 2 05:27:14 2013 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 78F3111E8273 for ; Wed, 2 Oct 2013 05:27:14 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txOoHLWo5Z8h for ; Wed, 2 Oct 2013 05:27:07 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 385A621F970E for ; Wed, 2 Oct 2013 05:26:19 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id u16so1519448iet.19 for ; Wed, 02 Oct 2013 05:26:18 -0700 (PDT) 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=NB4OCa2Hk9fULmZjrk26ms+CfIADK1IyxrUkOzitb/U=; b=a+XwFjhouZ5OvrDnm6aqgzYqOnO6Keb+ncvYBWguiM/NWFHI1Ad8GOr622z7h5uBt7 dkEw6thgbzMj90T22q+dduR/3qORXipI3i/KOXIS3lsogif5BBaDLa2l6rknBxwCqM8s LPJXfLQgKILmao69FS9s4p80dnoAH7eiG4MQchVGr1cWwJ52el7ZUGR0W6CwbE8jylmu mtS6avefI7TF8RDgE4dZ9g5K78sdnynZtOn+zv1jkBVeUhkkMHVAnXjjUgKKbyae/cAa TP4ubt1ojm9TEvaiEIfdLY2OJzgKC2PDayvUNHJkqun7AjMpyXCzMRldthN5ZCRJcuuj j5bg== MIME-Version: 1.0 X-Received: by 10.50.30.42 with SMTP id p10mr1387051igh.5.1380716778595; Wed, 02 Oct 2013 05:26:18 -0700 (PDT) Received: by 10.64.13.145 with HTTP; Wed, 2 Oct 2013 05:26:18 -0700 (PDT) In-Reply-To: <7696F762-9478-450F-81EE-55C0611FF5D3@juniper.net> References: <60DEDD93F5E54B4AB55647B8B6C74839947187@eusaamb109.ericsson.se> <7696F762-9478-450F-81EE-55C0611FF5D3@juniper.net> Date: Wed, 2 Oct 2013 08:26:18 -0400 Message-ID: Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt From: Alia Atlas To: Hannes Gredler Content-Type: multipart/alternative; boundary=047d7bdc9db21faeb504e7c12d36 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, 02 Oct 2013 12:27:14 -0000 --047d7bdc9db21faeb504e7c12d36 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable It would be excellent to see progress on the Remote LFA draft and on merging at least the two drafts that describe how to do node-protection for Remote LFA before the Vancouver IETF. Alia On Wed, Oct 2, 2013 at 4:51 AM, Hannes Gredler wrote: > hi jeff, > > the single biggest problem with draft-ietf-rtgwg-remote-lfa > is that it leaves a lot of ambiguity how to implement certain > functionality - node-protection, manageability among them. > > 'the right thing'(=99) would be to fix the rlfa spec, > which somehow seems not possible, so it remains > in the state which it is now =85 what i call 'underspecified'. > > draft-psarkar-rtgwg-rlfa-node-protection is a contribution > coming from a dev-team which had to implement this for > OSPF and IS-IS and make it work altogether. > > we got the impression that customers want to use both > node-protection *and* manageability together and as such > you need to do things a certain way which is described in > the draft. IMO thats a bit more than just > 'implementation details' but rather a guidance > how to get this right. therefore the intended status is > 'proposed standard'. > > /hannes > > On Oct 1, 2013, at 8:07 PM, Jeff Tantsura wrote: > > > Hi, > > > > Question to the authors of the draft about their intentions, obviously > the > > basic node protection equation(D_opt(Npq, Dst) < D_opt(Npq, Np) + > > Distance_opt(Np, Dst)) is correct, however the rest is more or less > > implementation details. > > So if the authors would like to share the details about their > > implementation should not the Intended Status be Informational? > > > > Cheers, > > Jeff > > > > > >>> > >>>> Folks, > >>>> > >>>> Does anyone know whether the draft deal will be treated in the IETF > 88? > >>>> > >>>> Regards, > >>>> > >>>> Rogerio Mariano > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> View this message in context: > >>>> > http://ietf.10.n7.nabble.com/Request-for-review-draft-psarkar-rtgwg-rlfa > >>>> - > >>>> n > >>>> ode-protection-01-txt-tp375714p386321.html > >>>> Sent from the IETF - Rtgwg mailing list archive at Nabble.com. > >>>> _______________________________________________ > >>>> 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 > > > > > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > --047d7bdc9db21faeb504e7c12d36 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
It would be excellent to see progress on the Remote LFA dr= aft and on merging at least the two drafts that describe how to do node-pro= tection for Remote LFA before the Vancouver IETF.

Alia


On Wed,= Oct 2, 2013 at 4:51 AM, Hannes Gredler <hannes@juniper.net> wrote:
hi jeff,

the single biggest problem with draft-ietf-rtgwg-remote-lfa
is that it leaves a lot of ambiguity how to implement certain
functionality - node-protection, manageability among them.

'the right thing'(=99) =A0would be to fix the rlfa spec,
which somehow seems not possible, so it remains
in the state which it is now =85 what i call 'underspecified'.

draft-psarkar-rtgwg-rlfa-node-protection is a contribution
coming from a dev-team which had to implement this for
OSPF and IS-IS and make it work altogether.

we got the impression that customers want to use both
node-protection *and* manageability together and as such
you need to do things a certain way which is described in
the draft. IMO thats a bit more than just
'implementation details' but rather a guidance
how to get this right. therefore the intended status is
'proposed standard'.

/hannes

On Oct 1, 2013, at 8:07 PM, Jeff Tantsura wrote:

> Hi,
>
> Question to the authors of the draft about their intentions, obviously= the
> basic node protection equation(D_opt(Npq, Dst) < D_opt(Npq, Np) + > Distance_opt(Np, Dst)) is correct, however the rest is more or less > implementation details.
> So if the authors would like to share the details about their
> implementation should not the Intended Status be Informational?
>
> Cheers,
> Jeff
>
>
>>>
>>>> Folks,
>>>>
>>>> Does anyone know whether the draft deal will be treated in= the IETF 88?
>>>>
>>>> Regards,
>>>>
>>>> Rogerio Mariano
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://ietf.10.n7.nabble.com/R= equest-for-review-draft-psarkar-rtgwg-rlfa
>>>> -
>>>> n
>>>> ode-protection-01-txt-tp375714p386321.html
>>>> Sent from the IETF - Rtgwg mailing list archive at Nabble.= com.
>>>> _______________________________________________
>>>> 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
>
>


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

--047d7bdc9db21faeb504e7c12d36-- From jdrake@juniper.net Wed Oct 2 05:53:54 2013 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 438B611E810B for ; Wed, 2 Oct 2013 05:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpDYPRyPuSFc for ; Wed, 2 Oct 2013 05:53:43 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 3E88321F8495 for ; Wed, 2 Oct 2013 05:52:58 -0700 (PDT) Received: from mail181-co1-R.bigfish.com (10.243.78.239) by CO1EHSOBE034.bigfish.com (10.243.66.99) with Microsoft SMTP Server id 14.1.225.22; Wed, 2 Oct 2013 12:52:57 +0000 Received: from mail181-co1 (localhost [127.0.0.1]) by mail181-co1-R.bigfish.com (Postfix) with ESMTP id 84F4F540096; Wed, 2 Oct 2013 12:52:57 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz98dI9371Ic85fh1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzc2hz8275ch1d7338h1de098h1033IL17326ah18c673h1de097h186068h18de19h8275bhf14I8275dhz2fh2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h9a9j1155h) Received-SPF: pass (mail181-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(377454003)(38605003)(199002)(189002)(51704005)(74366001)(65816001)(19609705001)(80022001)(74662001)(31966008)(74706001)(74502001)(47446002)(54356001)(53806001)(1941001)(47736001)(49866001)(50986001)(47976001)(81542001)(74876001)(4396001)(19300405004)(74316001)(16236675002)(83072001)(66066001)(33646001)(46102001)(79102001)(81816001)(81342001)(15975445006)(51856001)(81686001)(83322001)(19580405001)(69226001)(19580395003)(77096001)(76796001)(76786001)(76482001)(76576001)(56816003)(59766001)(77982001)(15202345003)(63696002)(56776001)(80976001)(54316002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB439; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail181-co1 (localhost.localdomain [127.0.0.1]) by mail181-co1 (MessageSwitch) id 1380718375301587_31399; Wed, 2 Oct 2013 12:52:55 +0000 (UTC) Received: from CO1EHSMHS005.bigfish.com (unknown [10.243.78.229]) by mail181-co1.bigfish.com (Postfix) with ESMTP id 4611A5C0053; Wed, 2 Oct 2013 12:52:55 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS005.bigfish.com (10.243.66.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 2 Oct 2013 12:52:55 +0000 Received: from BN1PR05MB439.namprd05.prod.outlook.com (10.141.58.22) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.359.1; Wed, 2 Oct 2013 12:52:54 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BN1PR05MB439.namprd05.prod.outlook.com (10.141.58.22) with Microsoft SMTP Server (TLS) id 15.0.775.9; Wed, 2 Oct 2013 12:52:52 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.177]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.177]) with mapi id 15.00.0775.005; Wed, 2 Oct 2013 12:52:51 +0000 From: John E Drake To: Alia Atlas , Hannes Gredler Subject: RE: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt Thread-Topic: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt Thread-Index: AQHOv0zGewYlf81MBUe/2NdLYDgaCZnhVpYAgAAHX6A= Date: Wed, 2 Oct 2013 12:52:50 +0000 Message-ID: References: <60DEDD93F5E54B4AB55647B8B6C74839947187@eusaamb109.ericsson.se> <7696F762-9478-450F-81EE-55C0611FF5D3@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0987ACA2E2 Content-Type: multipart/alternative; boundary="_000_ef0579f5ef5542d5a426d4cb615f7c27BY2PR05MB142namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 02 Oct 2013 12:53:54 -0000 --_000_ef0579f5ef5542d5a426d4cb615f7c27BY2PR05MB142namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What a concept Yours Irrespectively, John From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of A= lia Atlas Sent: Wednesday, October 02, 2013 5:26 AM To: Hannes Gredler Cc: rtgwg@ietf.org Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-= 01.txt It would be excellent to see progress on the Remote LFA draft and on mergin= g at least the two drafts that describe how to do node-protection for Remot= e LFA before the Vancouver IETF. Alia On Wed, Oct 2, 2013 at 4:51 AM, Hannes Gredler > wrote: hi jeff, the single biggest problem with draft-ietf-rtgwg-remote-lfa is that it leaves a lot of ambiguity how to implement certain functionality - node-protection, manageability among them. 'the right thing'((tm)) would be to fix the rlfa spec, which somehow seems not possible, so it remains in the state which it is now ... what i call 'underspecified'. draft-psarkar-rtgwg-rlfa-node-protection is a contribution coming from a dev-team which had to implement this for OSPF and IS-IS and make it work altogether. we got the impression that customers want to use both node-protection *and* manageability together and as such you need to do things a certain way which is described in the draft. IMO thats a bit more than just 'implementation details' but rather a guidance how to get this right. therefore the intended status is 'proposed standard'. /hannes On Oct 1, 2013, at 8:07 PM, Jeff Tantsura wrote: > Hi, > > Question to the authors of the draft about their intentions, obviously th= e > basic node protection equation(D_opt(Npq, Dst) < D_opt(Npq, Np) + > Distance_opt(Np, Dst)) is correct, however the rest is more or less > implementation details. > So if the authors would like to share the details about their > implementation should not the Intended Status be Informational? > > Cheers, > Jeff > > >>> >>>> Folks, >>>> >>>> Does anyone know whether the draft deal will be treated in the IETF 88= ? >>>> >>>> Regards, >>>> >>>> Rogerio Mariano >>>> >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://ietf.10.n7.nabble.com/Request-for-review-draft-psarkar-rtgwg-rl= fa >>>> - >>>> n >>>> ode-protection-01-txt-tp375714p386321.html >>>> Sent from the IETF - Rtgwg mailing list archive at Nabble.com. >>>> _______________________________________________ >>>> 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 > > _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg --_000_ef0579f5ef5542d5a426d4cb615f7c27BY2PR05MB142namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What a concept=

 <= /p>

Yours Irrespectively,

 <= /p>

John

 <= /p>

From: rtgwg-= bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Wednesday, October 02, 2013 5:26 AM
To: Hannes Gredler
Cc: rtgwg@ietf.org
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-prot= ection-01.txt

 

It would be excellent to see progress on the Remote = LFA draft and on merging at least the two drafts that describe how to do no= de-protection for Remote LFA before the Vancouver IETF.

 

Alia

 

On Wed, Oct 2, 2013 at 4:51 AM, Hannes Gredler <<= a href=3D"mailto:hannes@juniper.net" target=3D"_blank">hannes@juniper.net> wrote:

hi jeff,

the single biggest problem with draft-ietf-rtgwg-remote-lfa
is that it leaves a lot of ambiguity how to implement certain
functionality - node-protection, manageability among them.

'the right thing'(™)  would be to fix the rlfa spec,
which somehow seems not possible, so it remains
in the state which it is now … what i call 'underspecified'.

draft-psarkar-rtgwg-rlfa-node-protection is a contribution
coming from a dev-team which had to implement this for
OSPF and IS-IS and make it work altogether.

we got the impression that customers want to use both
node-protection *and* manageability together and as such
you need to do things a certain way which is described in
the draft. IMO thats a bit more than just
'implementation details' but rather a guidance
how to get this right. therefore the intended status is
'proposed standard'.

/hannes


On Oct 1, 2013, at 8:07 PM, Jeff Tantsura wrote:

> Hi,
>
> Question to the authors of the draft about their intentions, obviously= the
> basic node protection equation(D_opt(Npq, Dst) < D_opt(Npq, Np) = 3;
> Distance_opt(Np, Dst)) is correct, however the rest is more or less > implementation details.
> So if the authors would like to share the details about their
> implementation should not the Intended Status be Informational?
>
> Cheers,
> Jeff
>
>
>>>
>>>> Folks,
>>>>
>>>> Does anyone know whether the draft deal will be treated in= the IETF 88?
>>>>
>>>> Regards,
>>>>
>>>> Rogerio Mariano
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://ietf.10.n7.nabble.com/Request-for-review-draft-psarkar-rtgwg-rlfa
>>>> -
>>>> n
>>>> ode-protection-01-txt-tp375714p386321.html
>>>> Sent from the IETF - Rtgwg mailing list archive at Nabble.= com.
>>>> _______________________________________________
>>>> 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
>
>


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

 

--_000_ef0579f5ef5542d5a426d4cb615f7c27BY2PR05MB142namprd05pro_-- From curtis@occnc.com Tue Oct 1 18:02:01 2013 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 203A111E8285 for ; Tue, 1 Oct 2013 18:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RA1cqjcJicbS for ; Tue, 1 Oct 2013 18:01:48 -0700 (PDT) Received: from daor.pair.com (daor.pair.com [209.68.5.146]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4F211E826C for ; Tue, 1 Oct 2013 18:00:00 -0700 (PDT) Received: from [173.9.106.154] (unknown [173.9.106.154]) by daor.pair.com (Postfix) with ESMTPSA id 9556C10E480; Tue, 1 Oct 2013 20:59:53 -0400 (EDT) Date: Tue, 01 Oct 2013 20:59:32 -0400 Subject: Re: WG Last Call for draft-ietf-rtgwg-cl-requirement-11 Message-ID: From: Curtis Villamizar To: Alia Atlas MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=--_com.android.email_62377787841340_alt X-Mailman-Approved-At: Wed, 02 Oct 2013 14:55:27 -0700 Cc: " draft-ietf-rtgwg-cl-requirement@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, 02 Oct 2013 01:02:01 -0000 ----_com.android.email_62377787841340_alt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QWxpYSwKCldlIHNob3VsZCBzZW5kIGEgaGVhZHMgdXAgdG8gTVBMUyBhbmQgQ0NBTVAuICBXb3Vs ZCB5b3UgcGxlYXNlIGRvIHRoYXQgYXMgV0cgY2hhaXIuCgpDdXJ0aXMKCgpDdXJ0aXMgVmlsbGFt aXphciA8Y3VydGlzQG9jY25jLmNvbT4KU2VudCBmcm9tIG15IHRhYmxldCBzbyBwbGVhc2UgZGlz cmVnYXJkIHNsb3BweSB0eXBpbmcuCgpBbGlhIEF0bGFzIDxha2F0bGFzQGdtYWlsLmNvbT4gd3Jv dGU6Cgo+VGhpcyBzZWNvbmQgV0cgTGFzdCBDYWxsIGdvdCBhYnNvbHV0ZWx5IG5vIGNvbW1lbnRz Lgo+RG9lcyB0aGlzIGdyb3VwIG9mIGdlbmVyYWxseSBvcGluaW9uYXRlZCBhbmQgdGhvdWdodGZ1 bCBwZW9wbGUgdHJ1bHkgaGF2ZQo+bm90aGluZyB0byBzYXk/Cj5JZiBzbyBhbmQgZ2l2ZW4gdGhl IHByZXZpb3VzIFdHTEMgc3VjY2VlZGVkLCB0aGVuIG9uIE9jdCA5LCBJIHdpbGwgdGFrZQo+c2ls ZW5jZSBhcyBjb25zZW50IGFuZCBpbmRpY2F0ZSB0aGF0IG9uIHRoZSBkcmFmdCBzaGVwaGVyZCdz IHdyaXRlLXVwLi4uCj4KPkFsaWEKPgo+Cj5PbiBGcmksIFNlcCAxMywgMjAxMyBhdCAxOjI4IFBN LCBBbGlhIEF0bGFzIDxha2F0bGFzQGdtYWlsLmNvbT4gd3JvdGU6Cj4KPj4gVGhpcyBpcyB0byBz dGFydCBhIHNlY29uZCBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbgo+PiBkcmFmdC1pZXRmLXJ0 Z3dnLWNsLXJlcXVpcmVtZW50LTExLiBBcyB5b3UgbWF5IHJlY2FsbCwgd2Ugc3VjY2Vzc2Z1bGx5 Cj4+IGNvbXBsZXRlZCBhIFdHTEMgb24gZHJhZnQtaWV0Zi1ydGd3Zy1jbC1yZXF1aXJlbWVudC0x MC4gIEFmdGVyIHRoYXQsCj4+IHRoZXJlIHdhcyBjb25jZXJuIGFib3V0IHRoZSB1c2Ugb2YgSVRV IHRlcm1pbm9sb2d5IChjb21wb3NpdGUtbGluayBhbmQgTlBPKQo+PiB3aGVyZSB0aGUgZHJhZnQg d2FzIG5vdCBhY3R1YWxseSB1c2luZyB0aGUgZXhhY3QgbWVhbmluZyBzcGVjaWZpZWQgYnkgdGhl Cj4+IElUVS4KPj4KPj4gVGhlcmVmb3JlLCBpdCB3YXMgZGVjaWRlZCB0byByZXR1cm4gdGhlIGRy YWZ0IHRvIHRoZSBXRyBmb3IgYSBxdWljawo+PiB0ZXJtaW5vbG9neSB1cGRhdGUgKGFuZCBhbHNv IHRvIGFkZHJlc3Mgc29tZSBvdGhlciByZXZpZXcgY29tbWVudHMpLgo+Pgo+PiBUaGlzIFdHTEMg d2lsbCBlbmQgb24gU2VwdGVtYmVyIDMwLgo+Pgo+PiBUaGFua3MsCj4+IEFsaWEKPj4K ----_com.android.email_62377787841340_alt Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdj48ZGl2PkFsaWEsPC9kaXY+PGRpdj48YnIvPjwvZGl2PjxkaXY+V2Ugc2hvdWxkIHNlbmQg YSBoZWFkcyB1cCB0byBNUExTIGFuZCBDQ0FNUC4mIzE2MDsgV291bGQgeW91IHBsZWFzZSBkbyB0 aGF0IGFzIFdHIGNoYWlyLjwvZGl2PjxkaXY+PGJyLz48L2Rpdj48ZGl2PkN1cnRpczwvZGl2Pjxk aXY+PGJyLz48L2Rpdj48ZGl2Pjxici8+PC9kaXY+PGRpdj5DdXJ0aXMgVmlsbGFtaXphciAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmN1cnRpc0BvY2NuYy5jb20iPmN1cnRpc0BvY2NuYy5jb208L2E+Jmd0 OzwvZGl2PjxkaXY+U2VudCBmcm9tIG15IHRhYmxldCBzbyBwbGVhc2UgZGlzcmVnYXJkIHNsb3Bw eSB0eXBpbmcuPC9kaXY+PC9kaXY+PGJyPjxicj5BbGlhIEF0bGFzICZsdDtha2F0bGFzQGdtYWls LmNvbSZndDsgd3JvdGU6PGJyPjxicj48ZGl2IGRpcj0ibHRyIj5UaGlzIHNlY29uZCBXRyBMYXN0 IENhbGwgZ290IGFic29sdXRlbHkgbm8gY29tbWVudHMuPGRpdj5Eb2VzIHRoaXMgZ3JvdXAgb2Yg Z2VuZXJhbGx5IG9waW5pb25hdGVkIGFuZCB0aG91Z2h0ZnVsIHBlb3BsZSB0cnVseSBoYXZlIG5v dGhpbmcgdG8gc2F5PzwvZGl2PjxkaXY+SWYgc28gYW5kIGdpdmVuIHRoZSBwcmV2aW91cyBXR0xD IHN1Y2NlZWRlZCwgdGhlbiBvbiBPY3QgOSwgSSB3aWxsIHRha2Ugc2lsZW5jZSBhcyBjb25zZW50 IGFuZCBpbmRpY2F0ZSB0aGF0IG9uIHRoZSBkcmFmdCBzaGVwaGVyZCYjMzk7cyB3cml0ZS11cC4u LjwvZGl2Pg0KPGRpdj48YnI+PC9kaXY+PGRpdj5BbGlhPC9kaXY+PC9kaXY+PGRpdiBjbGFzcz0i Z21haWxfZXh0cmEiPjxicj48YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIEZyaSwgU2Vw IDEzLCAyMDEzIGF0IDE6MjggUE0sIEFsaWEgQXRsYXMgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBo cmVmPSJtYWlsdG86YWthdGxhc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5ha2F0bGFzQGdt YWlsLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBz b2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2IGRpcj0ibHRyIj5UaGlzIGlzIHRvIHN0YXJ0IGEg c2Vjb25kIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9uIGRyYWZ0LWlldGYtcnRnd2ctY2wtcmVx dWlyZW1lbnQtMTEuwqA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsc2Fucy1zZXJpZjtm b250LXNpemU6MTNweCI+QXMgeW91IG1heSByZWNhbGwsIHdlIHN1Y2Nlc3NmdWxseSBjb21wbGV0 ZWQgYSBXR0xDIG9uIGRyYWZ0LWlldGYtcnRnd2ctY2wtPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTphcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxM3B4Ij5yZXF1aXJlbWVudC0xMC4g wqBBZnRlciB0aGF0LCB0aGVyZSB3YXMgY29uY2VybiBhYm91dCB0aGUgdXNlIG9mIElUVSB0ZXJt aW5vbG9neSAoY29tcG9zaXRlLWxpbmsgYW5kIE5QTykgd2hlcmUgdGhlIGRyYWZ0IHdhcyBub3Qg YWN0dWFsbHkgdXNpbmcgdGhlIGV4YWN0IG1lYW5pbmcgc3BlY2lmaWVkIGJ5IHRoZSBJVFUuPC9z cGFuPjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjEz cHgiPg0KDQo8YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsc2Fucy1zZXJp Zjtmb250LXNpemU6MTNweCI+VGhlcmVmb3JlLCBpdCB3YXMgZGVjaWRlZCB0byByZXR1cm4gdGhl IGRyYWZ0IHRvIHRoZSBXRyBmb3IgYSBxdWljayB0ZXJtaW5vbG9neSB1cGRhdGUgKGFuZCBhbHNv IHRvIGFkZHJlc3Mgc29tZSBvdGhlciByZXZpZXcgY29tbWVudHMpLsKgPC9kaXY+PGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6YXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTNweCI+DQoNCjxicj48 L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTox M3B4Ij5UaGlzIFdHTEMgd2lsbCBlbmQgb24gU2VwdGVtYmVyIDMwLjwvZGl2PjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OmFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjEzcHgiPjxicj48L2Rpdj48 ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxM3B4Ij4N Cg0KVGhhbmtzLDwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLHNhbnMtc2VyaWY7 Zm9udC1zaXplOjEzcHgiPkFsaWE8L2Rpdj48L2Rpdj4NCjwvYmxvY2txdW90ZT48L2Rpdj48YnI+ PC9kaXY+DQo= ----_com.android.email_62377787841340_alt-- From akatlas@gmail.com Fri Oct 4 08:42:00 2013 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 0F09421F9E63 for ; Fri, 4 Oct 2013 08:42:00 -0700 (PDT) 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.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kv2DyzzIINAN for ; Fri, 4 Oct 2013 08:41:46 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6582621F9D68 for ; Fri, 4 Oct 2013 08:40:31 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id at1so9308394iec.2 for ; Fri, 04 Oct 2013 08:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=oxr+IdUVtkan4/1x9l5z8Il8EUk4hgGl4YYg7rOLN9g=; b=oqB55bIuKb9A85y+m0mW2UszUgmZVfxnhmTLjCNNPYH3EVsL0RTtkMTBHYLZFuiNAM UoAj3rFgXjpOBybjwJtK+0ZW2Jq3QWF0uy0IKX86Ko94CrI0TI46sPdbEfr39ZQqAN+P WFMcfwVA5nqG7h0HlfyCR4377oBcOeTYgE7Go1aOS8QkyvB7RH5nBcXeJXoYt8mowwpJ Ll61nj8RPKKHUiN3PMomTC8l4L82FRHez78X5msq/8uJ7mLtRgJ3ECHt8ScR9kfnJ+G1 3gkq3MxdBTCpQ6AnQaZTz4egv2tiKXfz+vZQnfVu1nU/SRL/aHG0VhipiF6qurPsvO+Y 9NbQ== MIME-Version: 1.0 X-Received: by 10.50.119.70 with SMTP id ks6mr7107165igb.22.1380901230708; Fri, 04 Oct 2013 08:40:30 -0700 (PDT) Received: by 10.64.13.145 with HTTP; Fri, 4 Oct 2013 08:40:30 -0700 (PDT) Date: Fri, 4 Oct 2013 11:40:30 -0400 Message-ID: Subject: please comment on draft-litkowski-rtgwg-uloop-delay-01 From: Alia Atlas To: "rtgwg@ietf.org" Content-Type: multipart/alternative; boundary=089e0111d9b853945804e7ec1f76 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, 04 Oct 2013 15:42:00 -0000 --089e0111d9b853945804e7ec1f76 Content-Type: text/plain; charset=ISO-8859-1 I would like to strongly encourage reading and commenting on draft-litkowski-rtgwg-uloop-delay-01. IMHO, it is a fairly simple extension that solves a real problem which appears for any alternates beyond LFA with a link/node down. I would like to see more detail on how this applies to node failures and detection for a broadcast interface as well. It would also be very useful to clearly articulate why this particular micro-loop prevention in the event of local failure is so important. Thanks, Alia --089e0111d9b853945804e7ec1f76 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I would like to strongly encourage reading and commenting = on=A0draft-litkowski-rtgwg-ul= oop-delay-01. =A0

IMHO, it is a fairly simple extensio= n that solves a real problem which appears for any alternates beyond LFA wi= th a link/node down.

I would like to see more detail= on how this applies to node failures and detection for a broadcast interfa= ce as well.

It would also be very useful to= clearly articulate why this particular micro-loop prevention in the event = of local failure is so important.

Thanks,
Alia
--089e0111d9b853945804e7ec1f76-- From jeff.tantsura@ericsson.com Sun Oct 6 23:29:49 2013 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 B254321E8172 for ; Sun, 6 Oct 2013 23:29:49 -0700 (PDT) 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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tM6ig-21MZMO for ; Sun, 6 Oct 2013 23:29:44 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5C15421E8165 for ; Sun, 6 Oct 2013 23:29:44 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-fe-525254d76312 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id A9.60.09414.7D452525; Mon, 7 Oct 2013 08:29:43 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Mon, 7 Oct 2013 02:29:36 -0400 From: Jeff Tantsura To: Alia Atlas , Hannes Gredler Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt Thread-Topic: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt Thread-Index: AQHOvsRIFEnb2veln0K+pQC0UlQWpJngUkIA//+gKQCAAWxkgIAAO+YAgAcCpYA= Date: Mon, 7 Oct 2013 06:29:35 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C7483994EA1C@eusaamb109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_60DEDD93F5E54B4AB55647B8B6C7483994EA1Ceusaamb109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXSPn+71kKAgg77lphafHl5itui/94TN 4sKb38wOzB47Z91l91iy5CeTx/Wmq+wBzFFcNimpOZllqUX6dglcGX0HdQv++Fd8freTrYFx smsXIyeHhICJxPrpx1ggbDGJC/fWs3UxcnEICRxllLh16yMThLOMUeLw4a2sIFVsAgYS/78d B+sQEXCX+L5qEVARBwezgKrE5m22IGFhgWCJSxPuMUGUhEicez2BEcL2k+jZ/gCslUVARWLF +nPMIDavgLdEx4U7YHFOgUCJtXt6wFYxAh30/dQasDnMAuISt57MZ4I4VEBiyZ7zzBC2qMTL x//A6kUF9CTajp1hh4grS3yf84gFojdf4tSDZywQuwQlTs58wjKBUXQWkrGzkJTNQlIGETeQ eH9uPjOErS2xbOFrKFtfYuOXs4wQtrXEn1N32ZHVLGDkWMXIUVqcWpabbmSwiREYf8ck2HR3 MO55aXmIUZqDRUmc98tb5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjKH5vk9drvB7/jzL liNwrWPl5v0zvSNfx1j9zTpqmFn/zX8St7eS+rPZh+T4ohas/nfE0vEBr+8chxXvTC5df6mm OluWMTSddVdO6OqpKZf9vPym97PN2q+20bsrXFVCvD7+1ZS1dz5/nvohsl6m/siJqT7Mehcl +ZVqX+gVtc1x3CVz6V1voRJLcUaioRZzUXEiAGx/gBqNAgAA 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, 07 Oct 2013 06:29:49 -0000 --_000_60DEDD93F5E54B4AB55647B8B6C7483994EA1Ceusaamb109ericsso_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Alia/Hannes, I support very much Alia's position here and would like to see node protect= ion as part of base rlfa spec rather than dev-team HLD pushed as standard t= rack document. Would be great to see input from all vendors to ensure interoperability. Thanks! Cheers, Jeff From: Alia Atlas > Date: Wednesday, October 2, 2013 5:26 AM To: Hannes Gredler > Cc: Jeff Tantsura >, "rtgwg@ietf.org" > Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-= 01.txt It would be excellent to see progress on the Remote LFA draft and on mergin= g at least the two drafts that describe how to do node-protection for Remot= e LFA before the Vancouver IETF. Alia On Wed, Oct 2, 2013 at 4:51 AM, Hannes Gredler > wrote: hi jeff, the single biggest problem with draft-ietf-rtgwg-remote-lfa is that it leaves a lot of ambiguity how to implement certain functionality - node-protection, manageability among them. 'the right thing'(=99) would be to fix the rlfa spec, which somehow seems not possible, so it remains in the state which it is now =85 what i call 'underspecified'. draft-psarkar-rtgwg-rlfa-node-protection is a contribution coming from a dev-team which had to implement this for OSPF and IS-IS and make it work altogether. we got the impression that customers want to use both node-protection *and* manageability together and as such you need to do things a certain way which is described in the draft. IMO thats a bit more than just 'implementation details' but rather a guidance how to get this right. therefore the intended status is 'proposed standard'. /hannes On Oct 1, 2013, at 8:07 PM, Jeff Tantsura wrote: > Hi, > > Question to the authors of the draft about their intentions, obviously th= e > basic node protection equation(D_opt(Npq, Dst) < D_opt(Npq, Np) + > Distance_opt(Np, Dst)) is correct, however the rest is more or less > implementation details. > So if the authors would like to share the details about their > implementation should not the Intended Status be Informational? > > Cheers, > Jeff > > >>> >>>> Folks, >>>> >>>> Does anyone know whether the draft deal will be treated in the IETF 88= ? >>>> >>>> Regards, >>>> >>>> Rogerio Mariano >>>> >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://ietf.10.n7.nabble.com/Request-for-review-draft-psarkar-rtgwg-rl= fa >>>> - >>>> n >>>> ode-protection-01-txt-tp375714p386321.html >>>> Sent from the IETF - Rtgwg mailing list archive at Nabble.com. >>>> _______________________________________________ >>>> 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 > > _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg --_000_60DEDD93F5E54B4AB55647B8B6C7483994EA1Ceusaamb109ericsso_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3B7C2BCAD3F2AE4CBBA93167292DD61E@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi Alia/Hannes,

I support very much Alia's position here and would like to see no= de protection as part of base rlfa spec rather than dev-team HLD pushed as = standard track document.
Would be great to see input from all vendors to ensure interoperabilit= y.

Thanks!

Cheers,
Jeff

From: Alia Atlas <akatlas@gmail.com>
Date: Wednesday, October 2, 2013 5:= 26 AM
To: Hannes Gredler <hannes@juniper.net>
Cc: Jeff Tantsura <jeff.tantsura@ericsson.com>, "= rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: Re: Request for review - d= raft-psarkar-rtgwg-rlfa-node-protection-01.txt

It would be excellent to see progress on the Remote LFA dr= aft and on merging at least the two drafts that describe how to do node-pro= tection for Remote LFA before the Vancouver IETF.

Alia


On Wed, Oct 2, 2013 at 4:51 AM, Hannes Gredler <= span dir=3D"ltr"> <hannes@juniper.= net> wrote:
hi jeff,

the single biggest problem with draft-ietf-rtgwg-remote-lfa
is that it leaves a lot of ambiguity how to implement certain
functionality - node-protection, manageability among them.

'the right thing'(=99)  would be to fix the rlfa spec,
which somehow seems not possible, so it remains
in the state which it is now =85 what i call 'underspecified'.

draft-psarkar-rtgwg-rlfa-node-protection is a contribution
coming from a dev-team which had to implement this for
OSPF and IS-IS and make it work altogether.

we got the impression that customers want to use both
node-protection *and* manageability together and as such
you need to do things a certain way which is described in
the draft. IMO thats a bit more than just
'implementation details' but rather a guidance
how to get this right. therefore the intended status is
'proposed standard'.

/hannes

On Oct 1, 2013, at 8:07 PM, Jeff Tantsura wrote:

> Hi,
>
> Question to the authors of the draft about their intentions, obviously= the
> basic node protection equation(D_opt(Npq, Dst) < D_opt(Npq, Np) = 3;
> Distance_opt(Np, Dst)) is correct, however the rest is more or less > implementation details.
> So if the authors would like to share the details about their
> implementation should not the Intended Status be Informational?
>
> Cheers,
> Jeff
>
>
>>>
>>>> Folks,
>>>>
>>>> Does anyone know whether the draft deal will be treated in= the IETF 88?
>>>>
>>>> Regards,
>>>>
>>>> Rogerio Mariano
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://ietf.10.n7.nabble.com/Request-for-review-draft-psarkar-rtgwg-rlfa
>>>> -
>>>> n
>>>> ode-protection-01-txt-tp375714p386321.html
>>>> Sent from the IETF - Rtgwg mailing list archive at Nabble.= com.
>>>> _______________________________________________
>>>> 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
>
>


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

 --_000_60DEDD93F5E54B4AB55647B8B6C7483994EA1Ceusaamb109ericsso_-- From jeff.tantsura@ericsson.com Sun Oct 6 23:36:14 2013 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 DD40A21E8155 for ; Sun, 6 Oct 2013 23:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCXoV66ScciT for ; Sun, 6 Oct 2013 23:36:09 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 78AB021E8169 for ; Sun, 6 Oct 2013 23:36:04 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-2e-52525653f4f1 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 14.70.09414.35652525; Mon, 7 Oct 2013 08:36:04 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Mon, 7 Oct 2013 02:35:55 -0400 From: Jeff Tantsura To: Alia Atlas , Hannes Gredler Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt Thread-Topic: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt Thread-Index: AQHOvsRIFEnb2veln0K+pQC0UlQWpJngUkIA//+gKQCAAWxkgIAAO+YAgAcCpYA= Date: Mon, 7 Oct 2013 06:35:54 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C7483994EA2E@eusaamb109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_60DEDD93F5E54B4AB55647B8B6C7483994EA2Eeusaamb109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXSPn25IWFCQwY9zvBafHl5itui/94TN 4sKb38wOzB47Z91l91iy5CeTx/Wmq+wBzFFcNimpOZllqUX6dglcGYfO6xf88a9YMPsqWwPj ZNcuRk4OCQETifMHXzJD2GISF+6tZ+ti5OIQEjjKKHHgXDuUs4xR4tq8pUwgVWwCBhL/vx1n AbFFBNwlvq9aBBTn4GAWUJXYvM0WJCwsECxxacI9JoiSEIlzrycwQth+Ej3bH4C1sgioSPz+ fhdsMa+At8TzV7NZQWxOgUCJtXt6wGxGoIO+n1oDNodZQFzi1pP5TBCHCkgs2XMe6mhRiZeP /4HViwroSbQdO8MOEVeW+D7nEQtEb77E3E3bGSF2CUqcnPmEZQKj6CwkY2chKZuFpAwibiDx /tx8ZghbW2LZwtdQtr7Exi9nGSFsa4n9p1eyIKtZwMixipGjtDi1LDfdyGATIzD+jkmw6e5g 3PPS8hCjNAeLkjjvl7fOQUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY5eNqJ25If/FcQ2pm bfKcBv4410uzFvR/uVaqJXbqNtsU/VW/bwdo/M5OcrRe/42DW/BosdeHiKQ1xr/9n8/dkNL8 N6Z4Tb/+kwPX2Q02zmjY1S71Ml1EWlbraGZDquBl9y28R5m33GC0nHHAwP4Ew6fFxpNTfnNn X3wusGS549nKhftepH2MVWIpzkg01GIuKk4EAGKCIGqNAgAA 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, 07 Oct 2013 06:36:15 -0000 --_000_60DEDD93F5E54B4AB55647B8B6C7483994EA2Eeusaamb109ericsso_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Alia/Hannes, I support very much Alia's position here and would like to see node protect= ion as part of base rlfa spec rather than dev-team HLD pushed as standard t= rack document. Would be great to see input from all vendors to ensure interoperability. Thanks! Cheers, Jeff From: Alia Atlas > Date: Wednesday, October 2, 2013 5:26 AM To: Hannes Gredler > Cc: Jeff Tantsura >, "rtgwg@ietf.org" > Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-= 01.txt It would be excellent to see progress on the Remote LFA draft and on mergin= g at least the two drafts that describe how to do node-protection for Remot= e LFA before the Vancouver IETF. Alia On Wed, Oct 2, 2013 at 4:51 AM, Hannes Gredler > wrote: hi jeff, the single biggest problem with draft-ietf-rtgwg-remote-lfa is that it leaves a lot of ambiguity how to implement certain functionality - node-protection, manageability among them. 'the right thing'(=99) would be to fix the rlfa spec, which somehow seems not possible, so it remains in the state which it is now =85 what i call 'underspecified'. draft-psarkar-rtgwg-rlfa-node-protection is a contribution coming from a dev-team which had to implement this for OSPF and IS-IS and make it work altogether. we got the impression that customers want to use both node-protection *and* manageability together and as such you need to do things a certain way which is described in the draft. IMO thats a bit more than just 'implementation details' but rather a guidance how to get this right. therefore the intended status is 'proposed standard'. /hannes On Oct 1, 2013, at 8:07 PM, Jeff Tantsura wrote: > Hi, > > Question to the authors of the draft about their intentions, obviously th= e > basic node protection equation(D_opt(Npq, Dst) < D_opt(Npq, Np) + > Distance_opt(Np, Dst)) is correct, however the rest is more or less > implementation details. > So if the authors would like to share the details about their > implementation should not the Intended Status be Informational? > > Cheers, > Jeff > > >>> >>>> Folks, >>>> >>>> Does anyone know whether the draft deal will be treated in the IETF 88= ? >>>> >>>> Regards, >>>> >>>> Rogerio Mariano >>>> >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://ietf.10.n7.nabble.com/Request-for-review-draft-psarkar-rtgwg-rl= fa >>>> - >>>> n >>>> ode-protection-01-txt-tp375714p386321.html >>>> Sent from the IETF - Rtgwg mailing list archive at Nabble.com. >>>> _______________________________________________ >>>> 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 > > _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg --_000_60DEDD93F5E54B4AB55647B8B6C7483994EA2Eeusaamb109ericsso_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Alia/Hannes,

I support very much Alia's position here and would like to see no= de protection as part of base rlfa spec rather than dev-team HLD pushed as = standard track document.
Would be great to see input from all vendors to ensure interoperabilit= y.

Thanks!

Cheers,
Jeff

From: Alia Atlas <akatlas@gmail.com>
Date: Wednesday, October 2, 2013 5:= 26 AM
To: Hannes Gredler <hannes@juniper.net>
Cc: Jeff Tantsura <jeff.tantsura@ericsson.com>, "= rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: Re: Request for review - d= raft-psarkar-rtgwg-rlfa-node-protection-01.txt

It would be excellent to see progress on the Remote LFA dr= aft and on merging at least the two drafts that describe how to do node-pro= tection for Remote LFA before the Vancouver IETF.

Alia


On Wed, Oct 2, 2013 at 4:51 AM, Hannes Gredler <= span dir=3D"ltr"> <hannes@juniper.= net> wrote:
hi jeff,

the single biggest problem with draft-ietf-rtgwg-remote-lfa
is that it leaves a lot of ambiguity how to implement certain
functionality - node-protection, manageability among them.

'the right thing'(=99)  would be to fix the rlfa spec,
which somehow seems not possible, so it remains
in the state which it is now =85 what i call 'underspecified'.

draft-psarkar-rtgwg-rlfa-node-protection is a contribution
coming from a dev-team which had to implement this for
OSPF and IS-IS and make it work altogether.

we got the impression that customers want to use both
node-protection *and* manageability together and as such
you need to do things a certain way which is described in
the draft. IMO thats a bit more than just
'implementation details' but rather a guidance
how to get this right. therefore the intended status is
'proposed standard'.

/hannes

On Oct 1, 2013, at 8:07 PM, Jeff Tantsura wrote:

> Hi,
>
> Question to the authors of the draft about their intentions, obviously= the
> basic node protection equation(D_opt(Npq, Dst) < D_opt(Npq, Np) = 3;
> Distance_opt(Np, Dst)) is correct, however the rest is more or less > implementation details.
> So if the authors would like to share the details about their
> implementation should not the Intended Status be Informational?
>
> Cheers,
> Jeff
>
>
>>>
>>>> Folks,
>>>>
>>>> Does anyone know whether the draft deal will be treated in= the IETF 88?
>>>>
>>>> Regards,
>>>>
>>>> Rogerio Mariano
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://ietf.10.n7.nabble.com/Request-for-review-draft-psarkar-rtgwg-rlfa
>>>> -
>>>> n
>>>> ode-protection-01-txt-tp375714p386321.html
>>>> Sent from the IETF - Rtgwg mailing list archive at Nabble.= com.
>>>> _______________________________________________
>>>> 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
>
>


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

 --_000_60DEDD93F5E54B4AB55647B8B6C7483994EA2Eeusaamb109ericsso_-- From stephane.litkowski@orange.com Mon Oct 7 00:10:56 2013 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 7EFD621F9DF0 for ; Mon, 7 Oct 2013 00:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id az-BileJ+c+A for ; Mon, 7 Oct 2013 00:10:34 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFEA21E816F for ; Mon, 7 Oct 2013 00:10:32 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 4EB5B2AC30E; Mon, 7 Oct 2013 09:10:31 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 2FB37180049; Mon, 7 Oct 2013 09:10:31 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.45]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Mon, 7 Oct 2013 09:10:30 +0200 From: To: Jeff Tantsura , Alia Atlas , Hannes Gredler Date: Mon, 7 Oct 2013 09:10:30 +0200 Subject: RE: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt Thread-Topic: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt Thread-Index: AQHOvsRIFEnb2veln0K+pQC0UlQWpJngUkIA//+gKQCAAWxkgIAAO+YAgAcCpYCAAD2WYA== Message-ID: <28701_1381129831_52525E67_28701_1402_1_EEE55384044474429A926C625D0FCC810966AAC7DA@PUEXCB2F.nanterre.francetelecom.fr> References: <60DEDD93F5E54B4AB55647B8B6C7483994EA2E@eusaamb109.ericsson.se> In-Reply-To: <60DEDD93F5E54B4AB55647B8B6C7483994EA2E@eusaamb109.ericsson.se> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_EEE55384044474429A926C625D0FCC810966AAC7DAPUEXCB2Fnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.9.27.80014 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, 07 Oct 2013 07:10:57 -0000 --_000_EEE55384044474429A926C625D0FCC810966AAC7DAPUEXCB2Fnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Agree with the approach of having a single doc. Stephane Litkowski FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE Operational Engineering & Support IPTAC for RAEI network Orange Expert Network of Future t=E9l. +33 2 23 28 49 83 mob. +33 6 37 86 97 52 stephane.litkowski@orange.com De : rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] De la part de J= eff Tantsura Envoy=E9 : lundi 7 octobre 2013 08:36 =C0 : Alia Atlas; Hannes Gredler Cc : rtgwg@ietf.org Objet : Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-0= 1.txt Hi Alia/Hannes, I support very much Alia's position here and would like to see node protect= ion as part of base rlfa spec rather than dev-team HLD pushed as standard t= rack document. Would be great to see input from all vendors to ensure interoperability. Thanks! Cheers, Jeff From: Alia Atlas > Date: Wednesday, October 2, 2013 5:26 AM To: Hannes Gredler > Cc: Jeff Tantsura >, "rtgwg@ietf.org" > Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-= 01.txt It would be excellent to see progress on the Remote LFA draft and on mergin= g at least the two drafts that describe how to do node-protection for Remot= e LFA before the Vancouver IETF. Alia On Wed, Oct 2, 2013 at 4:51 AM, Hannes Gredler > wrote: hi jeff, the single biggest problem with draft-ietf-rtgwg-remote-lfa is that it leaves a lot of ambiguity how to implement certain functionality - node-protection, manageability among them. 'the right thing'((tm)) would be to fix the rlfa spec, which somehow seems not possible, so it remains in the state which it is now ... what i call 'underspecified'. draft-psarkar-rtgwg-rlfa-node-protection is a contribution coming from a dev-team which had to implement this for OSPF and IS-IS and make it work altogether. we got the impression that customers want to use both node-protection *and* manageability together and as such you need to do things a certain way which is described in the draft. IMO thats a bit more than just 'implementation details' but rather a guidance how to get this right. therefore the intended status is 'proposed standard'. /hannes On Oct 1, 2013, at 8:07 PM, Jeff Tantsura wrote: > Hi, > > Question to the authors of the draft about their intentions, obviously the > basic node protection equation(D_opt(Npq, Dst) < D_opt(Npq, Np) + > Distance_opt(Np, Dst)) is correct, however the rest is more or less > implementation details. > So if the authors would like to share the details about their > implementation should not the Intended Status be Informational? > > Cheers, > Jeff > > >>> >>>> Folks, >>>> >>>> Does anyone know whether the draft deal will be treated in the IETF 88? >>>> >>>> Regards, >>>> >>>> Rogerio Mariano >>>> >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://ietf.10.n7.nabble.com/Request-for-review-draft-psarkar-rtgwg-rl= fa >>>> - >>>> n >>>> ode-protection-01-txt-tp375714p386321.html >>>> Sent from the IETF - Rtgwg mailing list archive at Nabble.com. >>>> _______________________________________________ >>>> 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 > > _______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_EEE55384044474429A926C625D0FCC810966AAC7DAPUEXCB2Fnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Agree with the approach of having a single doc.

 

=

 =

Stephane Litkowski<= /b>
FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE

Operational = Engineering & Support IPTAC for RAEI network

Orange Expert Network of Future
t=E9l. +33 2 23 28 49 83

mob. +33 6 37 86 97 52
stephane.litkowski@orange.com

De : rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@= ietf.org] De la part de Jeff Tantsura
Envoy=E9 : lund= i 7 octobre 2013 08:36
=C0 : Alia Atlas; Hannes Gredler
<= b>Cc : rtgwg@ietf.org
Objet : Re: Request for revie= w - draft-psarkar-rtgwg-rlfa-node-protection-01.txt

 

Hi Alia/Hannes,

 

I support very much Alia's position here and would like to see node = protection as part of base rlfa spec rather than dev-team HLD pushed as sta= ndard track document.

= Would be great to see input from all vendors to ensure interoperabilit= y.

 

Thanks!

 

=

Cheers,

Jeff

 

From: Alia Atlas <akatlas@gmail.com>
Date: Wednesday= , October 2, 2013 5:26 AM
To: Hannes Gredler <hannes@juniper.net>
Cc: Jeff Tantsur= a <jeff.tantsura@ericsson.= com>, "rtgwg@ietf.org&quo= t; <rtgwg@ietf.org>
Subje= ct: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-0= 1.txt

 =

It would be excellent to see progress on the Remote LFA draft and = on merging at least the two drafts that describe how to do node-protection = for Remote LFA before the Vancouver IETF.

 

Alia

 

On Wed, Oct 2, 2013 at 4:51 AM, Hannes Gredler <hannes@juniper.net&g= t; wrote:

hi jeff,

th= e single biggest problem with draft-ietf-rtgwg-remote-lfa
is that it lea= ves a lot of ambiguity how to implement certain
functionality - node-pro= tection, manageability among them.

'the right thing'(™)  = would be to fix the rlfa spec,
which somehow seems not possible, so it r= emains
in the state which it is now … what i call 'underspecified'= .

draft-psarkar-rtgwg-rlfa-node-protection is a contribution
comi= ng from a dev-team which had to implement this for
OSPF and IS-IS and ma= ke it work altogether.

we got the impression that customers want to = use both
node-protection *and* manageability together and as such
you= need to do things a certain way which is described in
the draft. IMO th= ats a bit more than just
'implementation details' but rather a guidance<= br>how to get this right. therefore the intended status is
'proposed sta= ndard'.

/hannes


On Oct 1, 20= 13, at 8:07 PM, Jeff Tantsura wrote:

> Hi,
>
> Questi= on to the authors of the draft about their intentions, obviously the
>= ; basic node protection equation(D_opt(Npq, Dst) < D_opt(Npq, Np) +
&= gt; Distance_opt(Np, Dst)) is correct, however the rest is more or less
= > implementation details.
> So if the authors would like to share = the details about their
> implementation should not the Intended Stat= us be Informational?
>
> Cheers,
> Jeff
>
>>>>
>>>> Folks,
>>>>
>>&g= t;> Does anyone know whether the draft deal will be treated in the IETF = 88?
>>>>
>>>> Regards,
>>>>>>>> Rogerio Mariano
>>>>
>>>>>>>>
>>>>
>>>> --
>>&g= t;> View this message in context:
>>>> http://ietf.10.n7.nabble.com/Request-for-review-draft-psarkar-r= tgwg-rlfa
>>>> -
>>>> n
>>>&g= t; ode-protection-01-txt-tp375714p386321.html
>>>> Sent from= the IETF - Rtgwg mailing list archive at Nabble.com.
>>>> _= ______________________________________________
>>>> rtgwg ma= iling list
>>>> rtgwg@ietf= .org
>>>> https://www.ietf.org/mailman/listinfo/rtgwg=
>>>
>>
>
> ______________________________= _________________
> 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<= /span>

 

__________________________=
___________________________________________________________________________=
____________________

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,
Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
= --_000_EEE55384044474429A926C625D0FCC810966AAC7DAPUEXCB2Fnante_-- From stephane.litkowski@orange.com Mon Oct 7 02:00:19 2013 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 A681721E8199 for ; Mon, 7 Oct 2013 02:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UidApupuINYY for ; Mon, 7 Oct 2013 02:00:13 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 10E9721E80FD for ; Mon, 7 Oct 2013 02:00:10 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 768FA1B8329; Mon, 7 Oct 2013 11:00:03 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 569DF180051; Mon, 7 Oct 2013 11:00:03 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.45]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Mon, 7 Oct 2013 10:59:58 +0200 From: To: "stbryant@cisco.com" , "Alvaro Retana (aretana)" Date: Mon, 7 Oct 2013 10:59:57 +0200 Subject: RE: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt Thread-Topic: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt Thread-Index: Ac6/YnjKUly0WhjUSKKg/XS5LSk1tgD2QMmA Message-ID: <18754_1381136403_52527813_18754_7041_1_EEE55384044474429A926C625D0FCC810966AAC932@PUEXCB2F.nanterre.francetelecom.fr> References: <524C02D3.6050309@cisco.com> In-Reply-To: <524C02D3.6050309@cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_EEE55384044474429A926C625D0FCC810966AAC932PUEXCB2Fnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.10.7.35116 Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , rogeriomariano , "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, 07 Oct 2013 09:00:19 -0000 --_000_EEE55384044474429A926C625D0FCC810966AAC932PUEXCB2Fnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Stewart, Here are some old comments you didn't provide on feedback on : "Regarding remote LFA draft, I would hope to see some points addressed in t= he draft before going to WGLC. - It would be good to add some simulation results about how much TLDP sessi= on are required (TX and TX+RX), this in order to make people aware on how m= uch rLFA may impact their TLDP session scaling - We already raised the point some months ago about possibly "interop" issu= es in the following cases : * PLR choose a PQ which is not able to accept TLDP session : we verifie= d it in a lab, and we can clearly fall into such situation in a live networ= k, leading to protection not available. * PQ having multiple IP addresses /32 attached, so which one would be u= sed to establish TLDP session ? Current implementations are using some heur= istics and it would be good to document this - Current text states that rLFA is computed only when LFA are not available= and our analysis pointed that this is really not a good idea as in term of= manageability rLFA alternate may be better than LFA alternate. It would be= good that rLFA draft points to potential manageability issues and refers t= o the appropriate draft. " Thanks Stephane Stephane Litkowski FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE Operational Engineering & Support IPTAC for RAEI network Orange Expert Network of Future t=E9l. +33 2 23 28 49 83 mob. +33 6 37 86 97 52 stephane.litkowski@orange.com De : rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] De la part de S= tewart Bryant Envoy=E9 : mercredi 2 octobre 2013 13:26 =C0 : Alvaro Retana (aretana) Cc : draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rogeriomariano; rtgwg@ietf= .org Objet : Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt I will try to get a new version out this week or next. I plan to put in the algorithm text, although having discussed this with Mike, our inclination is to include this as an appendix since it is not required for interoperability that you do the computation that way. I will look at the issues left unresolved and any comments posted in response to this email. I see no reason to request a slot at IETF88 unless there remain technical issues that we are unable to resolve on this list. - Stewart (as duty editor of the draft) On 01/10/2013 15:40, Alvaro Retana (aretana) wrote: On 10/1/13 10:31 AM, "rogeriomariano" > wrote: Rogerio: Folks, Does anyone know whether the draft deal will be treated in the IETF = 88? We haven't started working on the agenda yet, so it is perhaps too early to= talk about whether this draft will be discussed in Vancouver or not. In the meant time, if you have comments or questions on the draft, please p= ost them to the list. Thanks! Alvaro. _______________________________________________ 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 ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_EEE55384044474429A926C625D0FCC810966AAC932PUEXCB2Fnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Stewart,

 

Here are some old comments you didn’t provide on feedback o= n :

&nbs= p;

“<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif= "'>Regarding remote LFA draft, I would hope to see some points addressed in= the draft before going to WGLC.

- It would be good to add some simulation res= ults about how much TLDP session are required (TX and TX+RX), this in order= to make people aware on how much rLFA may impact their TLDP session scalin= g

 

- We a= lready raised the point some months ago about possibly "interop" = issues in the following cases :=

    * PLR choose a PQ which is = not able to accept TLDP session : we verified it in a lab, and we can clear= ly fall into such situation in a live network, leading to protection not av= ailable.

 

&= nbsp;   * PQ having multiple IP addresses /32 attached, so which = one would be used to establish TLDP session ? Current implementations are u= sing some heuristics and it would be good to document this

&nbs= p;

- Current text states that= rLFA is computed only when LFA are not available and our analysis pointed = that this is really not a good idea as in term of manageability rLFA altern= ate may be better than LFA alternate. It would be good that rLFA draft poin= ts to potential manageability issues and refers to the appropriate draft.

 

 

&#= 8220;

&n= bsp;

Thanks <= /o:p>

 <= /span>

Stephane

 

=

 

<= div>

 <= o:p>

Stephane Litkowski
FT/OF/DT= F/DEX/DERX/EE IP/TAC ENTREPRISE

Operational Engineering & Support IPTAC for RAEI network

Orange Expert Network of Future=
t=E9l. +33 2 23 28 49 83

mob. +33 6 = 37 86 97 52
stephane.= litkowski@orange.com

De : rtgwg-bounces@ietf.org [mailto:rtgwg-bo= unces@ietf.org] De la part de Stewart Bryant
Envoy=E9 : mercredi 2 octobre 2013 13:26
=C0 : Alvaro Retana (aretan= a)
Cc : draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rogeriom= ariano; rtgwg@ietf.org
Objet : Re: I-D Action: draft-ietf-rt= gwg-remote-lfa-02.txt

 

I will try to get a new ver= sion out this week or next.

I plan to put in the algorithm text, alt= hough having discussed
this with Mike, our inclination is to include thi= s as an
appendix since it is not required for interoperability that
= you do the computation that way.

I will look at the issues left unre= solved and any comments
posted in response to this email.

I see n= o reason to request a slot at IETF88 unless there remain
technical issue= s that we are unable to resolve on this list.

- Stewart (as duty edi= tor of the draft)



On 01/10/2013 15:40, Alvaro Retana (aretan= a) wrote:

On 10/1/13 10:31 AM, "rogeriom= ariano" <rsouza.rjo@gmail.c= om> wrote:

 =

Rogerio:

 

<= div>

Folks, Does anyone know whether the draft deal wil= l be treated in the IETF 88?

 

We = haven't started working on the agenda yet, so it is perhaps too early to ta= lk about whether this draft will be discussed in Vancouver or not.

 

In the meant time, if you have comments or questions on the= draft, please post them to the list.

 

Thanks!<= /o:p>

 

Alvaro.



_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinf=
o/rtgwg




<= o:p>

-- 
For corporate legal information=
 go to:
 
http://www.cis=
co.com/web/about/doing_business/legal/cri/index.html
 
______________________________________=
___________________________________________________________________________=
________

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,
Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
= --_000_EEE55384044474429A926C625D0FCC810966AAC932PUEXCB2Fnante_-- From hannes@juniper.net Mon Oct 7 05:30:17 2013 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 2042921F9FD6 for ; Mon, 7 Oct 2013 05:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMEzkjyNU4ZI for ; Mon, 7 Oct 2013 05:30:12 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 16D6321E808C for ; Mon, 7 Oct 2013 05:30:11 -0700 (PDT) Received: from mail172-ch1-R.bigfish.com (10.43.68.225) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.22; Mon, 7 Oct 2013 12:30:11 +0000 Received: from mail172-ch1 (localhost [127.0.0.1]) by mail172-ch1-R.bigfish.com (Postfix) with ESMTP id 041B83E00B8; Mon, 7 Oct 2013 12:30:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0512HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz98dI9371Ic89bhzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h93fhd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1c0dh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail172-ch1: domain of juniper.net designates 132.245.1.149 as permitted sender) client-ip=132.245.1.149; envelope-from=hannes@juniper.net; helo=BLUPRD0512HT002.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail172-ch1 (localhost.localdomain [127.0.0.1]) by mail172-ch1 (MessageSwitch) id 1381149008712996_28908; Mon, 7 Oct 2013 12:30:08 +0000 (UTC) Received: from CH1EHSMHS027.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.232]) by mail172-ch1.bigfish.com (Postfix) with ESMTP id A9029401B1; Mon, 7 Oct 2013 12:30:08 +0000 (UTC) Received: from BLUPRD0512HT002.namprd05.prod.outlook.com (132.245.1.149) by CH1EHSMHS027.bigfish.com (10.43.70.27) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 7 Oct 2013 12:30:08 +0000 Received: from juniper.net (193.110.54.36) by pod51010.outlook.com (10.255.215.163) with Microsoft SMTP Server (TLS) id 14.16.371.2; Mon, 7 Oct 2013 12:30:06 +0000 Date: Mon, 7 Oct 2013 14:30:10 +0200 From: Hannes Gredler To: Jeff Tantsura Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt Message-ID: <20131007123010.GB21218@juniper.net> References: <60DEDD93F5E54B4AB55647B8B6C7483994EA2E@eusaamb109.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <60DEDD93F5E54B4AB55647B8B6C7483994EA2E@eusaamb109.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [193.110.54.36] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 07 Oct 2013 12:30:17 -0000 jeff, i am happy to do this [rlfa single-spec for link and node-protection] unfortunately the current editor of the rlfa base spec is a bit reluctant to incorporate changes for some reason. IMO there are three roads to fix the problem: 1. keep rlfa, node protection seperate drafts 2. ask the current editor once more to incoporate the node-protection tex= t as well as other comments from stephane (e.g. how to signal T-LDP preferred transport addresses) 3. ask WG-chairs to assign a new editor to the draft /hannes On Mon, Oct 07, 2013 at 06:35:54AM +0000, Jeff Tantsura wrote: | Hi Alia/Hannes, |=20 | I support very much Alia's position here and would=C2=A0like to see nod= e protection | as part of base rlfa spec rather than dev-team HLD pushed as standard t= rack | document. | Would be great to see input from all vendors to ensure interoperability= . | | From: Alia Atlas | Date: Wednesday, October 2, 2013 5:26 AM | To: Hannes Gredler | Cc: Jeff Tantsura , "rtgwg@ietf.org&qu= ot; | | Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protect= ion- | 01.txt |=20 | It would be excellent to see progress on the Remote LFA draft and = on | merging at least the two drafts that describe how to do node- | protection for Remote LFA before the Vancouver IETF. |=20 | Alia |=20 |=20 | On Wed, Oct 2, 2013 at 4:51 AM, Hannes Gredler | wrote: | hi jeff, |=20 | the single biggest problem with draft-ietf-rtgwg-remote-lfa | is that it leaves a lot of ambiguity how to implement | certain | functionality - node-protection, manageability among them. |=20 | 'the right thing'(=E2=84=A2) =C2=A0would be to fix the rlfa s= pec, | which somehow seems not possible, so it remains | in the state which it is now =E2=80=A6 what i call | 'underspecified'. |=20 | draft-psarkar-rtgwg-rlfa-node-protection is a contribution | coming from a dev-team which had to implement this for | OSPF and IS-IS and make it work altogether. |=20 | we got the impression that customers want to use both | node-protection *and* manageability together and as such | you need to do things a certain way which is described in | the draft. IMO thats a bit more than just | 'implementation details' but rather a guidance | how to get this right. therefore the intended status is | 'proposed standard'. |=20 | /hannes |=20 | On Oct 1, 2013, at 8:07 PM, Jeff Tantsura wrote: |=20 | > Hi, | > | > Question to the authors of the draft about their | intentions, obviously the | > basic node protection equation(D_opt(Npq, Dst) < D_opt | (Npq, Np) + | > Distance_opt(Np, Dst)) is correct, however the rest is | more or less | > implementation details. | > So if the authors would like to share the details about | their | > implementation should not the Intended Status be | Informational? | > | > Cheers, | > Jeff | > | > | >>> | >>>> Folks, | >>>> | >>>> Does anyone know whether the draft deal will be | treated in the IETF 88? | >>>> | >>>> Regards, | >>>> | >>>> Rogerio Mariano | >>>> | >>>> | >>>> | >>>> | >>>> -- | >>>> View this message in context: | >>>> http://ietf.10.n7.nabble.com/Request-for-review-draft- | psarkar-rtgwg-rlfa | >>>> - | >>>> n | >>>> ode-protection-01-txt-tp375714p386321.html | >>>> Sent from the IETF - Rtgwg mailing list archive at | Nabble.com. | >>>> _______________________________________________ | >>>> 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 | > | > |=20 |=20 | _______________________________________________ | rtgwg mailing list | rtgwg@ietf.org | https://www.ietf.org/mailman/listinfo/rtgwg |=20 From stbryant@cisco.com Mon Oct 7 08:57:10 2013 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 20CBD21E81FA for ; Mon, 7 Oct 2013 08:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.404 X-Spam-Level: X-Spam-Status: No, score=-110.404 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3Eccq4KVWnb for ; Mon, 7 Oct 2013 08:57:05 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 761F521E81C5 for ; Mon, 7 Oct 2013 08:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25001; q=dns/txt; s=iport; t=1381161367; x=1382370967; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=Ry7TBi2vpx0GUzG9+Q120y0lADjEQD0D2eTuoeIT+Ik=; b=BRWuUFqFOcxNyQfbBQL1Y+l9MFfXIC/8UzY3Qub4LZYZFkaAPkF2wD93 LHBbtX4Rj3TlTINd5QwHEMU+BCCREEZmRry8ld+gmO/x1Xs7gQWECacMZ XerBZyyxN30l6lnl3orfP2nFZUEHB8KKs3dBzk10RGk3GrXVvt+jx5Ozn 0=; X-IronPort-AV: E=Sophos;i="4.93,872,1378857600"; d="scan'208,217";a="18115024" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 07 Oct 2013 15:55:58 +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 r97FtqS6032062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Oct 2013 15:55:53 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r97FtpMq006982; Mon, 7 Oct 2013 16:55:51 +0100 (BST) Message-ID: <5252D987.5050201@cisco.com> Date: Mon, 07 Oct 2013 16:55:51 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stephane.litkowski@orange.com Subject: Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt References: <524C02D3.6050309@cisco.com> <18754_1381136403_52527813_18754_7041_1_EEE55384044474429A926C625D0FCC810966AAC932@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: <18754_1381136403_52527813_18754_7041_1_EEE55384044474429A926C625D0FCC810966AAC932@PUEXCB2F.nanterre.francetelecom.fr> Content-Type: multipart/alternative; boundary="------------070301080600010708000502" Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , rogeriomariano , "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: Mon, 07 Oct 2013 15:57:10 -0000 This is a multi-part message in MIME format. --------------070301080600010708000502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 07/10/2013 09:59, stephane.litkowski@orange.com wrote: > > Hi Stewart, > > Here are some old comments you didn't provide on feedback on : > > "Regarding remote LFA draft, I would hope to see some points addressed > in the draft before going to WGLC. > > - It would be good to add some simulation results about how much TLDP > session are required (TX and TX+RX), this in order to make people > aware on how much rLFA may impact their TLDP session scaling > That is a issue for Mike to consider. > > - We already raised the point some months ago about possibly "interop" > issues in the following cases : > > * PLR choose a PQ which is not able to accept TLDP session : we > verified it in a lab, and we can clearly fall into such situation in a > live network, leading to protection not available. > There are clearly only two solutions to this, either permit TLDP on any likely LSR, protected with an ACL if you wish, and accept the cases that fail as being a minority concern, or two (and out of scope for this draft) get the LSRs to advertise TLDP willingness in the IGP. > > * PQ having multiple IP addresses /32 attached, so which one would > be used to establish TLDP session ? Current implementations are using > some heuristics and it would be good to document this > We can certainly discuss the issue, but I am reluctant to specify a heuristic in an IETF draft, because then it is a specification and not a heuristic. > - Current text states that rLFA is computed only when LFA are not > available and our analysis pointed that this is really not a good idea > as in term of manageability rLFA alternate may be better than LFA > alternate. It would be good that rLFA draft points to potential > manageability issues and refers to the appropriate draft. > Hopefully this can be an informative ref, but we can include some simple text that notes that it is up to the implementer how they need to make a trade-off between minimum cost and minimum compute. Thanks for bringing this to my attention, hope to get some work done on this draft at the end of this week. - Stewart > " > > Thanks > > Stephane > > *Stephane Litkowski* > FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE > > Operational Engineering & Support IPTAC for RAEI network > > Orange Expert Network of Future > tél. +33 2 23 28 49 83 > > mob. +33 6 37 86 97 52 > stephane.litkowski@orange.com > > *De :*rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] *De la > part de* Stewart Bryant > *Envoyé :* mercredi 2 octobre 2013 13:26 > *À :* Alvaro Retana (aretana) > *Cc :* draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rogeriomariano; > rtgwg@ietf.org > *Objet :* Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt > > I will try to get a new version out this week or next. > > I plan to put in the algorithm text, although having discussed > this with Mike, our inclination is to include this as an > appendix since it is not required for interoperability that > you do the computation that way. > > I will look at the issues left unresolved and any comments > posted in response to this email. > > I see no reason to request a slot at IETF88 unless there remain > technical issues that we are unable to resolve on this list. > > - Stewart (as duty editor of the draft) > > > > On 01/10/2013 15:40, Alvaro Retana (aretana) wrote: > > On 10/1/13 10:31 AM, "rogeriomariano" > wrote: > > Rogerio: > > Folks, Does anyone know whether the draft deal will be treated > in the IETF 88? > > We haven't started working on the agenda yet, so it is perhaps too > early to talk about whether this draft will be discussed in > Vancouver or not. > > In the meant time, if you have comments or questions on the draft, > please post them to the list. > > Thanks! > > Alvaro. > > > > > _______________________________________________ > > 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 > > _________________________________________________________________________________________________________________________ > > 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, > 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, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------070301080600010708000502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 07/10/2013 09:59, stephane.litkowski@orange.com wrote:

Hi Stewart,

 

Here are some old comments you didn’t provide on feedback on :

 

“Regarding remote LFA draft, I would hope to see some points addressed in the draft before going to WGLC.

- It would be good to add some simulation results about how much TLDP session are required (TX and TX+RX), this in order to make people aware on how much rLFA may impact their TLDP session scaling

 

That is a issue for Mike to consider.

- We already raised the point some months ago about possibly "interop" issues in the following cases :

    * PLR choose a PQ which is not able to accept TLDP session : we verified it in a lab, and we can clearly fall into such situation in a live network, leading to protection not available.

There are clearly only two solutions to this, either permit TLDP on any likely LSR, protected with an ACL if you wish, and accept the cases that fail as being a minority concern, or two (and out of scope for this draft) get the LSRs to advertise TLDP willingness in the IGP.

 

    * PQ having multiple IP addresses /32 attached, so which one would be used to establish TLDP session ? Current implementations are using some heuristics and it would be good to document this

 

We can certainly discuss the issue, but I am reluctant to specify a heuristic in an IETF draft, because then it is a specification and not a heuristic.

- Current text states that rLFA is computed only when LFA are not available and our analysis pointed that this is really not a good idea as in term of manageability rLFA alternate may be better than LFA alternate. It would be good that rLFA draft points to potential manageability issues and refers to the appropriate draft.

Hopefully this can be an informative ref, but we can include some simple text that notes that it is up to the implementer how they need to make a trade-off between minimum cost and minimum compute.

Thanks for bringing this to my attention, hope to get some work done on this draft at  the end of this week.

- Stewart

 

 

“

 

Thanks

 

Stephane

 

 

 

Stephane Litkowski
FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE

Operational Engineering & Support IPTAC for RAEI network

Orange Expert Network of Future
tél. +33 2 23 28 49 83

mob. +33 6 37 86 97 52
stephane.litkowski@orange.com

De : rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] De la part de Stewart Bryant
Envoyé : mercredi 2 octobre 2013 13:26
À : Alvaro Retana (aretana)
Cc : draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rogeriomariano; rtgwg@ietf.org
Objet : Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

 

I will try to get a new version out this week or next.

I plan to put in the algorithm text, although having discussed
this with Mike, our inclination is to include this as an
appendix since it is not required for interoperability that
you do the computation that way.

I will look at the issues left unresolved and any comments
posted in response to this email.

I see no reason to request a slot at IETF88 unless there remain
technical issues that we are unable to resolve on this list.

- Stewart (as duty editor of the draft)



On 01/10/2013 15:40, Alvaro Retana (aretana) wrote:

On 10/1/13 10:31 AM, "rogeriomariano" <rsouza.rjo@gmail.com> wrote:

 

Rogerio:

 

Folks, Does anyone know whether the draft deal will be treated in the IETF 88?

 

We haven't started working on the agenda yet, so it is perhaps too early to talk about whether this draft will be discussed in Vancouver or not.

 

In the meant time, if you have comments or questions on the draft, please post them to the list.

 

Thanks!

 

Alvaro.




_______________________________________________
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
 
_________________________________________________________________________________________________________________________

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,
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, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------070301080600010708000502-- From curtis@ipv6.occnc.com Mon Oct 7 11:09:31 2013 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 7240621E81B2 for ; Mon, 7 Oct 2013 11:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjwLNrLPIpfn for ; Mon, 7 Oct 2013 11:09:17 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 550C911E8102 for ; Mon, 7 Oct 2013 11:09:13 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r97I6eeV070034; Mon, 7 Oct 2013 14:06:40 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201310071806.r97I6eeV070034@gateway1.orleans.occnc.com> To: Alia Atlas From: Curtis Villamizar Subject: Re: WG Last Call for draft-ietf-rtgwg-cl-requirement-11 In-reply-to: Your message of "Tue, 01 Oct 2013 17:38:14 EDT." Date: Mon, 07 Oct 2013 14:06:39 -0400 Cc: "draft-ietf-rtgwg-cl-requirement@tools.ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 18:09:31 -0000 In message Alia Atlas writes: > This second WG Last Call got absolutely no comments. Does this group > of generally opinionated and thoughtful people truly have nothing to > say? > > If so and given the previous WGLC succeeded, then on Oct 9, I will > take silence as consent and indicate that on the draft shepherd's > write-up... > > Alia Alia, et al. Silence could mean lots of people read the document and could see no way to further improve it. I doubt that is the case. Silence could also mean that the document has been around for so long that people are tired or reading it and haven't bothered to read it again. More likely IMHO. It isn't clear (to me) in the above email if you were extending WGLC until Oct 9. As co-author, I wanted to give others a chance to comment first during WGLC and they have had plenty of time to do so. Given that there are multiple co-authors, there has been some compromise in the document. While combining contributions, there was some tendency to "go along to keep moving forward". That can be bad if there are too few critical reviewers outside the set of co-authors. With co-author hat off, I reread the document and here are my personal review comments. If there is agreement to make changes, I will put co-author hat back on and make these edits. If there is dissenting discussion, I'll edit as best as I can judge consensus and we can disuss at IETF-88 if we need to. If there is silence, I'll let Alia and Alvaro interpret the silence. (full agreement with all changes? lack of interest?) This *is* a WG doc, so WG please speak up. Curtis ---------------------------------------- General Comments (See specific instances of each in detailed comments): The section naming and grouping of requirements could stand some improvement. Some of the requirement wording are awkwardly worded. A few sentences border on meaningless. Some of the requirements are infeasible as worded. Most can be made feasible by replacing "flows or group of flows" with "client LSP". The following paragraph in the introduction gives a hint as to why these are feasible for client LSP but not flows: The ingress and egress of a multipath may be midpoint LSRs with respect to a given client LSP. A midpoint LSR does not participate in the signaling of any clients of the client LSP. Therefore, in general, multipath endpoints cannot determine requirements of clients of a client LSP through participation in the signaling of the clients of the client LSP. One requirement (bidirectional placement on components) is infeasible for flows and infeasible for all but small client LSP that fit into a single compoent link. The framework points this out. Specific Comments: wording: s/no significantly exceed/not significantly exceed/ FR#4 contains one awkward excessively wordy sentence followed by one that I struggle to find any meaning in if I didn't already know what the intent was. It may also be better to replace "path for a flow" with "set of paths for an LSP" and then specify the requirements for flows within that LSP. OLD FR#4 The solution SHALL provide a mechanism to select a path for a flow across a network that contains a number of paths comprised of pairs of nodes connected by advanced multipath in such a way as to automatically distribute the load over the network nodes connected by advanced multipaths while meeting all of the other mandatory requirements stated above. The solution SHOULD work in a manner similar to that of current networks without any advanced multipath protocol enhancements when the characteristics of the individual component links are advertised. NEW FR#4 The solution shall provide a mechanism to select a set of paths for an LSP across a network in such a way that flows within the LSP are distributed across the set of paths while meeting all of the other requirements stated above. The solution SHOULD work in a manner similar to existing multipath techniques except as necessary to accommodate advanced multipath requirements. I think these say pretty much the same thing, but with improved clarity in the new text. FR#10 and FR#11 are the following: FR#10 The solution SHALL provide a means to limit the latency to meet a Performance Objective target on a per flow basis or group of flow basis, where flows or groups of flows are identifiable in the forwarding plane and are signaled using in the control plane or set up using the management plane. The Performance Objectives differ across the services, and some services have different Performance Objectives for different QoS classes, for example, one QoS class may have a much larger latency bound than another. Overload can occur which would violate a Performance Objective parameter (e.g., loss) and some remedy to handle this case for an advanced multipath is required. FR#11 If the total demand offered by traffic flows exceeds the capacity of the advanced multipath, the solution SHOULD define a means to cause some traffic flows or groups of flows to move to some other point in the network that is not congested. These "preempted flows" may not be restored if there is no uncongested path in the network. FR#10 and FR#11 currently fall under the section "Component Links Provided by Lower Layer Networks" but have nothing to do with lower layer networks. These would fit better with the existing section named "Parallel Component Links with Different Characteristics" (though see comments below on rearranging that section). FR#10 may be redundant due to FR#17 and FR#18 which specify minimul latency and bounded latency. The first paragraph in FR#10 adds nothing to FR#17 and FR#18 except that the result should meet "a Performance Objective target". The second paragraph seems to be unrelated discussion and perhaps belongs in FR#11. If so, FR#10 can be eliminated possibly adding a statement about "a Performance Objective target" in FR#17 and FR#18, but preferably leaving them alone. FR#10 and FR#11 are infeasible if applied to "client LSP" rather than "flows or groups of flows" for reasons stated in General Comments above. (So are FR#17 and FR#18; see below). In FR#10 s/signaled using in the control plane/signaled using the control plane/ FR#11 needs to be about preemption of LSP, not preemption of flows. Since there is no signaling of flows, there is no prioritization of flows. There is OTOH diffserv, which will enforce prioritization, even among traffic within a microflow (AF service where some traffic is marked AFx2 or AFx3, aka yellow or red). In FR#11 s/traffic flows or groups of traffic flows/clent LSP/ makes the requirement feasible. In FR#11 s/some other point in the network/an alternate set of paths/ makes the requirement more clear. NEW FR#10 [Deleted] FR#11 If the total demand offered by traffic flows exceeds the capacity of the advanced multipath, the solution SHOULD define a means to cause some client LSP to move to an alternate set of paths that are not congested. These "preempted LSP" may not be restored if there is no uncongested path in the network. The title "Parallel Component Links with Different Characteristics" should be changed, dropping the word "Parallel". The requirements also apply to very diverse paths through a network with different characteristics. The set of requirements currently in "Component Links with Different Characteristics" are mostly of two types: 1. Load Balance Dynamics (FR#12-FR#15, FR#20-FR#23) 2. Requirements for Carrying Client LSP (FR#16-FR#19, FR#24). FR#22 and FR#23 could be in either category but apply more to dynamics of load balancing. It might be better to reorder these requirements and create two subsections. Both still do apply to "Component Links with Different Characteristics", but form two distinct subsets. In requirements FR#17-FR#19 s/a traffic flow/the traffic flows within a client LSP/ Signaling is applied to client LSP, not flows as mentioned in General Comments above. FR#24 is extremely problematic. The existing framework document indicates that there are significant feasibility issues associated with supporting this requirement for all but small client LSP and requiring a fallback to link bundling for these small cleint LSP. There has been no discussion supporting a feasible means to do this for large client LSP. Therefore it may be wise to either drop this requirement entirely or at the very least change it to a SHOULD. If the requirement is kept, perhaps a qualifier indicating "for small client LSP only (ones that fit on a single component)" is required. If link bundling is the solution, the requirement is a NOOP but the requirement may serve to indicate that link bundling must co-exist with hash based load balancing for a subset of LSP requiring that a both directions take the same component. If FR#24 is relaxed to say that both directions traverse the same set of nodes, then FR#24 becomes feasible for large client LSP. This would, for example, allow MPLS-TP OAM to function corrently for MPLS-TP LSP carried within client MPLS LSP. If this is desirable it should be a separate requirement. The section title "Derived Requirements" has irked a number of people. These requirements are distinct in that they reference protocols which would be used within a solution, but they are not truly "derived" from the "Functional Requirements" in the prior section. I prefer "General Requirements for Protocol Solutions". Therefore s/Derived Requirements/GeneralRequirements for Protocol Solutions/ s/DR/GR/ I suggest rewording DR#1 as follows: OLD DR#1 The solution SHOULD attempt to extend existing protocols wherever possible, developing a new protocol only if this adds a significant set of capabilities. NEW GR#1 The solution SHOULD extend existing protocols wherever possible, developing a new protocol only where doing so adds a significant set of capabilities. I dropped "attempt to". The solution SHOULD get it right. No E for Effort for trying but getting it wrong. :-) In DR#3, I'm not sure what the last sentence means as worded, though I think I know the intent. OLD Other functional requirements should be supported as independently of signaling protocol as possible. NEW Function requirements SHOULD, where possible, be supported in a manner that supports LDP signaled LSP, RSVP signaled LSP, and LSP set up using management plane mechanisms. Either the management section is perfect or I forgot to read it. :-) The Ack section should say that after some discussion Tom Yu suggested replacement text that was used as the basis for the security section. The Ack section should indicate that the document was renamed as a result of potential problems with terminology collision that were pointed out by Lou Berger in the RtgDir review. From stephane.litkowski@orange.com Tue Oct 8 00:07:08 2013 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 E7FAC21E814C for ; Tue, 8 Oct 2013 00:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWIlUmVZm6he for ; Tue, 8 Oct 2013 00:07:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6798E21E8154 for ; Tue, 8 Oct 2013 00:07:02 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 2A8C23B40E2; Tue, 8 Oct 2013 09:07:01 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 043EB23805C; Tue, 8 Oct 2013 09:07:01 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.45]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Tue, 8 Oct 2013 09:07:00 +0200 From: To: "stbryant@cisco.com" Date: Tue, 8 Oct 2013 09:06:59 +0200 Subject: RE: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt Thread-Topic: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt Thread-Index: Ac7DdbevA8xk6TndR4OOA9Xm/Dpm3AAftC8g Message-ID: <28731_1381216021_5253AF15_28731_628_1_EEE55384044474429A926C625D0FCC810968F4D3E6@PUEXCB2F.nanterre.francetelecom.fr> References: <524C02D3.6050309@cisco.com> <18754_1381136403_52527813_18754_7041_1_EEE55384044474429A926C625D0FCC810966AAC932@PUEXCB2F.nanterre.francetelecom.fr> <5252D987.5050201@cisco.com> In-Reply-To: <5252D987.5050201@cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_EEE55384044474429A926C625D0FCC810968F4D3E6PUEXCB2Fnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.82422 Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , rogeriomariano , "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, 08 Oct 2013 07:07:09 -0000 --_000_EEE55384044474429A926C625D0FCC810968F4D3E6PUEXCB2Fnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stewart, >There are clearly only two solutions to this, either permit TLDP on any li= kely LSR, protected with an ACL if you wish, and accept the cases that fail= as being a minority concern, or two (and out of scope for this draft) get = the LSRs to advertise TLDP willingness in the IGP. [SLI] Some nodes are not accepting any TLDP session at all and you cannot = configure them to do it ... > We can certainly discuss the issue, but I am reluctant to specify a heuri= stic in an IETF draft, because then it is a specification and not a heurist= ic. [SLI] Ok, so just specify an algorithm to choose the IP address to use to e= stablish the TLDP session. By doing nothing, you can fall into situations w= here you PLR is unable to establish a TLDP session because it's choosing th= e wrong IP address. Thanks, Stephane Litkowski FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE Operational Engineering & Support IPTAC for RAEI network Orange Expert Network of Future t=E9l. +33 2 23 28 49 83 mob. +33 6 37 86 97 52 stephane.litkowski@orange.com De : Stewart Bryant [mailto:stbryant@cisco.com] Envoy=E9 : lundi 7 octobre 2013 17:56 =C0 : LITKOWSKI Stephane DTF/DERX Cc : Alvaro Retana (aretana); draft-ietf-rtgwg-remote-lfa@tools.ietf.org; r= ogeriomariano; rtgwg@ietf.org Objet : Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt On 07/10/2013 09:59, stephane.litkowski@orange.com wrote: Hi Stewart, Here are some old comments you didn't provide on feedback on : "Regarding remote LFA draft, I would hope to see some points addressed in t= he draft before going to WGLC. - It would be good to add some simulation results about how much TLDP sessi= on are required (TX and TX+RX), this in order to make people aware on how m= uch rLFA may impact their TLDP session scaling That is a issue for Mike to consider. - We already raised the point some months ago about possibly "interop" issu= es in the following cases : * PLR choose a PQ which is not able to accept TLDP session : we verifie= d it in a lab, and we can clearly fall into such situation in a live networ= k, leading to protection not available. There are clearly only two solutions to this, either permit TLDP on any lik= ely LSR, protected with an ACL if you wish, and accept the cases that fail = as being a minority concern, or two (and out of scope for this draft) get t= he LSRs to advertise TLDP willingness in the IGP. * PQ having multiple IP addresses /32 attached, so which one would be u= sed to establish TLDP session ? Current implementations are using some heur= istics and it would be good to document this We can certainly discuss the issue, but I am reluctant to specify a heurist= ic in an IETF draft, because then it is a specification and not a heuristic. - Current text states that rLFA is computed only when LFA are not available= and our analysis pointed that this is really not a good idea as in term of= manageability rLFA alternate may be better than LFA alternate. It would be= good that rLFA draft points to potential manageability issues and refers t= o the appropriate draft. Hopefully this can be an informative ref, but we can include some simple te= xt that notes that it is up to the implementer how they need to make a trad= e-off between minimum cost and minimum compute. Thanks for bringing this to my attention, hope to get some work done on thi= s draft at the end of this week. - Stewart " Thanks Stephane Stephane Litkowski FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE Operational Engineering & Support IPTAC for RAEI network Orange Expert Network of Future t=E9l. +33 2 23 28 49 83 mob. +33 6 37 86 97 52 stephane.litkowski@orange.com De : rtgwg-bounces@ietf.org [mailto:rtgwg-bo= unces@ietf.org] De la part de Stewart Bryant Envoy=E9 : mercredi 2 octobre 2013 13:26 =C0 : Alvaro Retana (aretana) Cc : draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rogeriomariano; rtgwg@ietf.org Objet : Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt I will try to get a new version out this week or next. I plan to put in the algorithm text, although having discussed this with Mike, our inclination is to include this as an appendix since it is not required for interoperability that you do the computation that way. I will look at the issues left unresolved and any comments posted in response to this email. I see no reason to request a slot at IETF88 unless there remain technical issues that we are unable to resolve on this list. - Stewart (as duty editor of the draft) On 01/10/2013 15:40, Alvaro Retana (aretana) wrote: On 10/1/13 10:31 AM, "rogeriomariano" > wrote: Rogerio: Folks, Does anyone know whether the draft deal will be treated in the IETF = 88? We haven't started working on the agenda yet, so it is perhaps too early to= talk about whether this draft will be discussed in Vancouver or not. In the meant time, if you have comments or questions on the draft, please p= ost them to the list. Thanks! Alvaro. _______________________________________________ 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 ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_EEE55384044474429A926C625D0FCC810968F4D3E6PUEXCB2Fnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Stewart,

 

 

>= ;There are clearly only two solutions to this, either permit TLDP on any li= kely LSR, protected with an ACL if you wish, and accept the cases that fail= as being a minority concern, or two (and out of scope for this draft) get = the LSRs to advertise TLDP willingness in the IGP.

[SLI] Some nodes are not accep= ting any TLDP session=A0 at all and you cannot configure them to do it R= 30;

&nbs= p;

 

> We can certainly discuss the issue, but I am reluctant to specify= a heuristic in an IETF draft, because then it is a specification and not a= heuristic.

 

[SLI] Ok,= so just specify an algorithm to choose the IP address to use to establish = the TLDP session. By doing nothing, you can fall into situations where you = PLR is unable to establish a TLDP session because it’s choosing the w= rong IP address.

=

 =

Thanks,

 

Stephane Litkow= ski
FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE<= /o:p>

Operational Engineering & Support= IPTAC for RAEI network

Orange E= xpert Network of Future
t=E9l. +33 2 23 28 49 83

mob. +33 6 37 86 97 52
stephane.litkowski@orange.com

De : Stewart B= ryant [mailto:stbryant@cisco.com]
Envoy=E9 : lundi 7 octobr= e 2013 17:56
=C0 : LITKOWSKI Stephane DTF/DERX
Cc = ;: Alvaro Retana (aretana); draft-ietf-rtgwg-remote-lfa@tools.ietf.org;= rogeriomariano; rtgwg@ietf.org
Objet : Re: I-D Action: draf= t-ietf-rtgwg-remote-lfa-02.txt

 

On 07/10/2013 09:5= 9, stephane.litkowski@oran= ge.com wrote:

Hi Stewart,<= /span>

 =

Here are some old c= omments you didn’t provide on feedback on :

 

“Regarding remote LFA dra= ft, I would hope to see some points addressed in the draft before going to = WGLC.

- It would be good to a= dd some simulation results about how much TLDP session are required (TX and= TX+RX), this in order to make people aware on how much rLFA may impact the= ir TLDP session scaling

 

Tha= t is a issue for Mike to consider.

- We already raised the point some months ago about possibly "i= nterop" issues in the following cases :

    * PLR choose a PQ which is not able to = accept TLDP session : we verified it in a lab, and we can clearly fall into= such situation in a live network, leading to protection not available.

There are clearly only two solutions= to this, either permit TLDP on any likely LSR, protected with an ACL if yo= u wish, and accept the cases that fail as being a minority concern, or two = (and out of scope for this draft) get the LSRs to advertise TLDP willingnes= s in the IGP.

 

    *= PQ having multiple IP addresses /32 attached, so which one would be used t= o establish TLDP session ? Current implementations are using some heuristic= s and it would be good to document this

 

= We can certainly discuss the issue, but I am reluctant to specify a heurist= ic in an IETF draft, because then it is a specification and not a heuristic= .


- Current text state= s that rLFA is computed only when LFA are not available and our analysis po= inted that this is really not a good idea as in term of manageability rLFA = alternate may be better than LFA alternate. It would be good that rLFA draf= t points to potential manageability issues and refers to the appropriate dr= aft.

Hopefully this can be an inf= ormative ref, but we can include some simple text that notes that it is up = to the implementer how they need to make a trade-off between minimum cost a= nd minimum compute.

Thanks for bringing this to my attention, hope t= o get some work done on this draft at  the end of this week.

- = Stewart


&= nbsp;

 

“=

 <= /o:p>

Thanks =

 

Stephane

 

 

 <= /o:p>

Stephane Litkowski
FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE

Operational Engineering & Support IPTAC for RAEI network<= /span>

Orange Expert Network of Future<= /span>
t=E9l. +33 2 23 28 49 83

mob. = +33 6 37 86 97 52
ste= phane.litkowski@orange.com

De : rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] De la p= art de Stewart Bryant
Envoy=E9 : mercredi 2 octobre 2013= 13:26
=C0 : Alvaro Retana (aretana)
Cc : draft-ietf-rtgwg= -remote-lfa@tools.ietf.org; rogeriomariano; rtgwg@ietf.org
Objet : Re: I-D Action: draft-ietf= -rtgwg-remote-lfa-02.txt

 

I will try to get a new = version out this week or next.

I plan to put in the algorithm text, = although having discussed
this with Mike, our inclination is to include = this as an
appendix since it is not required for interoperability that <= br>you do the computation that way.

I will look at the issues left u= nresolved and any comments
posted in response to this email.

I se= e no reason to request a slot at IETF88 unless there remain
technical is= sues that we are unable to resolve on this list.

- Stewart (as duty = editor of the draft)



On 01/10/2013 15:40, Alvaro Retana (are= tana) wrote:

On 10/1/13 10:31 AM, "roger= iomariano" <rsouza.rjo@gmai= l.com> wrote:

 

Rogerio:

<= div>

 

Folks, Doe= s anyone know whether the draft deal will be treated in the IETF 88?

 

We haven't started working on the agen= da yet, so it is perhaps too early to talk about whether this draft will be= discussed in Vancouver or not.

 

In the meant time, = if you have comments or questions on the draft, please post them to the lis= t.

 

Thanks!

 

Alvaro.





______=
_________________________________________
rtgwg mailin=
g list
rtgwg@ietf.or=
g
https://www.ietf.org/mailman/listinfo/rtgwg





-- =

For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_busi=
ness/legal/cri/index.html
 
<= pre>_______________________________________________________________________= __________________________________________________
 
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 messag=
es electroniques etant susceptibles d'alteration,
Oran=
ge decline toute responsabilite si ce message a ete altere, deforme ou fals=
ifie. Merci.
 
This message =
and its attachments may contain confidential or privileged information that=
 may be protected by law;
they should not be distribut=
ed, used or copied without authorisation.
If you have =
received this email in error, please notify the sender and delete this mess=
age and its attachments.
As emails may be altered, Ora=
nge is not liable for messages that have been modified, changed or falsifie=
d.
Thank you.



-- 
For corporate legal i=
nformation go to:
 
htt=
p://www.cisco.com/web/about/doing_business/legal/cri/index.html
 
___________________________=
___________________________________________________________________________=
___________________

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,
Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
= --_000_EEE55384044474429A926C625D0FCC810968F4D3E6PUEXCB2Fnante_-- From stbryant@cisco.com Tue Oct 8 02:37:51 2013 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 F384E11E8194 for ; Tue, 8 Oct 2013 02:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.427 X-Spam-Level: X-Spam-Status: No, score=-110.427 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6OotvemCfoy for ; Tue, 8 Oct 2013 02:37:46 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 29F4911E8192 for ; Tue, 8 Oct 2013 02:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39287; q=dns/txt; s=iport; t=1381225059; x=1382434659; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=zZUnoqOZsyW1rVGsIe91MmJP/SvQ6+VxEm8j8vmJUM4=; b=XFpeA9F3VWoEy5FUQrKum1okpi5M/gA4IEwcj4r9ARuAyQJ653fp0qxD UYO7YTCm6UY6wYdq/nGHAAl8UXkc5fK+2kadqXdA6hhob0kdptaiZ3FX1 bCH74gnDN13S8rudSDezE3fRG2pjmVX7xJUxWghV0jHNAp/A9qkY1uryJ 4=; X-IronPort-AV: E=Sophos;i="4.90,1056,1371081600"; d="scan'208,217";a="87258348" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 08 Oct 2013 09:37:38 +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 r989bWMX029341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Oct 2013 09:37:33 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r989bVHU021802; Tue, 8 Oct 2013 10:37:31 +0100 (BST) Message-ID: <5253D25A.1020600@cisco.com> Date: Tue, 08 Oct 2013 10:37:30 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stephane.litkowski@orange.com Subject: Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt References: <524C02D3.6050309@cisco.com> <18754_1381136403_52527813_18754_7041_1_EEE55384044474429A926C625D0FCC810966AAC932@PUEXCB2F.nanterre.francetelecom.fr> <5252D987.5050201@cisco.com> <28731_1381216021_5253AF15_28731_628_1_EEE55384044474429A926C625D0FCC810968F4D3E6@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: <28731_1381216021_5253AF15_28731_628_1_EEE55384044474429A926C625D0FCC810968F4D3E6@PUEXCB2F.nanterre.francetelecom.fr> Content-Type: multipart/alternative; boundary="------------090905050502060107070501" Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , rogeriomariano , "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: Tue, 08 Oct 2013 09:37:51 -0000 This is a multi-part message in MIME format. --------------090905050502060107070501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 08/10/2013 08:06, stephane.litkowski@orange.com wrote: > > Stewart, > > >There are clearly only two solutions to this, either permit TLDP on any likely LSR, > protected with an ACL if you wish, and accept the cases that fail as > being a minority concern, or two (and out of scope for this draft) get > the LSRs to advertise TLDP willingness in the IGP. > > [SLI] Some nodes are not accepting any TLDP session at all and you > cannot configure them to do it ... > So if the nodes to not accept the TLDP they you have a number of alternatives: 1) Take it on the chin (it is FRR not convergence) 2) Replace the nodes with nodes that do 3) Modify the nodes to accept the TLDP 4) Get all other nodes to advertise the capability and address 5) Test the candidate nodes as part of the selection process Are there any other approaches? > >We can certainly discuss the issue, but I am reluctant to specify a > heuristic in an IETF draft, because then it is a specification and not > a heuristic. > > [SLI] Ok, so just specify an algorithm to choose the IP address to use > to establish the TLDP session. By doing nothing, you can fall into > situations where you PLR is unable to establish a TLDP session because > it's choosing the wrong IP address. > What algorithm do you suggest? Stewart > Thanks, > > *Stephane Litkowski* > FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE > > Operational Engineering & Support IPTAC for RAEI network > > Orange Expert Network of Future > tél. +33 2 23 28 49 83 > > mob. +33 6 37 86 97 52 > stephane.litkowski@orange.com > > *De :*Stewart Bryant [mailto:stbryant@cisco.com] > *Envoyé :* lundi 7 octobre 2013 17:56 > *À :* LITKOWSKI Stephane DTF/DERX > *Cc :* Alvaro Retana (aretana); > draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rogeriomariano; rtgwg@ietf.org > *Objet :* Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt > > On 07/10/2013 09:59, stephane.litkowski@orange.com > wrote: > > Hi Stewart, > > Here are some old comments you didn't provide on feedback on : > > "Regarding remote LFA draft, I would hope to see some points > addressed in the draft before going to WGLC. > > - It would be good to add some simulation results about how much > TLDP session are required (TX and TX+RX), this in order to make > people aware on how much rLFA may impact their TLDP session scaling > > That is a issue for Mike to consider. > > - We already raised the point some months ago about possibly "interop" > issues in the following cases : > > * PLR choose a PQ which is not able to accept TLDP session : we > verified it in a lab, and we can clearly fall into such situation in a > live network, leading to protection not available. > > There are clearly only two solutions to this, either permit TLDP on > any likely LSR, protected with an ACL if you wish, and accept the > cases that fail as being a minority concern, or two (and out of scope > for this draft) get the LSRs to advertise TLDP willingness in the IGP. > > * PQ having multiple IP addresses /32 attached, so which one would > be used to establish TLDP session ? Current implementations are using > some heuristics and it would be good to document this > > We can certainly discuss the issue, but I am reluctant to specify a > heuristic in an IETF draft, because then it is a specification and not > a heuristic. > > > - Current text states that rLFA is computed only when LFA are not > available and our analysis pointed that this is really not a good idea > as in term of manageability rLFA alternate may be better than LFA > alternate. It would be good that rLFA draft points to potential > manageability issues and refers to the appropriate draft. > > Hopefully this can be an informative ref, but we can include some > simple text that notes that it is up to the implementer how they need > to make a trade-off between minimum cost and minimum compute. > > Thanks for bringing this to my attention, hope to get some work done > on this draft at the end of this week. > > - Stewart > > > " > > Thanks > > Stephane > > *Stephane Litkowski* > FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE > > Operational Engineering & Support IPTAC for RAEI network > > Orange Expert Network of Future > tél. +33 2 23 28 49 83 > > mob. +33 6 37 86 97 52 > stephane.litkowski@orange.com > > *De :*rtgwg-bounces@ietf.org > [mailto:rtgwg-bounces@ietf.org] *De la part de* Stewart Bryant > *Envoyé :* mercredi 2 octobre 2013 13:26 > *À :* Alvaro Retana (aretana) > *Cc :* draft-ietf-rtgwg-remote-lfa@tools.ietf.org > ; rogeriomariano; > rtgwg@ietf.org > *Objet :* Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt > > I will try to get a new version out this week or next. > > I plan to put in the algorithm text, although having discussed > this with Mike, our inclination is to include this as an > appendix since it is not required for interoperability that > you do the computation that way. > > I will look at the issues left unresolved and any comments > posted in response to this email. > > I see no reason to request a slot at IETF88 unless there remain > technical issues that we are unable to resolve on this list. > > - Stewart (as duty editor of the draft) > > > > On 01/10/2013 15:40, Alvaro Retana (aretana) wrote: > > On 10/1/13 10:31 AM, "rogeriomariano" > wrote: > > Rogerio: > > Folks, Does anyone know whether the draft deal will be treated > in the IETF 88? > > We haven't started working on the agenda yet, so it is perhaps too > early to talk about whether this draft will be discussed in > Vancouver or not. > > In the meant time, if you have comments or questions on the draft, > please post them to the list. > > Thanks! > > Alvaro. > > > > > > _______________________________________________ > > 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 > > _________________________________________________________________________________________________________________________ > > 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, > 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, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > _________________________________________________________________________________________________________________________ > > 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, > 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, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------090905050502060107070501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 08/10/2013 08:06, stephane.litkowski@orange.com wrote:

Stewart,

 

 

>There are clearly only two solutions to this, either permit TLDP on any likely LSR, protected with an ACL if you wish, and accept the cases that fail as being a minority concern, or two (and out of scope for this draft) get the LSRs to advertise TLDP willingness in the IGP.

[SLI] Some nodes are not accepting any TLDP session  at all and you cannot configure them to do it …

So if the nodes to not accept the TLDP they you have a number of
alternatives:

1) Take it on the chin (it is FRR not convergence)
2) Replace the nodes with nodes that do
3) Modify the nodes to accept the TLDP
4) Get all other nodes to advertise the capability and address
5) Test the candidate nodes as part of the selection process

Are there any other approaches?

 

 

> We can certainly discuss the issue, but I am reluctant to specify a heuristic in an IETF draft, because then it is a specification and not a heuristic.

 

[SLI] Ok, so just specify an algorithm to choose the IP address to use to establish the TLDP session. By doing nothing, you can fall into situations where you PLR is unable to establish a TLDP session because it’s choosing the wrong IP address.

What algorithm do you suggest?

Stewart

 

Thanks,

 

Stephane Litkowski
FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE

Operational Engineering & Support IPTAC for RAEI network

Orange Expert Network of Future
tél. +33 2 23 28 49 83

mob. +33 6 37 86 97 52
stephane.litkowski@orange.com

De : Stewart Bryant [mailto:stbryant@cisco.com]
Envoyé : lundi 7 octobre 2013 17:56
À : LITKOWSKI Stephane DTF/DERX
Cc : Alvaro Retana (aretana); draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rogeriomariano; rtgwg@ietf.org
Objet : Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

 

On 07/10/2013 09:59, stephane.litkowski@orange.com wrote:

Hi Stewart,

 

Here are some old comments you didn’t provide on feedback on :

 

“Regarding remote LFA draft, I would hope to see some points addressed in the draft before going to WGLC.

- It would be good to add some simulation results about how much TLDP session are required (TX and TX+RX), this in order to make people aware on how much rLFA may impact their TLDP session scaling

 

That is a issue for Mike to consider.

- We already raised the point some months ago about possibly "interop" issues in the following cases :

    * PLR choose a PQ which is not able to accept TLDP session : we verified it in a lab, and we can clearly fall into such situation in a live network, leading to protection not available.

There are clearly only two solutions to this, either permit TLDP on any likely LSR, protected with an ACL if you wish, and accept the cases that fail as being a minority concern, or two (and out of scope for this draft) get the LSRs to advertise TLDP willingness in the IGP.

 

    * PQ having multiple IP addresses /32 attached, so which one would be used to establish TLDP session ? Current implementations are using some heuristics and it would be good to document this

 

We can certainly discuss the issue, but I am reluctant to specify a heuristic in an IETF draft, because then it is a specification and not a heuristic.


- Current text states that rLFA is computed only when LFA are not available and our analysis pointed that this is really not a good idea as in term of manageability rLFA alternate may be better than LFA alternate. It would be good that rLFA draft points to potential manageability issues and refers to the appropriate draft.

Hopefully this can be an informative ref, but we can include some simple text that notes that it is up to the implementer how they need to make a trade-off between minimum cost and minimum compute.

Thanks for bringing this to my attention, hope to get some work done on this draft at  the end of this week.

- Stewart


 

 

“

 

Thanks

 

Stephane

 

 

 

Stephane Litkowski
FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE

Operational Engineering & Support IPTAC for RAEI network

Orange Expert Network of Future
tél. +33 2 23 28 49 83

mob. +33 6 37 86 97 52
stephane.litkowski@orange.com

De : rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] De la part de Stewart Bryant
Envoyé : mercredi 2 octobre 2013 13:26
À : Alvaro Retana (aretana)
Cc : draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rogeriomariano; rtgwg@ietf.org
Objet : Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

 

I will try to get a new version out this week or next.

I plan to put in the algorithm text, although having discussed
this with Mike, our inclination is to include this as an
appendix since it is not required for interoperability that
you do the computation that way.

I will look at the issues left unresolved and any comments
posted in response to this email.

I see no reason to request a slot at IETF88 unless there remain
technical issues that we are unable to resolve on this list.

- Stewart (as duty editor of the draft)



On 01/10/2013 15:40, Alvaro Retana (aretana) wrote:

On 10/1/13 10:31 AM, "rogeriomariano" <rsouza.rjo@gmail.com> wrote:

 

Rogerio:

 

Folks, Does anyone know whether the draft deal will be treated in the IETF 88?

 

We haven't started working on the agenda yet, so it is perhaps too early to talk about whether this draft will be discussed in Vancouver or not.

 

In the meant time, if you have comments or questions on the draft, please post them to the list.

 

Thanks!

 

Alvaro.





_______________________________________________
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
 
_________________________________________________________________________________________________________________________
 
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,
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, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.




-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
 
_________________________________________________________________________________________________________________________

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,
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, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------090905050502060107070501-- From stephane.litkowski@orange.com Tue Oct 8 04:26:40 2013 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 C38F811E81AC for ; Tue, 8 Oct 2013 04:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.627 X-Spam-Level: X-Spam-Status: No, score=-1.627 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjsLm8OJ+UtO for ; Tue, 8 Oct 2013 04:26:33 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 37B8321E817D for ; Tue, 8 Oct 2013 04:26:30 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 35F90C052F; Tue, 8 Oct 2013 13:26:29 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id D90DB3841F8; Tue, 8 Oct 2013 13:26:28 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.45]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 8 Oct 2013 13:26:28 +0200 From: To: "stbryant@cisco.com" Date: Tue, 8 Oct 2013 13:26:27 +0200 Subject: RE: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt Thread-Topic: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt Thread-Index: Ac7ECghI0xyybwRpRB6AWlWq3h4WXAADW1Jw Message-ID: <18850_1381231588_5253EBE4_18850_9379_1_EEE55384044474429A926C625D0FCC810968F4D61B@PUEXCB2F.nanterre.francetelecom.fr> References: <524C02D3.6050309@cisco.com> <18754_1381136403_52527813_18754_7041_1_EEE55384044474429A926C625D0FCC810966AAC932@PUEXCB2F.nanterre.francetelecom.fr> <5252D987.5050201@cisco.com> <28731_1381216021_5253AF15_28731_628_1_EEE55384044474429A926C625D0FCC810968F4D3E6@PUEXCB2F.nanterre.francetelecom.fr> <5253D25A.1020600@cisco.com> In-Reply-To: <5253D25A.1020600@cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_EEE55384044474429A926C625D0FCC810968F4D61BPUEXCB2Fnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.10.8.91814 Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , rogeriomariano , "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, 08 Oct 2013 11:26:40 -0000 --_000_EEE55384044474429A926C625D0FCC810968F4D61BPUEXCB2Fnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So if the nodes to not accept the TLDP they you have a number of alternatives: 1) Take it on the chin (it is FRR not convergence) 2) Replace the nodes with nodes that do 3) Modify the nodes to accept the TLDP 4) Get all other nodes to advertise the capability and address 5) Test the candidate nodes as part of the selection process Are there any other approaches? [SLI] The good approach would be to use policies to automatically prune the= se PQs as operators know which PQ may not to be able to accept TLDP. What algorithm do you suggest? [SLI] Do you have nothing to propose ? I know that CISCO has a working rLFA= implementation , so I think you already have something to propose ... In case you don't, we could use the following approach : - Short term : use a tie breaker like (ISIS speaking) : o Use IP in TLV134 o If not existing, use IP in TLV132 if there's only one entry o If multiple entries in TLV132, use highest or lowest /32 IP listed as T= LV135 Note that there is some corner cases where such algo would not work, e.g. w= hen external /32 are advertised in ISIS using redistribution, in TLV135 you= don't have the information of internal or external route and you may choos= e an external one. - Long term : define an IGP extension to mark prefix associated wi= th TLDP listening. The idea is that the reader of the draft need to be aware on how the TLDP a= ddress is chosen and so may be able to adjust his LDP configs to make it wo= rking correctly. Stephane Litkowski FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE Operational Engineering & Support IPTAC for RAEI network Orange Expert Network of Future t=E9l. +33 2 23 28 49 83 mob. +33 6 37 86 97 52 stephane.litkowski@orange.com De : Stewart Bryant [mailto:stbryant@cisco.com] Envoy=E9 : mardi 8 octobre 2013 11:38 =C0 : LITKOWSKI Stephane DTF/DERX Cc : Alvaro Retana (aretana); draft-ietf-rtgwg-remote-lfa@tools.ietf.org; r= ogeriomariano; rtgwg@ietf.org Objet : Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt On 08/10/2013 08:06, stephane.litkowski@orange.com wrote: Stewart, >There are clearly only two solutions to this, either permit TLDP on any li= kely LSR, protected with an ACL if you wish, and accept the cases that fail= as being a minority concern, or two (and out of scope for this draft) get = the LSRs to advertise TLDP willingness in the IGP. [SLI] Some nodes are not accepting any TLDP session at all and you cannot = configure them to do it ... So if the nodes to not accept the TLDP they you have a number of alternatives: 1) Take it on the chin (it is FRR not convergence) 2) Replace the nodes with nodes that do 3) Modify the nodes to accept the TLDP 4) Get all other nodes to advertise the capability and address 5) Test the candidate nodes as part of the selection process Are there any other approaches? > We can certainly discuss the issue, but I am reluctant to specify a heuri= stic in an IETF draft, because then it is a specification and not a heurist= ic. [SLI] Ok, so just specify an algorithm to choose the IP address to use to e= stablish the TLDP session. By doing nothing, you can fall into situations w= here you PLR is unable to establish a TLDP session because it's choosing th= e wrong IP address. What algorithm do you suggest? Stewart Thanks, Stephane Litkowski FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE Operational Engineering & Support IPTAC for RAEI network Orange Expert Network of Future t=E9l. +33 2 23 28 49 83 mob. +33 6 37 86 97 52 stephane.litkowski@orange.com De : Stewart Bryant [mailto:stbryant@cisco.com] Envoy=E9 : lundi 7 octobre 2013 17:56 =C0 : LITKOWSKI Stephane DTF/DERX Cc : Alvaro Retana (aretana); draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rogeriomariano; rtgwg@iet= f.org Objet : Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt On 07/10/2013 09:59, stephane.litkowski@orange.com wrote: Hi Stewart, Here are some old comments you didn't provide on feedback on : "Regarding remote LFA draft, I would hope to see some points addressed in t= he draft before going to WGLC. - It would be good to add some simulation results about how much TLDP sessi= on are required (TX and TX+RX), this in order to make people aware on how m= uch rLFA may impact their TLDP session scaling That is a issue for Mike to consider. - We already raised the point some months ago about possibly "interop" issu= es in the following cases : * PLR choose a PQ which is not able to accept TLDP session : we verifie= d it in a lab, and we can clearly fall into such situation in a live networ= k, leading to protection not available. There are clearly only two solutions to this, either permit TLDP on any lik= ely LSR, protected with an ACL if you wish, and accept the cases that fail = as being a minority concern, or two (and out of scope for this draft) get t= he LSRs to advertise TLDP willingness in the IGP. * PQ having multiple IP addresses /32 attached, so which one would be u= sed to establish TLDP session ? Current implementations are using some heur= istics and it would be good to document this We can certainly discuss the issue, but I am reluctant to specify a heurist= ic in an IETF draft, because then it is a specification and not a heuristic. - Current text states that rLFA is computed only when LFA are not available= and our analysis pointed that this is really not a good idea as in term of= manageability rLFA alternate may be better than LFA alternate. It would be= good that rLFA draft points to potential manageability issues and refers t= o the appropriate draft. Hopefully this can be an informative ref, but we can include some simple te= xt that notes that it is up to the implementer how they need to make a trad= e-off between minimum cost and minimum compute. Thanks for bringing this to my attention, hope to get some work done on thi= s draft at the end of this week. - Stewart " Thanks Stephane Stephane Litkowski FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE Operational Engineering & Support IPTAC for RAEI network Orange Expert Network of Future t=E9l. +33 2 23 28 49 83 mob. +33 6 37 86 97 52 stephane.litkowski@orange.com De : rtgwg-bounces@ietf.org [mailto:rtgwg-bo= unces@ietf.org] De la part de Stewart Bryant Envoy=E9 : mercredi 2 octobre 2013 13:26 =C0 : Alvaro Retana (aretana) Cc : draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rogeriomariano; rtgwg@ietf.org Objet : Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt I will try to get a new version out this week or next. I plan to put in the algorithm text, although having discussed this with Mike, our inclination is to include this as an appendix since it is not required for interoperability that you do the computation that way. I will look at the issues left unresolved and any comments posted in response to this email. I see no reason to request a slot at IETF88 unless there remain technical issues that we are unable to resolve on this list. - Stewart (as duty editor of the draft) On 01/10/2013 15:40, Alvaro Retana (aretana) wrote: On 10/1/13 10:31 AM, "rogeriomariano" > wrote: Rogerio: Folks, Does anyone know whether the draft deal will be treated in the IETF = 88? We haven't started working on the agenda yet, so it is perhaps too early to= talk about whether this draft will be discussed in Vancouver or not. In the meant time, if you have comments or questions on the draft, please p= ost them to the list. Thanks! Alvaro. _______________________________________________ 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 ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_EEE55384044474429A926C625D0FCC810968F4D61BPUEXCB2Fnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

So if the nodes to not accept the TLDP they you have a numb= er of
alternatives:

1) Take it on the chin (it is FRR not converg= ence)
2) Replace the nodes with nodes that do
3) Modify the nodes to = accept the TLDP
4) Get all other nodes to advertise the capability and a= ddress
5) Test the candidate nodes as part of the selection process
<= br>Are there any other approaches?

 

[SLI] The good approach would be to use policies to automatic= ally prune these PQs as operators know which PQ may not to be able to accep= t TLDP.

&= nbsp;

 

 

What algorithm do you suggest?

[SLI] Do you have nothing to propose = ? I know that CISCO has a working rLFA implementation , so I think you alre= ady have something to propose ...

In case you don’t, we could use the following app= roach :

-          Short term : use a tie breaker like (ISIS= speaking) :

o  = ; Use IP in TLV134

o=    If not existing, use IP in TLV132 if there= ’s only one entry

o=    If multiple = entries in TLV132, use highest or lowest /32 IP listed as TLV135=

Note that there is some corner cases where such algo would not work, e= .g. when external /32 are advertised in ISIS using redistribution, in TLV13= 5 you don’t have the information of internal or external route and yo= u may choose an external one.

 

-     &n= bsp;    Long term : define an IGP extension to mark prefix= associated with TLDP listening.

 

=

The idea is that the reader of the draft need to be a= ware on how the TLDP address is chosen and so may be able to adjust his LDP= configs to make it working correctly.

 

Stephane Litkowski
FT= /OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE

Operational Engineering & Support IPTAC for RAEI network<= o:p>

Orange Expert Network of Future<= /span>
t=E9l. +33 2 23 28 49 83

mob. = +33 6 37 86 97 52
ste= phane.litkowski@orange.com

De : Stewart Bryant [mailto:stbryant@cisco.c= om]
Envoy=E9 : mardi 8 octobre 2013 11:38
=C0 :<= /b> LITKOWSKI Stephane DTF/DERX
Cc : Alvaro Retana (aretana)= ; draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rogeriomariano; rtgwg@ietf.or= g
Objet : Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt=

 

On 08/10/2013 08:06, stephane.litkowski@orange.com wrote:

Stewart,

 

 

>There are clearly only two solutions to this, either permi= t TLDP on any likely LSR, protected with an ACL if you wish, and accept the= cases that fail as being a minority concern, or two (and out of scope for = this draft) get the LSRs to advertise TLDP willingness in the IGP.

<= br>

[SLI] Some= nodes are not accepting any TLDP session  at all and you cannot confi= gure them to do it …

So if the nodes to not accept the TLDP they you h= ave a number of
alternatives:

1) Take it on the chin (it is FRR n= ot convergence)
2) Replace the nodes with nodes that do
3) Modify the= nodes to accept the TLDP
4) Get all other nodes to advertise the capabi= lity and address
5) Test the candidate nodes as part of the selection pr= ocess

Are there any other approaches?


<= /p>

 

 

> We can certainly discuss the issue= , but I am reluctant to specify a heuristic in an IETF draft, because then = it is a specification and not a heuristic.

 

[SLI] Ok, so just specify an algorithm to choose the = IP address to use to establish the TLDP session. By doing nothing, you can = fall into situations where you PLR is unable to establish a TLDP session be= cause it’s choosing the wrong IP address.

What algorithm do you suggest?

Stewart


 

Thanks,

 

<= /div>

Stephane Litkowski
FT/OF= /DTF/DEX/DERX/EE IP/TAC ENTREPRISE

Operational Engineering & Support IPTAC for RAEI network=

Orange Expert Network of Future<= br>t=E9l. +33 2 23 28 49 83

mob. +33 6 37 86= 97 52
stephane.litko= wski@orange.com

De : Stewart Bryant [mailto:stbryant@cisco.com]
En= voy=E9 : lundi 7 octobre 2013 17:56
=C0 : LITKOWSKI= Stephane DTF/DERX
Cc : Alvaro Retana (aretana); draft-ietf-rtgwg-remote-= lfa@tools.ietf.org; rogeriomariano; r= tgwg@ietf.org
Objet : Re: I-D Action: draft-ietf-rtgwg-r= emote-lfa-02.txt

&nbs= p;

On 07/10/2013 09:59, stephane.litkowski@orange.com wro= te:

Hi Stewart,

 

Here are some old comments you di= dn’t provide on feedback on :

 

“Regarding remote LFA draft, I would hope= to see some points addressed in the draft before going to WGLC.

- It would be good to add some simulati= on results about how much TLDP session are required (TX and TX+RX), this in= order to make people aware on how much rLFA may impact their TLDP session = scaling

 =

That is a issue for= Mike to consider.


- We = already raised the point some months ago about possibly "interop"= issues in the following cases :

=     * PLR choose a PQ which is not able to accept TLDP s= ession : we verified it in a lab, and we can clearly fall into such situati= on in a live network, leading to protection not available.

There are clearly only two solutions to this, eit= her permit TLDP on any likely LSR, protected with an ACL if you wish, and a= ccept the cases that fail as being a minority concern, or two (and out of s= cope for this draft) get the LSRs to advertise TLDP willingness in the IGP.=


 

    * PQ having= multiple IP addresses /32 attached, so which one would be used to establis= h TLDP session ? Current implementations are using some heuristics and it w= ould be good to document this

 

We can cer= tainly discuss the issue, but I am reluctant to specify a heuristic in an I= ETF draft, because then it is a specification and not a heuristic.

<= br>

- Current text states that r= LFA is computed only when LFA are not available and our analysis pointed th= at this is really not a good idea as in term of manageability rLFA alternat= e may be better than LFA alternate. It would be good that rLFA draft points= to potential manageability issues and refers to the appropriate draft.

Hopefully this can be an informative= ref, but we can include some simple text that notes that it is up to the i= mplementer how they need to make a trade-off between minimum cost and minim= um compute.

Thanks for bringing this to my attention, hope to get so= me work done on this draft at  the end of this week.

- Stewart<= br>


 = ;

 

“

 

Thanks

=

 

Stephane

 

 

 <= /o:p>

Stephane Litkowski
FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE

Operational Engineering & Support IPTAC for RAEI network<= /span>

Orange Expert Network of Future<= /span>
t=E9l. +33 2 23 28 49 83

mob. = +33 6 37 86 97 52
ste= phane.litkowski@orange.com

De : rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] De la p= art de Stewart Bryant
Envoy=E9 : mercredi 2 octobre 2013= 13:26
=C0 : Alvaro Retana (aretana)
Cc : draft-ietf-rtgwg= -remote-lfa@tools.ietf.org; rogeriomariano; rtgwg@ietf.org
Objet : Re: I-D Action: draft-ietf= -rtgwg-remote-lfa-02.txt

 

I will try to get a new = version out this week or next.

I plan to put in the algorithm text, = although having discussed
this with Mike, our inclination is to include = this as an
appendix since it is not required for interoperability that <= br>you do the computation that way.

I will look at the issues left u= nresolved and any comments
posted in response to this email.

I se= e no reason to request a slot at IETF88 unless there remain
technical is= sues that we are unable to resolve on this list.

- Stewart (as duty = editor of the draft)



On 01/10/2013 15:40, Alvaro Retana (are= tana) wrote:

On 10/1/13 10:31 AM, "roger= iomariano" <rsouza.rjo@gmai= l.com> wrote:

 

Rogerio:

<= div>

 

Folks, Doe= s anyone know whether the draft deal will be treated in the IETF 88?

 

We haven't started working on the agen= da yet, so it is perhaps too early to talk about whether this draft will be= discussed in Vancouver or not.

 

In the meant time, = if you have comments or questions on the draft, please post them to the lis= t.

 

Thanks!

 

Alvaro.






__=
_____________________________________________
rtgwg ma=
iling list
rtgwg@iet=
f.org
https://www.ietf.org/mailman/listinfo/rtgwg





=
-- 
For corporate legal information go to:<=
/pre>
 
http://www.cisco.com/web/about/do=
ing_business/legal/cri/index.html
 
_______________________________________________________________=
__________________________________________________________
=

 
Ce message et ses pieces jointes peuvent c=
ontenir des informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies sans autorisat=
ion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Le=
s messages electroniques etant susceptibles d'alteration,
<=
pre>Orange decline toute responsabilite si ce message a ete altere, deforme=
 ou falsifie. Merci.
 
This =
message and its attachments may contain confidential or privileged informat=
ion that may be protected by law;
they should not be d=
istributed, used or copied without authorisation.
If y=
ou have received this email in error, please notify the sender and delete t=
his message and its attachments.
As emails may be alte=
red, Orange is not liable for messages that have been modified, changed or =
falsified.
Thank you.




-- 
For corpo=
rate legal information go to:
 
<=
pre>http://www.cisco.com/web/about/doing_business/legal/cri/index.html<=
/a>
 
______________________=
___________________________________________________________________________=
________________________
 
C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
pas etre dif=
fuses, 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 sus=
ceptibles d'alteration,
Orange decline toute responsab=
ilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may co=
ntain confidential or privileged information that may be protected by law;<=
o:p>
they should not be distributed, used or copied without=
 authorisation.
If you have received this email in err=
or, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for mess=
ages that have been modified, changed or falsified.
Th=
ank you.



-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about=
/doing_business/legal/cri/index.html
 
______________________________________________________=
___________________________________________________________________

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,
Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
= --_000_EEE55384044474429A926C625D0FCC810968F4D61BPUEXCB2Fnante_-- From stephane.litkowski@orange.com Tue Oct 8 04:33:55 2013 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 3C8F411E81B7 for ; Tue, 8 Oct 2013 04:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSJzlvRMTZqp for ; Tue, 8 Oct 2013 04:33:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id DE94C11E8197 for ; Tue, 8 Oct 2013 04:33:50 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id F36B3190100; Tue, 8 Oct 2013 13:33:48 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id D18FE158118; Tue, 8 Oct 2013 13:33:48 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.45]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Tue, 8 Oct 2013 13:33:48 +0200 From: To: Hannes Gredler , Jeff Tantsura Date: Tue, 8 Oct 2013 13:33:47 +0200 Subject: RE: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt Thread-Topic: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt Thread-Index: Ac7DWP5PNvB0Tk3VTbKro2ExoqRHSQAwG7Hw Message-ID: <8189_1381232028_5253ED9C_8189_1805_1_EEE55384044474429A926C625D0FCC810968F4D62D@PUEXCB2F.nanterre.francetelecom.fr> References: <60DEDD93F5E54B4AB55647B8B6C7483994EA2E@eusaamb109.ericsson.se> <20131007123010.GB21218@juniper.net> In-Reply-To: <20131007123010.GB21218@juniper.net> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2011.11.18.222714 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, 08 Oct 2013 11:33:55 -0000 SGksDQoNCklNSE8sIGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gd2FpdCBtYXliZSB1bnRpbCBJRVRG ODkgdG8gZGVjaWRlIGFib3V0IG1lcmdpbmcgbm9kZSBwcm90ZWN0IHdpdGggYmFzaWMgckxGQSBz cGVjLg0KSSB0aGluayB3ZSBjb3VsZCBwcm9ncmVzcyBxdWl0ZSBmYXN0IG9uIG5vZGUgcHJvdGVj dGlvbiBhbmQgdHdvIElFVEYgbWVldGluZ3MgKDg4LCA4OSkgd291bGQgYmUgZmluZSB0byBoYXZl IGEgZ29vZCB2aWV3IGFuZCB3aGVyZSB3ZSBhcmUgb24gbm9kZSBwcm90ZWN0aW9uIG1hdHVyaXR5 LiBUaGVuIHdlIG1heSBkZWNpZGUgaWYgbWVyZ2UgaXMgcG9zc2libGUgb3Igbm90LiBUaGVzZSB0 d28gbWVldGluZ3Mgd291bGQgYWxzbyBwZXJtaXQgdG8gc3RhYmlsaXplIHRoZSByTEZBIGJhc2Ug c3BlYyBkZXRhaWxzIGFuZCBoYXZlIGNvbnNlbnN1cyBvbiB0aGUgcmVxdWlyZWQgbGV2ZWwgb2Yg ZGV0YWlscyB0aGF0IGFyZSBtaXNzaW5nIHRvZGF5Lg0KDQpJIHRoaW5rIG5vdyBpdCdzIGEgYml0 IGVhcmx5IHRvIGRlY2lkZSAuLi4NCg0KRmVlZGJhY2tzID8gZXNwZWNpYWxseSBmcm9tIGNoYWly cyA/DQoNCg0KLS0tDQpTdGVwaGFuZQ0KIA0KDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0t LQ0KRGXCoDogcnRnd2ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Z3dnLWJvdW5jZXNAaWV0 Zi5vcmddIERlIGxhIHBhcnQgZGUgSGFubmVzIEdyZWRsZXINCkVudm95w6nCoDogbHVuZGkgNyBv Y3RvYnJlIDIwMTMgMTQ6MzANCsOAwqA6IEplZmYgVGFudHN1cmENCkNjwqA6IHJ0Z3dnQGlldGYu b3JnDQpPYmpldMKgOiBSZTogUmVxdWVzdCBmb3IgcmV2aWV3IC0gZHJhZnQtcHNhcmthci1ydGd3 Zy1ybGZhLW5vZGUtcHJvdGVjdGlvbi0wMS50eHQNCg0KamVmZiwNCg0KaSBhbSBoYXBweSB0byBk byB0aGlzIFtybGZhIHNpbmdsZS1zcGVjIGZvciBsaW5rIGFuZCBub2RlLXByb3RlY3Rpb25dIHVu Zm9ydHVuYXRlbHkgdGhlIGN1cnJlbnQgZWRpdG9yIG9mIHRoZSBybGZhIGJhc2Ugc3BlYyBpcyBh IGJpdCA8Y291Z2gsIGNvdWdoPiByZWx1Y3RhbnQgdG8gaW5jb3Jwb3JhdGUgY2hhbmdlcyBmb3Ig c29tZSByZWFzb24uDQoNCklNTyB0aGVyZSBhcmUgdGhyZWUgcm9hZHMgdG8gZml4IHRoZSBwcm9i bGVtOg0KDQoxLiBrZWVwIHJsZmEsIG5vZGUgcHJvdGVjdGlvbiBzZXBlcmF0ZSBkcmFmdHMNCg0K Mi4gYXNrIHRoZSBjdXJyZW50IGVkaXRvciBvbmNlIG1vcmUgdG8gaW5jb3BvcmF0ZSB0aGUgbm9k ZS1wcm90ZWN0aW9uIHRleHQNCiAgIGFzIHdlbGwgYXMgb3RoZXIgY29tbWVudHMgZnJvbSBzdGVw aGFuZSAoZS5nLiBob3cgdG8gc2lnbmFsIFQtTERQDQogICBwcmVmZXJyZWQgdHJhbnNwb3J0IGFk ZHJlc3NlcykNCg0KMy4gYXNrIFdHLWNoYWlycyB0byBhc3NpZ24gYSBuZXcgZWRpdG9yIHRvIHRo ZSBkcmFmdA0KDQovaGFubmVzDQoNCk9uIE1vbiwgT2N0IDA3LCAyMDEzIGF0IDA2OjM1OjU0QU0g KzAwMDAsIEplZmYgVGFudHN1cmEgd3JvdGU6DQp8IEhpIEFsaWEvSGFubmVzLA0KfCANCnwgSSBz dXBwb3J0IHZlcnkgbXVjaCBBbGlhJ3MgcG9zaXRpb24gaGVyZSBhbmQgd291bGTCoGxpa2UgdG8g c2VlIG5vZGUgDQp8IHByb3RlY3Rpb24gYXMgcGFydCBvZiBiYXNlIHJsZmEgc3BlYyByYXRoZXIg dGhhbiBkZXYtdGVhbSBITEQgcHVzaGVkIA0KfCBhcyBzdGFuZGFyZCB0cmFjayBkb2N1bWVudC4N CnwgV291bGQgYmUgZ3JlYXQgdG8gc2VlIGlucHV0IGZyb20gYWxsIHZlbmRvcnMgdG8gZW5zdXJl IGludGVyb3BlcmFiaWxpdHkuDQp8DQp8IEZyb206IEFsaWEgQXRsYXMgPGFrYXRsYXNAZ21haWwu Y29tPg0KfCBEYXRlOiBXZWRuZXNkYXksIE9jdG9iZXIgMiwgMjAxMyA1OjI2IEFNDQp8IFRvOiBI YW5uZXMgR3JlZGxlciA8aGFubmVzQGp1bmlwZXIubmV0Pg0KfCBDYzogSmVmZiBUYW50c3VyYSA8 amVmZi50YW50c3VyYUBlcmljc3Nvbi5jb20+LCANCnwgJnF1b3Q7cnRnd2dAaWV0Zi5vcmcmcXVv dDsgPHJ0Z3dnQGlldGYub3JnPg0KfCBTdWJqZWN0OiBSZTogUmVxdWVzdCBmb3IgcmV2aWV3IC0g DQp8IGRyYWZ0LXBzYXJrYXItcnRnd2ctcmxmYS1ub2RlLXByb3RlY3Rpb24tDQp8IDAxLnR4dA0K fCANCnwgICAgICBJdCB3b3VsZCBiZSBleGNlbGxlbnQgdG8gc2VlIHByb2dyZXNzIG9uIHRoZSBS ZW1vdGUgTEZBIGRyYWZ0IGFuZCBvbg0KfCAgICAgIG1lcmdpbmcgYXQgbGVhc3QgdGhlIHR3byBk cmFmdHMgdGhhdCBkZXNjcmliZSBob3cgdG8gZG8gbm9kZS0NCnwgICAgICBwcm90ZWN0aW9uIGZv ciBSZW1vdGUgTEZBIGJlZm9yZSB0aGUgVmFuY291dmVyIElFVEYuDQp8IA0KfCAgICAgIEFsaWEN CnwgDQp8IA0KfCAgICAgIE9uIFdlZCwgT2N0IDIsIDIwMTMgYXQgNDo1MSBBTSwgSGFubmVzIEdy ZWRsZXIgIDxoYW5uZXNAanVuaXBlci5uZXQ+DQp8ICAgICAgd3JvdGU6DQp8ICAgICAgICAgICBo aSBqZWZmLA0KfCANCnwgICAgICAgICAgIHRoZSBzaW5nbGUgYmlnZ2VzdCBwcm9ibGVtIHdpdGgg ZHJhZnQtaWV0Zi1ydGd3Zy1yZW1vdGUtbGZhDQp8ICAgICAgICAgICBpcyB0aGF0IGl0IGxlYXZl cyBhIGxvdCBvZiBhbWJpZ3VpdHkgaG93IHRvIGltcGxlbWVudA0KfCAgICAgICAgICAgY2VydGFp bg0KfCAgICAgICAgICAgZnVuY3Rpb25hbGl0eSAtIG5vZGUtcHJvdGVjdGlvbiwgbWFuYWdlYWJp bGl0eSBhbW9uZyB0aGVtLg0KfCANCnwgICAgICAgICAgICd0aGUgcmlnaHQgdGhpbmcnKOKEoikg wqB3b3VsZCBiZSB0byBmaXggdGhlIHJsZmEgc3BlYywNCnwgICAgICAgICAgIHdoaWNoIHNvbWVo b3cgc2VlbXMgbm90IHBvc3NpYmxlLCBzbyBpdCByZW1haW5zDQp8ICAgICAgICAgICBpbiB0aGUg c3RhdGUgd2hpY2ggaXQgaXMgbm93IOKApiB3aGF0IGkgY2FsbA0KfCAgICAgICAgICAgJ3VuZGVy c3BlY2lmaWVkJy4NCnwgDQp8ICAgICAgICAgICBkcmFmdC1wc2Fya2FyLXJ0Z3dnLXJsZmEtbm9k ZS1wcm90ZWN0aW9uIGlzIGEgY29udHJpYnV0aW9uDQp8ICAgICAgICAgICBjb21pbmcgZnJvbSBh IGRldi10ZWFtIHdoaWNoIGhhZCB0byBpbXBsZW1lbnQgdGhpcyBmb3INCnwgICAgICAgICAgIE9T UEYgYW5kIElTLUlTIGFuZCBtYWtlIGl0IHdvcmsgYWx0b2dldGhlci4NCnwgDQp8ICAgICAgICAg ICB3ZSBnb3QgdGhlIGltcHJlc3Npb24gdGhhdCBjdXN0b21lcnMgd2FudCB0byB1c2UgYm90aA0K fCAgICAgICAgICAgbm9kZS1wcm90ZWN0aW9uICphbmQqIG1hbmFnZWFiaWxpdHkgdG9nZXRoZXIg YW5kIGFzIHN1Y2gNCnwgICAgICAgICAgIHlvdSBuZWVkIHRvIGRvIHRoaW5ncyBhIGNlcnRhaW4g d2F5IHdoaWNoIGlzIGRlc2NyaWJlZCBpbg0KfCAgICAgICAgICAgdGhlIGRyYWZ0LiBJTU8gdGhh dHMgYSBiaXQgbW9yZSB0aGFuIGp1c3QNCnwgICAgICAgICAgICdpbXBsZW1lbnRhdGlvbiBkZXRh aWxzJyBidXQgcmF0aGVyIGEgZ3VpZGFuY2UNCnwgICAgICAgICAgIGhvdyB0byBnZXQgdGhpcyBy aWdodC4gdGhlcmVmb3JlIHRoZSBpbnRlbmRlZCBzdGF0dXMgaXMNCnwgICAgICAgICAgICdwcm9w b3NlZCBzdGFuZGFyZCcuDQp8IA0KfCAgICAgICAgICAgL2hhbm5lcw0KfCANCnwgICAgICAgICAg IE9uIE9jdCAxLCAyMDEzLCBhdCA4OjA3IFBNLCBKZWZmIFRhbnRzdXJhIHdyb3RlOg0KfCANCnwg ICAgICAgICAgID4gSGksDQp8ICAgICAgICAgICA+DQp8ICAgICAgICAgICA+IFF1ZXN0aW9uIHRv IHRoZSBhdXRob3JzIG9mIHRoZSBkcmFmdCBhYm91dCB0aGVpcg0KfCAgICAgICAgICAgaW50ZW50 aW9ucywgb2J2aW91c2x5IHRoZQ0KfCAgICAgICAgICAgPiBiYXNpYyBub2RlIHByb3RlY3Rpb24g ZXF1YXRpb24oRF9vcHQoTnBxLCBEc3QpIDwgRF9vcHQNCnwgICAgICAgICAgIChOcHEsIE5wKSAr DQp8ICAgICAgICAgICA+IERpc3RhbmNlX29wdChOcCwgRHN0KSkgaXMgY29ycmVjdCwgaG93ZXZl ciB0aGUgcmVzdCBpcw0KfCAgICAgICAgICAgbW9yZSBvciBsZXNzDQp8ICAgICAgICAgICA+IGlt cGxlbWVudGF0aW9uIGRldGFpbHMuDQp8ICAgICAgICAgICA+IFNvIGlmIHRoZSBhdXRob3JzIHdv dWxkIGxpa2UgdG8gc2hhcmUgdGhlIGRldGFpbHMgYWJvdXQNCnwgICAgICAgICAgIHRoZWlyDQp8 ICAgICAgICAgICA+IGltcGxlbWVudGF0aW9uIHNob3VsZCBub3QgdGhlIEludGVuZGVkIFN0YXR1 cyBiZQ0KfCAgICAgICAgICAgSW5mb3JtYXRpb25hbD8NCnwgICAgICAgICAgID4NCnwgICAgICAg ICAgID4gQ2hlZXJzLA0KfCAgICAgICAgICAgPiBKZWZmDQp8ICAgICAgICAgICA+DQp8ICAgICAg ICAgICA+DQp8ICAgICAgICAgICA+Pj4NCnwgICAgICAgICAgID4+Pj4gRm9sa3MsDQp8ICAgICAg ICAgICA+Pj4+DQp8ICAgICAgICAgICA+Pj4+IERvZXMgYW55b25lIGtub3cgd2hldGhlciB0aGUg ZHJhZnQgZGVhbCB3aWxsIGJlDQp8ICAgICAgICAgICB0cmVhdGVkIGluIHRoZSBJRVRGIDg4Pw0K fCAgICAgICAgICAgPj4+Pg0KfCAgICAgICAgICAgPj4+PiBSZWdhcmRzLA0KfCAgICAgICAgICAg Pj4+Pg0KfCAgICAgICAgICAgPj4+PiBSb2dlcmlvIE1hcmlhbm8NCnwgICAgICAgICAgID4+Pj4N CnwgICAgICAgICAgID4+Pj4NCnwgICAgICAgICAgID4+Pj4NCnwgICAgICAgICAgID4+Pj4NCnwg ICAgICAgICAgID4+Pj4gLS0NCnwgICAgICAgICAgID4+Pj4gVmlldyB0aGlzIG1lc3NhZ2UgaW4g Y29udGV4dDoNCnwgICAgICAgICAgID4+Pj4gaHR0cDovL2lldGYuMTAubjcubmFiYmxlLmNvbS9S ZXF1ZXN0LWZvci1yZXZpZXctZHJhZnQtDQp8ICAgICAgICAgICBwc2Fya2FyLXJ0Z3dnLXJsZmEN CnwgICAgICAgICAgID4+Pj4gLQ0KfCAgICAgICAgICAgPj4+PiBuDQp8ICAgICAgICAgICA+Pj4+ IG9kZS1wcm90ZWN0aW9uLTAxLXR4dC10cDM3NTcxNHAzODYzMjEuaHRtbA0KfCAgICAgICAgICAg Pj4+PiBTZW50IGZyb20gdGhlIElFVEYgLSBSdGd3ZyBtYWlsaW5nIGxpc3QgYXJjaGl2ZSBhdA0K fCAgICAgICAgICAgTmFiYmxlLmNvbS4NCnwgICAgICAgICAgID4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnwgICAgICAgICAgID4+Pj4gcnRnd2cg bWFpbGluZyBsaXN0DQp8ICAgICAgICAgICA+Pj4+IHJ0Z3dnQGlldGYub3JnDQp8ICAgICAgICAg ICA+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnd2cNCnwgICAg ICAgICAgID4+Pg0KfCAgICAgICAgICAgPj4NCnwgICAgICAgICAgID4NCnwgICAgICAgICAgID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnwgICAgICAg ICAgID4gcnRnd2cgbWFpbGluZyBsaXN0DQp8ICAgICAgICAgICA+IHJ0Z3dnQGlldGYub3JnDQp8 ICAgICAgICAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnd2cN CnwgICAgICAgICAgID4NCnwgICAgICAgICAgID4NCnwgDQp8IA0KfCAgICAgICAgICAgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnwgICAgICAgICAgIHJ0 Z3dnIG1haWxpbmcgbGlzdA0KfCAgICAgICAgICAgcnRnd2dAaWV0Zi5vcmcNCnwgICAgICAgICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnd2cNCnwgDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGd3ZyBtYWlsaW5n IGxpc3QNCnJ0Z3dnQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3J0Z3dnDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1 dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxl Z2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3Ug Y29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBh ciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1 aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlx dWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRl IHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZh bHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHBy b3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFu Z2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNo YW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From agmalis@gmail.com Tue Oct 8 06:50:23 2013 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 6A9C511E80E2 for ; Tue, 8 Oct 2013 06:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUBV3dPM3HjA for ; Tue, 8 Oct 2013 06:50:22 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 35FF821E809D for ; Tue, 8 Oct 2013 06:50:16 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q58so4182299wes.3 for ; Tue, 08 Oct 2013 06:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SMnzzmq4K9PSc6CCBpavsIQszjsg/HjWvXI/PJWABl0=; b=zml5xnr7tFXqpie1oahvErzeSQMxIexqwo+pHFeuMTemYZLk3jPSoUUB31trN+G2CX vj+vwpHWrZxEQ68+a1BQ+SZtAAelRAQZFQtPON/4QPrD1gtspko+ROxX7F5DCkwHkVrm guNnxmIGzcoFGT40AqMkw9BCtcCcC7LgJPbW9Zt5G1qd2gUJ9fQt9eXrrnaPDnVpkyRu QHiUQrBbquvlVliUPgSW0UkFtMlxKZ5CoFa0yGSMFwZO/VOpZm0Hf166zLdFt1AsGXZZ KOSMxoXj927KNeyYU2WomeqQQNe9G2bW46Vuqs48MFFnZFDqf83A49slq8ITwEs6VQQ3 naAA== X-Received: by 10.180.184.107 with SMTP id et11mr24191060wic.60.1381240215177; Tue, 08 Oct 2013 06:50:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.54.6 with HTTP; Tue, 8 Oct 2013 06:49:55 -0700 (PDT) In-Reply-To: <201310071806.r97I6eeV070034@gateway1.orleans.occnc.com> References: <201310071806.r97I6eeV070034@gateway1.orleans.occnc.com> From: "Andrew G. Malis" Date: Tue, 8 Oct 2013 09:49:55 -0400 Message-ID: Subject: Re: WG Last Call for draft-ietf-rtgwg-cl-requirement-11 To: curtis@ipv6.occnc.com Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtgwg@ietf.org" , "draft-ietf-rtgwg-cl-requirement@tools.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, 08 Oct 2013 13:50:23 -0000 I have no objection to any of Curtis' specific changes. Cheers, Andy On Mon, Oct 7, 2013 at 2:06 PM, Curtis Villamizar wrote: > > In message > Alia Atlas writes: > >> This second WG Last Call got absolutely no comments. Does this group >> of generally opinionated and thoughtful people truly have nothing to >> say? >> >> If so and given the previous WGLC succeeded, then on Oct 9, I will >> take silence as consent and indicate that on the draft shepherd's >> write-up... >> >> Alia > > > Alia, et al. > > Silence could mean lots of people read the document and could see no > way to further improve it. I doubt that is the case. Silence could > also mean that the document has been around for so long that people > are tired or reading it and haven't bothered to read it again. More > likely IMHO. > > It isn't clear (to me) in the above email if you were extending WGLC > until Oct 9. As co-author, I wanted to give others a chance to > comment first during WGLC and they have had plenty of time to do so. > > Given that there are multiple co-authors, there has been some > compromise in the document. While combining contributions, there was > some tendency to "go along to keep moving forward". That can be bad > if there are too few critical reviewers outside the set of co-authors. > > With co-author hat off, I reread the document and here are my personal > review comments. > > If there is agreement to make changes, I will put co-author hat back > on and make these edits. If there is dissenting discussion, I'll edit > as best as I can judge consensus and we can disuss at IETF-88 if we > need to. If there is silence, I'll let Alia and Alvaro interpret the > silence. (full agreement with all changes? lack of interest?) > > This *is* a WG doc, so WG please speak up. > > Curtis > > > ---------------------------------------- > > General Comments (See specific instances of each in detailed comments): > > The section naming and grouping of requirements could stand some > improvement. > > Some of the requirement wording are awkwardly worded. A few sentences > border on meaningless. > > Some of the requirements are infeasible as worded. Most can be made > feasible by replacing "flows or group of flows" with "client LSP". > The following paragraph in the introduction gives a hint as to why > these are feasible for client LSP but not flows: > > The ingress and egress of a multipath may be midpoint LSRs with > respect to a given client LSP. A midpoint LSR does not participate > in the signaling of any clients of the client LSP. Therefore, in > general, multipath endpoints cannot determine requirements of clients > of a client LSP through participation in the signaling of the clients > of the client LSP. > > One requirement (bidirectional placement on components) is infeasible > for flows and infeasible for all but small client LSP that fit into a > single compoent link. The framework points this out. > > Specific Comments: > > wording: s/no significantly exceed/not significantly exceed/ > > FR#4 contains one awkward excessively wordy sentence followed by one > that I struggle to find any meaning in if I didn't already know what > the intent was. It may also be better to replace "path for a flow" > with "set of paths for an LSP" and then specify the requirements for > flows within that LSP. > > OLD > > FR#4 The solution SHALL provide a mechanism to select a path for a > flow across a network that contains a number of paths comprised > of pairs of nodes connected by advanced multipath in such a way > as to automatically distribute the load over the network nodes > connected by advanced multipaths while meeting all of the other > mandatory requirements stated above. The solution SHOULD work > in a manner similar to that of current networks without any > advanced multipath protocol enhancements when the > characteristics of the individual component links are > advertised. > > NEW > > FR#4 The solution shall provide a mechanism to select a set of > paths for an LSP across a network in such a way that flows > within the LSP are distributed across the set of paths while > meeting all of the other requirements stated above. The > solution SHOULD work in a manner similar to existing > multipath techniques except as necessary to accommodate > advanced multipath requirements. > > I think these say pretty much the same thing, but with improved > clarity in the new text. > > FR#10 and FR#11 are the following: > > FR#10 The solution SHALL provide a means to limit the latency to > meet a Performance Objective target on a per flow basis or > group of flow basis, where flows or groups of flows are > identifiable in the forwarding plane and are signaled using in > the control plane or set up using the management plane. > > The Performance Objectives differ across the services, and > some services have different Performance Objectives for > different QoS classes, for example, one QoS class may have a > much larger latency bound than another. Overload can occur > which would violate a Performance Objective parameter (e.g., > loss) and some remedy to handle this case for an advanced > multipath is required. > > FR#11 If the total demand offered by traffic flows exceeds the > capacity of the advanced multipath, the solution SHOULD define > a means to cause some traffic flows or groups of flows to move > to some other point in the network that is not congested. > These "preempted flows" may not be restored if there is no > uncongested path in the network. > > FR#10 and FR#11 currently fall under the section "Component Links > Provided by Lower Layer Networks" but have nothing to do with lower > layer networks. These would fit better with the existing section > named "Parallel Component Links with Different Characteristics" > (though see comments below on rearranging that section). > > FR#10 may be redundant due to FR#17 and FR#18 which specify minimul > latency and bounded latency. The first paragraph in FR#10 adds > nothing to FR#17 and FR#18 except that the result should meet "a > Performance Objective target". The second paragraph seems to be > unrelated discussion and perhaps belongs in FR#11. If so, FR#10 can > be eliminated possibly adding a statement about "a Performance > Objective target" in FR#17 and FR#18, but preferably leaving them > alone. > > FR#10 and FR#11 are infeasible if applied to "client LSP" rather than > "flows or groups of flows" for reasons stated in General Comments > above. (So are FR#17 and FR#18; see below). > > In FR#10 > s/signaled using in the control plane/signaled using the control plane/ > > FR#11 needs to be about preemption of LSP, not preemption of flows. > Since there is no signaling of flows, there is no prioritization of > flows. There is OTOH diffserv, which will enforce prioritization, > even among traffic within a microflow (AF service where some traffic > is marked AFx2 or AFx3, aka yellow or red). > > In FR#11 s/traffic flows or groups of traffic flows/clent LSP/ > makes the requirement feasible. > > In FR#11 s/some other point in the network/an alternate set of paths/ > makes the requirement more clear. > > NEW > > FR#10 [Deleted] > > FR#11 If the total demand offered by traffic flows exceeds the > capacity of the advanced multipath, the solution SHOULD > define a means to cause some client LSP to move to an > alternate set of paths that are not congested. These > "preempted LSP" may not be restored if there is no > uncongested path in the network. > > The title "Parallel Component Links with Different Characteristics" > should be changed, dropping the word "Parallel". The requirements > also apply to very diverse paths through a network with different > characteristics. > > The set of requirements currently in "Component Links with Different > Characteristics" are mostly of two types: > > 1. Load Balance Dynamics (FR#12-FR#15, FR#20-FR#23) > > 2. Requirements for Carrying Client LSP (FR#16-FR#19, FR#24). > > FR#22 and FR#23 could be in either category but apply more to dynamics > of load balancing. > > It might be better to reorder these requirements and create two > subsections. Both still do apply to "Component Links with Different > Characteristics", but form two distinct subsets. > > In requirements FR#17-FR#19 > s/a traffic flow/the traffic flows within a client LSP/ > Signaling is applied to client LSP, not flows as mentioned in General > Comments above. > > FR#24 is extremely problematic. The existing framework document > indicates that there are significant feasibility issues associated > with supporting this requirement for all but small client LSP and > requiring a fallback to link bundling for these small cleint LSP. > There has been no discussion supporting a feasible means to do this > for large client LSP. Therefore it may be wise to either drop this > requirement entirely or at the very least change it to a SHOULD. If > the requirement is kept, perhaps a qualifier indicating "for small > client LSP only (ones that fit on a single component)" is required. > If link bundling is the solution, the requirement is a NOOP but the > requirement may serve to indicate that link bundling must co-exist > with hash based load balancing for a subset of LSP requiring that a > both directions take the same component. > > If FR#24 is relaxed to say that both directions traverse the same set > of nodes, then FR#24 becomes feasible for large client LSP. This > would, for example, allow MPLS-TP OAM to function corrently for > MPLS-TP LSP carried within client MPLS LSP. If this is desirable > it should be a separate requirement. > > The section title "Derived Requirements" has irked a number of people. > These requirements are distinct in that they reference protocols which > would be used within a solution, but they are not truly "derived" from > the "Functional Requirements" in the prior section. I prefer "General > Requirements for Protocol Solutions". > > Therefore > s/Derived Requirements/GeneralRequirements for Protocol Solutions/ > s/DR/GR/ > > I suggest rewording DR#1 as follows: > > OLD > > DR#1 The solution SHOULD attempt to extend existing protocols > wherever possible, developing a new protocol only if this adds > a significant set of capabilities. > > NEW > > GR#1 The solution SHOULD extend existing protocols wherever > possible, developing a new protocol only where doing so adds > a significant set of capabilities. > > I dropped "attempt to". The solution SHOULD get it right. No E for > Effort for trying but getting it wrong. :-) > > In DR#3, I'm not sure what the last sentence means as worded, though I > think I know the intent. > > OLD > > Other functional requirements should be supported as independently > of signaling protocol as possible. > > NEW > > Function requirements SHOULD, where possible, be supported in a > manner that supports LDP signaled LSP, RSVP signaled LSP, and LSP > set up using management plane mechanisms. > > Either the management section is perfect or I forgot to read it. :-) > > The Ack section should say that after some discussion Tom Yu suggested > replacement text that was used as the basis for the security section. > > The Ack section should indicate that the document was renamed as a > result of potential problems with terminology collision that were > pointed out by Lou Berger in the RtgDir review. > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From Ning.So@tatacommunications.com Tue Oct 8 07:09:01 2013 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 2E0D411E819B for ; Tue, 8 Oct 2013 07:09:01 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8whrVE8OYKy8 for ; Tue, 8 Oct 2013 07:08:55 -0700 (PDT) Received: from vmx3.tatacommunications.com (vmx3.tatacommunications.com [66.198.167.208]) by ietfa.amsl.com (Postfix) with ESMTP id 04E0021F8C0C for ; Tue, 8 Oct 2013 07:08:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,1056,1371096000"; d="scan'208";a="18244161" Received: from unknown (HELO wv1-cas-01.vsnl.co.in) ([64.86.157.137]) by mx3-2.tatacommunications.com with ESMTP; 08 Oct 2013 10:08:45 -0400 Received: from uswv1vcas03.vsnl.co.in (64.86.157.183) by wv1-cas-01.vsnl.co.in (64.86.157.137) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 8 Oct 2013 10:08:45 -0400 Received: from USWV1VDAG02.vsnl.co.in ([fe80::7c6a:fd71:7022:40b6]) by uswv1vcas03.vsnl.co.in ([fe80::3911:1b21:3511:593b%13]) with mapi id 14.02.0342.003; Tue, 8 Oct 2013 10:08:45 -0400 From: Ning So To: "Andrew G. Malis" , "curtis@ipv6.occnc.com" Subject: RE: WG Last Call for draft-ietf-rtgwg-cl-requirement-11 Thread-Topic: WG Last Call for draft-ietf-rtgwg-cl-requirement-11 Thread-Index: AQHOxC1ciKG6+xeB80+2ZychfSxTipnq12mg Date: Tue, 8 Oct 2013 14:08:45 +0000 Message-ID: References: <201310071806.r97I6eeV070034@gateway1.orleans.occnc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.86.157.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtgwg@ietf.org" , "draft-ietf-rtgwg-cl-requirement@tools.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, 08 Oct 2013 14:09:01 -0000 I am fine as well. Best regards, Ning So Head of Network Architecture Mobile Broadband Services Tata Communications=20 (Cell) 972-955-0914 -----Original Message----- From: Andrew G. Malis [mailto:agmalis@gmail.com]=20 Sent: Tuesday, October 08, 2013 8:50 AM To: curtis@ipv6.occnc.com Cc: Alia Atlas; draft-ietf-rtgwg-cl-requirement@tools.ietf.org; rtgwg@ietf.= org Subject: Re: WG Last Call for draft-ietf-rtgwg-cl-requirement-11 I have no objection to any of Curtis' specific changes. Cheers, Andy On Mon, Oct 7, 2013 at 2:06 PM, Curtis Villamizar w= rote: > > In message=20 > > Alia Atlas writes: > >> This second WG Last Call got absolutely no comments. Does this group=20 >> of generally opinionated and thoughtful people truly have nothing to=20 >> say? >> >> If so and given the previous WGLC succeeded, then on Oct 9, I will=20 >> take silence as consent and indicate that on the draft shepherd's=20 >> write-up... >> >> Alia > > > Alia, et al. > > Silence could mean lots of people read the document and could see no=20 > way to further improve it. I doubt that is the case. Silence could=20 > also mean that the document has been around for so long that people=20 > are tired or reading it and haven't bothered to read it again. More=20 > likely IMHO. > > It isn't clear (to me) in the above email if you were extending WGLC=20 > until Oct 9. As co-author, I wanted to give others a chance to=20 > comment first during WGLC and they have had plenty of time to do so. > > Given that there are multiple co-authors, there has been some=20 > compromise in the document. While combining contributions, there was=20 > some tendency to "go along to keep moving forward". That can be bad=20 > if there are too few critical reviewers outside the set of co-authors. > > With co-author hat off, I reread the document and here are my personal=20 > review comments. > > If there is agreement to make changes, I will put co-author hat back=20 > on and make these edits. If there is dissenting discussion, I'll edit=20 > as best as I can judge consensus and we can disuss at IETF-88 if we=20 > need to. If there is silence, I'll let Alia and Alvaro interpret the=20 > silence. (full agreement with all changes? lack of interest?) > > This *is* a WG doc, so WG please speak up. > > Curtis > > > ---------------------------------------- > > General Comments (See specific instances of each in detailed comments): > > The section naming and grouping of requirements could stand some=20 > improvement. > > Some of the requirement wording are awkwardly worded. A few sentences=20 > border on meaningless. > > Some of the requirements are infeasible as worded. Most can be made=20 > feasible by replacing "flows or group of flows" with "client LSP". > The following paragraph in the introduction gives a hint as to why=20 > these are feasible for client LSP but not flows: > > The ingress and egress of a multipath may be midpoint LSRs with > respect to a given client LSP. A midpoint LSR does not participate > in the signaling of any clients of the client LSP. Therefore, in > general, multipath endpoints cannot determine requirements of clients > of a client LSP through participation in the signaling of the clients > of the client LSP. > > One requirement (bidirectional placement on components) is infeasible=20 > for flows and infeasible for all but small client LSP that fit into a=20 > single compoent link. The framework points this out. > > Specific Comments: > > wording: s/no significantly exceed/not significantly exceed/ > > FR#4 contains one awkward excessively wordy sentence followed by one=20 > that I struggle to find any meaning in if I didn't already know what=20 > the intent was. It may also be better to replace "path for a flow" > with "set of paths for an LSP" and then specify the requirements for=20 > flows within that LSP. > > OLD > > FR#4 The solution SHALL provide a mechanism to select a path for a > flow across a network that contains a number of paths comprised > of pairs of nodes connected by advanced multipath in such a way > as to automatically distribute the load over the network nodes > connected by advanced multipaths while meeting all of the other > mandatory requirements stated above. The solution SHOULD work > in a manner similar to that of current networks without any > advanced multipath protocol enhancements when the > characteristics of the individual component links are > advertised. > > NEW > > FR#4 The solution shall provide a mechanism to select a set of > paths for an LSP across a network in such a way that flows > within the LSP are distributed across the set of paths while > meeting all of the other requirements stated above. The > solution SHOULD work in a manner similar to existing > multipath techniques except as necessary to accommodate > advanced multipath requirements. > > I think these say pretty much the same thing, but with improved=20 > clarity in the new text. > > FR#10 and FR#11 are the following: > > FR#10 The solution SHALL provide a means to limit the latency to > meet a Performance Objective target on a per flow basis or > group of flow basis, where flows or groups of flows are > identifiable in the forwarding plane and are signaled using in > the control plane or set up using the management plane. > > The Performance Objectives differ across the services, and > some services have different Performance Objectives for > different QoS classes, for example, one QoS class may have a > much larger latency bound than another. Overload can occur > which would violate a Performance Objective parameter (e.g., > loss) and some remedy to handle this case for an advanced > multipath is required. > > FR#11 If the total demand offered by traffic flows exceeds the > capacity of the advanced multipath, the solution SHOULD define > a means to cause some traffic flows or groups of flows to move > to some other point in the network that is not congested. > These "preempted flows" may not be restored if there is no > uncongested path in the network. > > FR#10 and FR#11 currently fall under the section "Component Links=20 > Provided by Lower Layer Networks" but have nothing to do with lower=20 > layer networks. These would fit better with the existing section=20 > named "Parallel Component Links with Different Characteristics" > (though see comments below on rearranging that section). > > FR#10 may be redundant due to FR#17 and FR#18 which specify minimul=20 > latency and bounded latency. The first paragraph in FR#10 adds=20 > nothing to FR#17 and FR#18 except that the result should meet "a=20 > Performance Objective target". The second paragraph seems to be=20 > unrelated discussion and perhaps belongs in FR#11. If so, FR#10 can=20 > be eliminated possibly adding a statement about "a Performance=20 > Objective target" in FR#17 and FR#18, but preferably leaving them=20 > alone. > > FR#10 and FR#11 are infeasible if applied to "client LSP" rather than=20 > "flows or groups of flows" for reasons stated in General Comments=20 > above. (So are FR#17 and FR#18; see below). > > In FR#10 > s/signaled using in the control plane/signaled using the control=20 > plane/ > > FR#11 needs to be about preemption of LSP, not preemption of flows. > Since there is no signaling of flows, there is no prioritization of=20 > flows. There is OTOH diffserv, which will enforce prioritization,=20 > even among traffic within a microflow (AF service where some traffic=20 > is marked AFx2 or AFx3, aka yellow or red). > > In FR#11 s/traffic flows or groups of traffic flows/clent LSP/ makes=20 > the requirement feasible. > > In FR#11 s/some other point in the network/an alternate set of paths/=20 > makes the requirement more clear. > > NEW > > FR#10 [Deleted] > > FR#11 If the total demand offered by traffic flows exceeds the > capacity of the advanced multipath, the solution SHOULD > define a means to cause some client LSP to move to an > alternate set of paths that are not congested. These > "preempted LSP" may not be restored if there is no > uncongested path in the network. > > The title "Parallel Component Links with Different Characteristics" > should be changed, dropping the word "Parallel". The requirements=20 > also apply to very diverse paths through a network with different=20 > characteristics. > > The set of requirements currently in "Component Links with Different=20 > Characteristics" are mostly of two types: > > 1. Load Balance Dynamics (FR#12-FR#15, FR#20-FR#23) > > 2. Requirements for Carrying Client LSP (FR#16-FR#19, FR#24). > > FR#22 and FR#23 could be in either category but apply more to dynamics=20 > of load balancing. > > It might be better to reorder these requirements and create two=20 > subsections. Both still do apply to "Component Links with Different=20 > Characteristics", but form two distinct subsets. > > In requirements FR#17-FR#19 > s/a traffic flow/the traffic flows within a client LSP/ Signaling is=20 > applied to client LSP, not flows as mentioned in General Comments=20 > above. > > FR#24 is extremely problematic. The existing framework document=20 > indicates that there are significant feasibility issues associated=20 > with supporting this requirement for all but small client LSP and=20 > requiring a fallback to link bundling for these small cleint LSP. > There has been no discussion supporting a feasible means to do this=20 > for large client LSP. Therefore it may be wise to either drop this=20 > requirement entirely or at the very least change it to a SHOULD. If=20 > the requirement is kept, perhaps a qualifier indicating "for small=20 > client LSP only (ones that fit on a single component)" is required. > If link bundling is the solution, the requirement is a NOOP but the=20 > requirement may serve to indicate that link bundling must co-exist=20 > with hash based load balancing for a subset of LSP requiring that a=20 > both directions take the same component. > > If FR#24 is relaxed to say that both directions traverse the same set=20 > of nodes, then FR#24 becomes feasible for large client LSP. This=20 > would, for example, allow MPLS-TP OAM to function corrently for=20 > MPLS-TP LSP carried within client MPLS LSP. If this is desirable it=20 > should be a separate requirement. > > The section title "Derived Requirements" has irked a number of people. > These requirements are distinct in that they reference protocols which=20 > would be used within a solution, but they are not truly "derived" from=20 > the "Functional Requirements" in the prior section. I prefer "General=20 > Requirements for Protocol Solutions". > > Therefore > s/Derived Requirements/GeneralRequirements for Protocol Solutions/=20 > s/DR/GR/ > > I suggest rewording DR#1 as follows: > > OLD > > DR#1 The solution SHOULD attempt to extend existing protocols > wherever possible, developing a new protocol only if this adds > a significant set of capabilities. > > NEW > > GR#1 The solution SHOULD extend existing protocols wherever > possible, developing a new protocol only where doing so adds > a significant set of capabilities. > > I dropped "attempt to". The solution SHOULD get it right. No E for=20 > Effort for trying but getting it wrong. :-) > > In DR#3, I'm not sure what the last sentence means as worded, though I=20 > think I know the intent. > > OLD > > Other functional requirements should be supported as independently > of signaling protocol as possible. > > NEW > > Function requirements SHOULD, where possible, be supported in a > manner that supports LDP signaled LSP, RSVP signaled LSP, and LSP > set up using management plane mechanisms. > > Either the management section is perfect or I forgot to read it. :-) > > The Ack section should say that after some discussion Tom Yu suggested=20 > replacement text that was used as the basis for the security section. > > The Ack section should indicate that the document was renamed as a=20 > result of potential problems with terminology collision that were=20 > pointed out by Lou Berger in the RtgDir review. > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From lucy.yong@huawei.com Tue Oct 8 07:15:32 2013 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 6B54221E809D for ; Tue, 8 Oct 2013 07:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kes90dujdRJr for ; Tue, 8 Oct 2013 07:15:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 85BCC21E809B for ; Tue, 8 Oct 2013 07:15:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AWO36610; Tue, 08 Oct 2013 14:15:24 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 8 Oct 2013 15:15:02 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 8 Oct 2013 15:15:23 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0146.000; Tue, 8 Oct 2013 07:15:19 -0700 From: Lucy yong To: Ning So , "Andrew G. Malis" , "curtis@ipv6.occnc.com" Subject: RE: WG Last Call for draft-ietf-rtgwg-cl-requirement-11 Thread-Topic: WG Last Call for draft-ietf-rtgwg-cl-requirement-11 Thread-Index: AQHOw4hm4CdYA99Pgka4IexdiMqcHZnrSNGAgAAFQ4D//4yYwA== Date: Tue, 8 Oct 2013 14:15:19 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452D41A5@dfweml509-mbx.china.huawei.com> References: <201310071806.r97I6eeV070034@gateway1.orleans.occnc.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.138.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "rtgwg@ietf.org" , "draft-ietf-rtgwg-cl-requirement@tools.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, 08 Oct 2013 14:15:33 -0000 +1 lucy -----Original Message----- From: Ning So [mailto:Ning.So@tatacommunications.com]=20 Sent: Tuesday, October 08, 2013 9:09 AM To: Andrew G. Malis; curtis@ipv6.occnc.com Cc: Alia Atlas; draft-ietf-rtgwg-cl-requirement@tools.ietf.org; rtgwg@ietf.= org Subject: RE: WG Last Call for draft-ietf-rtgwg-cl-requirement-11 I am fine as well. Best regards, Ning So Head of Network Architecture Mobile Broadband Services Tata Communications=20 (Cell) 972-955-0914 -----Original Message----- From: Andrew G. Malis [mailto:agmalis@gmail.com]=20 Sent: Tuesday, October 08, 2013 8:50 AM To: curtis@ipv6.occnc.com Cc: Alia Atlas; draft-ietf-rtgwg-cl-requirement@tools.ietf.org; rtgwg@ietf.= org Subject: Re: WG Last Call for draft-ietf-rtgwg-cl-requirement-11 I have no objection to any of Curtis' specific changes. Cheers, Andy On Mon, Oct 7, 2013 at 2:06 PM, Curtis Villamizar w= rote: > > In message=20 > > Alia Atlas writes: > >> This second WG Last Call got absolutely no comments. Does this group=20 >> of generally opinionated and thoughtful people truly have nothing to=20 >> say? >> >> If so and given the previous WGLC succeeded, then on Oct 9, I will=20 >> take silence as consent and indicate that on the draft shepherd's=20 >> write-up... >> >> Alia > > > Alia, et al. > > Silence could mean lots of people read the document and could see no=20 > way to further improve it. I doubt that is the case. Silence could=20 > also mean that the document has been around for so long that people=20 > are tired or reading it and haven't bothered to read it again. More=20 > likely IMHO. > > It isn't clear (to me) in the above email if you were extending WGLC=20 > until Oct 9. As co-author, I wanted to give others a chance to=20 > comment first during WGLC and they have had plenty of time to do so. > > Given that there are multiple co-authors, there has been some=20 > compromise in the document. While combining contributions, there was=20 > some tendency to "go along to keep moving forward". That can be bad=20 > if there are too few critical reviewers outside the set of co-authors. > > With co-author hat off, I reread the document and here are my personal=20 > review comments. > > If there is agreement to make changes, I will put co-author hat back=20 > on and make these edits. If there is dissenting discussion, I'll edit=20 > as best as I can judge consensus and we can disuss at IETF-88 if we=20 > need to. If there is silence, I'll let Alia and Alvaro interpret the=20 > silence. (full agreement with all changes? lack of interest?) > > This *is* a WG doc, so WG please speak up. > > Curtis > > > ---------------------------------------- > > General Comments (See specific instances of each in detailed comments): > > The section naming and grouping of requirements could stand some=20 > improvement. > > Some of the requirement wording are awkwardly worded. A few sentences=20 > border on meaningless. > > Some of the requirements are infeasible as worded. Most can be made=20 > feasible by replacing "flows or group of flows" with "client LSP". > The following paragraph in the introduction gives a hint as to why=20 > these are feasible for client LSP but not flows: > > The ingress and egress of a multipath may be midpoint LSRs with > respect to a given client LSP. A midpoint LSR does not participate > in the signaling of any clients of the client LSP. Therefore, in > general, multipath endpoints cannot determine requirements of clients > of a client LSP through participation in the signaling of the clients > of the client LSP. > > One requirement (bidirectional placement on components) is infeasible=20 > for flows and infeasible for all but small client LSP that fit into a=20 > single compoent link. The framework points this out. > > Specific Comments: > > wording: s/no significantly exceed/not significantly exceed/ > > FR#4 contains one awkward excessively wordy sentence followed by one=20 > that I struggle to find any meaning in if I didn't already know what=20 > the intent was. It may also be better to replace "path for a flow" > with "set of paths for an LSP" and then specify the requirements for=20 > flows within that LSP. > > OLD > > FR#4 The solution SHALL provide a mechanism to select a path for a > flow across a network that contains a number of paths comprised > of pairs of nodes connected by advanced multipath in such a way > as to automatically distribute the load over the network nodes > connected by advanced multipaths while meeting all of the other > mandatory requirements stated above. The solution SHOULD work > in a manner similar to that of current networks without any > advanced multipath protocol enhancements when the > characteristics of the individual component links are > advertised. > > NEW > > FR#4 The solution shall provide a mechanism to select a set of > paths for an LSP across a network in such a way that flows > within the LSP are distributed across the set of paths while > meeting all of the other requirements stated above. The > solution SHOULD work in a manner similar to existing > multipath techniques except as necessary to accommodate > advanced multipath requirements. > > I think these say pretty much the same thing, but with improved=20 > clarity in the new text. > > FR#10 and FR#11 are the following: > > FR#10 The solution SHALL provide a means to limit the latency to > meet a Performance Objective target on a per flow basis or > group of flow basis, where flows or groups of flows are > identifiable in the forwarding plane and are signaled using in > the control plane or set up using the management plane. > > The Performance Objectives differ across the services, and > some services have different Performance Objectives for > different QoS classes, for example, one QoS class may have a > much larger latency bound than another. Overload can occur > which would violate a Performance Objective parameter (e.g., > loss) and some remedy to handle this case for an advanced > multipath is required. > > FR#11 If the total demand offered by traffic flows exceeds the > capacity of the advanced multipath, the solution SHOULD define > a means to cause some traffic flows or groups of flows to move > to some other point in the network that is not congested. > These "preempted flows" may not be restored if there is no > uncongested path in the network. > > FR#10 and FR#11 currently fall under the section "Component Links=20 > Provided by Lower Layer Networks" but have nothing to do with lower=20 > layer networks. These would fit better with the existing section=20 > named "Parallel Component Links with Different Characteristics" > (though see comments below on rearranging that section). > > FR#10 may be redundant due to FR#17 and FR#18 which specify minimul=20 > latency and bounded latency. The first paragraph in FR#10 adds=20 > nothing to FR#17 and FR#18 except that the result should meet "a=20 > Performance Objective target". The second paragraph seems to be=20 > unrelated discussion and perhaps belongs in FR#11. If so, FR#10 can=20 > be eliminated possibly adding a statement about "a Performance=20 > Objective target" in FR#17 and FR#18, but preferably leaving them=20 > alone. > > FR#10 and FR#11 are infeasible if applied to "client LSP" rather than=20 > "flows or groups of flows" for reasons stated in General Comments=20 > above. (So are FR#17 and FR#18; see below). > > In FR#10 > s/signaled using in the control plane/signaled using the control=20 > plane/ > > FR#11 needs to be about preemption of LSP, not preemption of flows. > Since there is no signaling of flows, there is no prioritization of=20 > flows. There is OTOH diffserv, which will enforce prioritization,=20 > even among traffic within a microflow (AF service where some traffic=20 > is marked AFx2 or AFx3, aka yellow or red). > > In FR#11 s/traffic flows or groups of traffic flows/clent LSP/ makes=20 > the requirement feasible. > > In FR#11 s/some other point in the network/an alternate set of paths/=20 > makes the requirement more clear. > > NEW > > FR#10 [Deleted] > > FR#11 If the total demand offered by traffic flows exceeds the > capacity of the advanced multipath, the solution SHOULD > define a means to cause some client LSP to move to an > alternate set of paths that are not congested. These > "preempted LSP" may not be restored if there is no > uncongested path in the network. > > The title "Parallel Component Links with Different Characteristics" > should be changed, dropping the word "Parallel". The requirements=20 > also apply to very diverse paths through a network with different=20 > characteristics. > > The set of requirements currently in "Component Links with Different=20 > Characteristics" are mostly of two types: > > 1. Load Balance Dynamics (FR#12-FR#15, FR#20-FR#23) > > 2. Requirements for Carrying Client LSP (FR#16-FR#19, FR#24). > > FR#22 and FR#23 could be in either category but apply more to dynamics=20 > of load balancing. > > It might be better to reorder these requirements and create two=20 > subsections. Both still do apply to "Component Links with Different=20 > Characteristics", but form two distinct subsets. > > In requirements FR#17-FR#19 > s/a traffic flow/the traffic flows within a client LSP/ Signaling is=20 > applied to client LSP, not flows as mentioned in General Comments=20 > above. > > FR#24 is extremely problematic. The existing framework document=20 > indicates that there are significant feasibility issues associated=20 > with supporting this requirement for all but small client LSP and=20 > requiring a fallback to link bundling for these small cleint LSP. > There has been no discussion supporting a feasible means to do this=20 > for large client LSP. Therefore it may be wise to either drop this=20 > requirement entirely or at the very least change it to a SHOULD. If=20 > the requirement is kept, perhaps a qualifier indicating "for small=20 > client LSP only (ones that fit on a single component)" is required. > If link bundling is the solution, the requirement is a NOOP but the=20 > requirement may serve to indicate that link bundling must co-exist=20 > with hash based load balancing for a subset of LSP requiring that a=20 > both directions take the same component. > > If FR#24 is relaxed to say that both directions traverse the same set=20 > of nodes, then FR#24 becomes feasible for large client LSP. This=20 > would, for example, allow MPLS-TP OAM to function corrently for=20 > MPLS-TP LSP carried within client MPLS LSP. If this is desirable it=20 > should be a separate requirement. > > The section title "Derived Requirements" has irked a number of people. > These requirements are distinct in that they reference protocols which=20 > would be used within a solution, but they are not truly "derived" from=20 > the "Functional Requirements" in the prior section. I prefer "General=20 > Requirements for Protocol Solutions". > > Therefore > s/Derived Requirements/GeneralRequirements for Protocol Solutions/=20 > s/DR/GR/ > > I suggest rewording DR#1 as follows: > > OLD > > DR#1 The solution SHOULD attempt to extend existing protocols > wherever possible, developing a new protocol only if this adds > a significant set of capabilities. > > NEW > > GR#1 The solution SHOULD extend existing protocols wherever > possible, developing a new protocol only where doing so adds > a significant set of capabilities. > > I dropped "attempt to". The solution SHOULD get it right. No E for=20 > Effort for trying but getting it wrong. :-) > > In DR#3, I'm not sure what the last sentence means as worded, though I=20 > think I know the intent. > > OLD > > Other functional requirements should be supported as independently > of signaling protocol as possible. > > NEW > > Function requirements SHOULD, where possible, be supported in a > manner that supports LDP signaled LSP, RSVP signaled LSP, and LSP > set up using management plane mechanisms. > > Either the management section is perfect or I forgot to read it. :-) > > The Ack section should say that after some discussion Tom Yu suggested=20 > replacement text that was used as the basis for the security section. > > The Ack section should indicate that the document was renamed as a=20 > result of potential problems with terminology collision that were=20 > pointed out by Lou Berger in the RtgDir review. > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From aretana@cisco.com Tue Oct 8 08:01:21 2013 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 C987621E81FC for ; Tue, 8 Oct 2013 08:01:21 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwdfri7O+A3I for ; Tue, 8 Oct 2013 08:01:16 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 798B221E820A for ; Tue, 8 Oct 2013 08:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1282; q=dns/txt; s=iport; t=1381244461; x=1382454061; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=839p2l6WhsaMg+wQgaRjy97SqvPEPC3+lUopaNeubCE=; b=RTPDnXUfs/wElNNGe5lF6uqrb3EWS8XJ/SnjkcY9u99P0RM3Ispy/BEg SHrh3mhI7cNZy1FML+GwVpULN9+R4BFuHbd1rfpTnPbb37g7y4QK87QTv GfxwaJSt40TlBLbqoYIMpy5voHZmKQhiFTBWMHKJ/S9Z3UIezGd5Csm0t I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIgdVFKtJXG//2dsb2JhbABZgweBCsEjgR4WdIInAQQOLCsUEgEIIhRCJQIEAQ0FCId+uluPETEHgx+BBAOqAYMkgio X-IronPort-AV: E=Sophos;i="4.90,1056,1371081600"; d="scan'208";a="269507486" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 08 Oct 2013 15:00:59 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r98F0xVf015421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Oct 2013 15:00:59 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.229]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Tue, 8 Oct 2013 10:00:59 -0500 From: "Alvaro Retana (aretana)" To: "stephane.litkowski@orange.com" , "Hannes Gredler" , Jeff Tantsura Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt Thread-Topic: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt Thread-Index: AQHOxDcyiGOC35JEykmO7dq06RgKbA== Date: Tue, 8 Oct 2013 15:00:59 +0000 Message-ID: In-Reply-To: <8189_1381232028_5253ED9C_8189_1805_1_EEE55384044474429A926C625D0FCC810968F4D62D@PUEXCB2F.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.88.224] Content-Type: text/plain; charset="us-ascii" Content-ID: <9349F3C36B0DF04E9CE649E36B708BA0@emea.cisco.com> 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: Tue, 08 Oct 2013 15:01:22 -0000 On 10/8/13 7:33 AM, "stephane.litkowski@orange.com" wrote: >IMHO, it would make sense to wait maybe until IETF89 to decide about >merging node protect with basic rLFA spec. >I think we could progress quite fast on node protection and two IETF >meetings (88, 89) would be fine to have a good view and where we are on >node protection maturity. Then we may decide if merge is possible or not. >These two meetings would also permit to stabilize the rLFA base spec >details and have consensus on the required level of details that are >missing today. > >I think now it's a bit early to decide ... > >Feedbacks ? especially from chairs ? Hi! I agree that we need to first work on the node protection topic *before* thinking about whether that should be merged onto the "basic rLFA spec". There's not much point in arguing on where the text should go if we haven't agreed on that first. Also, we need to be conscious of the balance of progressing work vs waiting for additional topics to be included in a draft. This is not a statement one way or another, but the estimated timeline above really puts us a year from now. OTOH, the discussions on the "basic spec" are still ongoing (as to this morning) as well. Alvaro. From stbryant@cisco.com Tue Oct 8 08:08:29 2013 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 04CDF21E821A for ; Tue, 8 Oct 2013 08:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.816 X-Spam-Level: X-Spam-Status: No, score=-109.816 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opHo6iArXuDr for ; Tue, 8 Oct 2013 08:08:23 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id CA59321E818D for ; Tue, 8 Oct 2013 08:08:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=54768; q=dns/txt; s=iport; t=1381244894; x=1382454494; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=dsLEalKxpY4/KwxHZYyZmAZJIzSyDGUyRSlGr4lc5Go=; b=L6+Ddm8Jxs3Zb5qOXIW2N3Qlz01LIe4DenlvMXt0pp5oXzFQwOmovn+u 2uJj4zUEL/cCoOrUzmDimXZg0QASEK4qCBUsOQ7vYxVt6Q+q/PMO4PF0l CmRDKP2dQJU2nLQZ+Jad8vLTMHjpYJL83IWDcr2GF5i1aK0qrLZAbx+jX E=; X-IronPort-AV: E=Sophos;i="4.90,1056,1371081600"; d="scan'208,217";a="87266209" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 08 Oct 2013 15:08:09 +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 r98F83mG027358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Oct 2013 15:08:04 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r98F82Kc012558; Tue, 8 Oct 2013 16:08:02 +0100 (BST) Message-ID: <52541FD1.90307@cisco.com> Date: Tue, 08 Oct 2013 16:08:01 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stephane.litkowski@orange.com Subject: Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt References: <524C02D3.6050309@cisco.com> <18754_1381136403_52527813_18754_7041_1_EEE55384044474429A926C625D0FCC810966AAC932@PUEXCB2F.nanterre.francetelecom.fr> <5252D987.5050201@cisco.com> <28731_1381216021_5253AF15_28731_628_1_EEE55384044474429A926C625D0FCC810968F4D3E6@PUEXCB2F.nanterre.francetelecom.fr> <5253D25A.1020600@cisco.com> <18850_1381231588_5253EBE4_18850_9379_1_EEE55384044474429A926C625D0FCC810968F4D61B@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: <18850_1381231588_5253EBE4_18850_9379_1_EEE55384044474429A926C625D0FCC810968F4D61B@PUEXCB2F.nanterre.francetelecom.fr> Content-Type: multipart/alternative; boundary="------------000206060800010900050302" X-Mailman-Approved-At: Tue, 08 Oct 2013 08:22:40 -0700 Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , rogeriomariano , "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: Tue, 08 Oct 2013 15:08:29 -0000 This is a multi-part message in MIME format. --------------000206060800010900050302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 08/10/2013 12:26, stephane.litkowski@orange.com wrote: > > So if the nodes to not accept the TLDP they you have a number of > alternatives: > > 1) Take it on the chin (it is FRR not convergence) > 2) Replace the nodes with nodes that do > 3) Modify the nodes to accept the TLDP > 4) Get all other nodes to advertise the capability and address > 5) Test the candidate nodes as part of the selection process > > Are there any other approaches? > > [SLI] The good approach would be to use policies to automatically > prune these PQs as operators know which PQ may not to be able to > accept TLDP. > So (6) is to have a local list of unacceptable PQ nodes to be excluded from the calculation. > > What algorithm do you suggest? > > [SLI] Do you have nothing to propose ? I know that CISCO has a working > rLFA implementation , so I think you already have something to propose ... > > In case you don't, we could use the following approach : > > -Short term : use a tie breaker like (ISIS speaking) : > > oUse IP in TLV134 > > oIf not existing, use IP in TLV132 if there's only one entry > > oIf multiple entries in TLV132, use highest or lowest /32 IP listed as > TLV135 > > Note that there is some corner cases where such algo would not work, > e.g. when external /32 are advertised in ISIS using redistribution, in > TLV135 you don't have the information of internal or external route > and you may choose an external one. > > -Long term : define an IGP extension to mark prefix associated with > TLDP listening. > > The idea is that the reader of the draft need to be aware on how the > TLDP address is chosen and so may be able to adjust his LDP configs to > make it working correctly. > I think that we have been through here before, and as I recall we concluded that RTGWG should specify the requirement for the advertisement and there should be a draft in OSPF and ISIS specifying how that advertsizement would happen. As I recall in ISIS the draft would be very short. Stewart > *Stephane Litkowski* > FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE > > Operational Engineering & Support IPTAC for RAEI network > > Orange Expert Network of Future > tél. +33 2 23 28 49 83 > > mob. +33 6 37 86 97 52 > stephane.litkowski@orange.com > > *De :*Stewart Bryant [mailto:stbryant@cisco.com] > *Envoyé :* mardi 8 octobre 2013 11:38 > *À :* LITKOWSKI Stephane DTF/DERX > *Cc :* Alvaro Retana (aretana); > draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rogeriomariano; rtgwg@ietf.org > *Objet :* Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt > > On 08/10/2013 08:06, stephane.litkowski@orange.com > wrote: > > Stewart, > > >There are clearly only two solutions to this, either permit TLDP on any likely LSR, > protected with an ACL if you wish, and accept the cases that fail > as being a minority concern, or two (and out of scope for this > draft) get the LSRs to advertise TLDP willingness in the IGP. > > > [SLI] Some nodes are not accepting any TLDP session at all and > you cannot configure them to do it ... > > So if the nodes to not accept the TLDP they you have a number of > alternatives: > > 1) Take it on the chin (it is FRR not convergence) > 2) Replace the nodes with nodes that do > 3) Modify the nodes to accept the TLDP > 4) Get all other nodes to advertise the capability and address > 5) Test the candidate nodes as part of the selection process > > Are there any other approaches? > > > >We can certainly discuss the issue, but I am reluctant to specify a > heuristic in an IETF draft, because then it is a specification and not > a heuristic. > > [SLI] Ok, so just specify an algorithm to choose the IP address to use > to establish the TLDP session. By doing nothing, you can fall into > situations where you PLR is unable to establish a TLDP session because > it's choosing the wrong IP address. > > What algorithm do you suggest? > > Stewart > > > Thanks, > > *Stephane Litkowski* > FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE > > Operational Engineering & Support IPTAC for RAEI network > > Orange Expert Network of Future > tél. +33 2 23 28 49 83 > > mob. +33 6 37 86 97 52 > stephane.litkowski@orange.com > > *De :*Stewart Bryant [mailto:stbryant@cisco.com] > *Envoyé :* lundi 7 octobre 2013 17:56 > *À :* LITKOWSKI Stephane DTF/DERX > *Cc :* Alvaro Retana (aretana); > draft-ietf-rtgwg-remote-lfa@tools.ietf.org > ; rogeriomariano; > rtgwg@ietf.org > *Objet :* Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt > > On 07/10/2013 09:59, stephane.litkowski@orange.com > wrote: > > Hi Stewart, > > Here are some old comments you didn't provide on feedback on : > > "Regarding remote LFA draft, I would hope to see some points > addressed in the draft before going to WGLC. > > - It would be good to add some simulation results about how much > TLDP session are required (TX and TX+RX), this in order to make > people aware on how much rLFA may impact their TLDP session scaling > > That is a issue for Mike to consider. > > > - We already raised the point some months ago about possibly "interop" > issues in the following cases : > > * PLR choose a PQ which is not able to accept TLDP session : we > verified it in a lab, and we can clearly fall into such situation in a > live network, leading to protection not available. > > There are clearly only two solutions to this, either permit TLDP on > any likely LSR, protected with an ACL if you wish, and accept the > cases that fail as being a minority concern, or two (and out of scope > for this draft) get the LSRs to advertise TLDP willingness in the IGP. > > > * PQ having multiple IP addresses /32 attached, so which one would > be used to establish TLDP session ? Current implementations are using > some heuristics and it would be good to document this > > We can certainly discuss the issue, but I am reluctant to specify a > heuristic in an IETF draft, because then it is a specification and not > a heuristic. > > > > - Current text states that rLFA is computed only when LFA are not > available and our analysis pointed that this is really not a good idea > as in term of manageability rLFA alternate may be better than LFA > alternate. It would be good that rLFA draft points to potential > manageability issues and refers to the appropriate draft. > > Hopefully this can be an informative ref, but we can include some > simple text that notes that it is up to the implementer how they need > to make a trade-off between minimum cost and minimum compute. > > Thanks for bringing this to my attention, hope to get some work done > on this draft at the end of this week. > > - Stewart > > > > " > > Thanks > > Stephane > > *Stephane Litkowski* > FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE > > Operational Engineering & Support IPTAC for RAEI network > > Orange Expert Network of Future > tél. +33 2 23 28 49 83 > > mob. +33 6 37 86 97 52 > stephane.litkowski@orange.com > > *De :*rtgwg-bounces@ietf.org > [mailto:rtgwg-bounces@ietf.org] *De la part de* Stewart Bryant > *Envoyé :* mercredi 2 octobre 2013 13:26 > *À :* Alvaro Retana (aretana) > *Cc :* draft-ietf-rtgwg-remote-lfa@tools.ietf.org > ; rogeriomariano; > rtgwg@ietf.org > *Objet :* Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt > > I will try to get a new version out this week or next. > > I plan to put in the algorithm text, although having discussed > this with Mike, our inclination is to include this as an > appendix since it is not required for interoperability that > you do the computation that way. > > I will look at the issues left unresolved and any comments > posted in response to this email. > > I see no reason to request a slot at IETF88 unless there remain > technical issues that we are unable to resolve on this list. > > - Stewart (as duty editor of the draft) > > > > On 01/10/2013 15:40, Alvaro Retana (aretana) wrote: > > On 10/1/13 10:31 AM, "rogeriomariano" > wrote: > > Rogerio: > > Folks, Does anyone know whether the draft deal will be treated > in the IETF 88? > > We haven't started working on the agenda yet, so it is perhaps too > early to talk about whether this draft will be discussed in > Vancouver or not. > > In the meant time, if you have comments or questions on the draft, > please post them to the list. > > Thanks! > > Alvaro. > > > > > > > _______________________________________________ > > 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 > > _________________________________________________________________________________________________________________________ > > 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, > 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, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > > > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > _________________________________________________________________________________________________________________________ > > 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, > 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, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > _________________________________________________________________________________________________________________________ > > 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, > 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, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------000206060800010900050302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 08/10/2013 12:26, stephane.litkowski@orange.com wrote:

So if the nodes to not accept the TLDP they you have a number of
alternatives:

1) Take it on the chin (it is FRR not convergence)
2) Replace the nodes with nodes that do
3) Modify the nodes to accept the TLDP
4) Get all other nodes to advertise the capability and address
5) Test the candidate nodes as part of the selection process

Are there any other approaches?

 

[SLI] The good approach would be to use policies to automatically prune these PQs as operators know which PQ may not to be able to accept TLDP.

 

So (6) is to have a local list of unacceptable PQ nodes to be excluded from the calculation.

 

 

What algorithm do you suggest?

[SLI] Do you have nothing to propose ? I know that CISCO has a working rLFA implementation , so I think you already have something to propose ...

In case you don’t, we could use the following approach :

-          Short term : use a tie breaker like (ISIS speaking) :

o   Use IP in TLV134

o   If not existing, use IP in TLV132 if there’s only one entry

o   If multiple entries in TLV132, use highest or lowest /32 IP listed as TLV135

Note that there is some corner cases where such algo would not work, e.g. when external /32 are advertised in ISIS using redistribution, in TLV135 you don’t have the information of internal or external route and you may choose an external one.

 

-          Long term : define an IGP extension to mark prefix associated with TLDP listening.

 

The idea is that the reader of the draft need to be aware on how the TLDP address is chosen and so may be able to adjust his LDP configs to make it working correctly.

 

I think that we have been through here before, and as I recall we concluded
that RTGWG should specify the requirement for the advertisement and there
should be a draft in OSPF and ISIS specifying how that advertsizement would
happen. As I recall in ISIS the draft would be very short.

Stewart

Stephane Litkowski
FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE

Operational Engineering & Support IPTAC for RAEI network

Orange Expert Network of Future
tél. +33 2 23 28 49 83

mob. +33 6 37 86 97 52
stephane.litkowski@orange.com

De : Stewart Bryant [mailto:stbryant@cisco.com]
Envoyé : mardi 8 octobre 2013 11:38
À : LITKOWSKI Stephane DTF/DERX
Cc : Alvaro Retana (aretana); draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rogeriomariano; rtgwg@ietf.org
Objet : Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

 

On 08/10/2013 08:06, stephane.litkowski@orange.com wrote:

Stewart,

 

 

>There are clearly only two solutions to this, either permit TLDP on any likely LSR, protected with an ACL if you wish, and accept the cases that fail as being a minority concern, or two (and out of scope for this draft) get the LSRs to advertise TLDP willingness in the IGP.


[SLI] Some nodes are not accepting any TLDP session  at all and you cannot configure them to do it …

So if the nodes to not accept the TLDP they you have a number of
alternatives:

1) Take it on the chin (it is FRR not convergence)
2) Replace the nodes with nodes that do
3) Modify the nodes to accept the TLDP
4) Get all other nodes to advertise the capability and address
5) Test the candidate nodes as part of the selection process

Are there any other approaches?


 

 

> We can certainly discuss the issue, but I am reluctant to specify a heuristic in an IETF draft, because then it is a specification and not a heuristic.

 

[SLI] Ok, so just specify an algorithm to choose the IP address to use to establish the TLDP session. By doing nothing, you can fall into situations where you PLR is unable to establish a TLDP session because it’s choosing the wrong IP address.

What algorithm do you suggest?

Stewart


 

Thanks,

 

Stephane Litkowski
FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE

Operational Engineering & Support IPTAC for RAEI network

Orange Expert Network of Future
tél. +33 2 23 28 49 83

mob. +33 6 37 86 97 52
stephane.litkowski@orange.com

De : Stewart Bryant [mailto:stbryant@cisco.com]
Envoyé : lundi 7 octobre 2013 17:56
À : LITKOWSKI Stephane DTF/DERX
Cc : Alvaro Retana (aretana); draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rogeriomariano; rtgwg@ietf.org
Objet : Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

 

On 07/10/2013 09:59, stephane.litkowski@orange.com wrote:

Hi Stewart,

 

Here are some old comments you didn’t provide on feedback on :

 

“Regarding remote LFA draft, I would hope to see some points addressed in the draft before going to WGLC.

- It would be good to add some simulation results about how much TLDP session are required (TX and TX+RX), this in order to make people aware on how much rLFA may impact their TLDP session scaling

 

That is a issue for Mike to consider.


- We already raised the point some months ago about possibly "interop" issues in the following cases :

    * PLR choose a PQ which is not able to accept TLDP session : we verified it in a lab, and we can clearly fall into such situation in a live network, leading to protection not available.

There are clearly only two solutions to this, either permit TLDP on any likely LSR, protected with an ACL if you wish, and accept the cases that fail as being a minority concern, or two (and out of scope for this draft) get the LSRs to advertise TLDP willingness in the IGP.


 

    * PQ having multiple IP addresses /32 attached, so which one would be used to establish TLDP session ? Current implementations are using some heuristics and it would be good to document this

 

We can certainly discuss the issue, but I am reluctant to specify a heuristic in an IETF draft, because then it is a specification and not a heuristic.



- Current text states that rLFA is computed only when LFA are not available and our analysis pointed that this is really not a good idea as in term of manageability rLFA alternate may be better than LFA alternate. It would be good that rLFA draft points to potential manageability issues and refers to the appropriate draft.

Hopefully this can be an informative ref, but we can include some simple text that notes that it is up to the implementer how they need to make a trade-off between minimum cost and minimum compute.

Thanks for bringing this to my attention, hope to get some work done on this draft at  the end of this week.

- Stewart



 

 

“

 

Thanks

 

Stephane

 

 

 

Stephane Litkowski
FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE

Operational Engineering & Support IPTAC for RAEI network

Orange Expert Network of Future
tél. +33 2 23 28 49 83

mob. +33 6 37 86 97 52
stephane.litkowski@orange.com

De : rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] De la part de Stewart Bryant
Envoyé : mercredi 2 octobre 2013 13:26
À : Alvaro Retana (aretana)
Cc : draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rogeriomariano; rtgwg@ietf.org
Objet : Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

 

I will try to get a new version out this week or next.

I plan to put in the algorithm text, although having discussed
this with Mike, our inclination is to include this as an
appendix since it is not required for interoperability that
you do the computation that way.

I will look at the issues left unresolved and any comments
posted in response to this email.

I see no reason to request a slot at IETF88 unless there remain
technical issues that we are unable to resolve on this list.

- Stewart (as duty editor of the draft)



On 01/10/2013 15:40, Alvaro Retana (aretana) wrote:

On 10/1/13 10:31 AM, "rogeriomariano" <rsouza.rjo@gmail.com> wrote:

 

Rogerio:

 

Folks, Does anyone know whether the draft deal will be treated in the IETF 88?

 

We haven't started working on the agenda yet, so it is perhaps too early to talk about whether this draft will be discussed in Vancouver or not.

 

In the meant time, if you have comments or questions on the draft, please post them to the list.

 

Thanks!

 

Alvaro.






_______________________________________________
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
 
_________________________________________________________________________________________________________________________
 
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,
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, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.





-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
 
_________________________________________________________________________________________________________________________
 
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,
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, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.




-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
 
_________________________________________________________________________________________________________________________

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,
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, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------000206060800010900050302-- From aretana@cisco.com Tue Oct 8 11:23:22 2013 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 E5D3111E80FA for ; Tue, 8 Oct 2013 11:23:22 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsOSOLsuzJ5v for ; Tue, 8 Oct 2013 11:23:18 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5077C11E810D for ; Tue, 8 Oct 2013 11:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4233; q=dns/txt; s=iport; t=1381256591; x=1382466191; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=4DEx4WywfeC0kks2dHNl/yyFWxDWW9Rhyi5IKzHtJCk=; b=WZ4SyTkc7voJpskm2EgNoB/nAQhn4MCLCf8vphNojxTqg4lTrY2Q6MsH tCPm9Eo3aZ6qKSQoF4nSJ/31pUkDfjPuzzmMomm5HLLfIV78cZ4XoAsL9 MvhIQ280/XZrYYvQmh73psMMx1/p2hJ7TMwtccGFLs5OMiIxNBAztUavU I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMFACVMVFKtJXHB/2dsb2JhbABZgkNEOFLBJYEiFm0HgicBBIELAQgEHh05FBECBBMIAYd9DJk8oT+OCYEIDymDH4EEA6oBgySBcTk X-IronPort-AV: E=Sophos;i="4.90,1057,1371081600"; d="scan'208,217";a="269616101" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 08 Oct 2013 18:23:09 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r98IN9SD000463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 8 Oct 2013 18:23:09 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.229]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Tue, 8 Oct 2013 13:23:09 -0500 From: "Alvaro Retana (aretana)" To: "rtgwg@ietf.org" Subject: Re: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm) Thread-Topic: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm) Thread-Index: AQHOu4CPrWxL1Z2c40Onwd/d+2+N/pnrQKGA Date: Tue, 8 Oct 2013 18:23:09 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.7] Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94E3958F18Exmbalnx15ciscoc_" 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, 08 Oct 2013 18:23:23 -0000 --_000_BBD66FD99311804F80324E8139B3C94E3958F18Exmbalnx15ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 9/27/13 8:53 AM, "Alvaro Retana (aretana)" > wrote: Hi! Thanks to all who have replied to this call! However, I think I probably wasn't clear when I wrote: We want to hear from people who have read and understood the draft (besides= the authors!) about this topic. Please provide some explanation as to why= you support or not the adoption of the draft =97 avoid "+1". As you express your support (or not) for the draft, please explain why you = are supporting it (or not). In the original message I explained how not many people who attended the me= eting in Berlin seemed to have reviewed the draft to be able to gather any = type of indication of support (or not) at the time. That is one of the rea= sons why we want to gather information beyond just "support" (or not). Ano= ther reason is that since the original publication of the draft I haven't b= een able to find comments on the list about it. http://www.ietf.org/mail-archive/web/rtgwg/current/msg03435.html Maybe lots of people have provided comments directly to the authors, which = is great! But for the rest of us is not clear. Thanks! Alvaro. --_000_BBD66FD99311804F80324E8139B3C94E3958F18Exmbalnx15ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7FCFB7D9DD13EB43BC8876D024D2A701@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 9/27/13 8:53 AM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

Hi!

Thanks to all who have replied to this call!

However, I think I probably wasn't clear when I wrote:

We want to hear from people who have read and understood the draft (besides= the authors!) about this topic.  Please provide some explanation as t= o why you support or not the adoption of the draft =97 avoid "+1&q= uot;.

As you express your support (or not) for the draft, please explain why= you are supporting it (or not).

In the original message I explained how not many people who attended t= he meeting in Berlin seemed to have reviewed the draft to be able to gather= any type of indication of support (or not) at the time.  That is one = of the reasons why we want to gather information beyond just "support" (or not).  Another reason= is that since the original publication of the draft I haven't been able to= find comments on the list about it.


Maybe lots of people have provided comments directly to the authors, w= hich is great!  But for the rest of us is not clear.

Thanks!

Alvaro.
--_000_BBD66FD99311804F80324E8139B3C94E3958F18Exmbalnx15ciscoc_-- From aretana@cisco.com Tue Oct 8 11:28:06 2013 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 E015D21E827B for ; Tue, 8 Oct 2013 11:28:06 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wc-IWXYJuBoV for ; Tue, 8 Oct 2013 11:28:01 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE2021E8221 for ; Tue, 8 Oct 2013 11:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1682; q=dns/txt; s=iport; t=1381256881; x=1382466481; h=from:to:cc:subject:date:message-id:mime-version; bh=HZ39c3Mzuh237Za8DLPK5bqj12nPsMZDbwsQbz6Fqa0=; b=MJ7wUiqjWLfCQZe/oBfgheVukfvWjgOep+KqOipqfT60Gy4KRq+aPuTT V5FOsEDTLRxniw4iTNiSqtThAyqPAWJdZQsGyCC4syFCRyL4eO0vu+wlA +MHKl4cJ1EhUQPBYL5xNup1CmhTOAg9YyJWA2svixxgz1dI8yKsU0Hv2E I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEFANFNVFKtJXG+/2dsb2JhbABZgkNEgQrBJYEiFm0HghwLAQR5EgELAR5WJwQODYd+uwyPETGDJoEEA6oBgySCKg X-IronPort-AV: E=Sophos;i="4.90,1057,1371081600"; d="scan'208,217";a="269597996" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 08 Oct 2013 18:28:01 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r98IS0dO019712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Oct 2013 18:28:00 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.229]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Tue, 8 Oct 2013 13:28:00 -0500 From: "Alvaro Retana (aretana)" To: "draft-enyedi-rtgwg-mrt-frr-algorithm@tools.ietf.org" Subject: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algorithm Thread-Topic: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algorithm Thread-Index: AQHOxFQejz6lsVRV/UKb2dqFz2SbTg== Date: Tue, 8 Oct 2013 18:28:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.7] Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94E3958F1EAxmbalnx15ciscoc_" 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: Tue, 08 Oct 2013 18:28:07 -0000 --_000_BBD66FD99311804F80324E8139B3C94E3958F1EAxmbalnx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! In parallel to the WG Adoption Call, I want to formally ask the authors (no= additional contributors are listed in the latest version of the draft) to = please respond to this message indicating whether or not you are aware of a= ny relevant IPR. The draft will not progress (pending the results of the W= G Adoption Call) until we have received a response from each author. Thanks! Alvaro. --_000_BBD66FD99311804F80324E8139B3C94E3958F1EAxmbalnx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <626FA811F97D424A957EFEACB6BAB241@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi!

In parallel to the WG Adoption Call, I want to formally ask the author= s (no additional contributors are listed in the latest version of the draft= ) to please respond to this message indicating whether or not you are aware= of any relevant IPR.  The draft will not progress (pending the results of the WG Adoption Call) until we h= ave received a response from each author.

Thanks!

Alvaro.
--_000_BBD66FD99311804F80324E8139B3C94E3958F1EAxmbalnx15ciscoc_-- From jeff.tantsura@ericsson.com Tue Oct 8 11:55:16 2013 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 83EF121E8205 for ; Tue, 8 Oct 2013 11:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvcMzXHSLmyJ for ; Tue, 8 Oct 2013 11:55:10 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 2713121E81AC for ; Tue, 8 Oct 2013 11:55:09 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-ff-5254550c98c1 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 76.8D.03458.C0554525; Tue, 8 Oct 2013 20:55:09 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Tue, 8 Oct 2013 14:54:40 -0400 From: Jeff Tantsura To: "Alvaro Retana (aretana)" , "rtgwg@ietf.org" Subject: Re: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm) Thread-Topic: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm) Thread-Index: AQHOxFfXPzwf1Q9bK0Oa4iefcRzB7g== Date: Tue, 8 Oct 2013 18:54:40 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C74839951957@eusaamb109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_60DEDD93F5E54B4AB55647B8B6C74839951957eusaamb109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyuXSPny5vaEiQwbL3whZ/f25ltLjw5jez A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJVx88xT1oK3hhUzNp9gb2A8o9XFyMkhIWAi seTkHEYIW0ziwr31bF2MXBxCAkcZJSb+/8wK4SxjlDi96zQrSBWbgIHE/2/HWUBsEYEwicsf 57KB2MICkRKH32wFinMAxaMkVr9ihSjRk9i8cSUziM0ioCKxeuEdsHJeAW+Jiyv3gC3mFPCV mPx6BdhIRqAjvp9awwRiMwuIS9x6Mp8J4jgBiSV7zjND2KISLx//A5svCjS/7dgZdoi4ssT3 OY9YIHrzJVruv2WC2CUocXLmE5YJjCKzkIydhaRsFpIyiLiBxPtz85khbG2JZQtfQ9n6Ehu/ nGWEsK0lth4+xoKsZgEjxypGjtLi1LLcdCPDTYzAqDomwea4g3HBJ8tDjNIcLErivF/eOgcJ CaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYAxcpGMSFe6277am5ZaZ/sv3SbR1r3zr5r29Qzkw 2u5l0q6+rxwR3b9ZMlmt7/mKJT4Ubr735kaz7Oay1kkyG8rVHsoeeqi9/6hE6fTVSj0H+Esu GD3SPJoo2HIi0Fp82lIjT68N86J/iB/IqIvMuz9FtSYtY4VIW0iV8q3YwvNsTOaLfZJalFiK MxINtZiLihMB1WfjZngCAAA= 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, 08 Oct 2013 18:55:17 -0000 --_000_60DEDD93F5E54B4AB55647B8B6C74839951957eusaamb109ericsso_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Alvaro, I support adoption of the draft as it provides base for number of solutions= we (rtgwg) have been building using mrt. Cheers, Jeff From: Alvaro Retana > Date: Tuesday, October 8, 2013 11:23 AM To: "rtgwg@ietf.org" > Subject: Re: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-fr= r-algorithm) On 9/27/13 8:53 AM, "Alvaro Retana (aretana)" > wrote: Hi! Thanks to all who have replied to this call! However, I think I probably wasn't clear when I wrote: We want to hear from people who have read and understood the draft (besides= the authors!) about this topic. Please provide some explanation as to why= you support or not the adoption of the draft =97 avoid "+1". As you express your support (or not) for the draft, please explain why you = are supporting it (or not). In the original message I explained how not many people who attended the me= eting in Berlin seemed to have reviewed the draft to be able to gather any = type of indication of support (or not) at the time. That is one of the rea= sons why we want to gather information beyond just "support" (or not). Ano= ther reason is that since the original publication of the draft I haven't b= een able to find comments on the list about it. http://www.ietf.org/mail-archive/web/rtgwg/current/msg03435.html Maybe lots of people have provided comments directly to the authors, which = is great! But for the rest of us is not clear. Thanks! Alvaro. --_000_60DEDD93F5E54B4AB55647B8B6C74839951957eusaamb109ericsso_ Content-Type: text/html; charset="Windows-1252" Content-ID: <366CF1DC6B7F47498A292FD4C8E79C15@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi Alvaro,

I support adoption of the draft as it provides base for number of solu= tions we (rtgwg) have been building using mrt.

Cheers,
Jeff

From: Alvaro Retana <aretana@cisco.com>
Date: Tuesday, October 8, 2013 11:2= 3 AM
To: "rtgwg@ietf.org" <rtg= wg@ietf.org>
Subject: Re: WG Adoption of MRT Alg= orithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm)

On 9/27/13 8:53 AM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

Hi!

Thanks to all who have replied to this call!

However, I think I probably wasn't clear when I wrote:

We want to hear from people who have read and understood the draft (besides= the authors!) about this topic.  Please provide some explanation as t= o why you support or not the adoption of the draft =97 avoid "+1&q= uot;.

As you express your support (or not) for the draft, please explain why= you are supporting it (or not).

In the original message I explained how not many people who attended t= he meeting in Berlin seemed to have reviewed the draft to be able to gather= any type of indication of support (or not) at the time.  That is one = of the reasons why we want to gather information beyond just "support" (or not).  Another reason= is that since the original publication of the draft I haven't been able to= find comments on the list about it.


Maybe lots of people have provided comments directly to the authors, w= hich is great!  But for the rest of us is not clear.

Thanks!

Alvaro.
 --_000_60DEDD93F5E54B4AB55647B8B6C74839951957eusaamb109ericsso_-- From acee.lindem@ericsson.com Tue Oct 8 12:40:52 2013 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 2C29021F9C28 for ; Tue, 8 Oct 2013 12:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxeP1aZeXZ4b for ; Tue, 8 Oct 2013 12:40:46 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id E1F8D21F9BEF for ; Tue, 8 Oct 2013 12:40:42 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-3d-52545fb6a6e5 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 4F.80.03458.6BF54525; Tue, 8 Oct 2013 21:40:38 +0200 (CEST) To: undisclosed-recipients:; Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Tue, 8 Oct 2013 15:40:37 -0400 From: Acee Lindem Subject: Re: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm) Thread-Topic: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm) Thread-Index: AQHOu4CPrWxL1Z2c40Onwd/d+2+N/pnrQKGAgAA7GwCAAAzUgA== Date: Tue, 8 Oct 2013 19:40:37 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470307F2F9@eusaamb101.ericsson.se> References: <60DEDD93F5E54B4AB55647B8B6C74839951957@eusaamb109.ericsson.se> In-Reply-To: <60DEDD93F5E54B4AB55647B8B6C74839951957@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE470307F2F9eusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyuXRPrO62+JAgg6XLtSz+/tzKaHHhzW9m ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugStj9Y7X7AXTbCsWz7nG2sC4x6SLkZNDQsBE Yvubn2wQtpjEhXvrgWwuDiGBo4wSn/6fYwdJiAjISMyd/ZgVIrGMUWL917VgHWwCOhLPH/1j BrGZBcIkPm1fBRYXFoiUaNn2GaiZA6g5SqJhpwvEHCeJfU2zwMpZBFQkPrT9ZwSxeQV8JZru bAFrFRLwlnhyBGQXJwengI9E05Q/YDWMQMd9P7WGCWKVuMStJ/OZII4WkFiy5zwzhC0q8fLx P1YIW1liyZP9LBD1+RJ/Fkxkg9glKHFy5hOWCYyis5CMmoWkbBaSMoi4gcT7c/OZIWxtiWUL X0PZ+hIbv5xlhLCtJc5Om8mCrGYBI8cqRo7S4tSy3HQjw02MwGg7JsHmuINxwSfLQ4zSHCxK 4rxf3joHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamB0ZEs217W4bVLP8m/+nYnxYQ23j1/w clzQEKGyvPqnul7u3X7p+//2PlgfHDYj+ly/1Hx7po687v7lPXZrNXpfxBwo+r/mzAsBIdfH L5meH/Z8MT1Fk/VgRf8rwVbZvbplXTN+FmquO7aq16f7Qdw76yOX69WmLgqZLsjV9ffPt6MT qhYVuAoqsRRnJBpqMRcVJwIAG8JixoQCAAA= 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, 08 Oct 2013 19:40:52 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE470307F2F9eusaamb101erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I support adoption since MRT appears to provide optimal coverage w/o as muc= h overhead as other technologies. Also, the first MRT algorithm (draft-enye= di-rtgwg-mrt-frr-algorithm-03) is much better specified than the competing = mechanisms. Thanks, Acee On Oct 8, 2013, at 2:54 PM, Jeff Tantsura wrote: Hi Alvaro, I support adoption of the draft as it provides base for number of solutions= we (rtgwg) have been building using mrt. Cheers, Jeff From: Alvaro Retana > Date: Tuesday, October 8, 2013 11:23 AM To: "rtgwg@ietf.org" > Subject: Re: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-fr= r-algorithm) On 9/27/13 8:53 AM, "Alvaro Retana (aretana)" > wrote: Hi! Thanks to all who have replied to this call! However, I think I probably wasn't clear when I wrote: We want to hear from people who have read and understood the draft (besides= the authors!) about this topic. Please provide some explanation as to why= you support or not the adoption of the draft =E2=80=94 avoid "+1". As you express your support (or not) for the draft, please explain why you = are supporting it (or not). In the original message I explained how not many people who attended the me= eting in Berlin seemed to have reviewed the draft to be able to gather any = type of indication of support (or not) at the time. That is one of the rea= sons why we want to gather information beyond just "support" (or not). Ano= ther reason is that since the original publication of the draft I haven't b= een able to find comments on the list about it. http://www.ietf.org/mail-archive/web/rtgwg/current/msg03435.html Maybe lots of people have provided comments directly to the authors, which = is great! But for the rest of us is not clear. Thanks! Alvaro. --_000_94A203EA12AECE4BA92D42DBFFE0AE470307F2F9eusaamb101erics_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable I support adoption since MRT appears to provide optimal coverage w/o as muc= h overhead as other technologies. Also, the first MRT algorithm (draft-enyedi-rtgwg-mrt-frr-algorithm-03) is much better specified than the competing mechanisms. 
Thanks,
Acee


On Oct 8, 2013, at 2:54 PM, Jeff Tantsura wrote:

Hi Alvaro,

I support adoption of the draft as it provides base for number of solu= tions we (rtgwg) have been building using mrt.

Cheers,
Jeff

From: Alvaro Retana <aretana@cisco.com>
Date: Tuesday, October 8, 2013 11:2= 3 AM
To: "rtgwg@ietf.org" <rtg= wg@ietf.org>
Subject: Re: WG Adoption of MRT Alg= orithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm)

On 9/27/13 8:53 AM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

Hi!

Thanks to all who have replied to this call!

However, I think I probably wasn't clear when I wrote:

We want to hear from people who have read and understood the draft (besides= the authors!) about this topic.  Please provide some explanation as t= o why you support or not the adoption of the draft =E2=80=94 avoid "&#= 43;1".

As you express your support (or not) for the draft, please explain why= you are supporting it (or not).

In the original message I explained how not many people who attended t= he meeting in Berlin seemed to have reviewed the draft to be able to gather= any type of indication of support (or not) at the time.  That is one = of the reasons why we want to gather information beyond just "support" (or not).  Another reason= is that since the original publication of the draft I haven't been able to= find comments on the list about it.


Maybe lots of people have provided comments directly to the authors, w= hich is great!  But for the rest of us is not clear.

Thanks!

Alvaro.

--_000_94A203EA12AECE4BA92D42DBFFE0AE470307F2F9eusaamb101erics_-- From curtis@ipv6.occnc.com Tue Oct 8 12:59:53 2013 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 EE67D21F9EDB for ; Tue, 8 Oct 2013 12:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECFuyC2lEvrG for ; Tue, 8 Oct 2013 12:59:49 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id D2EE021F9EC4 for ; Tue, 8 Oct 2013 12:59:48 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r98JuK7G097514; Tue, 8 Oct 2013 15:56:20 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201310081956.r98JuK7G097514@gateway1.orleans.occnc.com> To: Lucy yong From: Curtis Villamizar Subject: Re: WG Last Call for draft-ietf-rtgwg-cl-requirement-11 In-reply-to: Your message of "Tue, 08 Oct 2013 14:15:19 -0000." <2691CE0099834E4A9C5044EEC662BB9D452D41A5@dfweml509-mbx.china.huawei.com> Date: Tue, 08 Oct 2013 15:56:20 -0400 Cc: "draft-ietf-rtgwg-cl-requirement@tools.ietf.org" , Ning So , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 19:59:54 -0000 OK. That is a total +3 from co-authors. I think that is sufficient to start the actual edits and get back to the WG with proposed changes. Thanks to those that responded. Curtis In message <2691CE0099834E4A9C5044EEC662BB9D452D41A5@dfweml509-mbx.china.huawei.com> Lucy yong writes: +1 lucy -----Original Message----- From: Ning So [mailto:Ning.So@tatacommunications.com] Sent: Tuesday, October 08, 2013 9:09 AM To: Andrew G. Malis; curtis@ipv6.occnc.com Cc: Alia Atlas; draft-ietf-rtgwg-cl-requirement@tools.ietf.org; rtgwg@ietf.org Subject: RE: WG Last Call for draft-ietf-rtgwg-cl-requirement-11 I am fine as well. Best regards, Ning So Head of Network Architecture Mobile Broadband Services Tata Communications (Cell) 972-955-0914 -----Original Message----- From: Andrew G. Malis [mailto:agmalis@gmail.com] Sent: Tuesday, October 08, 2013 8:50 AM To: curtis@ipv6.occnc.com Cc: Alia Atlas; draft-ietf-rtgwg-cl-requirement@tools.ietf.org; rtgwg@ietf.org Subject: Re: WG Last Call for draft-ietf-rtgwg-cl-requirement-11 I have no objection to any of Curtis' specific changes. Cheers, Andy On Mon, Oct 7, 2013 at 2:06 PM, Curtis Villamizar wrote: > > In message > > Alia Atlas writes: > >> This second WG Last Call got absolutely no comments. Does this group >> of generally opinionated and thoughtful people truly have nothing to >> say? >> >> If so and given the previous WGLC succeeded, then on Oct 9, I will >> take silence as consent and indicate that on the draft shepherd's >> write-up... >> >> Alia > > > Alia, et al. > > Silence could mean lots of people read the document and could see no > way to further improve it. I doubt that is the case. Silence could > also mean that the document has been around for so long that people > are tired or reading it and haven't bothered to read it again. More > likely IMHO. > > It isn't clear (to me) in the above email if you were extending WGLC > until Oct 9. As co-author, I wanted to give others a chance to > comment first during WGLC and they have had plenty of time to do so. > > Given that there are multiple co-authors, there has been some > compromise in the document. While combining contributions, there was > some tendency to "go along to keep moving forward". That can be bad > if there are too few critical reviewers outside the set of co-authors. > > With co-author hat off, I reread the document and here are my personal > review comments. > > If there is agreement to make changes, I will put co-author hat back > on and make these edits. If there is dissenting discussion, I'll edit > as best as I can judge consensus and we can disuss at IETF-88 if we > need to. If there is silence, I'll let Alia and Alvaro interpret the > silence. (full agreement with all changes? lack of interest?) > > This *is* a WG doc, so WG please speak up. > > Curtis > > > ---------------------------------------- > > General Comments (See specific instances of each in detailed comments): > > The section naming and grouping of requirements could stand some > improvement. > > Some of the requirement wording are awkwardly worded. A few sentences > border on meaningless. > > Some of the requirements are infeasible as worded. Most can be made > feasible by replacing "flows or group of flows" with "client LSP". > The following paragraph in the introduction gives a hint as to why > these are feasible for client LSP but not flows: > > The ingress and egress of a multipath may be midpoint LSRs with > respect to a given client LSP. A midpoint LSR does not participate > in the signaling of any clients of the client LSP. Therefore, in > general, multipath endpoints cannot determine requirements of clients > of a client LSP through participation in the signaling of the clients > of the client LSP. > > One requirement (bidirectional placement on components) is infeasible > for flows and infeasible for all but small client LSP that fit into a > single compoent link. The framework points this out. > > Specific Comments: > > wording: s/no significantly exceed/not significantly exceed/ > > FR#4 contains one awkward excessively wordy sentence followed by one > that I struggle to find any meaning in if I didn't already know what > the intent was. It may also be better to replace "path for a flow" > with "set of paths for an LSP" and then specify the requirements for > flows within that LSP. > > OLD > > FR#4 The solution SHALL provide a mechanism to select a path for a > flow across a network that contains a number of paths comprised > of pairs of nodes connected by advanced multipath in such a way > as to automatically distribute the load over the network nodes > connected by advanced multipaths while meeting all of the other > mandatory requirements stated above. The solution SHOULD work > in a manner similar to that of current networks without any > advanced multipath protocol enhancements when the > characteristics of the individual component links are > advertised. > > NEW > > FR#4 The solution shall provide a mechanism to select a set of > paths for an LSP across a network in such a way that flows > within the LSP are distributed across the set of paths while > meeting all of the other requirements stated above. The > solution SHOULD work in a manner similar to existing > multipath techniques except as necessary to accommodate > advanced multipath requirements. > > I think these say pretty much the same thing, but with improved > clarity in the new text. > > FR#10 and FR#11 are the following: > > FR#10 The solution SHALL provide a means to limit the latency to > meet a Performance Objective target on a per flow basis or > group of flow basis, where flows or groups of flows are > identifiable in the forwarding plane and are signaled using in > the control plane or set up using the management plane. > > The Performance Objectives differ across the services, and > some services have different Performance Objectives for > different QoS classes, for example, one QoS class may have a > much larger latency bound than another. Overload can occur > which would violate a Performance Objective parameter (e.g., > loss) and some remedy to handle this case for an advanced > multipath is required. > > FR#11 If the total demand offered by traffic flows exceeds the > capacity of the advanced multipath, the solution SHOULD define > a means to cause some traffic flows or groups of flows to move > to some other point in the network that is not congested. > These "preempted flows" may not be restored if there is no > uncongested path in the network. > > FR#10 and FR#11 currently fall under the section "Component Links > Provided by Lower Layer Networks" but have nothing to do with lower > layer networks. These would fit better with the existing section > named "Parallel Component Links with Different Characteristics" > (though see comments below on rearranging that section). > > FR#10 may be redundant due to FR#17 and FR#18 which specify minimul > latency and bounded latency. The first paragraph in FR#10 adds > nothing to FR#17 and FR#18 except that the result should meet "a > Performance Objective target". The second paragraph seems to be > unrelated discussion and perhaps belongs in FR#11. If so, FR#10 can > be eliminated possibly adding a statement about "a Performance > Objective target" in FR#17 and FR#18, but preferably leaving them > alone. > > FR#10 and FR#11 are infeasible if applied to "client LSP" rather than > "flows or groups of flows" for reasons stated in General Comments > above. (So are FR#17 and FR#18; see below). > > In FR#10 > s/signaled using in the control plane/signaled using the control > plane/ > > FR#11 needs to be about preemption of LSP, not preemption of flows. > Since there is no signaling of flows, there is no prioritization of > flows. There is OTOH diffserv, which will enforce prioritization, > even among traffic within a microflow (AF service where some traffic > is marked AFx2 or AFx3, aka yellow or red). > > In FR#11 s/traffic flows or groups of traffic flows/clent LSP/ makes > the requirement feasible. > > In FR#11 s/some other point in the network/an alternate set of paths/ > makes the requirement more clear. > > NEW > > FR#10 [Deleted] > > FR#11 If the total demand offered by traffic flows exceeds the > capacity of the advanced multipath, the solution SHOULD > define a means to cause some client LSP to move to an > alternate set of paths that are not congested. These > "preempted LSP" may not be restored if there is no > uncongested path in the network. > > The title "Parallel Component Links with Different Characteristics" > should be changed, dropping the word "Parallel". The requirements > also apply to very diverse paths through a network with different > characteristics. > > The set of requirements currently in "Component Links with Different > Characteristics" are mostly of two types: > > 1. Load Balance Dynamics (FR#12-FR#15, FR#20-FR#23) > > 2. Requirements for Carrying Client LSP (FR#16-FR#19, FR#24). > > FR#22 and FR#23 could be in either category but apply more to dynamics > of load balancing. > > It might be better to reorder these requirements and create two > subsections. Both still do apply to "Component Links with Different > Characteristics", but form two distinct subsets. > > In requirements FR#17-FR#19 > s/a traffic flow/the traffic flows within a client LSP/ Signaling is > applied to client LSP, not flows as mentioned in General Comments > above. > > FR#24 is extremely problematic. The existing framework document > indicates that there are significant feasibility issues associated > with supporting this requirement for all but small client LSP and > requiring a fallback to link bundling for these small cleint LSP. > There has been no discussion supporting a feasible means to do this > for large client LSP. Therefore it may be wise to either drop this > requirement entirely or at the very least change it to a SHOULD. If > the requirement is kept, perhaps a qualifier indicating "for small > client LSP only (ones that fit on a single component)" is required. > If link bundling is the solution, the requirement is a NOOP but the > requirement may serve to indicate that link bundling must co-exist > with hash based load balancing for a subset of LSP requiring that a > both directions take the same component. > > If FR#24 is relaxed to say that both directions traverse the same set > of nodes, then FR#24 becomes feasible for large client LSP. This > would, for example, allow MPLS-TP OAM to function corrently for > MPLS-TP LSP carried within client MPLS LSP. If this is desirable it > should be a separate requirement. > > The section title "Derived Requirements" has irked a number of people. > These requirements are distinct in that they reference protocols which > would be used within a solution, but they are not truly "derived" from > the "Functional Requirements" in the prior section. I prefer "General > Requirements for Protocol Solutions". > > Therefore > s/Derived Requirements/GeneralRequirements for Protocol Solutions/ > s/DR/GR/ > > I suggest rewording DR#1 as follows: > > OLD > > DR#1 The solution SHOULD attempt to extend existing protocols > wherever possible, developing a new protocol only if this adds > a significant set of capabilities. > > NEW > > GR#1 The solution SHOULD extend existing protocols wherever > possible, developing a new protocol only where doing so adds > a significant set of capabilities. > > I dropped "attempt to". The solution SHOULD get it right. No E for > Effort for trying but getting it wrong. :-) > > In DR#3, I'm not sure what the last sentence means as worded, though I > think I know the intent. > > OLD > > Other functional requirements should be supported as independently > of signaling protocol as possible. > > NEW > > Function requirements SHOULD, where possible, be supported in a > manner that supports LDP signaled LSP, RSVP signaled LSP, and LSP > set up using management plane mechanisms. > > Either the management section is perfect or I forgot to read it. :-) > > The Ack section should say that after some discussion Tom Yu suggested > replacement text that was used as the basis for the security section. > > The Ack section should indicate that the document was renamed as a > result of potential problems with terminology collision that were > pointed out by Lou Berger in the RtgDir review. > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From curtis@ipv6.occnc.com Tue Oct 8 20:21:14 2013 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 504FF11E8123 for ; Tue, 8 Oct 2013 20:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dX4sb5lrdgbB for ; Tue, 8 Oct 2013 20:21:10 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id B4DDC11E8120 for ; Tue, 8 Oct 2013 20:21:09 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r993Jp6g001256; Tue, 8 Oct 2013 23:19:51 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201310090319.r993Jp6g001256@gateway1.orleans.occnc.com> To: "rtgwg@ietf.org" Subject: draft-ietf-rtgwg-cl-requirement preview of -12 version From: Curtis Villamizar Date: Tue, 08 Oct 2013 23:19:50 -0400 Cc: cl-req authors X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 03:21:14 -0000 RTGWG, Two preview versions were created to make it easier to see differences. draft-ietf-rtgwg-cl-requirement-12-preview1 This first preview contains no edits except to rearrange the set of paragraphs and bullets and create new sections. The section naming is not quite as suggested below. The prior subsection 3.3 is broken into these three subsections. 3.3. Component Links with Different Characteristics 3.4. Considerations for Bidirectional Client LSP 3.5. Multipath Load Balancing Dynamics Note that the old FR#10 was deleted as noted below, being deemed as redundant if the old FR#17 and FR#18 mention meeting Performance Objectives. draft-ietf-rtgwg-cl-requirement-12-preview2 In this preview none of the requirements are reordered. Instead, the contents of the bullets and paragraphs are edited. The edits are mostly as described below. Additional edits are: 1. s/ITU/ITU-T/ in a few places. (request by Loa) 2. The document has been spell checked. 3. Wording in one paragraph in the intro section had to be changed to reflect the section renaming. It was improved a bit. 4. s/1 ms/1 msec/ 5. Added paragraph(s) before the list of requirements in each of the new subsections to indicate the purpose of the set of requirements. Added paragraph(s) after the list of requirements with discussion, generally providing caveats. These new paragraphs are generally in line with discussion below but were not explicitly cited as changes below. 6. The requirement now numbered FR#15 was reworded. OLD The solution SHALL provide a means that communicates whether the flows within an client LSP can be split across multiple component links. The solution SHOULD provide a means to indicate the flow identification field(s) which can be used along the flow path which can be used to perform this function. NEW The solution SHALL provide a means that indicates whether any of the flows within an client LSP MUST NOT be split across multiple component links. The sense is reversed (identify those sensitive to load balancing rather than those insensitive to it). The entire client LSP is treated the same (either balanced or not). Signaling enhancement to identify flows within the client LSP is no longer called for. 7. FR#16 refers to "prior requirements in Section 3.3" rather than just "prior requirements". 8. s/nodes (or sites)/nodes/ (only occurance of sites) 9. s/bounded by a configured value/bounded by a specific value/ (it could be signaled or configured, decide in the framework) 10. In FR#21, the reminder of the definition of "flows" is removed (not needed). 11. First paragraph in renamed section "General Requirements for Protocol Solutions" is edited to reflect the discussion below regarding the renaming. Other changes described in detail below were made. Both versions are available at these URLs. http://www.occnc.com/draft-ietf-rtgwg-cl-requirement-12-preview1.txt http://www.occnc.com/draft-ietf-rtgwg-cl-requirement-12-preview2.txt The two versions can be diffed using the IETF diff tool. Either go to the URL http://tools.ietf.org/rfcdiff and type in the two URLs above or paste in the following (eliminating white space, making one line). http://tools.ietf.org/rfcdiff ?url1=http://www.occnc.com/draft-ietf-rtgwg-cl-requirement-12-preview1.txt &url2=http://www.occnc.com/draft-ietf-rtgwg-cl-requirement-12-preview2.txt It is also possible to diff the -11 version and either preview version with this tool, but due to the reordering of requirements and new sections, this diff doesn't work well. Using the diff tool on the two preview versions is a good way to see only the changes that were made. Please also reread the document. This is a WG doc and RTGWG should be providing the AD and IESG with a high quality document. More review at this stage is better. Curtis ------- Forwarded Message Return-Path: rtgwg-bounces@ietf.org Delivery-Date: Mon Oct 7 17:38:25 2013 Return-Path: Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) by harbor1.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id r97LcPEG091422 for ; Mon, 7 Oct 2013 17:38:25 -0400 (EDT) (envelope-from rtgwg-bounces@ietf.org) Received: (from curtis@localhost) by harbor1.ipv6.occnc.com (8.14.5/8.14.5/Submit) id r97LcPpU091420 for curtis; Mon, 7 Oct 2013 17:38:25 -0400 (EDT) (envelope-from rtgwg-bounces@ietf.org) Received: from maildrop0.ipv6.occnc.com [2001:470:1f07:1545::2:830] by harbor1.ipv6.occnc.com with IMAP (fetchmail-6.3.21) for (single-drop); Mon, 07 Oct 2013 17:38:25 -0400 (EDT) Received: from deliver ([unix socket]) by maildrop0.ipv6.occnc.com (Cyrus v2.4.16) with LMTPA; Mon, 07 Oct 2013 14:09:44 -0400 X-Sieve: CMU Sieve 2.4 Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:123a::1:1e]) by maildrop0.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id r97I9dQ7087297 for ; Mon, 7 Oct 2013 14:09:44 -0400 (EDT) (envelope-from rtgwg-bounces@ietf.org) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA1E21E80BA; Mon, 7 Oct 2013 11:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1381169373; bh=pz9B3Q/VoFV3XJrB1+4MiatTdgEQFiAYrq9GfGqAq18=; h=Message-Id:To:From:Subject:In-reply-to:Date:Cc:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=R4sRGOfdY4RZS8CamMpIrLP81JBgUfayzhrTkK/rdqCa9U/FBFYCyRO4q1t6qiEfA G+n3aAwAA3icSJVXnTduUDbkI+NNZQt5Unh1YRqxIY2M6qkBY/7x5FG1o5k7xhe0Ou qshOUJJVhwcATdqXTyN/I4jf1xyNY5kalDlhy9K0= 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 7240621E81B2 for ; Mon, 7 Oct 2013 11:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Score: -0.495 X-Spam-Level: Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjwLNrLPIpfn for ; Mon, 7 Oct 2013 11:09:17 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 550C911E8102 for ; Mon, 7 Oct 2013 11:09:13 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r97I6eeV070034; Mon, 7 Oct 2013 14:06:40 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201310071806.r97I6eeV070034@gateway1.orleans.occnc.com> To: Alia Atlas From: Curtis Villamizar Subject: Re: WG Last Call for draft-ietf-rtgwg-cl-requirement-11 In-reply-to: Your message of "Tue, 01 Oct 2013 17:38:14 EDT." Date: Mon, 07 Oct 2013 14:06:39 -0400 Cc: "draft-ietf-rtgwg-cl-requirement@tools.ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org In message Alia Atlas writes: > This second WG Last Call got absolutely no comments. Does this group > of generally opinionated and thoughtful people truly have nothing to > say? > > If so and given the previous WGLC succeeded, then on Oct 9, I will > take silence as consent and indicate that on the draft shepherd's > write-up... > > Alia Alia, et al. Silence could mean lots of people read the document and could see no way to further improve it. I doubt that is the case. Silence could also mean that the document has been around for so long that people are tired or reading it and haven't bothered to read it again. More likely IMHO. It isn't clear (to me) in the above email if you were extending WGLC until Oct 9. As co-author, I wanted to give others a chance to comment first during WGLC and they have had plenty of time to do so. Given that there are multiple co-authors, there has been some compromise in the document. While combining contributions, there was some tendency to "go along to keep moving forward". That can be bad if there are too few critical reviewers outside the set of co-authors. With co-author hat off, I reread the document and here are my personal review comments. If there is agreement to make changes, I will put co-author hat back on and make these edits. If there is dissenting discussion, I'll edit as best as I can judge consensus and we can disuss at IETF-88 if we need to. If there is silence, I'll let Alia and Alvaro interpret the silence. (full agreement with all changes? lack of interest?) This *is* a WG doc, so WG please speak up. Curtis - ---------------------------------------- General Comments (See specific instances of each in detailed comments): The section naming and grouping of requirements could stand some improvement. Some of the requirement wording are awkwardly worded. A few sentences border on meaningless. Some of the requirements are infeasible as worded. Most can be made feasible by replacing "flows or group of flows" with "client LSP". The following paragraph in the introduction gives a hint as to why these are feasible for client LSP but not flows: The ingress and egress of a multipath may be midpoint LSRs with respect to a given client LSP. A midpoint LSR does not participate in the signaling of any clients of the client LSP. Therefore, in general, multipath endpoints cannot determine requirements of clients of a client LSP through participation in the signaling of the clients of the client LSP. One requirement (bidirectional placement on components) is infeasible for flows and infeasible for all but small client LSP that fit into a single compoent link. The framework points this out. Specific Comments: wording: s/no significantly exceed/not significantly exceed/ FR#4 contains one awkward excessively wordy sentence followed by one that I struggle to find any meaning in if I didn't already know what the intent was. It may also be better to replace "path for a flow" with "set of paths for an LSP" and then specify the requirements for flows within that LSP. OLD FR#4 The solution SHALL provide a mechanism to select a path for a flow across a network that contains a number of paths comprised of pairs of nodes connected by advanced multipath in such a way as to automatically distribute the load over the network nodes connected by advanced multipaths while meeting all of the other mandatory requirements stated above. The solution SHOULD work in a manner similar to that of current networks without any advanced multipath protocol enhancements when the characteristics of the individual component links are advertised. NEW FR#4 The solution shall provide a mechanism to select a set of paths for an LSP across a network in such a way that flows within the LSP are distributed across the set of paths while meeting all of the other requirements stated above. The solution SHOULD work in a manner similar to existing multipath techniques except as necessary to accommodate advanced multipath requirements. I think these say pretty much the same thing, but with improved clarity in the new text. FR#10 and FR#11 are the following: FR#10 The solution SHALL provide a means to limit the latency to meet a Performance Objective target on a per flow basis or group of flow basis, where flows or groups of flows are identifiable in the forwarding plane and are signaled using in the control plane or set up using the management plane. The Performance Objectives differ across the services, and some services have different Performance Objectives for different QoS classes, for example, one QoS class may have a much larger latency bound than another. Overload can occur which would violate a Performance Objective parameter (e.g., loss) and some remedy to handle this case for an advanced multipath is required. FR#11 If the total demand offered by traffic flows exceeds the capacity of the advanced multipath, the solution SHOULD define a means to cause some traffic flows or groups of flows to move to some other point in the network that is not congested. These "preempted flows" may not be restored if there is no uncongested path in the network. FR#10 and FR#11 currently fall under the section "Component Links Provided by Lower Layer Networks" but have nothing to do with lower layer networks. These would fit better with the existing section named "Parallel Component Links with Different Characteristics" (though see comments below on rearranging that section). FR#10 may be redundant due to FR#17 and FR#18 which specify minimul latency and bounded latency. The first paragraph in FR#10 adds nothing to FR#17 and FR#18 except that the result should meet "a Performance Objective target". The second paragraph seems to be unrelated discussion and perhaps belongs in FR#11. If so, FR#10 can be eliminated possibly adding a statement about "a Performance Objective target" in FR#17 and FR#18, but preferably leaving them alone. FR#10 and FR#11 are infeasible if applied to "client LSP" rather than "flows or groups of flows" for reasons stated in General Comments above. (So are FR#17 and FR#18; see below). In FR#10 s/signaled using in the control plane/signaled using the control plane/ FR#11 needs to be about preemption of LSP, not preemption of flows. Since there is no signaling of flows, there is no prioritization of flows. There is OTOH diffserv, which will enforce prioritization, even among traffic within a microflow (AF service where some traffic is marked AFx2 or AFx3, aka yellow or red). In FR#11 s/traffic flows or groups of traffic flows/clent LSP/ makes the requirement feasible. In FR#11 s/some other point in the network/an alternate set of paths/ makes the requirement more clear. NEW FR#10 [Deleted] FR#11 If the total demand offered by traffic flows exceeds the capacity of the advanced multipath, the solution SHOULD define a means to cause some client LSP to move to an alternate set of paths that are not congested. These "preempted LSP" may not be restored if there is no uncongested path in the network. The title "Parallel Component Links with Different Characteristics" should be changed, dropping the word "Parallel". The requirements also apply to very diverse paths through a network with different characteristics. The set of requirements currently in "Component Links with Different Characteristics" are mostly of two types: 1. Load Balance Dynamics (FR#12-FR#15, FR#20-FR#23) 2. Requirements for Carrying Client LSP (FR#16-FR#19, FR#24). FR#22 and FR#23 could be in either category but apply more to dynamics of load balancing. It might be better to reorder these requirements and create two subsections. Both still do apply to "Component Links with Different Characteristics", but form two distinct subsets. In requirements FR#17-FR#19 s/a traffic flow/the traffic flows within a client LSP/ Signaling is applied to client LSP, not flows as mentioned in General Comments above. FR#24 is extremely problematic. The existing framework document indicates that there are significant feasibility issues associated with supporting this requirement for all but small client LSP and requiring a fallback to link bundling for these small cleint LSP. There has been no discussion supporting a feasible means to do this for large client LSP. Therefore it may be wise to either drop this requirement entirely or at the very least change it to a SHOULD. If the requirement is kept, perhaps a qualifier indicating "for small client LSP only (ones that fit on a single component)" is required. If link bundling is the solution, the requirement is a NOOP but the requirement may serve to indicate that link bundling must co-exist with hash based load balancing for a subset of LSP requiring that a both directions take the same component. If FR#24 is relaxed to say that both directions traverse the same set of nodes, then FR#24 becomes feasible for large client LSP. This would, for example, allow MPLS-TP OAM to function corrently for MPLS-TP LSP carried within client MPLS LSP. If this is desirable it should be a separate requirement. The section title "Derived Requirements" has irked a number of people. These requirements are distinct in that they reference protocols which would be used within a solution, but they are not truly "derived" from the "Functional Requirements" in the prior section. I prefer "General Requirements for Protocol Solutions". Therefore s/Derived Requirements/GeneralRequirements for Protocol Solutions/ s/DR/GR/ I suggest rewording DR#1 as follows: OLD DR#1 The solution SHOULD attempt to extend existing protocols wherever possible, developing a new protocol only if this adds a significant set of capabilities. NEW GR#1 The solution SHOULD extend existing protocols wherever possible, developing a new protocol only where doing so adds a significant set of capabilities. I dropped "attempt to". The solution SHOULD get it right. No E for Effort for trying but getting it wrong. :-) In DR#3, I'm not sure what the last sentence means as worded, though I think I know the intent. OLD Other functional requirements should be supported as independently of signaling protocol as possible. NEW Function requirements SHOULD, where possible, be supported in a manner that supports LDP signaled LSP, RSVP signaled LSP, and LSP set up using management plane mechanisms. Either the management section is perfect or I forgot to read it. :-) The Ack section should say that after some discussion Tom Yu suggested replacement text that was used as the basis for the security section. The Ack section should indicate that the document was renamed as a result of potential problems with terminology collision that were pointed out by Lou Berger in the RtgDir review. _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg ------- End of Forwarded Message From lizhenbin@huawei.com Tue Oct 8 20:30:04 2013 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 E2C8A21F9951 for ; Tue, 8 Oct 2013 20:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.45 X-Spam-Level: ** X-Spam-Status: No, score=2.45 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGp80K-E1XkQ for ; Tue, 8 Oct 2013 20:30:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 170D921F93B9 for ; Tue, 8 Oct 2013 20:29:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AWP09121; Wed, 09 Oct 2013 03:29:57 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 04:29:33 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 04:29:56 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.141]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0146.000; Wed, 9 Oct 2013 11:29:49 +0800 From: Lizhenbin To: "Alvaro Retana (aretana)" , "rtgwg@ietf.org" Subject: =?gb2312?B?tPC4tDogV0cgQWRvcHRpb24gb2YgTVJUIEFsZ29yaXRobXMgRHJhZnQJKGRy?= =?gb2312?Q?aft-enyedi-rtgwg-mrt-frr-algorithm)?= Thread-Topic: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm) Thread-Index: AQHOu4CPrWxL1Z2c40Onwd/d+2+N/pnrQKGAgACFhdA= Date: Wed, 9 Oct 2013 03:29:48 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D081C6608@nkgeml506-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.77] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D081C6608nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected 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, 09 Oct 2013 03:30:05 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D081C6608nkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQWx2YXJvLA0KDQpJIHN1cHBvcnQgYWRvcHRpb24gb2YgdGhlIGRyYWZ0IGJhc2VkIG9uIGZv bGxvd2luZyByZWFzb25zOg0KMS4gVGhlIGFsZ29yaXRobSBpbXBsZW1lbnRhdGlvbiBiYXNlZCBv biB0aGUgZHJhZnQgaGFzIGJlZW4gZG9uZSBieSB1cy4gSXQgY2FuIHdvcmsgd2VsbC4gV2UgdGhp bmsgdGhlIGF1dGhvcnMgaGF2ZSBkb25lIGEgd2lkZSByZXNlYXJjaCBhbmQgYW5hbHlzaXMgd29y ayBvbiB0aGUgYWxnb3JpdGhtIHRvIG1ha2UgaXQgbWF0dXJlIGVub3VnaC4NCjIuIFRoZSBMRFAt TVQtYmFzZWQgTVJUIEZSUiBzb2x1dGlvbnMgdXNpbmcgdGhlIGFsZ29yaXRobSBoYXZlIGJlZW4g YnVpbGRpbmcuIFdlIGJlbGlldmUgaXQgaXMgYSBzY2FsYWJsZSBzb2x1dGlvbiB0byBwcm92aWRl IDEwMCUgY292ZXJhZ2UgZm9yIEZSUi4NCg0KDQpSZWdhcmRzLA0KUm9iaW4NCg0KDQoNCg0KDQq3 orz+yMs6IHJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGd3Zy1ib3VuY2VzQGlldGYu b3JnXSC0+rHtIEFsdmFybyBSZXRhbmEgKGFyZXRhbmEpDQq3osvNyrG85DogMjAxM8TqMTDUwjnI 1SAyOjIzDQrK1bz+yMs6IHJ0Z3dnQGlldGYub3JnDQrW98ziOiBSZTogV0cgQWRvcHRpb24gb2Yg TVJUIEFsZ29yaXRobXMgRHJhZnQgKGRyYWZ0LWVueWVkaS1ydGd3Zy1tcnQtZnJyLWFsZ29yaXRo bSkNCg0KT24gOS8yNy8xMyA4OjUzIEFNLCAiQWx2YXJvIFJldGFuYSAoYXJldGFuYSkiIDxhcmV0 YW5hQGNpc2NvLmNvbTxtYWlsdG86YXJldGFuYUBjaXNjby5jb20+PiB3cm90ZToNCg0KSGkhDQoN ClRoYW5rcyB0byBhbGwgd2hvIGhhdmUgcmVwbGllZCB0byB0aGlzIGNhbGwhDQoNCkhvd2V2ZXIs IEkgdGhpbmsgSSBwcm9iYWJseSB3YXNuJ3QgY2xlYXIgd2hlbiBJIHdyb3RlOg0KDQpXZSB3YW50 IHRvIGhlYXIgZnJvbSBwZW9wbGUgd2hvIGhhdmUgcmVhZCBhbmQgdW5kZXJzdG9vZCB0aGUgZHJh ZnQgKGJlc2lkZXMgdGhlIGF1dGhvcnMhKSBhYm91dCB0aGlzIHRvcGljLiAgUGxlYXNlIHByb3Zp ZGUgc29tZSBleHBsYW5hdGlvbiBhcyB0byB3aHkgeW91IHN1cHBvcnQgb3Igbm90IHRoZSBhZG9w dGlvbiBvZiB0aGUgZHJhZnQgoaogYXZvaWQgIisxIi4NCg0KQXMgeW91IGV4cHJlc3MgeW91ciBz dXBwb3J0IChvciBub3QpIGZvciB0aGUgZHJhZnQsIHBsZWFzZSBleHBsYWluIHdoeSB5b3UgYXJl IHN1cHBvcnRpbmcgaXQgKG9yIG5vdCkuDQoNCkluIHRoZSBvcmlnaW5hbCBtZXNzYWdlIEkgZXhw bGFpbmVkIGhvdyBub3QgbWFueSBwZW9wbGUgd2hvIGF0dGVuZGVkIHRoZSBtZWV0aW5nIGluIEJl cmxpbiBzZWVtZWQgdG8gaGF2ZSByZXZpZXdlZCB0aGUgZHJhZnQgdG8gYmUgYWJsZSB0byBnYXRo ZXIgYW55IHR5cGUgb2YgaW5kaWNhdGlvbiBvZiBzdXBwb3J0IChvciBub3QpIGF0IHRoZSB0aW1l LiAgVGhhdCBpcyBvbmUgb2YgdGhlIHJlYXNvbnMgd2h5IHdlIHdhbnQgdG8gZ2F0aGVyIGluZm9y bWF0aW9uIGJleW9uZCBqdXN0ICJzdXBwb3J0IiAob3Igbm90KS4gIEFub3RoZXIgcmVhc29uIGlz IHRoYXQgc2luY2UgdGhlIG9yaWdpbmFsIHB1YmxpY2F0aW9uIG9mIHRoZSBkcmFmdCBJIGhhdmVu J3QgYmVlbiBhYmxlIHRvIGZpbmQgY29tbWVudHMgb24gdGhlIGxpc3QgYWJvdXQgaXQuDQoNCmh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9ydGd3Zy9jdXJyZW50L21zZzAzNDM1 Lmh0bWwNCg0KTWF5YmUgbG90cyBvZiBwZW9wbGUgaGF2ZSBwcm92aWRlZCBjb21tZW50cyBkaXJl Y3RseSB0byB0aGUgYXV0aG9ycywgd2hpY2ggaXMgZ3JlYXQhICBCdXQgZm9yIHRoZSByZXN0IG9m IHVzIGlzIG5vdCBjbGVhci4NCg0KVGhhbmtzIQ0KDQpBbHZhcm8uDQo= --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D081C6608nkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Alvaro,

 <= /o:p>

I support ad= option of the draft based on= following reasons:

1. The algor= ithm implementation based on the draft has been done by us. It can work wel= l. We think the authors have done a wide research and analysis work on the algorithm to make it mature enough.

2. The LDP-M= T-based MRT FRR solutions using the algorithm have been building. We believ= e it is a scalable solution to provide 100% coverage for FRR.

 <= /o:p>

 <= /o:p>

Regards,

Robin

 <= /o:p>

 <= /o:p>

 <= /o:p>

 = ;

 = ;

=B7=A2=BC=FE=C8=CB: rtgwg-bounces@ietf.or= g [mailto:rtgwg-bounces@ietf.org] =B4=FA=B1=ED = Alvaro Retana (aretana)
=B7=A2=CB=CD= =CA=B1=BC=E4: 2013=C4=EA10=D4=C2= 9=C8=D5 2:23
=CA=D5=BC=FE=C8=CB: rtgwg@ietf.org
=D6=F7=CC=E2: Re: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-frr-algor= ithm)

 

On 9/27/13 8= :53 AM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

 <= /o:p>

Hi!

 <= /o:p>

Thanks to al= l who have replied to this call!

 <= /o:p>

However, I t= hink I probably wasn't clear when I wrote:

 <= /o:p>

We want to h= ear from people who have read and understood the draft (besides the authors= !) about this topic.  Please provide some explanation as to why you support or not the adoption of the draft =A1=AA avoid "+1= ".

 <= /o:p>

As you expre= ss your support (or not) for the draft, please explain why you are supporti= ng it (or not).

 <= /o:p>

In the origi= nal message I explained how not many people who attended the meeting in Ber= lin seemed to have reviewed the draft to be able to gather any type of indication of support (or not) at the time.  That is one = of the reasons why we want to gather information beyond just "support&= quot; (or not).  Another reason is that since the original publication= of the draft I haven't been able to find comments on the list about it.

 <= /o:p>

 <= /o:p>

Maybe lots o= f people have provided comments directly to the authors, which is great! &n= bsp;But for the rest of us is not clear.

 <= /o:p>

Thanks!=

 <= /o:p>

Alvaro.=

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D081C6608nkgeml506mbxchi_-- From csikor@tmit.bme.hu Wed Oct 9 01:30:32 2013 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 E66BA21E8108 for ; Wed, 9 Oct 2013 01:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.596 X-Spam-Level: X-Spam-Status: No, score=0.596 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9PXCmZFkkCD for ; Wed, 9 Oct 2013 01:30:26 -0700 (PDT) Received: from ruby.tmit.bme.hu (ruby.tmit.bme.hu [152.66.245.193]) by ietfa.amsl.com (Postfix) with ESMTP id C299F21F9E80 for ; Wed, 9 Oct 2013 01:30:21 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ruby.tmit.bme.hu (Postfix) with ESMTP id 6B60B87350 for ; Wed, 9 Oct 2013 10:30:15 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at tmit.bme.hu Received: from ruby.tmit.bme.hu ([127.0.0.1]) by localhost (ruby.tmit.bme.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79nsAO8KIsV5 for ; Wed, 9 Oct 2013 10:30:06 +0200 (CEST) Received: from anyo.tmit.bme.hu (anyo.tmit.bme.hu [152.66.246.7]) by ruby.tmit.bme.hu (Postfix) with ESMTP id C85EE87346 for ; Wed, 9 Oct 2013 10:30:06 +0200 (CEST) Received: from [152.66.244.179] (csikor.tmit.bme.hu [152.66.244.179]) (authenticated bits=0) by anyo.tmit.bme.hu (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r998UCUn003804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 9 Oct 2013 10:30:12 +0200 Message-ID: <52551411.6080503@tmit.bme.hu> Date: Wed, 09 Oct 2013 10:30:09 +0200 From: Levente Csikor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: rtgwg@ietf.org Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 09 Oct 2013 08:30:32 -0000 Dear All, I also support to work more on the node protection draft first, before merging it with "basic rLFA spec", because of various reasons: First, I think it would be almost a good approach to show how node-protecting remote LFA works on the same, or almost the same sample network topology used in the basic rLFA spec., but for easier and more comprehensive understanding, a bit more complex but still simple example should be given. IMHO, in the basic rLFA spec. it is a bit confusing that node E is considered as a destination and this node is the next-hop as well, since the important parts of the different roles are not dissevering enough. Because of this, the similar example in node prot spec. is also not straightforward: "In the event of the node-failure on primary nexthop E, the alternate path from Remote-LFA nexthop C to E and F also becomes unavailable." According to the well-known last-hop problem, it is obvious that if the destination (in the first case: node E) goes down, then it cannot be protected. Moreover, since the example network topologyis not 2-node-connected, it is obvious again that the node F, which can be accessed only via node E, then the failure of node E infers that the node F can be never reached. To (re)solve this issue, I suggest to use another network (in the basic rLFA spec. as well), which could be the following (all link costs are unit costs): A----------B---------C | | / | | | / | | | / | F G / H | | / | | | / | | | / | D----------E---------S In this case, assuming that source node S wants to send a packet to node D, the next-hop of S is node E. - Link protecting case: If link(s,e) fails, then P-space of node S regarding to the failed link, would consist of node H,C,B and A, whilst the Q-space of D would consist all nodes except S and H. In this case, the PQ-nodes, as the possible repair tunnel endpoints, are node A,B and C. - Node protecting case: However, if node E itself fails, then the P-space of S would not alter, but the Q-space of D would only contain node F and A resulting that only node A is present in the set of PQ-nodes. I think that this network also shows the different between the node protection and link protection, but in a more comprehensive manner. And it also demonstrates the fact mentioned in Figure 2 that for node-protecting rLFA, only the Q-spaces should be checked with those distance functions. Moreover, if we assume that in the example network above, there is a link (A,E) and node E itself failed again, than PQ-space would be and empty set meaning that this case cannot be protected. Second, it would be better in the draft if the questions about "how difficult or impossible to obtain those distances" would be clearly stated in a bullet point list: For example: - Q-space can be obtained by rSPF calculated at destination node D - P-space can be obtained through SPF calculation at source node S and its 1-hop neighbor. - SPF at a PQ-node is impossible or if not what extensions should be implemented (actually, IMHO, this is the one, which is not clear enough) Third, according to the Targeted-LDP discussion, which is about the fact that if some node do not support TLDP, then how can be the inner MPLS label obtained from the PQ-node; I think that if we want remote LFA protection then the nodes MUST implement/support this feature, because without this the protection cannot be guaranteed. For me, it is similar to a hypothetic case for example of Not-via, where if the router do not support Not-via, then it cannot be used. Or isn't it so simple? Please comment my observations, in order to help me and may others as well to understand every aspects and little pieces of remote LFA specifications. Best Regards, Levente Csikor On 10/08/2013 05:00 PM, Alvaro Retana (aretana) wrote: > On 10/8/13 7:33 AM, "stephane.litkowski@orange.com" > wrote: > >> IMHO, it would make sense to wait maybe until IETF89 to decide about >> merging node protect with basic rLFA spec. >> I think we could progress quite fast on node protection and two IETF >> meetings (88, 89) would be fine to have a good view and where we are on >> node protection maturity. Then we may decide if merge is possible or not. >> These two meetings would also permit to stabilize the rLFA base spec >> details and have consensus on the required level of details that are >> missing today. >> >> I think now it's a bit early to decide ... >> >> Feedbacks ? especially from chairs ? > Hi! > > I agree that we need to first work on the node protection topic *before* > thinking about whether that should be merged onto the "basic rLFA spec". > There's not much point in arguing on where the text should go if we > haven't agreed on that first. > > Also, we need to be conscious of the balance of progressing work vs > waiting for additional topics to be included in a draft. This is not a > statement one way or another, but the estimated timeline above really puts > us a year from now. OTOH, the discussions on the "basic spec" are still > ongoing (as to this morning) as well. > > Alvaro. > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From hannes@juniper.net Wed Oct 9 02:10:37 2013 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 B781A21E812A for ; Wed, 9 Oct 2013 02:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GteozIw11+Iy for ; Wed, 9 Oct 2013 02:10:31 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0184.outbound.messaging.microsoft.com [213.199.154.184]) by ietfa.amsl.com (Postfix) with ESMTP id 04F6121E8093 for ; Wed, 9 Oct 2013 02:10:30 -0700 (PDT) Received: from mail60-db8-R.bigfish.com (10.174.8.241) by DB8EHSOBE033.bigfish.com (10.174.4.96) with Microsoft SMTP Server id 14.1.225.22; Wed, 9 Oct 2013 09:10:28 +0000 Received: from mail60-db8 (localhost [127.0.0.1]) by mail60-db8-R.bigfish.com (Postfix) with ESMTP id E0F263002DD; Wed, 9 Oct 2013 09:10:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.242.197; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0512HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: VPS1(zzbb2dI98dI9371I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1de097h8275bhz2fh2a8h839h946hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail60-db8: domain of juniper.net designates 157.56.242.197 as permitted sender) client-ip=157.56.242.197; envelope-from=hannes@juniper.net; helo=BL2PRD0512HT001.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail60-db8 (localhost.localdomain [127.0.0.1]) by mail60-db8 (MessageSwitch) id 1381309827446293_28944; Wed, 9 Oct 2013 09:10:27 +0000 (UTC) Received: from DB8EHSMHS025.bigfish.com (unknown [10.174.8.252]) by mail60-db8.bigfish.com (Postfix) with ESMTP id 53EC0B80056; Wed, 9 Oct 2013 09:10:27 +0000 (UTC) Received: from BL2PRD0512HT001.namprd05.prod.outlook.com (157.56.242.197) by DB8EHSMHS025.bigfish.com (10.174.4.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 9 Oct 2013 09:10:27 +0000 Received: from [172.26.205.90] (193.110.54.36) by pod51010.outlook.com (10.255.233.34) with Microsoft SMTP Server (TLS) id 14.16.359.1; Wed, 9 Oct 2013 09:10:25 +0000 Subject: Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Hannes Gredler In-Reply-To: <5253D25A.1020600@cisco.com> Date: Wed, 9 Oct 2013 11:10:21 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: References: <524C02D3.6050309@cisco.com> <18754_1381136403_52527813_18754_7041_1_EEE55384044474429A926C625D0FCC810966AAC932@PUEXCB2F.nanterre.francetelecom.fr> <5252D987.5050201@cisco.com> <28731_1381216021_5253AF15_28731_628_1_EEE55384044474429A926C625D0FCC810968F4D3E6@PUEXCB2F.nanterre.francetelecom.fr> <5253D25A.1020600@cisco.com> To: X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.54.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , rogeriomariano , "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, 09 Oct 2013 09:10:38 -0000 hi stewart, i am not much in favor of 'lets try if we can bring-up TLDP, and if not lets pick another PQ' strategy, mainly because it may create cross dependencies. today the typical R-LFA flow between IGP and LSP is like this: 1. IGP determines PQ set 2. IGP installs IP-FRR routes and gives LDP a hint which PQ IP address shall be used for a given IP-FRR backup route 3. LDP tries to bring up T-LDP to the PQ set 4. LDP has learned PQ set LDP database(s) and sets the backup nexthop for its MPLS tunnel and MPLS transit routes accordingly now if we need to add the PQ pruning logic it becomes like this: 1. IGP determines PQ set 2. IGP installs IP-FRR routes and gives LDP a hint which PQ IP address shall be used for a given IP-FRR backup route 3. LDP tries to bring up T-LDP to the PQ set 4. timeout for bringing up T-LDP to PQ set 5. prune 'unwilling' PQ neighbor, goto 1 now my question: what event *removes* the unwilling PQ neighbor from the PQ prune list, ever? - even if the PQ neighbor has been reconfigured and it would now accept T-LDP sessions, the calculating router would never try to establish a T-LDP session after the PQ is on the prune list. and periodical fallback is not a good solution either, right ;-) to avoid the above i'd like to see simple protocol extensions to the IGPs of a node willing or not willing to accept T-LDP sessions and avoid the cross-dependencies. /hannes On Oct 8, 2013, at 11:37 AM, Stewart Bryant wrote: [ =85 ] > On 08/10/2013 08:06, stephane.litkowski@orange.com wrote: [ .. ] >> [SLI] Some nodes are not accepting any TLDP session at all and you = cannot configure them to do it =85 > So if the nodes to not accept the TLDP they you have a number of > alternatives: >=20 > 1) Take it on the chin (it is FRR not convergence) > 2) Replace the nodes with nodes that do > 3) Modify the nodes to accept the TLDP > 4) Get all other nodes to advertise the capability and address > 5) Test the candidate nodes as part of the selection process From ice@cisco.com Wed Oct 9 03:31:18 2013 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 C070A11E8164 for ; Wed, 9 Oct 2013 03:31:18 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWksl0OVu9Fs for ; Wed, 9 Oct 2013 03:31:14 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 19B7B11E8168 for ; Wed, 9 Oct 2013 03:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1675; q=dns/txt; s=iport; t=1381314674; x=1382524274; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=pzdgS27oYbLFJF+WGGpt9pvcfIKvpHlhHVEfgSD5kfY=; b=at90/l8Pi1mRrdQZ7fXMQYDq4h2dZYngAHeB0nN0KYPsxTRmwrD5y8ZV zsMvMfmkktQPBngfEGj+Hlk90l+h86G60BNmmrdE0UMYuB/MuFctjWmck YeyEUorQuIOwEwSspG6tToe41QRMmUWfxM/TK0zIJ0wtmqkOq9V85wKNU w=; X-IronPort-AV: E=Sophos;i="4.90,1062,1371081600"; d="scan'208";a="18634622" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 09 Oct 2013 10:31:13 +0000 Received: from ams-iwijnand-8719.cisco.com (ams-iwijnand-8719.cisco.com [10.55.191.154]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r99AV4UA006471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Oct 2013 10:31:08 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm) From: IJsbrand Wijnands In-Reply-To: Date: Wed, 9 Oct 2013 12:31:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Alvaro Retana (aretana) 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: Wed, 09 Oct 2013 10:31:18 -0000 Dear WG, =46rom a multicast POV I support this work to be adopted. Being able to = build two non-intersection paths through a single plane network is very = useful for Multicast live-live and MoFRR deployments. It solves a real = problem which we see in today's networks. A more challenging question to answer is how = draft-enyedi-rtgwg-mrt-frr-algorithm relates to = draft-thubert-rtgwg-arc-00 and draft-thubert-rtgwg-arc-bicast-00. I = don't know if both can move forward individually or if some merge is = possible. It would be good if the authors get together and discuss this. Thx, Ice. On 27 Sep 2013, at 14:53, Alvaro Retana (aretana) = wrote: > Hi! >=20 > This message starts a two-week Call for WG Adoption for 'Algorithms = for computing Maximally Redundant Trees for IP/LDP Fast-Reroute' = (draft-enyedi-rtgwg-mrt-frr-algorithm). >=20 > http://tools.ietf.org/html/draft-enyedi-rtgwg-mrt-frr-algorithm >=20 > At the meeting in Berlin the authors asked for the WG adoption of = their draft, but here were very few people in the room who had actually = reviewed the document to get any type of read of the room. =20 >=20 > We want to hear from people who have read and understood the draft = (besides the authors!) about this topic. Please provide some = explanation as to why you support or not the adoption of the draft =97 = avoid "+1". >=20 > This call will be over by EOD on Oct/11, 2013 (pick your favorite time = zone). >=20 > Thanks!! >=20 > Alvaro. > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From psarkar@juniper.net Wed Oct 9 03:49:50 2013 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 9977521F9BAD for ; Wed, 9 Oct 2013 03:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNCECwXBDIql for ; Wed, 9 Oct 2013 03:49:44 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 20C0121F9B28 for ; Wed, 9 Oct 2013 03:49:43 -0700 (PDT) Received: from mail156-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.22; Wed, 9 Oct 2013 10:49:43 +0000 Received: from mail156-ch1 (localhost [127.0.0.1]) by mail156-ch1-R.bigfish.com (Postfix) with ESMTP id 394292000CB; Wed, 9 Oct 2013 10:49:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz9371Ic85fh542I1418Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah18c673h1de097h186068h8275bh8275dhz2fh2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h9a9j1155h) Received-SPF: pass (mail156-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=psarkar@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(377454003)(51444003)(13464003)(77982001)(63696002)(54316002)(54356001)(59766001)(33646001)(56776001)(53806001)(85306002)(47446002)(83322001)(19580405001)(19580395003)(81816001)(74502001)(51856001)(76796001)(76786001)(74316001)(46102001)(76576001)(4396001)(49866001)(69226001)(16236675002)(19300405004)(50986001)(47976001)(74876001)(81686001)(47736001)(74366001)(65816001)(76482001)(74706001)(15975445006)(81342001)(81542001)(15202345003)(79102001)(66066001)(80022001)(56816003)(77096001)(74662001)(31966008)(83072001)(80976001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB518; H:BN1PR05MB520.namprd05.prod.outlook.com; CLIP:116.197.178.92; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail156-ch1 (localhost.localdomain [127.0.0.1]) by mail156-ch1 (MessageSwitch) id 1381315780706770_1451; Wed, 9 Oct 2013 10:49:40 +0000 (UTC) Received: from CH1EHSMHS033.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail156-ch1.bigfish.com (Postfix) with ESMTP id 9D29F200F7; Wed, 9 Oct 2013 10:49:40 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS033.bigfish.com (10.43.70.33) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 9 Oct 2013 10:49:39 +0000 Received: from BN1PR05MB518.namprd05.prod.outlook.com (10.141.65.143) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.371.2; Wed, 9 Oct 2013 10:49:38 +0000 Received: from BN1PR05MB520.namprd05.prod.outlook.com (10.141.65.151) by BN1PR05MB518.namprd05.prod.outlook.com (10.141.65.143) with Microsoft SMTP Server (TLS) id 15.0.775.9; Wed, 9 Oct 2013 10:49:36 +0000 Received: from BN1PR05MB520.namprd05.prod.outlook.com ([169.254.16.135]) by BN1PR05MB520.namprd05.prod.outlook.com ([169.254.16.135]) with mapi id 15.00.0775.005; Wed, 9 Oct 2013 10:49:36 +0000 From: Pushpasis Sarkar To: Levente Csikor , "rtgwg@ietf.org" Subject: RE: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt Thread-Topic: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt Thread-Index: AQHOxM92mGj7+zZhlkyPvb7kuYGb25nsGT1A Date: Wed, 9 Oct 2013 10:49:35 +0000 Message-ID: <0560d0a67fcc4af688176a280f9bdf3f@BN1PR05MB520.namprd05.prod.outlook.com> References: <52551411.6080503@tmit.bme.hu> In-Reply-To: <52551411.6080503@tmit.bme.hu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.178.92] x-forefront-prvs: 0994F5E0C5 Content-Type: multipart/alternative; boundary="_000_0560d0a67fcc4af688176a280f9bdf3fBN1PR05MB520namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 09 Oct 2013 10:49:50 -0000 --_000_0560d0a67fcc4af688176a280f9bdf3fBN1PR05MB520namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Levente, Please find few comments inline... Thanks -Pushpasis -----Original Message----- From: Levente Csikor [mailto:csikor@tmit.bme.hu] Sent: Wednesday, October 09, 2013 2:00 PM To: rtgwg@ietf.org Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-= 01.txt Dear All, I also support to work more on the node protection draft first, before merg= ing it with "basic rLFA spec", because of various reasons: First, I think it would be almost a good approach to show how node-protecti= ng remote LFA works on the same, or almost the same sample network topology= used in the basic rLFA spec., but for easier and more comprehensive unders= tanding, a bit more complex but still simple example should be given. IMHO,= in the basic rLFA spec. it is a bit confusing that node E is considered as= a destination and this node is the next-hop as well, since the important p= arts of the different roles are not dissevering enough. Because of this, th= e similar example in node prot spec. is also not straightforward: [Pushpasis] If you see Table 1,2, and 3 in draft-psarkar-rtgwg-rlfa-node-pr= otection-01 we have specified the destinations E, F (and their correspondin= g RLFA backup paths explicitly), that will be affected by node-failure of E= . Also the destination G has been included which will still be reachable in= the case of node-failure of E. Perhaps basic RLFA spec can also include su= ch kind of illustrations "In the event of the node-failure on primary nexthop E, the alternate path = from Remote-LFA nexthop C to E and F also becomes unavailable." [Pushpasis] That is exactly we are also saying in this draft(I mean draft-p= sarkar-rtgwg-rlfa-node-protection-01).. If any destination takes the shorte= st-path segment C...E that will not have node-protection using C as the PQ = node, because C is going to forward the traffic to E anyhow. In Table 2 we = see that the path segment C->D->E is included in the shortest path from C t= o E and F. That is why in case of node-failure of E, E and F cannot provide= node-protection According to the well-known last-hop problem, it is obvious that if the des= tination (in the first case: node E) goes down, then it cannot be protected= . Moreover, since the example network topologyis not 2-node-connected, it i= s obvious again that the node F, which can be accessed only via node E, the= n the failure of node E infers that the node F can be never reached. To (re)solve this issue, I suggest to use another network (in the basic rLF= A spec. as well), which could be the following (all link costs are unit cos= ts): A----------B---------C | | / | | | / | | | / | F G / H | | / | | | / | | | / | D----------E---------S In this case, assuming that source node S wants to send a packet to node D,= the next-hop of S is node E. - Link protecting case: If link(s,e) fails, then P-space of node S regard= ing to the failed link, would consist of node H,C,B and A, whilst the Q-spa= ce of D would consist all nodes except S and H. In this case, the PQ-nodes,= as the possible repair tunnel endpoints, are node A,B and C. - Node protecting case: However, if node E itself fails, then the P-space= of S would not alter, but the Q-space of D would only contain node F and A= resulting that only node A is present in the set of PQ-nodes. [Pushpasis] Can you elaborate on the method you used for deriving the PQ-no= des A and F here... Seems to me like you are doing a RSPF rooted on destina= tion D and then pruning all links originating from E... I think Chris Bower= s has already pointed on a different thread that while best way to guarante= e node-protection is to run a RSPF rooted on each destination, we cannot af= ford to do so in reality... It will be much more feasible to run FSPF on fe= wer PQ-nodes as specified in our draft.. Also, the method specified by our draft also finds A as the node-protecting= PQ-node, becoz the draft suggest to find the shortest-path from the PQ-nod= es (C, B, and A) to destination D. Only the SPF path from A does not go thr= ough E, so only A will provide node-protection for D. I think that this network also shows the different between the node protect= ion and link protection, but in a more comprehensive manner. And it also de= monstrates the fact mentioned in Figure 2 that for node-protecting rLFA, on= ly the Q-spaces should be checked with those distance functions. Moreover, if we assume that in the example network above, there is a link (= A,E) and node E itself failed again, than PQ-space would be and empty set m= eaning that this case cannot be protected. [Pushpasis] True. Our draft will also pick A->E->D as the SPF from A to D i= n that case and disqualify A as node-protecting PQ-node. In reality too the= re is no feasible path in this case till A re-converges after learning E's = node-failure Second, it would be better in the draft if the questions about "how difficu= lt or impossible to obtain those distances" would be clearly stated in a bu= llet point list: For example: - Q-space can be obtained by rSPF calculated at destination node D - P-space can be obtained through SPF calculation at source node S and it= s 1-hop neighbor. - SPF at a PQ-node is impossible or if not what extensions should be impl= emented (actually, IMHO, this is the one, which is not clear enough) [Pushpasis] The first two should really be addressed in the original RLFA d= raft. Chris has already written to the authors on this mailing list with su= ggesting text for the draft. The third one is no different than standard SP= F we need for RFC5286 implementation.. only difference being that it is roo= ted on PQ-nodes in case of RLFA... It is up to individual implementations = to come up with ways to constraint those to a limit. Third, according to the Targeted-LDP discussion, which is about the fact th= at if some node do not support TLDP, then how can be the inner MPLS label o= btained from the PQ-node; I think that if we want remote LFA protection the= n the nodes MUST implement/support this feature, because without this the p= rotection cannot be guaranteed. For me, it is similar to a hypothetic case = for example of Not-via, where if the router do not support Not-via, then it= cannot be used. Or isn't it so simple? [Pushpasis] Again this is more related to original RLFA draft. I will prefe= r the corresponding authors to address this point :) Please comment my observations, in order to help me and may others as well = to understand every aspects and little pieces of remote LFA specifications. Best Regards, Levente Csikor --_000_0560d0a67fcc4af688176a280f9bdf3fBN1PR05MB520namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Levente,

 

Please find few comments inline... 

 

Thanks

-Pushpasis

 

-----Original Message-----
From: Levente Csikor [mailto:csikor@tmit.bme.hu]
Sent: Wednesday, October 09, 2013 2:00 PM
To: rtgwg@ietf.org
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-= 01.txt

 

Dear All,

I also support to work more on the node protectio= n draft first, before merging it with "basic rLFA spec", because = of various reasons:

 

First, I think it would be almost a good approach= to show how node-protecting remote LFA works on the same, or almost the sa= me sample network topology used in the basic rLFA spec., but for easier and= more comprehensive understanding, a bit more complex but still simple example should be given. IMHO, in the = basic rLFA spec. it is a bit confusing that node E is considered as a desti= nation and this node is the next-hop as well, since the important parts of = the different roles are not dissevering enough. Because of this, the similar example in node prot spec. is also no= t straightforward:

[Pushpasis] If y= ou see Table 1,2, and 3 in draft-psarkar-rtgwg-rlfa-node-protection-01 we h= ave specified the destinations E, F (and their corresponding RLFA backup pa= ths explicitly), that will be affected by node-failure of E. Also the destination G has been included which will = still be reachable in the case of node-failure of E. Perhaps basic RLFA spe= c can also include such kind of illustrations

 

"In the event of the node-failure on primary= nexthop E, the alternate path from Remote-LFA nexthop C to E and F also be= comes unavailable."

[Pushpasis] That= is exactly we are also saying in this draft(I mean draft-psarkar-rtgwg-rlf= a-node-protection-01).. If any destination takes the shortest-path segment = C…E that will not have node-protection using C as the PQ node, because C is going to forward the traffic to E any= how. In Table 2 we see that the path segment C->D->E is included in t= he shortest path from C to E and F. That is why in case of node-failure of = E, E and F cannot provide node-protection

 

According to the well-known last-hop problem, it = is obvious that if the destination (in the first case: node E) goes down, t= hen it cannot be protected. Moreover, since the example network topologyis = not 2-node-connected, it is obvious again that the node F, which can be accessed only via node E, then the fai= lure of node E infers that the node F can be never reached.

To (re)solve this issue, I suggest to use another= network (in the basic rLFA spec. as well), which could be the following (a= ll link costs are unit costs):

 

 

A----------B---------C

|        =   |       / |

|        =   |      /  |

|        =   |     /   |

F        =   G    /    H

|        =   |   /     |

|        =   |  /      |

|        =   | /       |

D----------E---------S

 

In this case, assuming that source node S wants t= o send a packet to node D, the next-hop of S is node E.

  - Link protecting case: If link(s,e) fails= , then P-space of node S regarding to the failed link, would consist of nod= e H,C,B and A, whilst the Q-space of D would consist all nodes except S and= H. In this case, the PQ-nodes, as the possible repair tunnel endpoints, are node A,B and C.

  - Node protecting case: However, if node E= itself fails, then the P-space of S would not alter, but the Q-space of D = would only contain node F and A resulting that only node A is present in th= e set of PQ-nodes.

[Pushpasis] Can = you elaborate on the method you used for deriving the PQ-nodes A and F here= … Seems to me like you are doing a RSPF rooted on destination D and t= hen pruning all links originating from E… I think Chris Bowers has already pointed on a different thread that while = best way to guarantee node-protection is to run a RSPF rooted on each desti= nation, we cannot afford to do so in reality… It will be much more fe= asible to run FSPF on fewer PQ-nodes as specified in our draft..

 

Also, the method= specified by our draft also finds A as the node-protecting PQ-node, becoz = the draft suggest to find the shortest-path from the PQ-nodes (C, B, and A)= to destination D. Only the SPF path from A does not go through E, so only A will provide node-protection for D= .

 

I think that this network also shows the differen= t between the node protection and link protection, but in a more comprehens= ive manner. And it also demonstrates the fact mentioned in Figure 2 that fo= r node-protecting rLFA, only the Q-spaces should be checked with those distance functions.

 

Moreover, if we assume that in the example networ= k above, there is a link (A,E) and node E itself failed again, than PQ-spac= e would be and empty set meaning that this case cannot be protected.

[Pushpasis] True= . Our draft will also pick A->E->D as the SPF from A to D in that cas= e and disqualify A as node-protecting PQ-node. In reality too there is no f= easible path in this case till A re-converges after learning E’s node-failure

 

Second, it would be better in the draft if the qu= estions about "how difficult or impossible to obtain those distances&q= uot; would be clearly stated in a bullet point list:

For example:

  - Q-space can be obtained by rSPF calculat= ed at destination node D

  - P-space can be obtained through SPF calc= ulation at source node S and its 1-hop neighbor.

  - SPF at a PQ-node is impossible or if not= what extensions should be implemented (actually, IMHO, this is the one, wh= ich is not clear enough)

[Pushpasis] The = first two should really be addressed in the original RLFA draft. Chris has = already written to the authors on this mailing list with suggesting text fo= r the draft. The third one is no different than standard SPF we need for RFC5286 implementation.. only difference bei= ng that it is rooted on PQ-nodes  in case of RLFA… It is up to i= ndividual implementations to come up with ways to constraint those to a lim= it.

 

Third, according to the Targeted-LDP discussion, = which is about the fact that if some node do not support TLDP, then how can= be the inner MPLS label obtained from the PQ-node; I think that if we want= remote LFA protection then the nodes MUST implement/support this feature, because without this the protection c= annot be guaranteed. For me, it is similar to a hypothetic case for example= of Not-via, where if the router do not support Not-via, then it cannot be = used. Or isn't it so simple?

[Pushpasis] Agai= n this is more related to original RLFA draft. I will prefer the correspond= ing authors to address this point J<= span style=3D"color:#0070C0">

 

Please comment my observations, in order to help = me and may others as well to understand every aspects and little pieces of = remote LFA specifications.

 

Best Regards,

Levente Csikor

 

 

--_000_0560d0a67fcc4af688176a280f9bdf3fBN1PR05MB520namprd05pro_-- From csikor@tmit.bme.hu Wed Oct 9 04:47:19 2013 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 2DEC911E8184 for ; Wed, 9 Oct 2013 04:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vow0W0912SAq for ; Wed, 9 Oct 2013 04:47:13 -0700 (PDT) Received: from ruby.tmit.bme.hu (ruby.tmit.bme.hu [152.66.245.193]) by ietfa.amsl.com (Postfix) with ESMTP id E4B7711E8177 for ; Wed, 9 Oct 2013 04:47:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ruby.tmit.bme.hu (Postfix) with ESMTP id 73CE787346; Wed, 9 Oct 2013 13:46:59 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at tmit.bme.hu Received: from ruby.tmit.bme.hu ([127.0.0.1]) by localhost (ruby.tmit.bme.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oho-SrxlzOQu; Wed, 9 Oct 2013 13:46:33 +0200 (CEST) Received: from anyo.tmit.bme.hu (anyo.tmit.bme.hu [152.66.246.7]) by ruby.tmit.bme.hu (Postfix) with ESMTP id A814187345; Wed, 9 Oct 2013 13:46:32 +0200 (CEST) Received: from [152.66.244.179] (csikor.tmit.bme.hu [152.66.244.179]) (authenticated bits=0) by anyo.tmit.bme.hu (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r99Bkdfp019873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Oct 2013 13:46:39 +0200 Message-ID: <5255421C.2010101@tmit.bme.hu> Date: Wed, 09 Oct 2013 13:46:36 +0200 From: Levente Csikor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Pushpasis Sarkar Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt References: <52551411.6080503@tmit.bme.hu> <0560d0a67fcc4af688176a280f9bdf3f@BN1PR05MB520.namprd05.prod.outlook.com> In-Reply-To: <0560d0a67fcc4af688176a280f9bdf3f@BN1PR05MB520.namprd05.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------030508090108040300060409" 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, 09 Oct 2013 11:47:19 -0000 This is a multi-part message in MIME format. --------------030508090108040300060409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear Pushpasis, thanks for your comments. For reactions see mine inline: On 10/09/2013 12:49 PM, Pushpasis Sarkar wrote: > > Hi Levente, > > Please find few comments inline... > > Thanks > > -Pushpasis > > -----Original Message----- > From: Levente Csikor [mailto:csikor@tmit.bme.hu] > Sent: Wednesday, October 09, 2013 2:00 PM > To: rtgwg@ietf.org > Subject: Re: Request for review - > draft-psarkar-rtgwg-rlfa-node-protection-01.txt > > Dear All, > > I also support to work more on the node protection draft first, before > merging it with "basic rLFA spec", because of various reasons: > > First, I think it would be almost a good approach to show how > node-protecting remote LFA works on the same, or almost the same > sample network topology used in the basic rLFA spec., but for easier > and more comprehensive understanding, a bit more complex but still > simple example should be given. IMHO, in the basic rLFA spec. it is a > bit confusing that node E is considered as a destination and this node > is the next-hop as well, since the important parts of the different > roles are not dissevering enough. Because of this, the similar example > in node prot spec. is also not straightforward: > > *[Pushpasis] If you see Table 1,2, and 3 in > draft-psarkar-rtgwg-rlfa-node-protection-01 we have specified the > destinations E, F (and their corresponding RLFA backup paths > explicitly), that will be affected by node-failure of E. Also the > destination G has been included which will still be reachable in the > case of node-failure of E. Perhaps basic RLFA spec can also include > such kind of illustrations* > **Yeah, I know and there is also the entry in the back-up path column for G, but here, I wanted to emphasized that the connectedness of the network does not remain any other opportunities to be considered. In other words, if there were an additional node between F and G, say H, and nodes E-D-G-H-F would also form a 5-cycle, then all your claims will remain valid, since C's shortest path to F won't avoid the failed node E, but the graph-topological requirements would be not so confusing (maybe only for me :) , but when I analyze a network to calculate the rLFA protection coverage, then I always assume this basic graph topological property to easily derive the level of protection (in percent, for example) of the possible attainable 100%). > > ** > > "In the event of the node-failure on primary nexthop E, the alternate > path from Remote-LFA nexthop C to E and F also becomes unavailable." > > *[Pushpasis] That is exactly we are also saying in this draft(I mean > draft-psarkar-rtgwg-rlfa-node-protection-01).. If any destination > takes the shortest-path segment C...E that will not have > node-protection using C as the PQ node, because C is going to forward > the traffic to E anyhow. In Table 2 we see that the path segment > C->D->E is included in the shortest path from C to E and F. That is > why in case of node-failure of E, E and F cannot provide node-protection* > **It was a quote from the draft, so it is really the fact that you are saying :) > > According to the well-known last-hop problem, it is obvious that if > the destination (in the first case: node E) goes down, then it cannot > be protected. Moreover, since the example network topologyis not > 2-node-connected, it is obvious again that the node F, which can be > accessed only via node E, then the failure of node E infers that the > node F can be never reached. > > To (re)solve this issue, I suggest to use another network (in the > basic rLFA spec. as well), which could be the following (all link > costs are unit costs): > > A----------B---------C > > | | / | > > | | / | > > | | / | > > F G / H > > | | / | > > | | / | > > | | / | > > D----------E---------S > > In this case, assuming that source node S wants to send a packet to > node D, the next-hop of S is node E. > > - Link protecting case: If link(s,e) fails, then P-space of node S > regarding to the failed link, would consist of node H,C,B and A, > whilst the Q-space of D would consist all nodes except S and H. In > this case, the PQ-nodes, as the possible repair tunnel endpoints, are > node A,B and C. > > - Node protecting case: However, if node E itself fails, then the > P-space of S would not alter, but the Q-space of D would only contain > node F and A resulting that only node A is present in the set of PQ-nodes. > > *[Pushpasis] Can you elaborate on the method you used for deriving the > PQ-nodes A and F here... Seems to me like you are doing a RSPF rooted > on destination D and then pruning all links originating from E... I > think Chris Bowers has already pointed on a different thread that > while best way to guarantee node-protection is to run a RSPF rooted on > each destination, we cannot afford to do so in reality... It will be > much more feasible to run FSPF on fewer PQ-nodes as specified in our > draft..* > **I did not consider any possible way of determining PQ-nodes, only used the description of P and Q spaces from the original draft, and from my research on this topic, where every kind of spaces were defined in cost terms to easily analyze the network theoretically. > > ** > > ** > > *Also, the method specified by our draft also finds A as the > node-protecting PQ-node, becoz the draft suggest to find the > shortest-path from the PQ-nodes (C, B, and A) to destination D. Only > the SPF path from A does not go through E, so only A will provide > node-protection for D.* > > I think that this network also shows the different between the node > protection and link protection, but in a more comprehensive manner. > And it also demonstrates the fact mentioned in Figure 2 that for > node-protecting rLFA, only the Q-spaces should be checked with those > distance functions. > > Moreover, if we assume that in the example network above, there is a > link (A,E) and node E itself failed again, than PQ-space would be and > empty set meaning that this case cannot be protected. > > *[Pushpasis] True. Our draft will also pick A->E->D as the SPF from A > to D in that case and disqualify A as node-protecting PQ-node. In > reality too there is no feasible path in this case till A re-converges > after learning E's node-failure* > **I know that it is true, I just wanted to say that by this network, the case of absence of node protection could be demonstrated easily assuming that the main example was the network described above. > > Second, it would be better in the draft if the questions about "how > difficult or impossible to obtain those distances" would be clearly > stated in a bullet point list: > > For example: > > - Q-space can be obtained by rSPF calculated at destination node D > > - P-space can be obtained through SPF calculation at source node S > and its 1-hop neighbor. > > - SPF at a PQ-node is impossible or if not what extensions should be > implemented (actually, IMHO, this is the one, which is not clear enough) > > *[Pushpasis] The first two should really be addressed in the original > RLFA draft. Chris has already written to the authors on this mailing > list with suggesting text for the draft. The third one is no different > than standard SPF we need for RFC5286 implementation.. only difference > being that it is rooted on PQ-nodes in case of RLFA... It is up to > individual implementations to come up with ways to constraint those to > a limit. * > **Thanks > > Third, according to the Targeted-LDP discussion, which is about the > fact that if some node do not support TLDP, then how can be the inner > MPLS label obtained from the PQ-node; I think that if we want remote > LFA protection then the nodes MUST implement/support this feature, > because without this the protection cannot be guaranteed. For me, it > is similar to a hypothetic case for example of Not-via, where if the > router do not support Not-via, then it cannot be used. Or isn't it so > simple? > > *[Pushpasis] Again this is more related to original RLFA draft. I will > prefer the corresponding authors to address this point **J* > **Thanks > > ** > > Please comment my observations, in order to help me and may others as > well to understand every aspects and little pieces of remote LFA > specifications. > > Best Regards, > > Levente Csikor > Thanks, Levente Csikor --------------030508090108040300060409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Pushpasis,
thanks for your comments.
For reactions see mine inline:
On 10/09/2013 12:49 PM, Pushpasis Sarkar wrote:

Hi Levente,

 

Please find few comments inline... 

 

Thanks

-Pushpasis

 

-----Original Message-----
From: Levente Csikor [mailto:csikor@tmit.bme.hu]
Sent: Wednesday, October 09, 2013 2:00 PM
To: rtgwg@ietf.org
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt

 

Dear All,

I also support to work more on the node protection draft first, before merging it with "basic rLFA spec", because of various reasons:

 

First, I think it would be almost a good approach to show how node-protecting remote LFA works on the same, or almost the same sample network topology used in the basic rLFA spec., but for easier and more comprehensive understanding, a bit more complex but still simple example should be given. IMHO, in the basic rLFA spec. it is a bit confusing that node E is considered as a destination and this node is the next-hop as well, since the important parts of the different roles are not dissevering enough. Because of this, the similar example in node prot spec. is also not straightforward:

[Pushpasis] If you see Table 1,2, and 3 in draft-psarkar-rtgwg-rlfa-node-protection-01 we have specified the destinations E, F (and their corresponding RLFA backup paths explicitly), that will be affected by node-failure of E. Also the destination G has been included which will still be reachable in the case of node-failure of E. Perhaps basic RLFA spec can also include such kind of illustrations

    Yeah, I know and there is also the entry in the back-up path column for G, but here, I wanted to emphasized that the connectedness of the network does not remain any other opportunities to be considered.
In other words, if there were an additional node between F and G, say H, and nodes E-D-G-H-F would also form a 5-cycle, then all your claims will remain valid, since C's shortest path to F won't avoid the failed node E, but the graph-topological requirements would be not so confusing (maybe only for me :) , but when I analyze a network to calculate the rLFA protection coverage, then I always assume this basic graph topological property to easily derive the level of protection (in percent, for example) of the possible attainable 100%).

 

"In the event of the node-failure on primary nexthop E, the alternate path from Remote-LFA nexthop C to E and F also becomes unavailable."

[Pushpasis] That is exactly we are also saying in this draft(I mean draft-psarkar-rtgwg-rlfa-node-protection-01).. If any destination takes the shortest-path segment C…E that will not have node-protection using C as the PQ node, because C is going to forward the traffic to E anyhow. In Table 2 we see that the path segment C->D->E is included in the shortest path from C to E and F. That is why in case of node-failure of E, E and F cannot provide node-protection

    It was a quote from the draft, so it is really the fact that you are saying :)

 

According to the well-known last-hop problem, it is obvious that if the destination (in the first case: node E) goes down, then it cannot be protected. Moreover, since the example network topologyis not 2-node-connected, it is obvious again that the node F, which can be accessed only via node E, then the failure of node E infers that the node F can be never reached.

To (re)solve this issue, I suggest to use another network (in the basic rLFA spec. as well), which could be the following (all link costs are unit costs):

 

 

A----------B---------C

|          |       / |

|          |      /  |

|          |     /   |

F          G    /    H

|          |   /     |

|          |  /      |

|          | /       |

D----------E---------S

 

In this case, assuming that source node S wants to send a packet to node D, the next-hop of S is node E.

  - Link protecting case: If link(s,e) fails, then P-space of node S regarding to the failed link, would consist of node H,C,B and A, whilst the Q-space of D would consist all nodes except S and H. In this case, the PQ-nodes, as the possible repair tunnel endpoints, are node A,B and C.

  - Node protecting case: However, if node E itself fails, then the P-space of S would not alter, but the Q-space of D would only contain node F and A resulting that only node A is present in the set of PQ-nodes.

[Pushpasis] Can you elaborate on the method you used for deriving the PQ-nodes A and F here… Seems to me like you are doing a RSPF rooted on destination D and then pruning all links originating from E… I think Chris Bowers has already pointed on a different thread that while best way to guarantee node-protection is to run a RSPF rooted on each destination, we cannot afford to do so in reality… It will be much more feasible to run FSPF on fewer PQ-nodes as specified in our draft..

    I did not consider any possible way of determining PQ-nodes, only used the description of P and Q spaces from the original draft, and from my research on this topic, where every kind of spaces were defined in cost terms to easily analyze the network theoretically.

 

Also, the method specified by our draft also finds A as the node-protecting PQ-node, becoz the draft suggest to find the shortest-path from the PQ-nodes (C, B, and A) to destination D. Only the SPF path from A does not go through E, so only A will provide node-protection for D.

 

I think that this network also shows the different between the node protection and link protection, but in a more comprehensive manner. And it also demonstrates the fact mentioned in Figure 2 that for node-protecting rLFA, only the Q-spaces should be checked with those distance functions.

 

Moreover, if we assume that in the example network above, there is a link (A,E) and node E itself failed again, than PQ-space would be and empty set meaning that this case cannot be protected.

[Pushpasis] True. Our draft will also pick A->E->D as the SPF from A to D in that case and disqualify A as node-protecting PQ-node. In reality too there is no feasible path in this case till A re-converges after learning E’s node-failure

    I know that it is true, I just wanted to say that by this network, the case of absence of node protection could be demonstrated easily assuming that the main example was the network described above.

 

Second, it would be better in the draft if the questions about "how difficult or impossible to obtain those distances" would be clearly stated in a bullet point list:

For example:

  - Q-space can be obtained by rSPF calculated at destination node D

  - P-space can be obtained through SPF calculation at source node S and its 1-hop neighbor.

  - SPF at a PQ-node is impossible or if not what extensions should be implemented (actually, IMHO, this is the one, which is not clear enough)

[Pushpasis] The first two should really be addressed in the original RLFA draft. Chris has already written to the authors on this mailing list with suggesting text for the draft. The third one is no different than standard SPF we need for RFC5286 implementation.. only difference being that it is rooted on PQ-nodes  in case of RLFA… It is up to individual implementations to come up with ways to constraint those to a limit.

    Thanks

 

Third, according to the Targeted-LDP discussion, which is about the fact that if some node do not support TLDP, then how can be the inner MPLS label obtained from the PQ-node; I think that if we want remote LFA protection then the nodes MUST implement/support this feature, because without this the protection cannot be guaranteed. For me, it is similar to a hypothetic case for example of Not-via, where if the router do not support Not-via, then it cannot be used. Or isn't it so simple?

[Pushpasis] Again this is more related to original RLFA draft. I will prefer the corresponding authors to address this point J

    Thanks

 

Please comment my observations, in order to help me and may others as well to understand every aspects and little pieces of remote LFA specifications.

 

Best Regards,

Levente Csikor

 

 


Thanks,

Levente Csikor


--------------030508090108040300060409-- From andrew.g.malis@verizon.com Wed Oct 9 05:53:19 2013 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 9927C21E8083 for ; Wed, 9 Oct 2013 05:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvn84CDLwaa8 for ; Wed, 9 Oct 2013 05:53:14 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD7911E8178 for ; Wed, 9 Oct 2013 05:53:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by omzsmtpe03.verizonbusiness.com with ESMTP; 09 Oct 2013 12:53:09 +0000 From: "Malis, Andrew G (Andy)" X-IronPort-AV: E=Sophos;i="4.90,1063,1371081600"; d="scan'208";a="565026385" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi02.verizon.com with ESMTP; 09 Oct 2013 12:53:09 +0000 Received: from fhdp1lumxc7v22.us.one.verizon.com ([169.254.2.214]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Wed, 9 Oct 2013 08:53:09 -0400 To: "curtis@ipv6.occnc.com" , "rtgwg@ietf.org" Date: Wed, 9 Oct 2013 08:53:07 -0400 Subject: Re: draft-ietf-rtgwg-cl-requirement preview of -12 version Thread-Topic: draft-ietf-rtgwg-cl-requirement preview of -12 version Thread-Index: Ac7E7oGEKAIoxarvQra/rC3wibtb1Q== Message-ID: In-Reply-To: <201310090319.r993Jp6g001256@gateway1.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: cl-req authors , "Malis, Andrew G \(Andy\)" 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, 09 Oct 2013 12:53:19 -0000 Curtis, OK, I'll admit to being confused. The current revision is -11. However, the first of your two preview files says draft-ietf-rtgwg-cl-requirement-11-preview1 at the top. So it is an old preview of 11? A halfway point to -12? And why two previews? Thanks, Andy On 10/8/2013 23:19 , "Curtis Villamizar" wrote: RTGWG, Two preview versions were created to make it easier to see differences. draft-ietf-rtgwg-cl-requirement-12-preview1 This first preview contains no edits except to rearrange the set of paragraphs and bullets and create new sections. The section naming is not quite as suggested below. The prior subsection 3.3 is broken into these three subsections. 3.3. Component Links with Different Characteristics 3.4. Considerations for Bidirectional Client LSP 3.5. Multipath Load Balancing Dynamics Note that the old FR#10 was deleted as noted below, being deemed as redundant if the old FR#17 and FR#18 mention meeting Performance Objectives. draft-ietf-rtgwg-cl-requirement-12-preview2 In this preview none of the requirements are reordered. Instead, the contents of the bullets and paragraphs are edited. The edits are mostly as described below. Additional edits are: 1. s/ITU/ITU-T/ in a few places. (request by Loa) 2. The document has been spell checked. 3. Wording in one paragraph in the intro section had to be changed to reflect the section renaming. It was improved a bit. 4. s/1 ms/1 msec/ 5. Added paragraph(s) before the list of requirements in each of the new subsections to indicate the purpose of the set of requirements. Added paragraph(s) after the list of requirements with discussion, generally providing caveats. These new paragraphs are generally in line with discussion below but were not explicitly cited as changes below. 6. The requirement now numbered FR#15 was reworded. OLD The solution SHALL provide a means that communicates whether the flows within an client LSP can be split across multiple component links. The solution SHOULD provide a means to indicate the flow identification field(s) which can be used along the flow path which can be used to perform this function. NEW The solution SHALL provide a means that indicates whether any of the flows within an client LSP MUST NOT be split across multiple component links. The sense is reversed (identify those sensitive to load balancing rather than those insensitive to it). The entire client LSP is treated the same (either balanced or not). Signaling enhancement to identify flows within the client LSP is no longer called for. 7. FR#16 refers to "prior requirements in Section 3.3" rather than just "prior requirements". 8. s/nodes (or sites)/nodes/ (only occurance of sites) 9. s/bounded by a configured value/bounded by a specific value/ (it could be signaled or configured, decide in the framework) 10. In FR#21, the reminder of the definition of "flows" is removed (not needed). 11. First paragraph in renamed section "General Requirements for Protocol Solutions" is edited to reflect the discussion below regarding the renaming. Other changes described in detail below were made. Both versions are available at these URLs. http://www.occnc.com/draft-ietf-rtgwg-cl-requirement-12-preview1.txt http://www.occnc.com/draft-ietf-rtgwg-cl-requirement-12-preview2.txt The two versions can be diffed using the IETF diff tool. Either go to the URL http://tools.ietf.org/rfcdiff and type in the two URLs above or paste in the following (eliminating white space, making one line). http://tools.ietf.org/rfcdiff ?url1=3Dhttp://www.occnc.com/draft-ietf-rtgwg-cl-requirement-12-preview1.tx= t &url2=3Dhttp://www.occnc.com/draft-ietf-rtgwg-cl-requirement-12-preview2.tx= t It is also possible to diff the -11 version and either preview version with this tool, but due to the reordering of requirements and new sections, this diff doesn't work well. Using the diff tool on the two preview versions is a good way to see only the changes that were made. Please also reread the document. This is a WG doc and RTGWG should be providing the AD and IESG with a high quality document. More review at this stage is better. Curtis ------- Forwarded Message Return-Path: rtgwg-bounces@ietf.org Delivery-Date: Mon Oct 7 17:38:25 2013 Return-Path: Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) by harbor1.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id r97LcPEG091= 422 for ; Mon, 7 Oct 2013 17:38:25 -0400= (EDT) (envelope-from rtgwg-bounces@ietf.org) Received: (from curtis@localhost) by harbor1.ipv6.occnc.com (8.14.5/8.14.5/Submit) id r97LcPpU091420 for curtis; Mon, 7 Oct 2013 17:38:25 -0400 (EDT) (envelope-from rtgwg-bounces@ietf.org) Received: from maildrop0.ipv6.occnc.com [2001:470:1f07:1545::2:830] by harbor1.ipv6.occnc.com with IMAP (fetchmail-6.3.21) for (single-drop); Mon, 07 Oct 2013 17:38:25 -04= 00 (EDT) Received: from deliver ([unix socket]) by maildrop0.ipv6.occnc.com (Cyrus v2.4.16) with LMTPA; Mon, 07 Oct 2013 14:09:44 -0400 X-Sieve: CMU Sieve 2.4 Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:123a::1:1e]) by maildrop0.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id r97I9dQ70= 87297 for ; Mon, 7 Oct 2013 14:09:44 -0400 (EDT) (envelope-from rtgwg-bounces@ietf.org) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA1E21E80BA; Mon, 7 Oct 2013 11:09:33 -0700 (PDT) DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/simple; d=3Dietf.org; s= =3Dietf1; t=3D1381169373; bh=3Dpz9B3Q/VoFV3XJrB1+4MiatTdgEQFiAYrq9GfGqAq18=3D= ; h=3DMessage-Id:To:From:Subject:In-reply-to:Date:Cc:Reply-To:List-Id= : List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=3DR4sRGOfdY4RZS8CamMpIrLP81JBgUfayzhrTkK/rdqCa9U/FBFYCyRO4q1t6qiE= fA G+n3aAwAA3icSJVXnTduUDbkI+NNZQt5Unh1YRqxIY2M6qkBY/7x5FG1o5k7xhe0Ou qshOUJJVhwcATdqXTyN/I4jf1xyNY5kalDlhy9K0=3D 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 7240621E81B2 for ; Mon, 7 Oct 2013 11:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Score: -0.495 X-Spam-Level: Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjwLNrLPIpfn for ; Mon, 7 Oct 2013 11:09:17 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 550C911E8102 for ; Mon, 7 Oct 2013 11:09:13 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=3D0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r97I6eeV070034; Mon, 7 Oct 2013 14:06:40 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201310071806.r97I6eeV070034@gateway1.orleans.occnc.com> To: Alia Atlas From: Curtis Villamizar Subject: Re: WG Last Call for draft-ietf-rtgwg-cl-requirement-11 In-reply-to: Your message of "Tue, 01 Oct 2013 17:38:14 EDT." Date: Mon, 07 Oct 2013 14:06:39 -0400 Cc: "draft-ietf-rtgwg-cl-requirement@tools.ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset=3D"us-ascii" Content-Transfer-Encoding: 7bit Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org In message Alia Atlas writes: > This second WG Last Call got absolutely no comments. Does this group > of generally opinionated and thoughtful people truly have nothing to > say? > > If so and given the previous WGLC succeeded, then on Oct 9, I will > take silence as consent and indicate that on the draft shepherd's > write-up... > > Alia Alia, et al. Silence could mean lots of people read the document and could see no way to further improve it. I doubt that is the case. Silence could also mean that the document has been around for so long that people are tired or reading it and haven't bothered to read it again. More likely IMHO. It isn't clear (to me) in the above email if you were extending WGLC until Oct 9. As co-author, I wanted to give others a chance to comment first during WGLC and they have had plenty of time to do so. Given that there are multiple co-authors, there has been some compromise in the document. While combining contributions, there was some tendency to "go along to keep moving forward". That can be bad if there are too few critical reviewers outside the set of co-authors. With co-author hat off, I reread the document and here are my personal review comments. If there is agreement to make changes, I will put co-author hat back on and make these edits. If there is dissenting discussion, I'll edit as best as I can judge consensus and we can disuss at IETF-88 if we need to. If there is silence, I'll let Alia and Alvaro interpret the silence. (full agreement with all changes? lack of interest?) This *is* a WG doc, so WG please speak up. Curtis - ---------------------------------------- General Comments (See specific instances of each in detailed comments): The section naming and grouping of requirements could stand some improvement. Some of the requirement wording are awkwardly worded. A few sentences border on meaningless. Some of the requirements are infeasible as worded. Most can be made feasible by replacing "flows or group of flows" with "client LSP". The following paragraph in the introduction gives a hint as to why these are feasible for client LSP but not flows: The ingress and egress of a multipath may be midpoint LSRs with respect to a given client LSP. A midpoint LSR does not participate in the signaling of any clients of the client LSP. Therefore, in general, multipath endpoints cannot determine requirements of clients of a client LSP through participation in the signaling of the clients of the client LSP. One requirement (bidirectional placement on components) is infeasible for flows and infeasible for all but small client LSP that fit into a single compoent link. The framework points this out. Specific Comments: wording: s/no significantly exceed/not significantly exceed/ FR#4 contains one awkward excessively wordy sentence followed by one that I struggle to find any meaning in if I didn't already know what the intent was. It may also be better to replace "path for a flow" with "set of paths for an LSP" and then specify the requirements for flows within that LSP. OLD FR#4 The solution SHALL provide a mechanism to select a path for a flow across a network that contains a number of paths comprised of pairs of nodes connected by advanced multipath in such a way as to automatically distribute the load over the network nodes connected by advanced multipaths while meeting all of the other mandatory requirements stated above. The solution SHOULD work in a manner similar to that of current networks without any advanced multipath protocol enhancements when the characteristics of the individual component links are advertised. NEW FR#4 The solution shall provide a mechanism to select a set of paths for an LSP across a network in such a way that flows within the LSP are distributed across the set of paths while meeting all of the other requirements stated above. The solution SHOULD work in a manner similar to existing multipath techniques except as necessary to accommodate advanced multipath requirements. I think these say pretty much the same thing, but with improved clarity in the new text. FR#10 and FR#11 are the following: FR#10 The solution SHALL provide a means to limit the latency to meet a Performance Objective target on a per flow basis or group of flow basis, where flows or groups of flows are identifiable in the forwarding plane and are signaled using in the control plane or set up using the management plane. The Performance Objectives differ across the services, and some services have different Performance Objectives for different QoS classes, for example, one QoS class may have a much larger latency bound than another. Overload can occur which would violate a Performance Objective parameter (e.g., loss) and some remedy to handle this case for an advanced multipath is required. FR#11 If the total demand offered by traffic flows exceeds the capacity of the advanced multipath, the solution SHOULD define a means to cause some traffic flows or groups of flows to move to some other point in the network that is not congested. These "preempted flows" may not be restored if there is no uncongested path in the network. FR#10 and FR#11 currently fall under the section "Component Links Provided by Lower Layer Networks" but have nothing to do with lower layer networks. These would fit better with the existing section named "Parallel Component Links with Different Characteristics" (though see comments below on rearranging that section). FR#10 may be redundant due to FR#17 and FR#18 which specify minimul latency and bounded latency. The first paragraph in FR#10 adds nothing to FR#17 and FR#18 except that the result should meet "a Performance Objective target". The second paragraph seems to be unrelated discussion and perhaps belongs in FR#11. If so, FR#10 can be eliminated possibly adding a statement about "a Performance Objective target" in FR#17 and FR#18, but preferably leaving them alone. FR#10 and FR#11 are infeasible if applied to "client LSP" rather than "flows or groups of flows" for reasons stated in General Comments above. (So are FR#17 and FR#18; see below). In FR#10 s/signaled using in the control plane/signaled using the control plane/ FR#11 needs to be about preemption of LSP, not preemption of flows. Since there is no signaling of flows, there is no prioritization of flows. There is OTOH diffserv, which will enforce prioritization, even among traffic within a microflow (AF service where some traffic is marked AFx2 or AFx3, aka yellow or red). In FR#11 s/traffic flows or groups of traffic flows/clent LSP/ makes the requirement feasible. In FR#11 s/some other point in the network/an alternate set of paths/ makes the requirement more clear. NEW FR#10 [Deleted] FR#11 If the total demand offered by traffic flows exceeds the capacity of the advanced multipath, the solution SHOULD define a means to cause some client LSP to move to an alternate set of paths that are not congested. These "preempted LSP" may not be restored if there is no uncongested path in the network. The title "Parallel Component Links with Different Characteristics" should be changed, dropping the word "Parallel". The requirements also apply to very diverse paths through a network with different characteristics. The set of requirements currently in "Component Links with Different Characteristics" are mostly of two types: 1. Load Balance Dynamics (FR#12-FR#15, FR#20-FR#23) 2. Requirements for Carrying Client LSP (FR#16-FR#19, FR#24). FR#22 and FR#23 could be in either category but apply more to dynamics of load balancing. It might be better to reorder these requirements and create two subsections. Both still do apply to "Component Links with Different Characteristics", but form two distinct subsets. In requirements FR#17-FR#19 s/a traffic flow/the traffic flows within a client LSP/ Signaling is applied to client LSP, not flows as mentioned in General Comments above. FR#24 is extremely problematic. The existing framework document indicates that there are significant feasibility issues associated with supporting this requirement for all but small client LSP and requiring a fallback to link bundling for these small cleint LSP. There has been no discussion supporting a feasible means to do this for large client LSP. Therefore it may be wise to either drop this requirement entirely or at the very least change it to a SHOULD. If the requirement is kept, perhaps a qualifier indicating "for small client LSP only (ones that fit on a single component)" is required. If link bundling is the solution, the requirement is a NOOP but the requirement may serve to indicate that link bundling must co-exist with hash based load balancing for a subset of LSP requiring that a both directions take the same component. If FR#24 is relaxed to say that both directions traverse the same set of nodes, then FR#24 becomes feasible for large client LSP. This would, for example, allow MPLS-TP OAM to function corrently for MPLS-TP LSP carried within client MPLS LSP. If this is desirable it should be a separate requirement. The section title "Derived Requirements" has irked a number of people. These requirements are distinct in that they reference protocols which would be used within a solution, but they are not truly "derived" from the "Functional Requirements" in the prior section. I prefer "General Requirements for Protocol Solutions". Therefore s/Derived Requirements/GeneralRequirements for Protocol Solutions/ s/DR/GR/ I suggest rewording DR#1 as follows: OLD DR#1 The solution SHOULD attempt to extend existing protocols wherever possible, developing a new protocol only if this adds a significant set of capabilities. NEW GR#1 The solution SHOULD extend existing protocols wherever possible, developing a new protocol only where doing so adds a significant set of capabilities. I dropped "attempt to". The solution SHOULD get it right. No E for Effort for trying but getting it wrong. :-) In DR#3, I'm not sure what the last sentence means as worded, though I think I know the intent. OLD Other functional requirements should be supported as independently of signaling protocol as possible. NEW Function requirements SHOULD, where possible, be supported in a manner that supports LDP signaled LSP, RSVP signaled LSP, and LSP set up using management plane mechanisms. Either the management section is perfect or I forgot to read it. :-) The Ack section should say that after some discussion Tom Yu suggested replacement text that was used as the basis for the security section. The Ack section should indicate that the document was renamed as a result of potential problems with terminology collision that were pointed out by Lou Berger in the RtgDir review. _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg ------- End of Forwarded Message From curtis@ipv6.occnc.com Wed Oct 9 06:29:56 2013 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 E238E21E811C for ; Wed, 9 Oct 2013 06:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcJ2PGeH83JF for ; Wed, 9 Oct 2013 06:29:53 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id B9CF421E8138 for ; Wed, 9 Oct 2013 06:29:44 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r99DSQIZ005519; Wed, 9 Oct 2013 09:28:26 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201310091328.r99DSQIZ005519@gateway1.orleans.occnc.com> To: "Malis, Andrew G (Andy)" From: Curtis Villamizar Subject: Re: draft-ietf-rtgwg-cl-requirement preview of -12 version In-reply-to: Your message of "Wed, 09 Oct 2013 08:53:07 EDT." Date: Wed, 09 Oct 2013 09:28:26 -0400 Cc: cl-req authors , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 13:29:57 -0000 Andy, The current is 11. I got the filenames 12-preview1 and 12-preview2 right but in the file 12-preview1 the document says 11-preview1. Please ignore that mistake. There are two previews because if anyone wants to see the differnces between the text before the changes and after the changes, diff would not work if the requirements text was both reordered and changed. The solution to make the diffs work is to first reorder the requirements text without changing the text and save that as preview1, then make the changes to the text and add any new text and save that as preview2. This is done only to make it easy for the reader to find the new text and find the changes to existing text. If there is no need for further change, 12-preview2 would be submitted as draft-ietf-rtgwg-cl-requirement-12 with a filename and date change. If there is need for change and a need for pre-submit review of changes, then there would be a 12-preview3 before submitting 12. Curtis In message "Malis, Andrew G (Andy)" writes: Curtis, OK, I'll admit to being confused. The current revision is -11. However, the first of your two preview files says draft-ietf-rtgwg-cl-requirement-11-preview1 at the top. So it is an old preview of 11? A halfway point to -12? And why two previews? Thanks, Andy On 10/8/2013 23:19 , "Curtis Villamizar" wrote: RTGWG, Two preview versions were created to make it easier to see differences. draft-ietf-rtgwg-cl-requirement-12-preview1 This first preview contains no edits except to rearrange the set of paragraphs and bullets and create new sections. The section naming is not quite as suggested below. The prior subsection 3.3 is broken into these three subsections. 3.3. Component Links with Different Characteristics 3.4. Considerations for Bidirectional Client LSP 3.5. Multipath Load Balancing Dynamics Note that the old FR#10 was deleted as noted below, being deemed as redundant if the old FR#17 and FR#18 mention meeting Performance Objectives. draft-ietf-rtgwg-cl-requirement-12-preview2 In this preview none of the requirements are reordered. Instead, the contents of the bullets and paragraphs are edited. The edits are mostly as described below. Additional edits are: 1. s/ITU/ITU-T/ in a few places. (request by Loa) 2. The document has been spell checked. 3. Wording in one paragraph in the intro section had to be changed to reflect the section renaming. It was improved a bit. 4. s/1 ms/1 msec/ 5. Added paragraph(s) before the list of requirements in each of the new subsections to indicate the purpose of the set of requirements. Added paragraph(s) after the list of requirements with discussion, generally providing caveats. These new paragraphs are generally in line with discussion below but were not explicitly cited as changes below. 6. The requirement now numbered FR#15 was reworded. OLD The solution SHALL provide a means that communicates whether the flows within an client LSP can be split across multiple component links. The solution SHOULD provide a means to indicate the flow identification field(s) which can be used along the flow path which can be used to perform this function. NEW The solution SHALL provide a means that indicates whether any of the flows within an client LSP MUST NOT be split across multiple component links. The sense is reversed (identify those sensitive to load balancing rather than those insensitive to it). The entire client LSP is treated the same (either balanced or not). Signaling enhancement to identify flows within the client LSP is no longer called for. 7. FR#16 refers to "prior requirements in Section 3.3" rather than just "prior requirements". 8. s/nodes (or sites)/nodes/ (only occurance of sites) 9. s/bounded by a configured value/bounded by a specific value/ (it could be signaled or configured, decide in the framework) 10. In FR#21, the reminder of the definition of "flows" is removed (not needed). 11. First paragraph in renamed section "General Requirements for Protocol Solutions" is edited to reflect the discussion below regarding the renaming. Other changes described in detail below were made. Both versions are available at these URLs. http://www.occnc.com/draft-ietf-rtgwg-cl-requirement-12-preview1.txt http://www.occnc.com/draft-ietf-rtgwg-cl-requirement-12-preview2.txt The two versions can be diffed using the IETF diff tool. Either go to the URL http://tools.ietf.org/rfcdiff and type in the two URLs above or paste in the following (eliminating white space, making one line). http://tools.ietf.org/rfcdiff ?url1=http://www.occnc.com/draft-ietf-rtgwg-cl-requirement-12-preview1.txt &url2=http://www.occnc.com/draft-ietf-rtgwg-cl-requirement-12-preview2.txt It is also possible to diff the -11 version and either preview version with this tool, but due to the reordering of requirements and new sections, this diff doesn't work well. Using the diff tool on the two preview versions is a good way to see only the changes that were made. Please also reread the document. This is a WG doc and RTGWG should be providing the AD and IESG with a high quality document. More review at this stage is better. Curtis ------- Forwarded Message Return-Path: rtgwg-bounces@ietf.org Delivery-Date: Mon Oct 7 17:38:25 2013 Return-Path: Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) by harbor1.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id r97LcPEG091422 for ; Mon, 7 Oct 2013 17:38:25 -0400 (EDT) (envelope-from rtgwg-bounces@ietf.org) Received: (from curtis@localhost) by harbor1.ipv6.occnc.com (8.14.5/8.14.5/Submit) id r97LcPpU091420 for curtis; Mon, 7 Oct 2013 17:38:25 -0400 (EDT) (envelope-from rtgwg-bounces@ietf.org) Received: from maildrop0.ipv6.occnc.com [2001:470:1f07:1545::2:830] by harbor1.ipv6.occnc.com with IMAP (fetchmail-6.3.21) for (single-drop); Mon, 07 Oct 2013 17:38:25 -0400 (EDT) Received: from deliver ([unix socket]) by maildrop0.ipv6.occnc.com (Cyrus v2.4.16) with LMTPA; Mon, 07 Oct 2013 14:09:44 -0400 X-Sieve: CMU Sieve 2.4 Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:123a::1:1e]) by maildrop0.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id r97I9dQ7087297 for ; Mon, 7 Oct 2013 14:09:44 -0400 (EDT) (envelope-from rtgwg-bounces@ietf.org) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA1E21E80BA; Mon, 7 Oct 2013 11:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1381169373; bh=pz9B3Q/VoFV3XJrB1+4MiatTdgEQFiAYrq9GfGqAq18=; h=Message-Id:To:From:Subject:In-reply-to:Date:Cc:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=R4sRGOfdY4RZS8CamMpIrLP81JBgUfayzhrTkK/rdqCa9U/FBFYCyRO4q1t6qiEfA G+n3aAwAA3icSJVXnTduUDbkI+NNZQt5Unh1YRqxIY2M6qkBY/7x5FG1o5k7xhe0Ou qshOUJJVhwcATdqXTyN/I4jf1xyNY5kalDlhy9K0= 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 7240621E81B2 for ; Mon, 7 Oct 2013 11:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Score: -0.495 X-Spam-Level: Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjwLNrLPIpfn for ; Mon, 7 Oct 2013 11:09:17 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 550C911E8102 for ; Mon, 7 Oct 2013 11:09:13 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r97I6eeV070034; Mon, 7 Oct 2013 14:06:40 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201310071806.r97I6eeV070034@gateway1.orleans.occnc.com> To: Alia Atlas From: Curtis Villamizar Subject: Re: WG Last Call for draft-ietf-rtgwg-cl-requirement-11 In-reply-to: Your message of "Tue, 01 Oct 2013 17:38:14 EDT." Date: Mon, 07 Oct 2013 14:06:39 -0400 Cc: "draft-ietf-rtgwg-cl-requirement@tools.ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org In message Alia Atlas writes: > This second WG Last Call got absolutely no comments. Does this group > of generally opinionated and thoughtful people truly have nothing to > say? > > If so and given the previous WGLC succeeded, then on Oct 9, I will > take silence as consent and indicate that on the draft shepherd's > write-up... > > Alia Alia, et al. Silence could mean lots of people read the document and could see no way to further improve it. I doubt that is the case. Silence could also mean that the document has been around for so long that people are tired or reading it and haven't bothered to read it again. More likely IMHO. It isn't clear (to me) in the above email if you were extending WGLC until Oct 9. As co-author, I wanted to give others a chance to comment first during WGLC and they have had plenty of time to do so. Given that there are multiple co-authors, there has been some compromise in the document. While combining contributions, there was some tendency to "go along to keep moving forward". That can be bad if there are too few critical reviewers outside the set of co-authors. With co-author hat off, I reread the document and here are my personal review comments. If there is agreement to make changes, I will put co-author hat back on and make these edits. If there is dissenting discussion, I'll edit as best as I can judge consensus and we can disuss at IETF-88 if we need to. If there is silence, I'll let Alia and Alvaro interpret the silence. (full agreement with all changes? lack of interest?) This *is* a WG doc, so WG please speak up. Curtis - ---------------------------------------- General Comments (See specific instances of each in detailed comments): The section naming and grouping of requirements could stand some improvement. Some of the requirement wording are awkwardly worded. A few sentences border on meaningless. Some of the requirements are infeasible as worded. Most can be made feasible by replacing "flows or group of flows" with "client LSP". The following paragraph in the introduction gives a hint as to why these are feasible for client LSP but not flows: The ingress and egress of a multipath may be midpoint LSRs with respect to a given client LSP. A midpoint LSR does not participate in the signaling of any clients of the client LSP. Therefore, in general, multipath endpoints cannot determine requirements of clients of a client LSP through participation in the signaling of the clients of the client LSP. One requirement (bidirectional placement on components) is infeasible for flows and infeasible for all but small client LSP that fit into a single compoent link. The framework points this out. Specific Comments: wording: s/no significantly exceed/not significantly exceed/ FR#4 contains one awkward excessively wordy sentence followed by one that I struggle to find any meaning in if I didn't already know what the intent was. It may also be better to replace "path for a flow" with "set of paths for an LSP" and then specify the requirements for flows within that LSP. OLD FR#4 The solution SHALL provide a mechanism to select a path for a flow across a network that contains a number of paths comprised of pairs of nodes connected by advanced multipath in such a way as to automatically distribute the load over the network nodes connected by advanced multipaths while meeting all of the other mandatory requirements stated above. The solution SHOULD work in a manner similar to that of current networks without any advanced multipath protocol enhancements when the characteristics of the individual component links are advertised. NEW FR#4 The solution shall provide a mechanism to select a set of paths for an LSP across a network in such a way that flows within the LSP are distributed across the set of paths while meeting all of the other requirements stated above. The solution SHOULD work in a manner similar to existing multipath techniques except as necessary to accommodate advanced multipath requirements. I think these say pretty much the same thing, but with improved clarity in the new text. FR#10 and FR#11 are the following: FR#10 The solution SHALL provide a means to limit the latency to meet a Performance Objective target on a per flow basis or group of flow basis, where flows or groups of flows are identifiable in the forwarding plane and are signaled using in the control plane or set up using the management plane. The Performance Objectives differ across the services, and some services have different Performance Objectives for different QoS classes, for example, one QoS class may have a much larger latency bound than another. Overload can occur which would violate a Performance Objective parameter (e.g., loss) and some remedy to handle this case for an advanced multipath is required. FR#11 If the total demand offered by traffic flows exceeds the capacity of the advanced multipath, the solution SHOULD define a means to cause some traffic flows or groups of flows to move to some other point in the network that is not congested. These "preempted flows" may not be restored if there is no uncongested path in the network. FR#10 and FR#11 currently fall under the section "Component Links Provided by Lower Layer Networks" but have nothing to do with lower layer networks. These would fit better with the existing section named "Parallel Component Links with Different Characteristics" (though see comments below on rearranging that section). FR#10 may be redundant due to FR#17 and FR#18 which specify minimul latency and bounded latency. The first paragraph in FR#10 adds nothing to FR#17 and FR#18 except that the result should meet "a Performance Objective target". The second paragraph seems to be unrelated discussion and perhaps belongs in FR#11. If so, FR#10 can be eliminated possibly adding a statement about "a Performance Objective target" in FR#17 and FR#18, but preferably leaving them alone. FR#10 and FR#11 are infeasible if applied to "client LSP" rather than "flows or groups of flows" for reasons stated in General Comments above. (So are FR#17 and FR#18; see below). In FR#10 s/signaled using in the control plane/signaled using the control plane/ FR#11 needs to be about preemption of LSP, not preemption of flows. Since there is no signaling of flows, there is no prioritization of flows. There is OTOH diffserv, which will enforce prioritization, even among traffic within a microflow (AF service where some traffic is marked AFx2 or AFx3, aka yellow or red). In FR#11 s/traffic flows or groups of traffic flows/clent LSP/ makes the requirement feasible. In FR#11 s/some other point in the network/an alternate set of paths/ makes the requirement more clear. NEW FR#10 [Deleted] FR#11 If the total demand offered by traffic flows exceeds the capacity of the advanced multipath, the solution SHOULD define a means to cause some client LSP to move to an alternate set of paths that are not congested. These "preempted LSP" may not be restored if there is no uncongested path in the network. The title "Parallel Component Links with Different Characteristics" should be changed, dropping the word "Parallel". The requirements also apply to very diverse paths through a network with different characteristics. The set of requirements currently in "Component Links with Different Characteristics" are mostly of two types: 1. Load Balance Dynamics (FR#12-FR#15, FR#20-FR#23) 2. Requirements for Carrying Client LSP (FR#16-FR#19, FR#24). FR#22 and FR#23 could be in either category but apply more to dynamics of load balancing. It might be better to reorder these requirements and create two subsections. Both still do apply to "Component Links with Different Characteristics", but form two distinct subsets. In requirements FR#17-FR#19 s/a traffic flow/the traffic flows within a client LSP/ Signaling is applied to client LSP, not flows as mentioned in General Comments above. FR#24 is extremely problematic. The existing framework document indicates that there are significant feasibility issues associated with supporting this requirement for all but small client LSP and requiring a fallback to link bundling for these small cleint LSP. There has been no discussion supporting a feasible means to do this for large client LSP. Therefore it may be wise to either drop this requirement entirely or at the very least change it to a SHOULD. If the requirement is kept, perhaps a qualifier indicating "for small client LSP only (ones that fit on a single component)" is required. If link bundling is the solution, the requirement is a NOOP but the requirement may serve to indicate that link bundling must co-exist with hash based load balancing for a subset of LSP requiring that a both directions take the same component. If FR#24 is relaxed to say that both directions traverse the same set of nodes, then FR#24 becomes feasible for large client LSP. This would, for example, allow MPLS-TP OAM to function corrently for MPLS-TP LSP carried within client MPLS LSP. If this is desirable it should be a separate requirement. The section title "Derived Requirements" has irked a number of people. These requirements are distinct in that they reference protocols which would be used within a solution, but they are not truly "derived" from the "Functional Requirements" in the prior section. I prefer "General Requirements for Protocol Solutions". Therefore s/Derived Requirements/GeneralRequirements for Protocol Solutions/ s/DR/GR/ I suggest rewording DR#1 as follows: OLD DR#1 The solution SHOULD attempt to extend existing protocols wherever possible, developing a new protocol only if this adds a significant set of capabilities. NEW GR#1 The solution SHOULD extend existing protocols wherever possible, developing a new protocol only where doing so adds a significant set of capabilities. I dropped "attempt to". The solution SHOULD get it right. No E for Effort for trying but getting it wrong. :-) In DR#3, I'm not sure what the last sentence means as worded, though I think I know the intent. OLD Other functional requirements should be supported as independently of signaling protocol as possible. NEW Function requirements SHOULD, where possible, be supported in a manner that supports LDP signaled LSP, RSVP signaled LSP, and LSP set up using management plane mechanisms. Either the management section is perfect or I forgot to read it. :-) The Ack section should say that after some discussion Tom Yu suggested replacement text that was used as the basis for the security section. The Ack section should indicate that the document was renamed as a result of potential problems with terminology collision that were pointed out by Lou Berger in the RtgDir review. _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg ------- End of Forwarded Message From gabor.sandor.enyedi@ericsson.com Wed Oct 9 07:26:31 2013 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 7804A11E8198 for ; Wed, 9 Oct 2013 07:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejc5cetlaEts for ; Wed, 9 Oct 2013 07:26:20 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D158521E808A for ; Wed, 9 Oct 2013 07:25:28 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-59-52556751752a Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 6D.8B.16099.15765525; Wed, 9 Oct 2013 16:25:21 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.84]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0328.009; Wed, 9 Oct 2013 16:25:21 +0200 From: =?iso-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= To: IJsbrand Wijnands , Alvaro Retana Subject: RE: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm) Thread-Topic: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm) Thread-Index: AQHOu4CPrWxL1Z2c40Onwd/d+2+N/pnsHMcAgABW90A= Date: Wed, 9 Oct 2013 14:25:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+JvrW5gemiQwfF3BhZ/f25ltHg15w6z xYU3v5kdmD2m/N7I6rFkyU+mAKYoLpuU1JzMstQifbsErozOZ/oFN4Qqlq49wtLAuIa/i5GT Q0LARGLa0mmsELaYxIV769m6GLk4hAQOM0rsnvCDBcJZxCixY9UlFpAqNoFgie0PNrCB2CIC HhKbr21h72Lk4GAWUJXYvM0WJCwsEClxYP5CRpCwiECURMNOF4hqK4nWnyvBOlkEVCT2n2hn BinhFfCVaHhuARIWEqiX6Gm+wAYS5hSwlTj8shTEZBSQlXi4FqyCWUBc4taT+UwQBwtILNlz nhnCFpV4+fgf1COKEh9f7WOEqNeTuDF1ChuErS2xbOFrsHpeAUGJkzOfsExgFJuFZOwsJC2z kLTMQtKygJFlFSN7bmJmTnq54SZGYIwc3PJbdwfjqXMihxilOViUxHk/vHUOEhJITyxJzU5N LUgtii8qzUktPsTIxMEp1cBovNn4+4tGzaSZ7V+5D4ofW1uiHmvdXdj9bHXWaTnHNdeefFpa 3bPsxNWXx8USnD2c50iq2cq7G3h9nXp7eWZh0Bonlh1O8qonN+3RNd1295tboJGoCtdHS+6E LxzCa+wXHAxeaXuDf/aLOzfYhe98fsnTlLxS+cdeZoauDW4Km5ZdesqzqLhEiaU4I9FQi7mo OBEA83KIBV8CAAA= 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, 09 Oct 2013 14:26:32 -0000 Hi, Please keep in mind that even if MRT and ARC are both using the "ear-decomp= osition", they are using it in a different way. Some merging/common work ma= y be possible, but I don't feel the common points too strong now. Maybe we = should speak about this in Vancouver. Gabor -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of I= Jsbrand Wijnands Sent: Wednesday, October 09, 2013 12:31 PM To: Alvaro Retana Cc: rtgwg@ietf.org Subject: Re: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-fr= r-algorithm) Dear WG, >From a multicast POV I support this work to be adopted. Being able to build= two non-intersection paths through a single plane network is very useful f= or Multicast live-live and MoFRR deployments. It solves a real problem whic= h we see in today's networks. A more challenging question to answer is how draft-enyedi-rtgwg-mrt-frr-alg= orithm relates to draft-thubert-rtgwg-arc-00 and draft-thubert-rtgwg-arc-bi= cast-00. I don't know if both can move forward individually or if some merg= e is possible. It would be good if the authors get together and discuss thi= s. Thx, Ice. On 27 Sep 2013, at 14:53, Alvaro Retana (aretana) wrote= : > Hi! >=20 > This message starts a two-week Call for WG Adoption for 'Algorithms for c= omputing Maximally Redundant Trees for IP/LDP Fast-Reroute' (draft-enyedi-r= tgwg-mrt-frr-algorithm). >=20 > http://tools.ietf.org/html/draft-enyedi-rtgwg-mrt-frr-algorithm >=20 > At the meeting in Berlin the authors asked for the WG adoption of their d= raft, but here were very few people in the room who had actually reviewed t= he document to get any type of read of the room. =20 >=20 > We want to hear from people who have read and understood the draft (besid= es the authors!) about this topic. Please provide some explanation as to w= hy you support or not the adoption of the draft - avoid "+1". >=20 > This call will be over by EOD on Oct/11, 2013 (pick your favorite time zo= ne). >=20 > Thanks!! >=20 > Alvaro. > _______________________________________________ > 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 From akatlas@gmail.com Wed Oct 9 07:29:59 2013 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 8C2DB21F8411 for ; Wed, 9 Oct 2013 07:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C09v7vmF1+4q for ; Wed, 9 Oct 2013 07:29:52 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 22A9211E81A6 for ; Wed, 9 Oct 2013 07:29:30 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id at1so1990162iec.30 for ; Wed, 09 Oct 2013 07:29:10 -0700 (PDT) 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=uenRTfsmjBhKgcY11NyfScqbMB7OMlqVoTP/3Mgc/qo=; b=L9D5vD95gWDhrNg6AHdjT6wPrIoL3h2AlnZ+/J22bVph01ghitDnW5AXDDlJKRKUc2 /fIHTO6pjSn+7WnMuh1RacAlr/iJqmBz1rZQWHmhPIKG5KHVrU62YLi855VL/tCqh7FQ s5S+/uhZIckLTSbkNEKoaj83K9tTF49R0zg3lagMT5wI7Ar7Vwcne1DXYT+CmthaxQ71 /34NQw+/Yxq/2u902knnX3C2CzncS7B/hryo+QTCmxSYNgQq1c4RtIYV+Xhmz8811pD3 Npq9vTDKsTbzSonUYOd69BAkdCDOM5uAKUUpzV/ITFv/cf/TtdlXQn0C40CL1WDR8Cu4 tWgg== MIME-Version: 1.0 X-Received: by 10.50.119.70 with SMTP id ks6mr2293150igb.22.1381328950661; Wed, 09 Oct 2013 07:29:10 -0700 (PDT) Received: by 10.64.78.72 with HTTP; Wed, 9 Oct 2013 07:29:10 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Oct 2013 10:29:10 -0400 Message-ID: Subject: Re: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm) From: Alia Atlas To: =?ISO-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= Content-Type: multipart/alternative; boundary=089e0111d9b86c1d0504e84fb56f 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, 09 Oct 2013 14:30:02 -0000 --089e0111d9b86c1d0504e84fb56f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (WG-chair hat off) I agree. I haven't seen any work on the ARC drafts in the last year. I don't see the work needed to take an algorithm into the functioning MRT architecture. Remember that it's taken a good amount of time to flesh out all the details for MRT. Alia On Wed, Oct 9, 2013 at 10:25 AM, G=E1bor S=E1ndor Enyedi < gabor.sandor.enyedi@ericsson.com> wrote: > Hi, > > Please keep in mind that even if MRT and ARC are both using the > "ear-decomposition", they are using it in a different way. Some > merging/common work may be possible, but I don't feel the common points t= oo > strong now. Maybe we should speak about this in Vancouver. > > Gabor > > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of > IJsbrand Wijnands > Sent: Wednesday, October 09, 2013 12:31 PM > To: Alvaro Retana > Cc: rtgwg@ietf.org > Subject: Re: WG Adoption of MRT Algorithms Draft > (draft-enyedi-rtgwg-mrt-frr-algorithm) > > Dear WG, > > From a multicast POV I support this work to be adopted. Being able to > build two non-intersection paths through a single plane network is very > useful for Multicast live-live and MoFRR deployments. It solves a real > problem which we see in today's networks. > > A more challenging question to answer is how > draft-enyedi-rtgwg-mrt-frr-algorithm relates to draft-thubert-rtgwg-arc-0= 0 > and draft-thubert-rtgwg-arc-bicast-00. I don't know if both can move > forward individually or if some merge is possible. It would be good if th= e > authors get together and discuss this. > > Thx, > > Ice. > > On 27 Sep 2013, at 14:53, Alvaro Retana (aretana) > wrote: > > > Hi! > > > > This message starts a two-week Call for WG Adoption for 'Algorithms for > computing Maximally Redundant Trees for IP/LDP Fast-Reroute' > (draft-enyedi-rtgwg-mrt-frr-algorithm). > > > > http://tools.ietf.org/html/draft-enyedi-rtgwg-mrt-frr-algorithm > > > > At the meeting in Berlin the authors asked for the WG adoption of their > draft, but here were very few people in the room who had actually reviewe= d > the document to get any type of read of the room. > > > > We want to hear from people who have read and understood the draft > (besides the authors!) about this topic. Please provide some explanation > as to why you support or not the adoption of the draft - avoid "+1". > > > > This call will be over by EOD on Oct/11, 2013 (pick your favorite time > zone). > > > > Thanks!! > > > > Alvaro. > > _______________________________________________ > > 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 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > --089e0111d9b86c1d0504e84fb56f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
(WG-chair hat off)

I agree. =A0I = haven't seen any work on the ARC drafts in the last year. =A0I don'= t see the work needed to take an algorithm into the functioning MRT archite= cture. =A0Remember that it's taken a good amount of time to flesh out a= ll the details for MRT.

Alia


On Wed, Oct 9, 2013 at 10:25 AM, G=E1bor S=E1ndor Enyedi = <gabor.sandor.enyedi@ericsson.com> wrote:
Hi,

Please keep in mind that even if MRT and ARC are both using the "ear-d= ecomposition", they are using it in a different way. Some merging/comm= on work may be possible, but I don't feel the common points too strong = now. Maybe we should speak about this in Vancouver.

Gabor

-----Original Message-----
From: rtgwg-bounces@ietf.org = [mailto:rtgwg-bounces@ietf.org] On Behalf Of IJsbrand Wijnands
Sent: Wednesday, October 09, 2013 12:31 PM
To: Alvaro Retana
Cc: rtgwg@ietf.org
Subject: Re: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-fr= r-algorithm)

Dear WG,

>From a multicast POV I support this work to be adopted. Being able to build= two non-intersection paths through a single plane network is very useful f= or Multicast live-live and MoFRR deployments. It solves a real problem whic= h we see in today's networks.

A more challenging question to answer is how draft-enyedi-rtgwg-mrt-frr-alg= orithm relates to draft-thubert-rtgwg-arc-00 and draft-thubert-rtgwg-arc-bi= cast-00. I don't know if both can move forward individually or if some = merge is possible. It would be good if the authors get together and discuss= this.

Thx,

Ice.

On 27 Sep 2013, at 14:53, Alvaro Retana (aretana) <aretana@cisco.com> wrote:

> Hi!
>
> This message starts a two-week Call for WG Adoption for 'Algorithm= s for computing Maximally Redundant Trees for IP/LDP Fast-Reroute' (dra= ft-enyedi-rtgwg-mrt-frr-algorithm).
>
> http://tools.ietf.org/html/draft-enyedi-rtgwg-mrt-f= rr-algorithm
>
> At the meeting in Berlin the authors asked for the WG adoption of thei= r draft, but here were very few people in the room who had actually reviewe= d the document to get any type of read of the room.
>
> We want to hear from people who have read and understood the draft (be= sides the authors!) about this topic. =A0Please provide some explanation as= to why you support or not the adoption of the draft - avoid "+1"= .
>
> This call will be over by EOD on Oct/11, 2013 (pick your favorite time= zone).
>
> Thanks!!
>
> Alvaro.
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg

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

--089e0111d9b86c1d0504e84fb56f-- From psarkar@juniper.net Wed Oct 9 07:30:19 2013 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 9288121F9C6C for ; Wed, 9 Oct 2013 07:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoH5Z6elJunp for ; Wed, 9 Oct 2013 07:30:07 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8A411E81B0 for ; Wed, 9 Oct 2013 07:29:30 -0700 (PDT) Received: from mail195-va3-R.bigfish.com (10.7.14.235) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.22; Wed, 9 Oct 2013 14:29:05 +0000 Received: from mail195-va3 (localhost [127.0.0.1]) by mail195-va3-R.bigfish.com (Postfix) with ESMTP id DAD2830005F; Wed, 9 Oct 2013 14:29:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(zzbb2dI98dI9371I1431Jc85fh542I1418I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah18c673h1de097h186068h8275bh8275dhz2fh2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h9a9j1155h) Received-SPF: pass (mail195-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=psarkar@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(164054003)(51444003)(13464003)(24454002)(479174003)(189002)(199002)(377454003)(51694002)(15202345003)(81542001)(79102001)(77096001)(56816003)(80022001)(66066001)(65816001)(76482001)(74366001)(15975445006)(81342001)(74706001)(74662001)(80976001)(31966008)(83072001)(19580405001)(83322001)(47446002)(19580395003)(74502001)(81816001)(63696002)(54316002)(54356001)(77982001)(85306002)(53806001)(56776001)(59766001)(33646001)(69226001)(49866001)(16236675002)(19300405004)(4396001)(74876001)(47976001)(50986001)(47736001)(81686001)(76786001)(74316001)(76796001)(51856001)(76576001)(46102001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB518; H:BN1PR05MB520.namprd05.prod.outlook.com; CLIP:116.197.178.91; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail195-va3 (localhost.localdomain [127.0.0.1]) by mail195-va3 (MessageSwitch) id 1381328942221919_25834; Wed, 9 Oct 2013 14:29:02 +0000 (UTC) Received: from VA3EHSMHS046.bigfish.com (unknown [10.7.14.235]) by mail195-va3.bigfish.com (Postfix) with ESMTP id 1EAC2180243; Wed, 9 Oct 2013 14:29:02 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS046.bigfish.com (10.7.99.56) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 9 Oct 2013 14:28:52 +0000 Received: from BN1PR05MB518.namprd05.prod.outlook.com (10.141.65.143) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.371.2; Wed, 9 Oct 2013 14:28:51 +0000 Received: from BN1PR05MB520.namprd05.prod.outlook.com (10.141.65.151) by BN1PR05MB518.namprd05.prod.outlook.com (10.141.65.143) with Microsoft SMTP Server (TLS) id 15.0.775.9; Wed, 9 Oct 2013 14:28:48 +0000 Received: from BN1PR05MB520.namprd05.prod.outlook.com ([169.254.16.135]) by BN1PR05MB520.namprd05.prod.outlook.com ([169.254.16.135]) with mapi id 15.00.0775.005; Wed, 9 Oct 2013 14:28:48 +0000 From: Pushpasis Sarkar To: Levente Csikor Subject: RE: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt Thread-Topic: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt Thread-Index: AQHOxPvetrh3EkzRN0CUBJla0U+fVg== Date: Wed, 9 Oct 2013 14:28:48 +0000 Message-ID: References: <52551411.6080503@tmit.bme.hu> <0560d0a67fcc4af688176a280f9bdf3f@BN1PR05MB520.namprd05.prod.outlook.com> <5255421C.2010101@tmit.bme.hu> In-Reply-To: <5255421C.2010101@tmit.bme.hu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.178.91] x-forefront-prvs: 0994F5E0C5 Content-Type: multipart/alternative; boundary="_000_b0e21150c21f42d7a8315025609ccc20BN1PR05MB520namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 09 Oct 2013 14:30:19 -0000 --_000_b0e21150c21f42d7a8315025609ccc20BN1PR05MB520namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Levente, "I did not consider any possible way of determining PQ-nodes, only used the= description of P and Q spaces from the original draft, and from my researc= h on this topic, where every kind of spaces were defined in cost terms to e= asily analyze the network theoretically." The original Q-space definition is... "the set of routers which can reach the primary neighbor E can without trav= ersing the link (S-E) being protected" What will the definition for Q-space definition in this case? Do you mean..= . " the set of routers than can reach the primary neighbor E without traversi= ng any links originating from E"? That will leave no routers in the set.. R= ight? What makes sense is "the set of routers that can reach destination without = traversing any links originating/attached to E".... For doing that we will = have two options 1. RSPF rooted on the destination (will be very expensive if we have = to do that for every destination node in the network).. OR 2. FSPF rooted on the PQ-node and check if primary neighbor E is on t= he SPF path from PQ-node to destination.. This is what is specified in our = draft.. Assuming number of PQ-nodes are far less than number of nodes in th= e network this approach looked more feasible. Also now we are able to colle= ct full path attributes for RLFA backup paths for LFA-manageability. Also R= LFA does not attempt to provide 100% coverage. So like already said, implem= entations can decide to only consider upto a certain number of PQ-nodes to = be considered in the whole network to limit the number of extra FSPFs to be= computed. Thanks -Pushpasis From: Levente Csikor [mailto:csikor@tmit.bme.hu] Sent: Wednesday, October 09, 2013 5:17 PM To: Pushpasis Sarkar Cc: rtgwg@ietf.org; Chris Bowers Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-= 01.txt Dear Pushpasis, thanks for your comments. For reactions see mine inline: On 10/09/2013 12:49 PM, Pushpasis Sarkar wrote: Hi Levente, Please find few comments inline... Thanks -Pushpasis -----Original Message----- From: Levente Csikor [mailto:csikor@tmit.bme.hu] Sent: Wednesday, October 09, 2013 2:00 PM To: rtgwg@ietf.org Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-= 01.txt Dear All, I also support to work more on the node protection draft first, before merg= ing it with "basic rLFA spec", because of various reasons: First, I think it would be almost a good approach to show how node-protecti= ng remote LFA works on the same, or almost the same sample network topology= used in the basic rLFA spec., but for easier and more comprehensive unders= tanding, a bit more complex but still simple example should be given. IMHO,= in the basic rLFA spec. it is a bit confusing that node E is considered as= a destination and this node is the next-hop as well, since the important p= arts of the different roles are not dissevering enough. Because of this, th= e similar example in node prot spec. is also not straightforward: [Pushpasis] If you see Table 1,2, and 3 in draft-psarkar-rtgwg-rlfa-node-pr= otection-01 we have specified the destinations E, F (and their correspondin= g RLFA backup paths explicitly), that will be affected by node-failure of E= . Also the destination G has been included which will still be reachable in= the case of node-failure of E. Perhaps basic RLFA spec can also include su= ch kind of illustrations Yeah, I know and there is also the entry in the back-up path column for= G, but here, I wanted to emphasized that the connectedness of the network = does not remain any other opportunities to be considered. In other words, if there were an additional node between F and G, say H, an= d nodes E-D-G-H-F would also form a 5-cycle, then all your claims will rema= in valid, since C's shortest path to F won't avoid the failed node E, but t= he graph-topological requirements would be not so confusing (maybe only for= me :) , but when I analyze a network to calculate the rLFA protection cove= rage, then I always assume this basic graph topological property to easily = derive the level of protection (in percent, for example) of the possible at= tainable 100%). "In the event of the node-failure on primary nexthop E, the alternate path = from Remote-LFA nexthop C to E and F also becomes unavailable." [Pushpasis] That is exactly we are also saying in this draft(I mean draft-p= sarkar-rtgwg-rlfa-node-protection-01).. If any destination takes the shorte= st-path segment C...E that will not have node-protection using C as the PQ = node, because C is going to forward the traffic to E anyhow. In Table 2 we = see that the path segment C->D->E is included in the shortest path from C t= o E and F. That is why in case of node-failure of E, E and F cannot provide= node-protection It was a quote from the draft, so it is really the fact that you are sa= ying :) According to the well-known last-hop problem, it is obvious that if the des= tination (in the first case: node E) goes down, then it cannot be protected= . Moreover, since the example network topologyis not 2-node-connected, it i= s obvious again that the node F, which can be accessed only via node E, the= n the failure of node E infers that the node F can be never reached. To (re)solve this issue, I suggest to use another network (in the basic rLF= A spec. as well), which could be the following (all link costs are unit cos= ts): A----------B---------C | | / | | | / | | | / | F G / H | | / | | | / | | | / | D----------E---------S In this case, assuming that source node S wants to send a packet to node D,= the next-hop of S is node E. - Link protecting case: If link(s,e) fails, then P-space of node S regard= ing to the failed link, would consist of node H,C,B and A, whilst the Q-spa= ce of D would consist all nodes except S and H. In this case, the PQ-nodes,= as the possible repair tunnel endpoints, are node A,B and C. - Node protecting case: However, if node E itself fails, then the P-space= of S would not alter, but the Q-space of D would only contain node F and A= resulting that only node A is present in the set of PQ-nodes. [Pushpasis] Can you elaborate on the method you used for deriving the PQ-no= des A and F here... Seems to me like you are doing a RSPF rooted on destina= tion D and then pruning all links originating from E... I think Chris Bower= s has already pointed on a different thread that while best way to guarante= e node-protection is to run a RSPF rooted on each destination, we cannot af= ford to do so in reality... It will be much more feasible to run FSPF on fe= wer PQ-nodes as specified in our draft.. I did not consider any possible way of determining PQ-nodes, only used = the description of P and Q spaces from the original draft, and from my rese= arch on this topic, where every kind of spaces were defined in cost terms t= o easily analyze the network theoretically. Also, the method specified by our draft also finds A as the node-protecting= PQ-node, becoz the draft suggest to find the shortest-path from the PQ-nod= es (C, B, and A) to destination D. Only the SPF path from A does not go thr= ough E, so only A will provide node-protection for D. I think that this network also shows the different between the node protect= ion and link protection, but in a more comprehensive manner. And it also de= monstrates the fact mentioned in Figure 2 that for node-protecting rLFA, on= ly the Q-spaces should be checked with those distance functions. Moreover, if we assume that in the example network above, there is a link (= A,E) and node E itself failed again, than PQ-space would be and empty set m= eaning that this case cannot be protected. [Pushpasis] True. Our draft will also pick A->E->D as the SPF from A to D i= n that case and disqualify A as node-protecting PQ-node. In reality too the= re is no feasible path in this case till A re-converges after learning E's = node-failure I know that it is true, I just wanted to say that by this network, the = case of absence of node protection could be demonstrated easily assuming th= at the main example was the network described above. Second, it would be better in the draft if the questions about "how difficu= lt or impossible to obtain those distances" would be clearly stated in a bu= llet point list: For example: - Q-space can be obtained by rSPF calculated at destination node D - P-space can be obtained through SPF calculation at source node S and it= s 1-hop neighbor. - SPF at a PQ-node is impossible or if not what extensions should be impl= emented (actually, IMHO, this is the one, which is not clear enough) [Pushpasis] The first two should really be addressed in the original RLFA d= raft. Chris has already written to the authors on this mailing list with su= ggesting text for the draft. The third one is no different than standard SP= F we need for RFC5286 implementation.. only difference being that it is roo= ted on PQ-nodes in case of RLFA... It is up to individual implementations = to come up with ways to constraint those to a limit. Thanks Third, according to the Targeted-LDP discussion, which is about the fact th= at if some node do not support TLDP, then how can be the inner MPLS label o= btained from the PQ-node; I think that if we want remote LFA protection the= n the nodes MUST implement/support this feature, because without this the p= rotection cannot be guaranteed. For me, it is similar to a hypothetic case = for example of Not-via, where if the router do not support Not-via, then it= cannot be used. Or isn't it so simple? [Pushpasis] Again this is more related to original RLFA draft. I will prefe= r the corresponding authors to address this point :) Thanks Please comment my observations, in order to help me and may others as well = to understand every aspects and little pieces of remote LFA specifications. Best Regards, Levente Csikor Thanks, Levente Csikor --_000_b0e21150c21f42d7a8315025609ccc20BN1PR05MB520namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Levente,=

 

“I did not consider any possible way of determi= ning PQ-nodes, only used the description of P and Q spaces from the origina= l draft, and from my research on this topic, where every kind of spaces were defined in cost terms to easily analyze th= e network theoretically.”

 

The original Q-space d= efinition is…  

“the set of rout= ers which can reach the primary neighbor E can without traversing the link = (S-E) being protected”

 

What will the definiti= on for Q-space definition in this case? Do you mean…

“ the set of rou= ters than can reach the primary neighbor E without traversing any links ori= ginating from E”? That will leave no routers in the set.. Right?=

 

What makes sense is &#= 8220;the set of routers that can reach destination without traversing any l= inks originating/attached to E”…. For doing that we will have t= wo options

1.&n= bsp;      RSPF rooted on= the destination (will be very expensive if we have to do that for every de= stination node in the network)..  OR

2.&n= bsp;      FSPF rooted on= the PQ-node and check if primary neighbor E is on the SPF path from PQ-nod= e to destination.. This is what is specified in our draft.. Assuming number= of PQ-nodes are far less than number of nodes in the network this approach looked more feasible. Also now we ar= e able to collect full path attributes for RLFA backup paths for LFA-manage= ability. Also RLFA does not attempt to provide 100% coverage. So like alrea= dy said, implementations can decide to only consider upto a certain number of PQ-nodes to be considered in the= whole network to limit the number of extra FSPFs to be computed.

 

Thanks

-Pushpasis<= /span>

 

From:= Levente Csikor [mailto:csikor@tmit.bme.hu= ]
Sent: Wednesday, October 09, 2013 5:17 PM
To: Pushpasis Sarkar
Cc: rtgwg@ietf.org; Chris Bowers
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-prot= ection-01.txt

 

Dear Pushpasis,
thanks for your comments.
For reactions see mine inline:

On 10/09/2013 12:49 PM, Pushpasis Sarkar wrote:=

Hi Levente,

 

Please find few comments inline... 

 

Thanks

-Pushpasis

 

-----Original Message-----
From: Levente Csikor [mailto:csikor@t= mit.bme.hu]
Sent: Wednesday, October 09, 2013 2:00 PM
To: rtgwg@ietf.org
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-= 01.txt

 

Dear All,

I also support to work more on the node protectio= n draft first, before merging it with "basic rLFA spec", because = of various reasons:

 

First, I think it would be almost a good approach= to show how node-protecting remote LFA works on the same, or almost the sa= me sample network topology used in the basic rLFA spec., but for easier and= more comprehensive understanding, a bit more complex but still simple example should be given. IMHO, in the = basic rLFA spec. it is a bit confusing that node E is considered as a desti= nation and this node is the next-hop as well, since the important parts of = the different roles are not dissevering enough. Because of this, the similar example in node prot spec. is also no= t straightforward:

[Pushpasis] If y= ou see Table 1,2, and 3 in draft-psarkar-rtgwg-rlfa-node-protection-01 we h= ave specified the destinations E, F (and their corresponding RLFA backup pa= ths explicitly), that will be affected by node-failure of E. Also the destination G has been included which will = still be reachable in the case of node-failure of E. Perhaps basic RLFA spe= c can also include such kind of illustrations

    Yeah, I know and there is a= lso the entry in the back-up path column for G, but here, I wanted to empha= sized that the connectedness of the network does not remain any other oppor= tunities to be considered.
In other words, if there were an additional node between F and G, say H= , and nodes E-D-G-H-F would also form a 5-cycle, then all your claims will = remain valid, since C's shortest path to F won't avoid the failed node E, b= ut the graph-topological requirements would be not so confusing (maybe only for me :) , but when I analyze a net= work to calculate the rLFA protection coverage, then I always assume this b= asic graph topological property to easily derive the level of protection (i= n percent, for example) of the possible attainable 100%).

 

"In the event of the node-failure on primary= nexthop E, the alternate path from Remote-LFA nexthop C to E and F also be= comes unavailable."

[Pushpasis] That= is exactly we are also saying in this draft(I mean draft-psarkar-rtgwg-rlf= a-node-protection-01).. If any destination takes the shortest-path segment = C…E that will not have node-protection using C as the PQ node, because C is going to forward the traffic to E any= how. In Table 2 we see that the path segment C->D->E is included in t= he shortest path from C to E and F. That is why in case of node-failure of = E, E and F cannot provide node-protection

  =   It was a quote = from the draft, so it is really the fact that you are saying :)=

 

According to the well-known last-hop problem, it = is obvious that if the destination (in the first case: node E) goes down, t= hen it cannot be protected. Moreover, since the example network topologyis = not 2-node-connected, it is obvious again that the node F, which can be accessed only via node E, then the fai= lure of node E infers that the node F can be never reached.

To (re)solve this issue, I suggest to use another= network (in the basic rLFA spec. as well), which could be the following (a= ll link costs are unit costs):

 

 

A----------B---------C

|        =   |       / |

|        =   |      /  |

|        =   |     /   |

F        =   G    /    H

|        =   |   /     |

|        =   |  /      |

|        =   | /       |

D----------E---------S

 

In this case, assuming that source node S wants t= o send a packet to node D, the next-hop of S is node E.

  - Link protecting case: If link(s,e) fails= , then P-space of node S regarding to the failed link, would consist of nod= e H,C,B and A, whilst the Q-space of D would consist all nodes except S and= H. In this case, the PQ-nodes, as the possible repair tunnel endpoints, are node A,B and C.

  - Node protecting case: However, if node E= itself fails, then the P-space of S would not alter, but the Q-space of D = would only contain node F and A resulting that only node A is present in th= e set of PQ-nodes.

[Pushpasis] Can = you elaborate on the method you used for deriving the PQ-nodes A and F here= … Seems to me like you are doing a RSPF rooted on destination D and t= hen pruning all links originating from E… I think Chris Bowers has already pointed on a different thread that while = best way to guarantee node-protection is to run a RSPF rooted on each desti= nation, we cannot afford to do so in reality… It will be much more fe= asible to run FSPF on fewer PQ-nodes as specified in our draft..

    I did not consider any poss= ible way of determining PQ-nodes, only used the description of P and Q spac= es from the original draft, and from my research on this topic, where every= kind of spaces were defined in cost terms to easily analyze the network theoretically.

 

Also, the method= specified by our draft also finds A as the node-protecting PQ-node, becoz = the draft suggest to find the shortest-path from the PQ-nodes (C, B, and A)= to destination D. Only the SPF path from A does not go through E, so only A will provide node-protection for D= .

 

I think that this network also shows the differen= t between the node protection and link protection, but in a more comprehens= ive manner. And it also demonstrates the fact mentioned in Figure 2 that fo= r node-protecting rLFA, only the Q-spaces should be checked with those distance functions.

 

Moreover, if we assume that in the example networ= k above, there is a link (A,E) and node E itself failed again, than PQ-spac= e would be and empty set meaning that this case cannot be protected.

[Pushpasis] True= . Our draft will also pick A->E->D as the SPF from A to D in that cas= e and disqualify A as node-protecting PQ-node. In reality too there is no f= easible path in this case till A re-converges after learning E’s node-failure

  =   I know that it = is true, I just wanted to say that by this network, the case of absence of = node protection could be demonstrated easily assuming that the main example was the network described above.

 

Second, it would be better in the draft if the qu= estions about "how difficult or impossible to obtain those distances&q= uot; would be clearly stated in a bullet point list:

For example:

  - Q-space can be obtained by rSPF calculat= ed at destination node D

  - P-space can be obtained through SPF calc= ulation at source node S and its 1-hop neighbor.

  - SPF at a PQ-node is impossible or if not= what extensions should be implemented (actually, IMHO, this is the one, wh= ich is not clear enough)

[Pushpasis] The = first two should really be addressed in the original RLFA draft. Chris has = already written to the authors on this mailing list with suggesting text fo= r the draft. The third one is no different than standard SPF we need for RFC5286 implementation.. only difference bei= ng that it is rooted on PQ-nodes  in case of RLFA… It is up to i= ndividual implementations to come up with ways to constraint those to a lim= it.

    Thanks

 

Third, according to the Targeted-LDP discussion, = which is about the fact that if some node do not support TLDP, then how can= be the inner MPLS label obtained from the PQ-node; I think that if we want= remote LFA protection then the nodes MUST implement/support this feature, because without this the protection c= annot be guaranteed. For me, it is similar to a hypothetic case for example= of Not-via, where if the router do not support Not-via, then it cannot be = used. Or isn't it so simple?

[Pushpasis] Agai= n this is more related to original RLFA draft. I will prefer the correspond= ing authors to address this point J<= /b>

    Thanks

 

Please comment my observations, in order to help = me and may others as well to understand every aspects and little pieces of = remote LFA specifications.

 

Best Regards,

Levente Csikor

 

 

 

Thanks,

Levente Csikor

 

--_000_b0e21150c21f42d7a8315025609ccc20BN1PR05MB520namprd05pro_-- From jeff.tantsura@ericsson.com Wed Oct 9 07:33:37 2013 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 B7FC421F9C42 for ; Wed, 9 Oct 2013 07:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90mWSYLWZeBr for ; Wed, 9 Oct 2013 07:33:32 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 757D421F9C7A for ; Wed, 9 Oct 2013 07:33:26 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-7c-52556935c3e6 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E2.BB.03458.53965525; Wed, 9 Oct 2013 16:33:25 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Wed, 9 Oct 2013 10:33:24 -0400 From: Jeff Tantsura To: Alia Atlas , =?iso-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= Subject: Re: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm) Thread-Topic: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm) Thread-Index: AQHOxPyDDP2+bXGgBEmLoLVA4iQTpQ== Date: Wed, 9 Oct 2013 14:33:25 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C74839954003@eusaamb109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_60DEDD93F5E54B4AB55647B8B6C74839954003eusaamb109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyuXRPoK5pZmiQwYuDBhafHl5itrjw5jez A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJVxqqeTpaA9oGLSnJOsDYyNrl2MnBwSAiYS dz5MYYKwxSQu3FvP1sXIxSEkcJRRYv3zY+wQzjJGie17l4FVsQkYSPz/dpwFxBYRKJRYu3kN kM3BwSygKrF5my1IWFggUuLwm61gYRGBKInVr1ghqvUkzqxYDWazCKhINO25BGbzCnhLNH24 A2ZzCgRKnHn2BGwTI9A930+tAbOZBcQlbj2ZD3WngMSSPeeZIWxRiZeP/4H1igLNbzt2hh0i rizxfc4jqMvyJW6+jodYJShxcuYTlgmMorOQTJ2FUDULSRVEiZ7EjalT2CBsbYllC18zQ9i6 EjP+HYKqsZZYOPsSO7KaBYwcqxg5SotTy3LTjQw3MQLj7JgEm+MOxgWfLA8xSnOwKInzfnnr HCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBsWeGTO2PULfFavxpbJ7z7/1yqvzkPO/ViQ0i 93ILMnXtFjubrbRbw9rmuDhFucrjz24R3XjmjDs7dzgfUV1V8ot1tuDBCqZi9q3z/lk/rP7s IBYcJdpa92/zFnvjz51v424qdD9u26Y/yWvh7IaFdw/3vdix7qHLsdATs555dnd7/qg+uElh shJLcUaioRZzUXEiAAyNDjGBAgAA 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, 09 Oct 2013 14:33:37 -0000 --_000_60DEDD93F5E54B4AB55647B8B6C74839954003eusaamb109ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Agree with both comments. Cheers, Jeff From: Alia Atlas > Date: Wednesday, October 9, 2013 7:29 AM To: G=E1bor S=E1ndor Enyedi > Cc: "rtgwg@ietf.org" > Subject: Re: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-fr= r-algorithm) (WG-chair hat off) I agree. I haven't seen any work on the ARC drafts in the last year. I do= n't see the work needed to take an algorithm into the functioning MRT archi= tecture. Remember that it's taken a good amount of time to flesh out all t= he details for MRT. Alia On Wed, Oct 9, 2013 at 10:25 AM, G=E1bor S=E1ndor Enyedi > wrote: Hi, Please keep in mind that even if MRT and ARC are both using the "ear-decomp= osition", they are using it in a different way. Some merging/common work ma= y be possible, but I don't feel the common points too strong now. Maybe we = should speak about this in Vancouver. Gabor -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-b= ounces@ietf.org] On Behalf Of IJsbrand Wijna= nds Sent: Wednesday, October 09, 2013 12:31 PM To: Alvaro Retana Cc: rtgwg@ietf.org Subject: Re: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-fr= r-algorithm) Dear WG, >From a multicast POV I support this work to be adopted. Being able to build= two non-intersection paths through a single plane network is very useful f= or Multicast live-live and MoFRR deployments. It solves a real problem whic= h we see in today's networks. A more challenging question to answer is how draft-enyedi-rtgwg-mrt-frr-alg= orithm relates to draft-thubert-rtgwg-arc-00 and draft-thubert-rtgwg-arc-bi= cast-00. I don't know if both can move forward individually or if some merg= e is possible. It would be good if the authors get together and discuss thi= s. Thx, Ice. On 27 Sep 2013, at 14:53, Alvaro Retana (aretana) > wrote: > Hi! > > This message starts a two-week Call for WG Adoption for 'Algorithms for c= omputing Maximally Redundant Trees for IP/LDP Fast-Reroute' (draft-enyedi-r= tgwg-mrt-frr-algorithm). > > http://tools.ietf.org/html/draft-enyedi-rtgwg-mrt-frr-algorithm > > At the meeting in Berlin the authors asked for the WG adoption of their d= raft, but here were very few people in the room who had actually reviewed t= he document to get any type of read of the room. > > We want to hear from people who have read and understood the draft (besid= es the authors!) about this topic. Please provide some explanation as to w= hy you support or not the adoption of the draft - avoid "+1". > > This call will be over by EOD on Oct/11, 2013 (pick your favorite time zo= ne). > > Thanks!! > > Alvaro. > _______________________________________________ > 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 _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg --_000_60DEDD93F5E54B4AB55647B8B6C74839954003eusaamb109ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <3C00FA20BB64F5449CB7CA422AF392EB@ericsson.com> Content-Transfer-Encoding: quoted-printable
Agree with both comments. 

Cheers,
Jeff

From: Alia Atlas <akatlas@gmail.com>
Date: Wednesday, October 9, 2013 7:= 29 AM
To: G=E1bor S=E1ndor Enyedi <gabor.sandor.enyedi@ericss= on.com>
Cc: "rtgwg@ietf.org" <rtg= wg@ietf.org>
Subject: Re: WG Adoption of MRT Alg= orithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm)

(WG-chair hat off)

I agree.  I haven't seen any work on the ARC drafts in the last year. =  I don't see the work needed to take an algorithm into the functioning= MRT architecture.  Remember that it's taken a good amount of time to = flesh out all the details for MRT.

Alia


On Wed, Oct 9, 2013 at 10:25 AM, G=E1bor S=E1ndo= r Enyedi <g= abor.sandor.enyedi@ericsson.com> wrote:
Hi,

Please keep in mind that even if MRT and ARC are both using the "ear-d= ecomposition", they are using it in a different way. Some merging/comm= on work may be possible, but I don't feel the common points too strong now.= Maybe we should speak about this in Vancouver.

Gabor

-----Original Message-----
From: rtgwg-bounces@ietf.org = [mailto:rtgwg-bounces@ietf.org] On Behalf Of IJsbrand Wijnands
Sent: Wednesday, October 09, 2013 12:31 PM
To: Alvaro Retana
Cc: rtgwg@ietf.org
Subject: Re: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-fr= r-algorithm)

Dear WG,

>From a multicast POV I support this work to be adopted. Being able to build= two non-intersection paths through a single plane network is very useful f= or Multicast live-live and MoFRR deployments. It solves a real problem whic= h we see in today's networks.

A more challenging question to answer is how draft-enyedi-rtgwg-mrt-frr-alg= orithm relates to draft-thubert-rtgwg-arc-00 and draft-thubert-rtgwg-arc-bi= cast-00. I don't know if both can move forward individually or if some merg= e is possible. It would be good if the authors get together and discuss this.

Thx,

Ice.

On 27 Sep 2013, at 14:53, Alvaro Retana (aretana) <aretana@cisco.com> wrote:

> Hi!
>
> This message starts a two-week Call for WG Adoption for 'Algorithms fo= r computing Maximally Redundant Trees for IP/LDP Fast-Reroute' (draft-enyed= i-rtgwg-mrt-frr-algorithm).
>
> http://tools.ietf.org/html/draft-enyedi-rtgwg-mrt-frr-algorithm
>
> At the meeting in Berlin the authors asked for the WG adoption of thei= r draft, but here were very few people in the room who had actually reviewe= d the document to get any type of read of the room.
>
> We want to hear from people who have read and understood the draft (be= sides the authors!) about this topic.  Please provide some explanation= as to why you support or not the adoption of the draft - avoid "+= 1".
>
> This call will be over by EOD on Oct/11, 2013 (pick your favorite time= zone).
>
> Thanks!!
>
> Alvaro.
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg

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

 --_000_60DEDD93F5E54B4AB55647B8B6C74839954003eusaamb109ericsso_-- From csikor@tmit.bme.hu Wed Oct 9 07:51:50 2013 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 E3CFF11E81AF for ; Wed, 9 Oct 2013 07:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.047 X-Spam-Level: * X-Spam-Status: No, score=1.047 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TWdYRtUG49B for ; Wed, 9 Oct 2013 07:51:44 -0700 (PDT) Received: from ruby.tmit.bme.hu (ruby.tmit.bme.hu [152.66.245.193]) by ietfa.amsl.com (Postfix) with ESMTP id B854F11E81A7 for ; Wed, 9 Oct 2013 07:51:43 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ruby.tmit.bme.hu (Postfix) with ESMTP id 4EDAA87346; Wed, 9 Oct 2013 16:51:36 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at tmit.bme.hu Received: from ruby.tmit.bme.hu ([127.0.0.1]) by localhost (ruby.tmit.bme.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEdobgLICDev; Wed, 9 Oct 2013 16:51:06 +0200 (CEST) Received: from anyo.tmit.bme.hu (anyo.tmit.bme.hu [152.66.246.7]) by ruby.tmit.bme.hu (Postfix) with ESMTP id CC4B687345; Wed, 9 Oct 2013 16:51:06 +0200 (CEST) Received: from [152.66.244.179] (csikor.tmit.bme.hu [152.66.244.179]) (authenticated bits=0) by anyo.tmit.bme.hu (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r99EpFEL031946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Oct 2013 16:51:15 +0200 Message-ID: <52556D5F.4090308@tmit.bme.hu> Date: Wed, 09 Oct 2013 16:51:11 +0200 From: Levente Csikor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Pushpasis Sarkar Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt References: <52551411.6080503@tmit.bme.hu> <0560d0a67fcc4af688176a280f9bdf3f@BN1PR05MB520.namprd05.prod.outlook.com> <5255421C.2010101@tmit.bme.hu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020000000606030000080700" 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, 09 Oct 2013 14:51:51 -0000 This is a multi-part message in MIME format. --------------020000000606030000080700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To calculate, which nodes are in the Q-space I've just looked fornodes for which your distance function in Fig.2. applies. From an industrial/implementationpoint of view, I have no exact claim how the calculations should be made. Furthermore, assumingthatonly link failures are consideredin a unit cost network (where every link has the same unit cost), then rLFA provides 100% failure coverage. Note that in this case the minimal graph topological requirement is 2-edge-connectivity. That's why I said that theoretical investigation of the rLFA node-protecting failure coverage needs 2-node-connected networks to suppose that may 100% node-protection can be reached. On 10/09/2013 04:28 PM, Pushpasis Sarkar wrote: > > Hi Levente, > > "I did not consider any possible way of determining PQ-nodes, only > used the description of P and Q spaces from the original draft, and > from my research on this topic, where every kind of spaces were > defined in cost terms to easily analyze the network theoretically." > > The original Q-space definition is... > > "the set of routers which can reach the primary neighbor E can without > traversing the link (S-E) being protected" > > What will the definition for Q-space definition in this case? Do you > mean... > > " the set of routers than can reach the primary neighbor E without > traversing any links originating from E"? That will leave no routers > in the set.. Right? > > What makes sense is "the set of routers that can reach destination > without traversing any links originating/attached to E".... For doing > that we will have two options > > 1.RSPF rooted on the destination (will be very expensive if we have to > do that for every destination node in the network).. OR > > 2.FSPF rooted on the PQ-node and check if primary neighbor E is on the > SPF path from PQ-node to destination.. This is what is specified in > our draft.. Assuming number of PQ-nodes are far less than number of > nodes in the network this approach looked more feasible. Also now we > are able to collect full path attributes for RLFA backup paths for > LFA-manageability. Also RLFA does not attempt to provide 100% > coverage. So like already said, implementations can decide to only > consider upto a certain number of PQ-nodes to be considered in the > whole network to limit the number of extra FSPFs to be computed. > > Thanks > > -Pushpasis > > *From:*Levente Csikor [mailto:csikor@tmit.bme.hu] > *Sent:* Wednesday, October 09, 2013 5:17 PM > *To:* Pushpasis Sarkar > *Cc:* rtgwg@ietf.org; Chris Bowers > *Subject:* Re: Request for review - > draft-psarkar-rtgwg-rlfa-node-protection-01.txt > > Dear Pushpasis, > thanks for your comments. > For reactions see mine inline: > > On 10/09/2013 12:49 PM, Pushpasis Sarkar wrote: > > Hi Levente, > > Please find few comments inline... > > Thanks > > -Pushpasis > > -----Original Message----- > From: Levente Csikor [mailto:csikor@tmit.bme.hu] > Sent: Wednesday, October 09, 2013 2:00 PM > To: rtgwg@ietf.org > Subject: Re: Request for review - > draft-psarkar-rtgwg-rlfa-node-protection-01.txt > > Dear All, > > I also support to work more on the node protection draft first, > before merging it with "basic rLFA spec", because of various reasons: > > First, I think it would be almost a good approach to show how > node-protecting remote LFA works on the same, or almost the same > sample network topology used in the basic rLFA spec., but for > easier and more comprehensive understanding, a bit more complex > but still simple example should be given. IMHO, in the basic rLFA > spec. it is a bit confusing that node E is considered as a > destination and this node is the next-hop as well, since the > important parts of the different roles are not dissevering enough. > Because of this, the similar example in node prot spec. is also > not straightforward: > > *[Pushpasis] If you see Table 1,2, and 3 in > draft-psarkar-rtgwg-rlfa-node-protection-01 we have specified the > destinations E, F (and their corresponding RLFA backup paths > explicitly), that will be affected by node-failure of E. Also the > destination G has been included which will still be reachable in > the case of node-failure of E. Perhaps basic RLFA spec can also > include such kind of illustrations* > > **Yeah, I know and there is also the entry in the back-up path column > for G, but here, I wanted to emphasized that the connectedness of the > network does not remain any other opportunities to be considered. > In other words, if there were an additional node between F and G, say > H, and nodes E-D-G-H-F would also form a 5-cycle, then all your claims > will remain valid, since C's shortest path to F won't avoid the failed > node E, but the graph-topological requirements would be not so > confusing (maybe only for me :) , but when I analyze a network to > calculate the rLFA protection coverage, then I always assume this > basic graph topological property to easily derive the level of > protection (in percent, for example) of the possible attainable 100%). > > "In the event of the node-failure on primary nexthop E, the > alternate path from Remote-LFA nexthop C to E and F also becomes > unavailable." > > *[Pushpasis] That is exactly we are also saying in this draft(I > mean draft-psarkar-rtgwg-rlfa-node-protection-01).. If any > destination takes the shortest-path segment C...E that will not > have node-protection using C as the PQ node, because C is going to > forward the traffic to E anyhow. In Table 2 we see that the path > segment C->D->E is included in the shortest path from C to E and > F. That is why in case of node-failure of E, E and F cannot > provide node-protection* > > **It was a quote from the draft, so it is really the fact that you are > saying :) > > According to the well-known last-hop problem, it is obvious that > if the destination (in the first case: node E) goes down, then it > cannot be protected. Moreover, since the example network > topologyis not 2-node-connected, it is obvious again that the node > F, which can be accessed only via node E, then the failure of node > E infers that the node F can be never reached. > > To (re)solve this issue, I suggest to use another network (in the > basic rLFA spec. as well), which could be the following (all link > costs are unit costs): > > A----------B---------C > > | | / | > > | | / | > > | | / | > > F G / H > > | | / | > > | | / | > > | | / | > > D----------E---------S > > In this case, assuming that source node S wants to send a packet > to node D, the next-hop of S is node E. > > - Link protecting case: If link(s,e) fails, then P-space of node > S regarding to the failed link, would consist of node H,C,B and A, > whilst the Q-space of D would consist all nodes except S and H. In > this case, the PQ-nodes, as the possible repair tunnel endpoints, > are node A,B and C. > > - Node protecting case: However, if node E itself fails, then > the P-space of S would not alter, but the Q-space of D would only > contain node F and A resulting that only node A is present in the > set of PQ-nodes. > > *[Pushpasis] Can you elaborate on the method you used for deriving > the PQ-nodes A and F here... Seems to me like you are doing a RSPF > rooted on destination D and then pruning all links originating > from E... I think Chris Bowers has already pointed on a different > thread that while best way to guarantee node-protection is to run > a RSPF rooted on each destination, we cannot afford to do so in > reality... It will be much more feasible to run FSPF on fewer > PQ-nodes as specified in our draft..* > > **I did not consider any possible way of determining PQ-nodes, only > used the description of P and Q spaces from the original draft, and > from my research on this topic, where every kind of spaces were > defined in cost terms to easily analyze the network theoretically. > > ** > > *Also, the method specified by our draft also finds A as the > node-protecting PQ-node, becoz the draft suggest to find the > shortest-path from the PQ-nodes (C, B, and A) to destination D. > Only the SPF path from A does not go through E, so only A will > provide node-protection for D.* > > I think that this network also shows the different between the > node protection and link protection, but in a more comprehensive > manner. And it also demonstrates the fact mentioned in Figure 2 > that for node-protecting rLFA, only the Q-spaces should be checked > with those distance functions. > > Moreover, if we assume that in the example network above, there is > a link (A,E) and node E itself failed again, than PQ-space would > be and empty set meaning that this case cannot be protected. > > *[Pushpasis] True. Our draft will also pick A->E->D as the SPF > from A to D in that case and disqualify A as node-protecting > PQ-node. In reality too there is no feasible path in this case > till A re-converges after learning E's node-failure* > > **I know that it is true, I just wanted to say that by this network, > the case of absence of node protection could be demonstrated easily > assuming that the main example was the network described above. > > Second, it would be better in the draft if the questions about > "how difficult or impossible to obtain those distances" would be > clearly stated in a bullet point list: > > For example: > > - Q-space can be obtained by rSPF calculated at destination node D > > - P-space can be obtained through SPF calculation at source node > S and its 1-hop neighbor. > > - SPF at a PQ-node is impossible or if not what extensions > should be implemented (actually, IMHO, this is the one, which is > not clear enough) > > *[Pushpasis] The first two should really be addressed in the > original RLFA draft. Chris has already written to the authors on > this mailing list with suggesting text for the draft. The third > one is no different than standard SPF we need for RFC5286 > implementation.. only difference being that it is rooted on > PQ-nodes in case of RLFA... It is up to individual > implementations to come up with ways to constraint those to a limit. * > > **Thanks > > Third, according to the Targeted-LDP discussion, which is about > the fact that if some node do not support TLDP, then how can be > the inner MPLS label obtained from the PQ-node; I think that if we > want remote LFA protection then the nodes MUST implement/support > this feature, because without this the protection cannot be > guaranteed. For me, it is similar to a hypothetic case for example > of Not-via, where if the router do not support Not-via, then it > cannot be used. Or isn't it so simple? > > *[Pushpasis] Again this is more related to original RLFA draft. I > will prefer the corresponding authors to address this point **J* > > **Thanks > > Please comment my observations, in order to help me and may others > as well to understand every aspects and little pieces of remote > LFA specifications. > > Best Regards, > > Levente Csikor > > Thanks, > > Levente Csikor > --------------020000000606030000080700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit To calculate, which nodes are in the Q-space I've just looked for nodes for which your distance function in Fig.2. applies.
From an industrial/implementation point of view, I have no exact claim how the calculations should be made.

Furthermore, assuming that only link failures are considered in a unit cost network (where every link has the same unit cost), then rLFA provides 100% failure coverage. Note that in this case the minimal graph topological requirement is 2-edge-connectivity. That's why I said that theoretical investigation of the rLFA node-protecting failure coverage needs 2-node-connected networks to suppose that may 100% node-protection can be reached.
On 10/09/2013 04:28 PM, Pushpasis Sarkar wrote:

Hi Levente,

 

“I did not consider any possible way of determining PQ-nodes, only used the description of P and Q spaces from the original draft, and from my research on this topic, where every kind of spaces were defined in cost terms to easily analyze the network theoretically.”

 

The original Q-space definition is…  

“the set of routers which can reach the primary neighbor E can without traversing the link (S-E) being protected”

 

What will the definition for Q-space definition in this case? Do you mean…

“ the set of routers than can reach the primary neighbor E without traversing any links originating from E”? That will leave no routers in the set.. Right?

 

What makes sense is “the set of routers that can reach destination without traversing any links originating/attached to E”…. For doing that we will have two options

1.       RSPF rooted on the destination (will be very expensive if we have to do that for every destination node in the network)..  OR

2.       FSPF rooted on the PQ-node and check if primary neighbor E is on the SPF path from PQ-node to destination.. This is what is specified in our draft.. Assuming number of PQ-nodes are far less than number of nodes in the network this approach looked more feasible. Also now we are able to collect full path attributes for RLFA backup paths for LFA-manageability. Also RLFA does not attempt to provide 100% coverage. So like already said, implementations can decide to only consider upto a certain number of PQ-nodes to be considered in the whole network to limit the number of extra FSPFs to be computed.

 

Thanks

-Pushpasis

 

From: Levente Csikor [mailto:csikor@tmit.bme.hu]
Sent: Wednesday, October 09, 2013 5:17 PM
To: Pushpasis Sarkar
Cc: rtgwg@ietf.org; Chris Bowers
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt

 

Dear Pushpasis,
thanks for your comments.
For reactions see mine inline:

On 10/09/2013 12:49 PM, Pushpasis Sarkar wrote:

Hi Levente,

 

Please find few comments inline... 

 

Thanks

-Pushpasis

 

-----Original Message-----
From: Levente Csikor [mailto:csikor@tmit.bme.hu]
Sent: Wednesday, October 09, 2013 2:00 PM
To: rtgwg@ietf.org
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt

 

Dear All,

I also support to work more on the node protection draft first, before merging it with "basic rLFA spec", because of various reasons:

 

First, I think it would be almost a good approach to show how node-protecting remote LFA works on the same, or almost the same sample network topology used in the basic rLFA spec., but for easier and more comprehensive understanding, a bit more complex but still simple example should be given. IMHO, in the basic rLFA spec. it is a bit confusing that node E is considered as a destination and this node is the next-hop as well, since the important parts of the different roles are not dissevering enough. Because of this, the similar example in node prot spec. is also not straightforward:

[Pushpasis] If you see Table 1,2, and 3 in draft-psarkar-rtgwg-rlfa-node-protection-01 we have specified the destinations E, F (and their corresponding RLFA backup paths explicitly), that will be affected by node-failure of E. Also the destination G has been included which will still be reachable in the case of node-failure of E. Perhaps basic RLFA spec can also include such kind of illustrations

    Yeah, I know and there is also the entry in the back-up path column for G, but here, I wanted to emphasized that the connectedness of the network does not remain any other opportunities to be considered.
In other words, if there were an additional node between F and G, say H, and nodes E-D-G-H-F would also form a 5-cycle, then all your claims will remain valid, since C's shortest path to F won't avoid the failed node E, but the graph-topological requirements would be not so confusing (maybe only for me :) , but when I analyze a network to calculate the rLFA protection coverage, then I always assume this basic graph topological property to easily derive the level of protection (in percent, for example) of the possible attainable 100%).

 

"In the event of the node-failure on primary nexthop E, the alternate path from Remote-LFA nexthop C to E and F also becomes unavailable."

[Pushpasis] That is exactly we are also saying in this draft(I mean draft-psarkar-rtgwg-rlfa-node-protection-01).. If any destination takes the shortest-path segment C…E that will not have node-protection using C as the PQ node, because C is going to forward the traffic to E anyhow. In Table 2 we see that the path segment C->D->E is included in the shortest path from C to E and F. That is why in case of node-failure of E, E and F cannot provide node-protection

    It was a quote from the draft, so it is really the fact that you are saying :)

 

According to the well-known last-hop problem, it is obvious that if the destination (in the first case: node E) goes down, then it cannot be protected. Moreover, since the example network topologyis not 2-node-connected, it is obvious again that the node F, which can be accessed only via node E, then the failure of node E infers that the node F can be never reached.

To (re)solve this issue, I suggest to use another network (in the basic rLFA spec. as well), which could be the following (all link costs are unit costs):

 

 

A----------B---------C

|          |       / |

|          |      /  |

|          |     /   |

F          G    /    H

|          |   /     |

|          |  /      |

|          | /       |

D----------E---------S

 

In this case, assuming that source node S wants to send a packet to node D, the next-hop of S is node E.

  - Link protecting case: If link(s,e) fails, then P-space of node S regarding to the failed link, would consist of node H,C,B and A, whilst the Q-space of D would consist all nodes except S and H. In this case, the PQ-nodes, as the possible repair tunnel endpoints, are node A,B and C.

  - Node protecting case: However, if node E itself fails, then the P-space of S would not alter, but the Q-space of D would only contain node F and A resulting that only node A is present in the set of PQ-nodes.

[Pushpasis] Can you elaborate on the method you used for deriving the PQ-nodes A and F here… Seems to me like you are doing a RSPF rooted on destination D and then pruning all links originating from E… I think Chris Bowers has already pointed on a different thread that while best way to guarantee node-protection is to run a RSPF rooted on each destination, we cannot afford to do so in reality… It will be much more feasible to run FSPF on fewer PQ-nodes as specified in our draft..

    I did not consider any possible way of determining PQ-nodes, only used the description of P and Q spaces from the original draft, and from my research on this topic, where every kind of spaces were defined in cost terms to easily analyze the network theoretically.

 

Also, the method specified by our draft also finds A as the node-protecting PQ-node, becoz the draft suggest to find the shortest-path from the PQ-nodes (C, B, and A) to destination D. Only the SPF path from A does not go through E, so only A will provide node-protection for D.

 

I think that this network also shows the different between the node protection and link protection, but in a more comprehensive manner. And it also demonstrates the fact mentioned in Figure 2 that for node-protecting rLFA, only the Q-spaces should be checked with those distance functions.

 

Moreover, if we assume that in the example network above, there is a link (A,E) and node E itself failed again, than PQ-space would be and empty set meaning that this case cannot be protected.

[Pushpasis] True. Our draft will also pick A->E->D as the SPF from A to D in that case and disqualify A as node-protecting PQ-node. In reality too there is no feasible path in this case till A re-converges after learning E’s node-failure

    I know that it is true, I just wanted to say that by this network, the case of absence of node protection could be demonstrated easily assuming that the main example was the network described above.

 

Second, it would be better in the draft if the questions about "how difficult or impossible to obtain those distances" would be clearly stated in a bullet point list:

For example:

  - Q-space can be obtained by rSPF calculated at destination node D

  - P-space can be obtained through SPF calculation at source node S and its 1-hop neighbor.

  - SPF at a PQ-node is impossible or if not what extensions should be implemented (actually, IMHO, this is the one, which is not clear enough)

[Pushpasis] The first two should really be addressed in the original RLFA draft. Chris has already written to the authors on this mailing list with suggesting text for the draft. The third one is no different than standard SPF we need for RFC5286 implementation.. only difference being that it is rooted on PQ-nodes  in case of RLFA… It is up to individual implementations to come up with ways to constraint those to a limit.

    Thanks

 

Third, according to the Targeted-LDP discussion, which is about the fact that if some node do not support TLDP, then how can be the inner MPLS label obtained from the PQ-node; I think that if we want remote LFA protection then the nodes MUST implement/support this feature, because without this the protection cannot be guaranteed. For me, it is similar to a hypothetic case for example of Not-via, where if the router do not support Not-via, then it cannot be used. Or isn't it so simple?

[Pushpasis] Again this is more related to original RLFA draft. I will prefer the corresponding authors to address this point J

    Thanks

 

Please comment my observations, in order to help me and may others as well to understand every aspects and little pieces of remote LFA specifications.

 

Best Regards,

Levente Csikor

 

 

 

Thanks,

Levente Csikor

 


--------------020000000606030000080700-- From gabor.sandor.enyedi@ericsson.com Wed Oct 9 08:07:05 2013 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 69BD221F93C4 for ; Wed, 9 Oct 2013 08:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=-2.425, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNOas02bByUO for ; Wed, 9 Oct 2013 08:05:59 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 48F9321F915C for ; Wed, 9 Oct 2013 08:05:46 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-c8-525570c5a55d Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 3B.C9.25272.5C075525; Wed, 9 Oct 2013 17:05:41 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.84]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Wed, 9 Oct 2013 17:05:35 +0200 From: =?iso-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= To: Levente Csikor , Pushpasis Sarkar Subject: RE: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt Thread-Topic: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt Thread-Index: AQHOv0y3gq/zYv8ebkapff/PXpmus5nhNQ8AgAd5wgCAAGL7AIABgpSAgAA55ICAASUigIAAJvWAgAAP7gCAAC1SAIAABkGAgAAjkUA= Date: Wed, 9 Oct 2013 15:05:35 +0000 Message-ID: References: <52551411.6080503@tmit.bme.hu> <0560d0a67fcc4af688176a280f9bdf3f@BN1PR05MB520.namprd05.prod.outlook.com> <5255421C.2010101@tmit.bme.hu> <52556D5F.4090308@tmit.bme.hu> In-Reply-To: <52556D5F.4090308@tmit.bme.hu> Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_F1429C3E9C264E4EAEB43B5422D0D5D11166243AESESSMB307erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+Jvre7RgtAgg+4vshZ/dn9mtLiy5zOT xYU3v5kdmD2WLPnJ5HG96Sq7x7Jn81gDmKO4bFJSczLLUov07RK4Mr6/PM9ecGg1U8XBAyeY Gxgb/jF2MXJySAiYSKx4/5MVwhaTuHBvPVsXIxeHkMBRRon+CT1gCSGBRYwSh256gNhsAsES 2x9sYAOxRQQCJc4feQ40iIODWUBVYvM2W5CwMFDJmT2TmCFKQiQmLLnNAlIiIlAmcXejKkiY RUBF4tGHBrDpvAK+EpNmLWGH2HScSeLOxUwQm1NAW+LJlh1g0xkFZCUerrUACTMLiEvcejKf CeJiAYkle84zQ9iiEi8f/4P6RFHi46t9jBD1+RJb9y9gg1glKHFy5hOWCYyis5CMmoWkbBaS Moi4nsSNqVPYIGxtiWULXzND2LoSM/4dYkEWX8DIvoqRozi1OCk33chgEyMwzg5u+W2xg/Hy X5tDjNIcLErivB/fOgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYNyiEVm5zeJUlGqWdNzL upPnt8r7uyTqBH8wcHhz2n5Ll+189btMU5ZxxjzMl/m2aZJL85lfWlOOds49eFzgZVVwOWsU R963MNerd5Zm1qncbp0p9kl4VlhvX4kpg4BW9NUfbOFOu2WMJykcUjaaesLPbuWq7Y/emwnp /vx/WPneh+M54q8WCyixFGckGmoxFxUnAgARyyiKgQIAAA== 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, 09 Oct 2013 15:07:06 -0000 --_000_F1429C3E9C264E4EAEB43B5422D0D5D11166243AESESSMB307erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, "That's why I said that theoretical investigation of the rLFA node-protecti= ng failure coverage needs 2-node-connected networks to suppose that may 100= % node-protection can be reached." What if we say that 100% node-protection means that 100% of those node fail= ures can be protected, which do not split the network? BR, Gabor From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of L= evente Csikor Sent: Wednesday, October 09, 2013 4:51 PM To: Pushpasis Sarkar Cc: rtgwg@ietf.org Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-= 01.txt To calculate, which nodes are in the Q-space I've just looked for nodes for= which your distance function in Fig.2. applies. >From an industrial/implementation point of view, I have no exact claim how = the calculations should be made. Furthermore, assuming that only link failures are considered in a unit cost= network (where every link has the same unit cost), then rLFA provides 100%= failure coverage. Note that in this case the minimal graph topological req= uirement is 2-edge-connectivity. That's why I said that theoretical investi= gation of the rLFA node-protecting failure coverage needs 2-node-connected = networks to suppose that may 100% node-protection can be reached. On 10/09/2013 04:28 PM, Pushpasis Sarkar wrote: Hi Levente, "I did not consider any possible way of determining PQ-nodes, only used the= description of P and Q spaces from the original draft, and from my researc= h on this topic, where every kind of spaces were defined in cost terms to e= asily analyze the network theoretically." The original Q-space definition is... "the set of routers which can reach the primary neighbor E can without trav= ersing the link (S-E) being protected" What will the definition for Q-space definition in this case? Do you mean..= . " the set of routers than can reach the primary neighbor E without traversi= ng any links originating from E"? That will leave no routers in the set.. R= ight? What makes sense is "the set of routers that can reach destination without = traversing any links originating/attached to E".... For doing that we will = have two options 1. RSPF rooted on the destination (will be very expensive if we have = to do that for every destination node in the network).. OR 2. FSPF rooted on the PQ-node and check if primary neighbor E is on t= he SPF path from PQ-node to destination.. This is what is specified in our = draft.. Assuming number of PQ-nodes are far less than number of nodes in th= e network this approach looked more feasible. Also now we are able to colle= ct full path attributes for RLFA backup paths for LFA-manageability. Also R= LFA does not attempt to provide 100% coverage. So like already said, implem= entations can decide to only consider upto a certain number of PQ-nodes to = be considered in the whole network to limit the number of extra FSPFs to be= computed. Thanks -Pushpasis From: Levente Csikor [mailto:csikor@tmit.bme.hu] Sent: Wednesday, October 09, 2013 5:17 PM To: Pushpasis Sarkar Cc: rtgwg@ietf.org; Chris Bowers Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-= 01.txt Dear Pushpasis, thanks for your comments. For reactions see mine inline: On 10/09/2013 12:49 PM, Pushpasis Sarkar wrote: Hi Levente, Please find few comments inline... Thanks -Pushpasis -----Original Message----- From: Levente Csikor [mailto:csikor@tmit.bme.hu] Sent: Wednesday, October 09, 2013 2:00 PM To: rtgwg@ietf.org Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-= 01.txt Dear All, I also support to work more on the node protection draft first, before merg= ing it with "basic rLFA spec", because of various reasons: First, I think it would be almost a good approach to show how node-protecti= ng remote LFA works on the same, or almost the same sample network topology= used in the basic rLFA spec., but for easier and more comprehensive unders= tanding, a bit more complex but still simple example should be given. IMHO,= in the basic rLFA spec. it is a bit confusing that node E is considered as= a destination and this node is the next-hop as well, since the important p= arts of the different roles are not dissevering enough. Because of this, th= e similar example in node prot spec. is also not straightforward: [Pushpasis] If you see Table 1,2, and 3 in draft-psarkar-rtgwg-rlfa-node-pr= otection-01 we have specified the destinations E, F (and their correspondin= g RLFA backup paths explicitly), that will be affected by node-failure of E= . Also the destination G has been included which will still be reachable in= the case of node-failure of E. Perhaps basic RLFA spec can also include su= ch kind of illustrations Yeah, I know and there is also the entry in the back-up path column for= G, but here, I wanted to emphasized that the connectedness of the network = does not remain any other opportunities to be considered. In other words, if there were an additional node between F and G, say H, an= d nodes E-D-G-H-F would also form a 5-cycle, then all your claims will rema= in valid, since C's shortest path to F won't avoid the failed node E, but t= he graph-topological requirements would be not so confusing (maybe only for= me :) , but when I analyze a network to calculate the rLFA protection cove= rage, then I always assume this basic graph topological property to easily = derive the level of protection (in percent, for example) of the possible at= tainable 100%). "In the event of the node-failure on primary nexthop E, the alternate path = from Remote-LFA nexthop C to E and F also becomes unavailable." [Pushpasis] That is exactly we are also saying in this draft(I mean draft-p= sarkar-rtgwg-rlfa-node-protection-01).. If any destination takes the shorte= st-path segment C...E that will not have node-protection using C as the PQ = node, because C is going to forward the traffic to E anyhow. In Table 2 we = see that the path segment C->D->E is included in the shortest path from C t= o E and F. That is why in case of node-failure of E, E and F cannot provide= node-protection It was a quote from the draft, so it is really the fact that you are sa= ying :) According to the well-known last-hop problem, it is obvious that if the des= tination (in the first case: node E) goes down, then it cannot be protected= . Moreover, since the example network topologyis not 2-node-connected, it i= s obvious again that the node F, which can be accessed only via node E, the= n the failure of node E infers that the node F can be never reached. To (re)solve this issue, I suggest to use another network (in the basic rLF= A spec. as well), which could be the following (all link costs are unit cos= ts): A----------B---------C | | / | | | / | | | / | F G / H | | / | | | / | | | / | D----------E---------S In this case, assuming that source node S wants to send a packet to node D,= the next-hop of S is node E. - Link protecting case: If link(s,e) fails, then P-space of node S regard= ing to the failed link, would consist of node H,C,B and A, whilst the Q-spa= ce of D would consist all nodes except S and H. In this case, the PQ-nodes,= as the possible repair tunnel endpoints, are node A,B and C. - Node protecting case: However, if node E itself fails, then the P-space= of S would not alter, but the Q-space of D would only contain node F and A= resulting that only node A is present in the set of PQ-nodes. [Pushpasis] Can you elaborate on the method you used for deriving the PQ-no= des A and F here... Seems to me like you are doing a RSPF rooted on destina= tion D and then pruning all links originating from E... I think Chris Bower= s has already pointed on a different thread that while best way to guarante= e node-protection is to run a RSPF rooted on each destination, we cannot af= ford to do so in reality... It will be much more feasible to run FSPF on fe= wer PQ-nodes as specified in our draft.. I did not consider any possible way of determining PQ-nodes, only used = the description of P and Q spaces from the original draft, and from my rese= arch on this topic, where every kind of spaces were defined in cost terms t= o easily analyze the network theoretically. Also, the method specified by our draft also finds A as the node-protecting= PQ-node, becoz the draft suggest to find the shortest-path from the PQ-nod= es (C, B, and A) to destination D. Only the SPF path from A does not go thr= ough E, so only A will provide node-protection for D. I think that this network also shows the different between the node protect= ion and link protection, but in a more comprehensive manner. And it also de= monstrates the fact mentioned in Figure 2 that for node-protecting rLFA, on= ly the Q-spaces should be checked with those distance functions. Moreover, if we assume that in the example network above, there is a link (= A,E) and node E itself failed again, than PQ-space would be and empty set m= eaning that this case cannot be protected. [Pushpasis] True. Our draft will also pick A->E->D as the SPF from A to D i= n that case and disqualify A as node-protecting PQ-node. In reality too the= re is no feasible path in this case till A re-converges after learning E's = node-failure I know that it is true, I just wanted to say that by this network, the = case of absence of node protection could be demonstrated easily assuming th= at the main example was the network described above. Second, it would be better in the draft if the questions about "how difficu= lt or impossible to obtain those distances" would be clearly stated in a bu= llet point list: For example: - Q-space can be obtained by rSPF calculated at destination node D - P-space can be obtained through SPF calculation at source node S and it= s 1-hop neighbor. - SPF at a PQ-node is impossible or if not what extensions should be impl= emented (actually, IMHO, this is the one, which is not clear enough) [Pushpasis] The first two should really be addressed in the original RLFA d= raft. Chris has already written to the authors on this mailing list with su= ggesting text for the draft. The third one is no different than standard SP= F we need for RFC5286 implementation.. only difference being that it is roo= ted on PQ-nodes in case of RLFA... It is up to individual implementations = to come up with ways to constraint those to a limit. Thanks Third, according to the Targeted-LDP discussion, which is about the fact th= at if some node do not support TLDP, then how can be the inner MPLS label o= btained from the PQ-node; I think that if we want remote LFA protection the= n the nodes MUST implement/support this feature, because without this the p= rotection cannot be guaranteed. For me, it is similar to a hypothetic case = for example of Not-via, where if the router do not support Not-via, then it= cannot be used. Or isn't it so simple? [Pushpasis] Again this is more related to original RLFA draft. I will prefe= r the corresponding authors to address this point :) Thanks Please comment my observations, in order to help me and may others as well = to understand every aspects and little pieces of remote LFA specifications. Best Regards, Levente Csikor Thanks, Levente Csikor --_000_F1429C3E9C264E4EAEB43B5422D0D5D11166243AESESSMB307erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

“That's why I said that theoretical investigati= on of the rLFA node-protecting failure coverage needs 2-node-connected netw= orks to suppose that may 100% node-protection can be reached.”

 

What if we say = that 100% node-protection means that 100% of those node failures can be pro= tected, which do not split the network?

BR,<= /span>

 

Gabor

 

 

From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf= .org] On Behalf Of Levente Csikor
Sent: Wednesday, October 09, 2013 4:51 PM
To: Pushpasis Sarkar
Cc: rtgwg@ietf.org
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-prot= ection-01.txt

 

To calculate, which nodes are in the Q-space I've just look= ed for nodes for which your distance function in Fig.2. applies.
From an industrial/implementation point of view, I have no exact claim = how the calculations should be made.

Furthermore, assuming that only link failures are considered in a unit = cost network (where every link has the same unit cost), then rLFA provides = 100% failure coverage. Note that in this case the minimal graph topological= requirement is 2-edge-connectivity. That's why I said that theoretical investigation of the rLFA node-protecti= ng failure coverage needs 2-node-connected networks to suppose that may 100= % node-protection can be reached.

On 10/09/2013 04:28 PM, Pushpasis Sarkar wrote:=

Hi Levente,

 

“I did not consider any possible way of determi= ning PQ-nodes, only used the description of P and Q spaces from the origina= l draft, and from my research on this topic, where every kind of spaces were defined in cost terms to easily analyze th= e network theoretically.”

 

The original Q-space d= efinition is…  

“the set of rout= ers which can reach the primary neighbor E can without traversing the link = (S-E) being protected”

 

What will the definiti= on for Q-space definition in this case? Do you mean…

“ the set of rou= ters than can reach the primary neighbor E without traversing any links ori= ginating from E”? That will leave no routers in the set.. Right?

 

What makes sense is &#= 8220;the set of routers that can reach destination without traversing any l= inks originating/attached to E”…. For doing that we will have t= wo options

1.    = ;   RSPF rooted on the destination (will b= e very expensive if we have to do that for every destination node in the ne= twork)..  OR

2.    = ;   FSPF rooted on the PQ-node and check i= f primary neighbor E is on the SPF path from PQ-node to destination.. This = is what is specified in our draft.. Assuming number of PQ-nodes are far les= s than number of nodes in the network this approach looked more feasible. Also now we are able to collect full p= ath attributes for RLFA backup paths for LFA-manageability. Also RLFA does = not attempt to provide 100% coverage. So like already said, implementations= can decide to only consider upto a certain number of PQ-nodes to be considered in the whole network to limi= t the number of extra FSPFs to be computed.

 

Thanks

-Pushpasis=

 

From:= Levente Csikor [mailto:csikor@tmit.bme.hu]
Sent: Wednesday, October 09, 2013 5:17 PM
To: Pushpasis Sarkar
Cc: rtgwg@ietf.org; Chris Bowe= rs
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-prot= ection-01.txt

 

Dear Pushpasis,
thanks for your comments.
For reactions see mine inline:

On 10/09/2013 12:49 PM, Pushpasis Sarkar wrote:=

Hi Levente,

 

Please find few comments inline... 

 

Thanks

-Pushpasis

 

-----Original Message-----
From: Levente Csikor [mailto:csikor@t= mit.bme.hu]
Sent: Wednesday, October 09, 2013 2:00 PM
To: rtgwg@ietf.org
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-= 01.txt

 

Dear All,

I also support to work more on the node protectio= n draft first, before merging it with "basic rLFA spec", because = of various reasons:

 

First, I think it would be almost a good approach= to show how node-protecting remote LFA works on the same, or almost the sa= me sample network topology used in the basic rLFA spec., but for easier and= more comprehensive understanding, a bit more complex but still simple example should be given. IMHO, in the = basic rLFA spec. it is a bit confusing that node E is considered as a desti= nation and this node is the next-hop as well, since the important parts of = the different roles are not dissevering enough. Because of this, the similar example in node prot spec. is also no= t straightforward:

[Pushpasis] If y= ou see Table 1,2, and 3 in draft-psarkar-rtgwg-rlfa-node-protection-01 we h= ave specified the destinations E, F (and their corresponding RLFA backup pa= ths explicitly), that will be affected by node-failure of E. Also the destination G has been included which will = still be reachable in the case of node-failure of E. Perhaps basic RLFA spe= c can also include such kind of illustrations

    Yeah, I know and there is a= lso the entry in the back-up path column for G, but here, I wanted to empha= sized that the connectedness of the network does not remain any other oppor= tunities to be considered.
In other words, if there were an additional node between F and G, say H= , and nodes E-D-G-H-F would also form a 5-cycle, then all your claims will = remain valid, since C's shortest path to F won't avoid the failed node E, b= ut the graph-topological requirements would be not so confusing (maybe only for me :) , but when I analyze a net= work to calculate the rLFA protection coverage, then I always assume this b= asic graph topological property to easily derive the level of protection (i= n percent, for example) of the possible attainable 100%).


 

"In the event of the node-failure on primary= nexthop E, the alternate path from Remote-LFA nexthop C to E and F also be= comes unavailable."

[Pushpasis] That= is exactly we are also saying in this draft(I mean draft-psarkar-rtgwg-rlf= a-node-protection-01).. If any destination takes the shortest-path segment = C…E that will not have node-protection using C as the PQ node, because C is going to forward the traffic to E any= how. In Table 2 we see that the path segment C->D->E is included in t= he shortest path from C to E and F. That is why in case of node-failure of = E, E and F cannot provide node-protection

  =   It was a quote = from the draft, so it is really the fact that you are saying :)=


 

According to the well-known last-hop problem, it = is obvious that if the destination (in the first case: node E) goes down, t= hen it cannot be protected. Moreover, since the example network topologyis = not 2-node-connected, it is obvious again that the node F, which can be accessed only via node E, then the fai= lure of node E infers that the node F can be never reached.

To (re)solve this issue, I suggest to use another= network (in the basic rLFA spec. as well), which could be the following (a= ll link costs are unit costs):

 

 

A----------B---------C

|        =   |       / |

|        =   |      /  |

|        =   |     /   |

F        =   G    /    H

|        =   |   /     |

|        =   |  /      |

|        =   | /       |

D----------E---------S

 

In this case, assuming that source node S wants t= o send a packet to node D, the next-hop of S is node E.

  - Link protecting case: If link(s,e) fails= , then P-space of node S regarding to the failed link, would consist of nod= e H,C,B and A, whilst the Q-space of D would consist all nodes except S and= H. In this case, the PQ-nodes, as the possible repair tunnel endpoints, are node A,B and C.

  - Node protecting case: However, if node E= itself fails, then the P-space of S would not alter, but the Q-space of D = would only contain node F and A resulting that only node A is present in th= e set of PQ-nodes.

[Pushpasis] Can = you elaborate on the method you used for deriving the PQ-nodes A and F here= … Seems to me like you are doing a RSPF rooted on destination D and t= hen pruning all links originating from E… I think Chris Bowers has already pointed on a different thread that while = best way to guarantee node-protection is to run a RSPF rooted on each desti= nation, we cannot afford to do so in reality… It will be much more fe= asible to run FSPF on fewer PQ-nodes as specified in our draft..

    I did not consider any poss= ible way of determining PQ-nodes, only used the description of P and Q spac= es from the original draft, and from my research on this topic, where every= kind of spaces were defined in cost terms to easily analyze the network theoretically.


 

Also, the method= specified by our draft also finds A as the node-protecting PQ-node, becoz = the draft suggest to find the shortest-path from the PQ-nodes (C, B, and A)= to destination D. Only the SPF path from A does not go through E, so only A will provide node-protection for D= .

 

I think that this network also shows the differen= t between the node protection and link protection, but in a more comprehens= ive manner. And it also demonstrates the fact mentioned in Figure 2 that fo= r node-protecting rLFA, only the Q-spaces should be checked with those distance functions.

 

Moreover, if we assume that in the example networ= k above, there is a link (A,E) and node E itself failed again, than PQ-spac= e would be and empty set meaning that this case cannot be protected.

[Pushpasis] True= . Our draft will also pick A->E->D as the SPF from A to D in that cas= e and disqualify A as node-protecting PQ-node. In reality too there is no f= easible path in this case till A re-converges after learning E’s node-failure

  =   I know that it = is true, I just wanted to say that by this network, the case of absence of = node protection could be demonstrated easily assuming that the main example was the network described above.


 

Second, it would be better in the draft if the qu= estions about "how difficult or impossible to obtain those distances&q= uot; would be clearly stated in a bullet point list:

For example:

  - Q-space can be obtained by rSPF calculat= ed at destination node D

  - P-space can be obtained through SPF calc= ulation at source node S and its 1-hop neighbor.

  - SPF at a PQ-node is impossible or if not= what extensions should be implemented (actually, IMHO, this is the one, wh= ich is not clear enough)

[Pushpasis] The = first two should really be addressed in the original RLFA draft. Chris has = already written to the authors on this mailing list with suggesting text fo= r the draft. The third one is no different than standard SPF we need for RFC5286 implementation.. only difference bei= ng that it is rooted on PQ-nodes  in case of RLFA… It is up to i= ndividual implementations to come up with ways to constraint those to a lim= it.

    Thanks


 

Third, according to the Targeted-LDP discussion, = which is about the fact that if some node do not support TLDP, then how can= be the inner MPLS label obtained from the PQ-node; I think that if we want= remote LFA protection then the nodes MUST implement/support this feature, because without this the protection c= annot be guaranteed. For me, it is similar to a hypothetic case for example= of Not-via, where if the router do not support Not-via, then it cannot be = used. Or isn't it so simple?

[Pushpasis] Agai= n this is more related to original RLFA draft. I will prefer the correspond= ing authors to address this point J<= /b>

    Thanks


 

Please comment my observations, in order to help = me and may others as well to understand every aspects and little pieces of = remote LFA specifications.

 

Best Regards,

Levente Csikor

 

 

 

Thanks,

Levente Csikor

 

 

--_000_F1429C3E9C264E4EAEB43B5422D0D5D11166243AESESSMB307erics_-- From psarkar@juniper.net Wed Oct 9 08:46:35 2013 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 8273411E8198 for ; Wed, 9 Oct 2013 08:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0W5zwf9-YAbX for ; Wed, 9 Oct 2013 08:46:29 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0250.outbound.messaging.microsoft.com [213.199.154.250]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB7611E8192 for ; Wed, 9 Oct 2013 08:46:25 -0700 (PDT) Received: from mail157-db9-R.bigfish.com (10.174.16.232) by DB9EHSOBE002.bigfish.com (10.174.14.65) with Microsoft SMTP Server id 14.1.225.22; Wed, 9 Oct 2013 15:46:24 +0000 Received: from mail157-db9 (localhost [127.0.0.1]) by mail157-db9-R.bigfish.com (Postfix) with ESMTP id 5323E420227; Wed, 9 Oct 2013 15:46:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(zzbb2dI98dI9371I1431Jc85fh542I1418I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah18c673h1de097h186068h8275bh8275dhz2fh2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h9a9j1155h) Received-SPF: pass (mail157-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=psarkar@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(479174003)(199002)(189002)(377454003)(51694002)(51444003)(164054003)(13464003)(77982001)(63696002)(54316002)(54356001)(59766001)(33646001)(56776001)(53806001)(85306002)(47446002)(83322001)(19580405001)(19580395003)(81816001)(74502001)(51856001)(76796001)(76786001)(74316001)(46102001)(76576001)(4396001)(49866001)(69226001)(16236675002)(19300405004)(50986001)(47976001)(74876001)(81686001)(47736001)(74366001)(65816001)(76482001)(74706001)(15975445006)(81342001)(81542001)(15202345003)(79102001)(66066001)(80022001)(56816003)(77096001)(74662001)(31966008)(83072001)(80976001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB518; H:BN1PR05MB520.namprd05.prod.outlook.com; CLIP:116.197.178.91; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail157-db9 (localhost.localdomain [127.0.0.1]) by mail157-db9 (MessageSwitch) id 1381333581357461_26484; Wed, 9 Oct 2013 15:46:21 +0000 (UTC) Received: from DB9EHSMHS019.bigfish.com (unknown [10.174.16.230]) by mail157-db9.bigfish.com (Postfix) with ESMTP id 528D71E0094; Wed, 9 Oct 2013 15:46:21 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS019.bigfish.com (10.174.14.29) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 9 Oct 2013 15:46:20 +0000 Received: from BN1PR05MB518.namprd05.prod.outlook.com (10.141.65.143) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.371.2; Wed, 9 Oct 2013 15:46:15 +0000 Received: from BN1PR05MB520.namprd05.prod.outlook.com (10.141.65.151) by BN1PR05MB518.namprd05.prod.outlook.com (10.141.65.143) with Microsoft SMTP Server (TLS) id 15.0.775.9; Wed, 9 Oct 2013 15:46:14 +0000 Received: from BN1PR05MB520.namprd05.prod.outlook.com ([169.254.16.135]) by BN1PR05MB520.namprd05.prod.outlook.com ([169.254.16.135]) with mapi id 15.00.0775.005; Wed, 9 Oct 2013 15:46:14 +0000 From: Pushpasis Sarkar To: Levente Csikor Subject: RE: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt Thread-Topic: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt Thread-Index: AQHOxPvetrh3EkzRN0CUBJla0U+fVpnsdAWAgAAGvVA= Date: Wed, 9 Oct 2013 15:46:13 +0000 Message-ID: <5f5758bf22ac4eb280dd93ef07224ec4@BN1PR05MB520.namprd05.prod.outlook.com> References: <52551411.6080503@tmit.bme.hu> <0560d0a67fcc4af688176a280f9bdf3f@BN1PR05MB520.namprd05.prod.outlook.com> <5255421C.2010101@tmit.bme.hu> <52556D5F.4090308@tmit.bme.hu> In-Reply-To: <52556D5F.4090308@tmit.bme.hu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.178.91] x-forefront-prvs: 0994F5E0C5 Content-Type: multipart/alternative; boundary="_000_5f5758bf22ac4eb280dd93ef07224ec4BN1PR05MB520namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 09 Oct 2013 15:46:35 -0000 --_000_5f5758bf22ac4eb280dd93ef07224ec4BN1PR05MB520namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Levente, As far as I understand.. 100% protection coverage means as long as there is= a single feasible alternate path in the network, the protecting router sha= ll use it to provide traffic protection.. irrespective of whether it is all= unit cost link or not.. irrespective of whether the single feasible path i= s on the shortest path from any of my neighbor or not. There has to be just= another path with any cost other than the primary path. Thanks -Pushpasis From: Levente Csikor [mailto:csikor@tmit.bme.hu] Sent: Wednesday, October 09, 2013 8:21 PM To: Pushpasis Sarkar Cc: rtgwg@ietf.org; Chris Bowers Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-= 01.txt To calculate, which nodes are in the Q-space I've just looked for nodes for= which your distance function in Fig.2. applies. >From an industrial/implementation point of view, I have no exact claim how = the calculations should be made. Furthermore, assuming that only link failures are considered in a unit cost= network (where every link has the same unit cost), then rLFA provides 100%= failure coverage. Note that in this case the minimal graph topological req= uirement is 2-edge-connectivity. That's why I said that theoretical investi= gation of the rLFA node-protecting failure coverage needs 2-node-connected = networks to suppose that may 100% node-protection can be reached. On 10/09/2013 04:28 PM, Pushpasis Sarkar wrote: Hi Levente, "I did not consider any possible way of determining PQ-nodes, only used the= description of P and Q spaces from the original draft, and from my researc= h on this topic, where every kind of spaces were defined in cost terms to e= asily analyze the network theoretically." The original Q-space definition is... "the set of routers which can reach the primary neighbor E can without trav= ersing the link (S-E) being protected" What will the definition for Q-space definition in this case? Do you mean..= . " the set of routers than can reach the primary neighbor E without traversi= ng any links originating from E"? That will leave no routers in the set.. R= ight? What makes sense is "the set of routers that can reach destination without = traversing any links originating/attached to E".... For doing that we will = have two options 1. RSPF rooted on the destination (will be very expensive if we have = to do that for every destination node in the network).. OR 2. FSPF rooted on the PQ-node and check if primary neighbor E is on t= he SPF path from PQ-node to destination.. This is what is specified in our = draft.. Assuming number of PQ-nodes are far less than number of nodes in th= e network this approach looked more feasible. Also now we are able to colle= ct full path attributes for RLFA backup paths for LFA-manageability. Also R= LFA does not attempt to provide 100% coverage. So like already said, implem= entations can decide to only consider upto a certain number of PQ-nodes to = be considered in the whole network to limit the number of extra FSPFs to be= computed. Thanks -Pushpasis From: Levente Csikor [mailto:csikor@tmit.bme.hu] Sent: Wednesday, October 09, 2013 5:17 PM To: Pushpasis Sarkar Cc: rtgwg@ietf.org; Chris Bowers Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-= 01.txt Dear Pushpasis, thanks for your comments. For reactions see mine inline: On 10/09/2013 12:49 PM, Pushpasis Sarkar wrote: Hi Levente, Please find few comments inline... Thanks -Pushpasis -----Original Message----- From: Levente Csikor [mailto:csikor@tmit.bme.hu] Sent: Wednesday, October 09, 2013 2:00 PM To: rtgwg@ietf.org Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-= 01.txt Dear All, I also support to work more on the node protection draft first, before merg= ing it with "basic rLFA spec", because of various reasons: First, I think it would be almost a good approach to show how node-protecti= ng remote LFA works on the same, or almost the same sample network topology= used in the basic rLFA spec., but for easier and more comprehensive unders= tanding, a bit more complex but still simple example should be given. IMHO,= in the basic rLFA spec. it is a bit confusing that node E is considered as= a destination and this node is the next-hop as well, since the important p= arts of the different roles are not dissevering enough. Because of this, th= e similar example in node prot spec. is also not straightforward: [Pushpasis] If you see Table 1,2, and 3 in draft-psarkar-rtgwg-rlfa-node-pr= otection-01 we have specified the destinations E, F (and their correspondin= g RLFA backup paths explicitly), that will be affected by node-failure of E= . Also the destination G has been included which will still be reachable in= the case of node-failure of E. Perhaps basic RLFA spec can also include su= ch kind of illustrations Yeah, I know and there is also the entry in the back-up path column for= G, but here, I wanted to emphasized that the connectedness of the network = does not remain any other opportunities to be considered. In other words, if there were an additional node between F and G, say H, an= d nodes E-D-G-H-F would also form a 5-cycle, then all your claims will rema= in valid, since C's shortest path to F won't avoid the failed node E, but t= he graph-topological requirements would be not so confusing (maybe only for= me :) , but when I analyze a network to calculate the rLFA protection cove= rage, then I always assume this basic graph topological property to easily = derive the level of protection (in percent, for example) of the possible at= tainable 100%). "In the event of the node-failure on primary nexthop E, the alternate path = from Remote-LFA nexthop C to E and F also becomes unavailable." [Pushpasis] That is exactly we are also saying in this draft(I mean draft-p= sarkar-rtgwg-rlfa-node-protection-01).. If any destination takes the shorte= st-path segment C...E that will not have node-protection using C as the PQ = node, because C is going to forward the traffic to E anyhow. In Table 2 we = see that the path segment C->D->E is included in the shortest path from C t= o E and F. That is why in case of node-failure of E, E and F cannot provide= node-protection It was a quote from the draft, so it is really the fact that you are sa= ying :) According to the well-known last-hop problem, it is obvious that if the des= tination (in the first case: node E) goes down, then it cannot be protected= . Moreover, since the example network topologyis not 2-node-connected, it i= s obvious again that the node F, which can be accessed only via node E, the= n the failure of node E infers that the node F can be never reached. To (re)solve this issue, I suggest to use another network (in the basic rLF= A spec. as well), which could be the following (all link costs are unit cos= ts): A----------B---------C | | / | | | / | | | / | F G / H | | / | | | / | | | / | D----------E---------S In this case, assuming that source node S wants to send a packet to node D,= the next-hop of S is node E. - Link protecting case: If link(s,e) fails, then P-space of node S regard= ing to the failed link, would consist of node H,C,B and A, whilst the Q-spa= ce of D would consist all nodes except S and H. In this case, the PQ-nodes,= as the possible repair tunnel endpoints, are node A,B and C. - Node protecting case: However, if node E itself fails, then the P-space= of S would not alter, but the Q-space of D would only contain node F and A= resulting that only node A is present in the set of PQ-nodes. [Pushpasis] Can you elaborate on the method you used for deriving the PQ-no= des A and F here... Seems to me like you are doing a RSPF rooted on destina= tion D and then pruning all links originating from E... I think Chris Bower= s has already pointed on a different thread that while best way to guarante= e node-protection is to run a RSPF rooted on each destination, we cannot af= ford to do so in reality... It will be much more feasible to run FSPF on fe= wer PQ-nodes as specified in our draft.. I did not consider any possible way of determining PQ-nodes, only used = the description of P and Q spaces from the original draft, and from my rese= arch on this topic, where every kind of spaces were defined in cost terms t= o easily analyze the network theoretically. Also, the method specified by our draft also finds A as the node-protecting= PQ-node, becoz the draft suggest to find the shortest-path from the PQ-nod= es (C, B, and A) to destination D. Only the SPF path from A does not go thr= ough E, so only A will provide node-protection for D. I think that this network also shows the different between the node protect= ion and link protection, but in a more comprehensive manner. And it also de= monstrates the fact mentioned in Figure 2 that for node-protecting rLFA, on= ly the Q-spaces should be checked with those distance functions. Moreover, if we assume that in the example network above, there is a link (= A,E) and node E itself failed again, than PQ-space would be and empty set m= eaning that this case cannot be protected. [Pushpasis] True. Our draft will also pick A->E->D as the SPF from A to D i= n that case and disqualify A as node-protecting PQ-node. In reality too the= re is no feasible path in this case till A re-converges after learning E's = node-failure I know that it is true, I just wanted to say that by this network, the = case of absence of node protection could be demonstrated easily assuming th= at the main example was the network described above. Second, it would be better in the draft if the questions about "how difficu= lt or impossible to obtain those distances" would be clearly stated in a bu= llet point list: For example: - Q-space can be obtained by rSPF calculated at destination node D - P-space can be obtained through SPF calculation at source node S and it= s 1-hop neighbor. - SPF at a PQ-node is impossible or if not what extensions should be impl= emented (actually, IMHO, this is the one, which is not clear enough) [Pushpasis] The first two should really be addressed in the original RLFA d= raft. Chris has already written to the authors on this mailing list with su= ggesting text for the draft. The third one is no different than standard SP= F we need for RFC5286 implementation.. only difference being that it is roo= ted on PQ-nodes in case of RLFA... It is up to individual implementations = to come up with ways to constraint those to a limit. Thanks Third, according to the Targeted-LDP discussion, which is about the fact th= at if some node do not support TLDP, then how can be the inner MPLS label o= btained from the PQ-node; I think that if we want remote LFA protection the= n the nodes MUST implement/support this feature, because without this the p= rotection cannot be guaranteed. For me, it is similar to a hypothetic case = for example of Not-via, where if the router do not support Not-via, then it= cannot be used. Or isn't it so simple? [Pushpasis] Again this is more related to original RLFA draft. I will prefe= r the corresponding authors to address this point :) Thanks Please comment my observations, in order to help me and may others as well = to understand every aspects and little pieces of remote LFA specifications. Best Regards, Levente Csikor Thanks, Levente Csikor --_000_5f5758bf22ac4eb280dd93ef07224ec4BN1PR05MB520namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Levente,=

 

As far as I understand= .. 100% protection coverage means as long as there is a single feasible alt= ernate path in the network, the protecting router shall use it to provide t= raffic protection.. irrespective of whether it is all unit cost link or not.. irrespective of whether the sing= le feasible path is on the shortest path from any of my neighbor or not. Th= ere has to be just another path with any cost other than the primary path.<= o:p>

 

Thanks

-Pushpasis<= /span>

 

From:= Levente Csikor [mailto:csikor@tmit.bme.hu= ]
Sent: Wednesday, October 09, 2013 8:21 PM
To: Pushpasis Sarkar
Cc: rtgwg@ietf.org; Chris Bowers
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-prot= ection-01.txt

 

To calculate, which nodes are in the Q-space I've just look= ed for nodes for which your distance function in Fig.2. applies.
From an industrial/implementation point of view, I have no exact claim = how the calculations should be made.

Furthermore, assuming that only link failures are considered in a unit = cost network (where every link has the same unit cost), then rLFA provides = 100% failure coverage. Note that in this case the minimal graph topological= requirement is 2-edge-connectivity. That's why I said that theoretical investigation of the rLFA node-protecti= ng failure coverage needs 2-node-connected networks to suppose that may 100= % node-protection can be reached.

On 10/09/2013 04:28 PM, Pushpasis Sarkar wrote:=

Hi Levente,

 

“I did not consider any possible way of determi= ning PQ-nodes, only used the description of P and Q spaces from the origina= l draft, and from my research on this topic, where every kind of spaces were defined in cost terms to easily analyze th= e network theoretically.”

 

The original Q-space d= efinition is…  

“the set of rout= ers which can reach the primary neighbor E can without traversing the link = (S-E) being protected”

 

What will the definiti= on for Q-space definition in this case? Do you mean…

“ the set of rou= ters than can reach the primary neighbor E without traversing any links ori= ginating from E”? That will leave no routers in the set.. Right?

 

What makes sense is &#= 8220;the set of routers that can reach destination without traversing any l= inks originating/attached to E”…. For doing that we will have t= wo options

1.     &= nbsp; RSPF rooted on the de= stination (will be very expensive if we have to do that for every destinati= on node in the network)..  OR

2.     &= nbsp; FSPF rooted on the PQ= -node and check if primary neighbor E is on the SPF path from PQ-node to de= stination.. This is what is specified in our draft.. Assuming number of PQ-= nodes are far less than number of nodes in the network this approach looked more feasible. Also now we are a= ble to collect full path attributes for RLFA backup paths for LFA-manageabi= lity. Also RLFA does not attempt to provide 100% coverage. So like already = said, implementations can decide to only consider upto a certain number of PQ-nodes to be considered in the= whole network to limit the number of extra FSPFs to be computed.

 

Thanks

-Pushpasis=

 

From:= Levente Csikor [mailto:csikor@tmit.bme.hu]
Sent: Wednesday, October 09, 2013 5:17 PM
To: Pushpasis Sarkar
Cc: rtgwg@ietf.org; Chris Bowers
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-prot= ection-01.txt

 

Dear Pushpasis,
thanks for your comments.
For reactions see mine inline:

On 10/09/2013 12:49 PM, Pushpasis Sarkar wrote:=

Hi Levente,

 

Please find few comments inline... 

 

Thanks

-Pushpasis

 

-----Original Message-----
From: Levente Csikor [mailto:csikor@t= mit.bme.hu]
Sent: Wednesday, October 09, 2013 2:00 PM
To: rtgwg@ietf.org
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-= 01.txt

 

Dear All,

I also support to work more on the node protectio= n draft first, before merging it with "basic rLFA spec", because = of various reasons:

 

First, I think it would be almost a good approach= to show how node-protecting remote LFA works on the same, or almost the sa= me sample network topology used in the basic rLFA spec., but for easier and= more comprehensive understanding, a bit more complex but still simple example should be given. IMHO, in the = basic rLFA spec. it is a bit confusing that node E is considered as a desti= nation and this node is the next-hop as well, since the important parts of = the different roles are not dissevering enough. Because of this, the similar example in node prot spec. is also no= t straightforward:

[Pushpasis] If y= ou see Table 1,2, and 3 in draft-psarkar-rtgwg-rlfa-node-protection-01 we h= ave specified the destinations E, F (and their corresponding RLFA backup pa= ths explicitly), that will be affected by node-failure of E. Also the destination G has been included which will = still be reachable in the case of node-failure of E. Perhaps basic RLFA spe= c can also include such kind of illustrations

    Yeah, I know and there is a= lso the entry in the back-up path column for G, but here, I wanted to empha= sized that the connectedness of the network does not remain any other oppor= tunities to be considered.
In other words, if there were an additional node between F and G, say H= , and nodes E-D-G-H-F would also form a 5-cycle, then all your claims will = remain valid, since C's shortest path to F won't avoid the failed node E, b= ut the graph-topological requirements would be not so confusing (maybe only for me :) , but when I analyze a net= work to calculate the rLFA protection coverage, then I always assume this b= asic graph topological property to easily derive the level of protection (i= n percent, for example) of the possible attainable 100%).


 

"In the event of the node-failure on primary= nexthop E, the alternate path from Remote-LFA nexthop C to E and F also be= comes unavailable."

[Pushpasis] That= is exactly we are also saying in this draft(I mean draft-psarkar-rtgwg-rlf= a-node-protection-01).. If any destination takes the shortest-path segment = C…E that will not have node-protection using C as the PQ node, because C is going to forward the traffic to E any= how. In Table 2 we see that the path segment C->D->E is included in t= he shortest path from C to E and F. That is why in case of node-failure of = E, E and F cannot provide node-protection

  =   It was a quote = from the draft, so it is really the fact that you are saying :)=


 

According to the well-known last-hop problem, it = is obvious that if the destination (in the first case: node E) goes down, t= hen it cannot be protected. Moreover, since the example network topologyis = not 2-node-connected, it is obvious again that the node F, which can be accessed only via node E, then the fai= lure of node E infers that the node F can be never reached.

To (re)solve this issue, I suggest to use another= network (in the basic rLFA spec. as well), which could be the following (a= ll link costs are unit costs):

 

 

A----------B---------C

|        =   |       / |

|        =   |      /  |

|        =   |     /   |

F        =   G    /    H

|        =   |   /     |

|        =   |  /      |

|        =   | /       |

D----------E---------S

 

In this case, assuming that source node S wants t= o send a packet to node D, the next-hop of S is node E.

  - Link protecting case: If link(s,e) fails= , then P-space of node S regarding to the failed link, would consist of nod= e H,C,B and A, whilst the Q-space of D would consist all nodes except S and= H. In this case, the PQ-nodes, as the possible repair tunnel endpoints, are node A,B and C.

  - Node protecting case: However, if node E= itself fails, then the P-space of S would not alter, but the Q-space of D = would only contain node F and A resulting that only node A is present in th= e set of PQ-nodes.

[Pushpasis] Can = you elaborate on the method you used for deriving the PQ-nodes A and F here= … Seems to me like you are doing a RSPF rooted on destination D and t= hen pruning all links originating from E… I think Chris Bowers has already pointed on a different thread that while = best way to guarantee node-protection is to run a RSPF rooted on each desti= nation, we cannot afford to do so in reality… It will be much more fe= asible to run FSPF on fewer PQ-nodes as specified in our draft..

    I did not consider any poss= ible way of determining PQ-nodes, only used the description of P and Q spac= es from the original draft, and from my research on this topic, where every= kind of spaces were defined in cost terms to easily analyze the network theoretically.


 

Also, the method= specified by our draft also finds A as the node-protecting PQ-node, becoz = the draft suggest to find the shortest-path from the PQ-nodes (C, B, and A)= to destination D. Only the SPF path from A does not go through E, so only A will provide node-protection for D= .

 

I think that this network also shows the differen= t between the node protection and link protection, but in a more comprehens= ive manner. And it also demonstrates the fact mentioned in Figure 2 that fo= r node-protecting rLFA, only the Q-spaces should be checked with those distance functions.

 

Moreover, if we assume that in the example networ= k above, there is a link (A,E) and node E itself failed again, than PQ-spac= e would be and empty set meaning that this case cannot be protected.

[Pushpasis] True= . Our draft will also pick A->E->D as the SPF from A to D in that cas= e and disqualify A as node-protecting PQ-node. In reality too there is no f= easible path in this case till A re-converges after learning E’s node-failure

  =   I know that it = is true, I just wanted to say that by this network, the case of absence of = node protection could be demonstrated easily assuming that the main example was the network described above.


 

Second, it would be better in the draft if the qu= estions about "how difficult or impossible to obtain those distances&q= uot; would be clearly stated in a bullet point list:

For example:

  - Q-space can be obtained by rSPF calculat= ed at destination node D

  - P-space can be obtained through SPF calc= ulation at source node S and its 1-hop neighbor.

  - SPF at a PQ-node is impossible or if not= what extensions should be implemented (actually, IMHO, this is the one, wh= ich is not clear enough)

[Pushpasis] The = first two should really be addressed in the original RLFA draft. Chris has = already written to the authors on this mailing list with suggesting text fo= r the draft. The third one is no different than standard SPF we need for RFC5286 implementation.. only difference bei= ng that it is rooted on PQ-nodes  in case of RLFA… It is up to i= ndividual implementations to come up with ways to constraint those to a lim= it.

    Thanks


 

Third, according to the Targeted-LDP discussion, = which is about the fact that if some node do not support TLDP, then how can= be the inner MPLS label obtained from the PQ-node; I think that if we want= remote LFA protection then the nodes MUST implement/support this feature, because without this the protection c= annot be guaranteed. For me, it is similar to a hypothetic case for example= of Not-via, where if the router do not support Not-via, then it cannot be = used. Or isn't it so simple?

[Pushpasis] Agai= n this is more related to original RLFA draft. I will prefer the correspond= ing authors to address this point J<= /b>

    Thanks


 

Please comment my observations, in order to help = me and may others as well to understand every aspects and little pieces of = remote LFA specifications.

 

Best Regards,

Levente Csikor

 

 

 

Thanks,

Levente Csikor

 

 

--_000_5f5758bf22ac4eb280dd93ef07224ec4BN1PR05MB520namprd05pro_-- From csikor@tmit.bme.hu Wed Oct 9 08:52:45 2013 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 0B46F11E81C5 for ; Wed, 9 Oct 2013 08:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.097 X-Spam-Level: * X-Spam-Status: No, score=1.097 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cciq9dVG2mzN for ; Wed, 9 Oct 2013 08:52:38 -0700 (PDT) Received: from ruby.tmit.bme.hu (ruby.tmit.bme.hu [152.66.245.193]) by ietfa.amsl.com (Postfix) with ESMTP id D5AE211E81AC for ; Wed, 9 Oct 2013 08:52:37 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ruby.tmit.bme.hu (Postfix) with ESMTP id 60AC187346; Wed, 9 Oct 2013 17:52:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at tmit.bme.hu Received: from ruby.tmit.bme.hu ([127.0.0.1]) by localhost (ruby.tmit.bme.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tots1fsJiDAR; Wed, 9 Oct 2013 17:51:58 +0200 (CEST) Received: from anyo.tmit.bme.hu (anyo.tmit.bme.hu [152.66.246.7]) by ruby.tmit.bme.hu (Postfix) with ESMTP id 910ED87345; Wed, 9 Oct 2013 17:51:58 +0200 (CEST) Received: from [152.66.244.179] (csikor.tmit.bme.hu [152.66.244.179]) (authenticated bits=0) by anyo.tmit.bme.hu (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r99Fq7gf002470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Oct 2013 17:52:07 +0200 Message-ID: <52557BA4.8040207@tmit.bme.hu> Date: Wed, 09 Oct 2013 17:52:04 +0200 From: Levente Csikor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Pushpasis Sarkar Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt References: <52551411.6080503@tmit.bme.hu> <0560d0a67fcc4af688176a280f9bdf3f@BN1PR05MB520.namprd05.prod.outlook.com> <5255421C.2010101@tmit.bme.hu> <52556D5F.4090308@tmit.bme.hu> <5f5758bf22ac4eb280dd93ef07224ec4@BN1PR05MB520.namprd05.prod.outlook.com> In-Reply-To: <5f5758bf22ac4eb280dd93ef07224ec4@BN1PR05MB520.namprd05.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------060003010700070209080800" 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, 09 Oct 2013 15:52:45 -0000 This is a multi-part message in MIME format. --------------060003010700070209080800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/09/2013 05:46 PM, Pushpasis Sarkar wrote: > > Hi Levente, > > As far as I understand.. 100% protection coverage means as long as > there is a single feasible alternate path in the network, the > protecting router shall use it to provide traffic protection.. > irrespective of whether it is all unit cost link or not.. irrespective > of whether the single feasible path is on the shortest path from any > of my neighbor or not. There has to be just another path with any cost > other than the primary path. > Yes > Thanks > > -Pushpasis > > *From:*Levente Csikor [mailto:csikor@tmit.bme.hu] > *Sent:* Wednesday, October 09, 2013 8:21 PM > *To:* Pushpasis Sarkar > *Cc:* rtgwg@ietf.org; Chris Bowers > *Subject:* Re: Request for review - > draft-psarkar-rtgwg-rlfa-node-protection-01.txt > > To calculate, which nodes are in the Q-space I've just looked for > nodes for which your distance function in Fig.2. applies. > From an industrial/implementation point of view, I have no exact claim > how the calculations should be made. > > Furthermore, assuming that only link failures are considered in a unit > cost network (where every link has the same unit cost), then rLFA > provides 100% failure coverage. Note that in this case the minimal > graph topological requirement is 2-edge-connectivity. That's why I > said that theoretical investigation of the rLFA node-protecting > failure coverage needs 2-node-connected networks to suppose that may > 100% node-protection can be reached. > > On 10/09/2013 04:28 PM, Pushpasis Sarkar wrote: > > Hi Levente, > > "I did not consider any possible way of determining PQ-nodes, only > used the description of P and Q spaces from the original draft, > and from my research on this topic, where every kind of spaces > were defined in cost terms to easily analyze the network > theoretically." > > The original Q-space definition is... > > "the set of routers which can reach the primary neighbor E can > without traversing the link (S-E) being protected" > > What will the definition for Q-space definition in this case? Do > you mean... > > " the set of routers than can reach the primary neighbor E without > traversing any links originating from E"? That will leave no > routers in the set.. Right? > > What makes sense is "the set of routers that can reach destination > without traversing any links originating/attached to E".... For > doing that we will have two options > > 1.RSPF rooted on the destination (will be very expensive if we > have to do that for every destination node in the network).. OR > > 2.FSPF rooted on the PQ-node and check if primary neighbor E is on > the SPF path from PQ-node to destination.. This is what is > specified in our draft.. Assuming number of PQ-nodes are far less > than number of nodes in the network this approach looked more > feasible. Also now we are able to collect full path attributes for > RLFA backup paths for LFA-manageability. Also RLFA does not > attempt to provide 100% coverage. So like already said, > implementations can decide to only consider upto a certain number > of PQ-nodes to be considered in the whole network to limit the > number of extra FSPFs to be computed. > > Thanks > > -Pushpasis > > *From:*Levente Csikor [mailto:csikor@tmit.bme.hu] > *Sent:* Wednesday, October 09, 2013 5:17 PM > *To:* Pushpasis Sarkar > *Cc:* rtgwg@ietf.org ; Chris Bowers > *Subject:* Re: Request for review - > draft-psarkar-rtgwg-rlfa-node-protection-01.txt > > Dear Pushpasis, > thanks for your comments. > For reactions see mine inline: > > On 10/09/2013 12:49 PM, Pushpasis Sarkar wrote: > > Hi Levente, > > Please find few comments inline... > > Thanks > > -Pushpasis > > -----Original Message----- > From: Levente Csikor [mailto:csikor@tmit.bme.hu] > Sent: Wednesday, October 09, 2013 2:00 PM > To: rtgwg@ietf.org > Subject: Re: Request for review - > draft-psarkar-rtgwg-rlfa-node-protection-01.txt > > Dear All, > > I also support to work more on the node protection draft > first, before merging it with "basic rLFA spec", because of > various reasons: > > First, I think it would be almost a good approach to show how > node-protecting remote LFA works on the same, or almost the > same sample network topology used in the basic rLFA spec., but > for easier and more comprehensive understanding, a bit more > complex but still simple example should be given. IMHO, in the > basic rLFA spec. it is a bit confusing that node E is > considered as a destination and this node is the next-hop as > well, since the important parts of the different roles are not > dissevering enough. Because of this, the similar example in > node prot spec. is also not straightforward: > > *[Pushpasis] If you see Table 1,2, and 3 in > draft-psarkar-rtgwg-rlfa-node-protection-01 we have specified > the destinations E, F (and their corresponding RLFA backup > paths explicitly), that will be affected by node-failure of E. > Also the destination G has been included which will still be > reachable in the case of node-failure of E. Perhaps basic RLFA > spec can also include such kind of illustrations* > > **Yeah, I know and there is also the entry in the back-up path > column for G, but here, I wanted to emphasized that the > connectedness of the network does not remain any other > opportunities to be considered. > In other words, if there were an additional node between F and G, > say H, and nodes E-D-G-H-F would also form a 5-cycle, then all > your claims will remain valid, since C's shortest path to F won't > avoid the failed node E, but the graph-topological requirements > would be not so confusing (maybe only for me :) , but when I > analyze a network to calculate the rLFA protection coverage, then > I always assume this basic graph topological property to easily > derive the level of protection (in percent, for example) of the > possible attainable 100%). > > > "In the event of the node-failure on primary nexthop E, the > alternate path from Remote-LFA nexthop C to E and F also > becomes unavailable." > > *[Pushpasis] That is exactly we are also saying in this > draft(I mean draft-psarkar-rtgwg-rlfa-node-protection-01).. If > any destination takes the shortest-path segment C...E that > will not have node-protection using C as the PQ node, because > C is going to forward the traffic to E anyhow. In Table 2 we > see that the path segment C->D->E is included in the shortest > path from C to E and F. That is why in case of node-failure of > E, E and F cannot provide node-protection* > > **It was a quote from the draft, so it is really the fact that you > are saying :) > > > According to the well-known last-hop problem, it is obvious > that if the destination (in the first case: node E) goes down, > then it cannot be protected. Moreover, since the example > network topologyis not 2-node-connected, it is obvious again > that the node F, which can be accessed only via node E, then > the failure of node E infers that the node F can be never reached. > > To (re)solve this issue, I suggest to use another network (in > the basic rLFA spec. as well), which could be the following > (all link costs are unit costs): > > A----------B---------C > > | | / | > > | | / | > > | | / | > > F G / H > > | | / | > > | | / | > > | | / | > > D----------E---------S > > In this case, assuming that source node S wants to send a > packet to node D, the next-hop of S is node E. > > - Link protecting case: If link(s,e) fails, then P-space of > node S regarding to the failed link, would consist of node > H,C,B and A, whilst the Q-space of D would consist all nodes > except S and H. In this case, the PQ-nodes, as the possible > repair tunnel endpoints, are node A,B and C. > > - Node protecting case: However, if node E itself fails, > then the P-space of S would not alter, but the Q-space of D > would only contain node F and A resulting that only node A is > present in the set of PQ-nodes. > > *[Pushpasis] Can you elaborate on the method you used for > deriving the PQ-nodes A and F here... Seems to me like you are > doing a RSPF rooted on destination D and then pruning all > links originating from E... I think Chris Bowers has already > pointed on a different thread that while best way to guarantee > node-protection is to run a RSPF rooted on each destination, > we cannot afford to do so in reality... It will be much more > feasible to run FSPF on fewer PQ-nodes as specified in our > draft..* > > **I did not consider any possible way of determining PQ-nodes, > only used the description of P and Q spaces from the original > draft, and from my research on this topic, where every kind of > spaces were defined in cost terms to easily analyze the network > theoretically. > > > ** > > *Also, the method specified by our draft also finds A as the > node-protecting PQ-node, becoz the draft suggest to find the > shortest-path from the PQ-nodes (C, B, and A) to destination > D. Only the SPF path from A does not go through E, so only A > will provide node-protection for D.* > > I think that this network also shows the different between the > node protection and link protection, but in a more > comprehensive manner. And it also demonstrates the fact > mentioned in Figure 2 that for node-protecting rLFA, only the > Q-spaces should be checked with those distance functions. > > Moreover, if we assume that in the example network above, > there is a link (A,E) and node E itself failed again, than > PQ-space would be and empty set meaning that this case cannot > be protected. > > *[Pushpasis] True. Our draft will also pick A->E->D as the SPF > from A to D in that case and disqualify A as node-protecting > PQ-node. In reality too there is no feasible path in this case > till A re-converges after learning E's node-failure* > > **I know that it is true, I just wanted to say that by this > network, the case of absence of node protection could be > demonstrated easily assuming that the main example was the network > described above. > > > Second, it would be better in the draft if the questions about > "how difficult or impossible to obtain those distances" would > be clearly stated in a bullet point list: > > For example: > > - Q-space can be obtained by rSPF calculated at destination > node D > > - P-space can be obtained through SPF calculation at source > node S and its 1-hop neighbor. > > - SPF at a PQ-node is impossible or if not what extensions > should be implemented (actually, IMHO, this is the one, which > is not clear enough) > > *[Pushpasis] The first two should really be addressed in the > original RLFA draft. Chris has already written to the authors > on this mailing list with suggesting text for the draft. The > third one is no different than standard SPF we need for > RFC5286 implementation.. only difference being that it is > rooted on PQ-nodes in case of RLFA... It is up to individual > implementations to come up with ways to constraint those to a > limit. * > > **Thanks > > > Third, according to the Targeted-LDP discussion, which is > about the fact that if some node do not support TLDP, then how > can be the inner MPLS label obtained from the PQ-node; I think > that if we want remote LFA protection then the nodes MUST > implement/support this feature, because without this the > protection cannot be guaranteed. For me, it is similar to a > hypothetic case for example of Not-via, where if the router do > not support Not-via, then it cannot be used. Or isn't it so > simple? > > *[Pushpasis] Again this is more related to original RLFA > draft. I will prefer the corresponding authors to address this > point **J* > > **Thanks > > > Please comment my observations, in order to help me and may > others as well to understand every aspects and little pieces > of remote LFA specifications. > > Best Regards, > > Levente Csikor > > Thanks, > > Levente Csikor > --------------060003010700070209080800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/09/2013 05:46 PM, Pushpasis Sarkar wrote:

Hi Levente,

 

As far as I understand.. 100% protection coverage means as long as there is a single feasible alternate path in the network, the protecting router shall use it to provide traffic protection.. irrespective of whether it is all unit cost link or not.. irrespective of whether the single feasible path is on the shortest path from any of my neighbor or not. There has to be just another path with any cost other than the primary path.

Yes

 

Thanks

-Pushpasis

 

From: Levente Csikor [mailto:csikor@tmit.bme.hu]
Sent: Wednesday, October 09, 2013 8:21 PM
To: Pushpasis Sarkar
Cc: rtgwg@ietf.org; Chris Bowers
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt

 

To calculate, which nodes are in the Q-space I've just looked for nodes for which your distance function in Fig.2. applies.
From an industrial/implementation point of view, I have no exact claim how the calculations should be made.

Furthermore, assuming that only link failures are considered in a unit cost network (where every link has the same unit cost), then rLFA provides 100% failure coverage. Note that in this case the minimal graph topological requirement is 2-edge-connectivity. That's why I said that theoretical investigation of the rLFA node-protecting failure coverage needs 2-node-connected networks to suppose that may 100% node-protection can be reached.

On 10/09/2013 04:28 PM, Pushpasis Sarkar wrote:

Hi Levente,

 

“I did not consider any possible way of determining PQ-nodes, only used the description of P and Q spaces from the original draft, and from my research on this topic, where every kind of spaces were defined in cost terms to easily analyze the network theoretically.”

 

The original Q-space definition is…  

“the set of routers which can reach the primary neighbor E can without traversing the link (S-E) being protected”

 

What will the definition for Q-space definition in this case? Do you mean…

“ the set of routers than can reach the primary neighbor E without traversing any links originating from E”? That will leave no routers in the set.. Right?

 

What makes sense is “the set of routers that can reach destination without traversing any links originating/attached to E”…. For doing that we will have two options

1.       RSPF rooted on the destination (will be very expensive if we have to do that for every destination node in the network)..  OR

2.       FSPF rooted on the PQ-node and check if primary neighbor E is on the SPF path from PQ-node to destination.. This is what is specified in our draft.. Assuming number of PQ-nodes are far less than number of nodes in the network this approach looked more feasible. Also now we are able to collect full path attributes for RLFA backup paths for LFA-manageability. Also RLFA does not attempt to provide 100% coverage. So like already said, implementations can decide to only consider upto a certain number of PQ-nodes to be considered in the whole network to limit the number of extra FSPFs to be computed.

 

Thanks

-Pushpasis

 

From: Levente Csikor [mailto:csikor@tmit.bme.hu]
Sent: Wednesday, October 09, 2013 5:17 PM
To: Pushpasis Sarkar
Cc: rtgwg@ietf.org; Chris Bowers
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt

 

Dear Pushpasis,
thanks for your comments.
For reactions see mine inline:

On 10/09/2013 12:49 PM, Pushpasis Sarkar wrote:

Hi Levente,

 

Please find few comments inline... 

 

Thanks

-Pushpasis

 

-----Original Message-----
From: Levente Csikor [mailto:csikor@tmit.bme.hu]
Sent: Wednesday, October 09, 2013 2:00 PM
To: rtgwg@ietf.org
Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt

 

Dear All,

I also support to work more on the node protection draft first, before merging it with "basic rLFA spec", because of various reasons:

 

First, I think it would be almost a good approach to show how node-protecting remote LFA works on the same, or almost the same sample network topology used in the basic rLFA spec., but for easier and more comprehensive understanding, a bit more complex but still simple example should be given. IMHO, in the basic rLFA spec. it is a bit confusing that node E is considered as a destination and this node is the next-hop as well, since the important parts of the different roles are not dissevering enough. Because of this, the similar example in node prot spec. is also not straightforward:

[Pushpasis] If you see Table 1,2, and 3 in draft-psarkar-rtgwg-rlfa-node-protection-01 we have specified the destinations E, F (and their corresponding RLFA backup paths explicitly), that will be affected by node-failure of E. Also the destination G has been included which will still be reachable in the case of node-failure of E. Perhaps basic RLFA spec can also include such kind of illustrations

    Yeah, I know and there is also the entry in the back-up path column for G, but here, I wanted to emphasized that the connectedness of the network does not remain any other opportunities to be considered.
In other words, if there were an additional node between F and G, say H, and nodes E-D-G-H-F would also form a 5-cycle, then all your claims will remain valid, since C's shortest path to F won't avoid the failed node E, but the graph-topological requirements would be not so confusing (maybe only for me :) , but when I analyze a network to calculate the rLFA protection coverage, then I always assume this basic graph topological property to easily derive the level of protection (in percent, for example) of the possible attainable 100%).


 

"In the event of the node-failure on primary nexthop E, the alternate path from Remote-LFA nexthop C to E and F also becomes unavailable."

[Pushpasis] That is exactly we are also saying in this draft(I mean draft-psarkar-rtgwg-rlfa-node-protection-01).. If any destination takes the shortest-path segment C…E that will not have node-protection using C as the PQ node, because C is going to forward the traffic to E anyhow. In Table 2 we see that the path segment C->D->E is included in the shortest path from C to E and F. That is why in case of node-failure of E, E and F cannot provide node-protection

    It was a quote from the draft, so it is really the fact that you are saying :)


 

According to the well-known last-hop problem, it is obvious that if the destination (in the first case: node E) goes down, then it cannot be protected. Moreover, since the example network topologyis not 2-node-connected, it is obvious again that the node F, which can be accessed only via node E, then the failure of node E infers that the node F can be never reached.

To (re)solve this issue, I suggest to use another network (in the basic rLFA spec. as well), which could be the following (all link costs are unit costs):

 

 

A----------B---------C

|          |       / |

|          |      /  |

|          |     /   |

F          G    /    H

|          |   /     |

|          |  /      |

|          | /       |

D----------E---------S

 

In this case, assuming that source node S wants to send a packet to node D, the next-hop of S is node E.

  - Link protecting case: If link(s,e) fails, then P-space of node S regarding to the failed link, would consist of node H,C,B and A, whilst the Q-space of D would consist all nodes except S and H. In this case, the PQ-nodes, as the possible repair tunnel endpoints, are node A,B and C.

  - Node protecting case: However, if node E itself fails, then the P-space of S would not alter, but the Q-space of D would only contain node F and A resulting that only node A is present in the set of PQ-nodes.

[Pushpasis] Can you elaborate on the method you used for deriving the PQ-nodes A and F here… Seems to me like you are doing a RSPF rooted on destination D and then pruning all links originating from E… I think Chris Bowers has already pointed on a different thread that while best way to guarantee node-protection is to run a RSPF rooted on each destination, we cannot afford to do so in reality… It will be much more feasible to run FSPF on fewer PQ-nodes as specified in our draft..

    I did not consider any possible way of determining PQ-nodes, only used the description of P and Q spaces from the original draft, and from my research on this topic, where every kind of spaces were defined in cost terms to easily analyze the network theoretically.


 

Also, the method specified by our draft also finds A as the node-protecting PQ-node, becoz the draft suggest to find the shortest-path from the PQ-nodes (C, B, and A) to destination D. Only the SPF path from A does not go through E, so only A will provide node-protection for D.

 

I think that this network also shows the different between the node protection and link protection, but in a more comprehensive manner. And it also demonstrates the fact mentioned in Figure 2 that for node-protecting rLFA, only the Q-spaces should be checked with those distance functions.

 

Moreover, if we assume that in the example network above, there is a link (A,E) and node E itself failed again, than PQ-space would be and empty set meaning that this case cannot be protected.

[Pushpasis] True. Our draft will also pick A->E->D as the SPF from A to D in that case and disqualify A as node-protecting PQ-node. In reality too there is no feasible path in this case till A re-converges after learning E’s node-failure

    I know that it is true, I just wanted to say that by this network, the case of absence of node protection could be demonstrated easily assuming that the main example was the network described above.


 

Second, it would be better in the draft if the questions about "how difficult or impossible to obtain those distances" would be clearly stated in a bullet point list:

For example:

  - Q-space can be obtained by rSPF calculated at destination node D

  - P-space can be obtained through SPF calculation at source node S and its 1-hop neighbor.

  - SPF at a PQ-node is impossible or if not what extensions should be implemented (actually, IMHO, this is the one, which is not clear enough)

[Pushpasis] The first two should really be addressed in the original RLFA draft. Chris has already written to the authors on this mailing list with suggesting text for the draft. The third one is no different than standard SPF we need for RFC5286 implementation.. only difference being that it is rooted on PQ-nodes  in case of RLFA… It is up to individual implementations to come up with ways to constraint those to a limit.

    Thanks


 

Third, according to the Targeted-LDP discussion, which is about the fact that if some node do not support TLDP, then how can be the inner MPLS label obtained from the PQ-node; I think that if we want remote LFA protection then the nodes MUST implement/support this feature, because without this the protection cannot be guaranteed. For me, it is similar to a hypothetic case for example of Not-via, where if the router do not support Not-via, then it cannot be used. Or isn't it so simple?

[Pushpasis] Again this is more related to original RLFA draft. I will prefer the corresponding authors to address this point J

    Thanks


 

Please comment my observations, in order to help me and may others as well to understand every aspects and little pieces of remote LFA specifications.

 

Best Regards,

Levente Csikor

 

 

 

Thanks,

Levente Csikor

 

 


--------------060003010700070209080800-- From aretana@cisco.com Wed Oct 9 11:49:55 2013 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 B9F6521E8186 for ; Wed, 9 Oct 2013 11:49:55 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucHs5cgJmXIN for ; Wed, 9 Oct 2013 11:49:50 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D8F1B21E8092 for ; Wed, 9 Oct 2013 11:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24204; q=dns/txt; s=iport; t=1381344589; x=1382554189; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=YYmhw9OfaJHtRfxUaOrgi48c2zdihcuaV26h2gk6x18=; b=HmU/5ZZsyPYQHLMLB91T1V10zuMm4MlzhfnmRQINZDbxrrmrSInQGQty LU0QkF0GOcqzNql/cVZ/zAFd+xBGzj0LEegHZiq5xIuMyEHg0b9+sOWW0 ptag4YgRjM7PS3vHcxu0HDyF7GH40HWNZz1n1mvEe3H6tP69VcNCNtnXT c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUFAHikVVKtJV2a/2dsb2JhbABagkNEgQrBNoEfFm0HgicBBHkSAQgSEBYHORQDDgIEDgUIh364co8UMQeDH4EEA5MKgRyVXoMkgio X-IronPort-AV: E=Sophos;i="4.90,1065,1371081600"; d="scan'208,217";a="270129918" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 09 Oct 2013 18:49:48 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r99Inmv6004020 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Oct 2013 18:49:48 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.40]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Wed, 9 Oct 2013 13:49:48 -0500 From: "Alvaro Retana (aretana)" To: "rtgwg@ietf.org" Subject: Re: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm) Thread-Topic: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm) Thread-Index: AQHOu4CPrWxL1Z2c40Onwd/d+2+N/pns2maA Date: Wed, 9 Oct 2013 18:49:48 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.7] Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94E395C2D51xmbalnx15ciscoc_" MIME-Version: 1.0 Cc: "draft-enyedi-rtgwg-mrt-frr-algorithm@tools.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, 09 Oct 2013 18:49:55 -0000 --_000_BBD66FD99311804F80324E8139B3C94E395C2D51xmbalnx15ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 9/27/13 8:53 AM, "Alvaro Retana (aretana)" > wrote: We want to hear from people who have read and understood the draft (besides= the authors!) about this topic. Please provide some explanation as to why= you support or not the adoption of the draft =97 avoid "+1". Hi! I reviewed the draft and put some comments below. In general, I think the = draft is well written and surprisingly (given the potential complexity of t= he topic) relatively easy to follow..but not in one sitting! I do need the authors to clarify one thing before I "cast my vote" about ad= option: it's Intended Status. The draft has an intended status of Informat= ional. However, the Introduction reads: "This document defines the MRT Lo= wpoint algorithm to be used as a standard in the default MRT profile for MR= T-FRR." Which one is it? IMHO, there's a significant difference in saying "this is an algorithm than= can be used" (informational) vs "this is the algorithm that MUST be used" = (standard). For the record, I have no issues with adopting this draft with= an intended status of Informational. Thanks! Alvaro. Major Issues: 1. The draft has an intended status of Informational. However, the Intr= oduction reads: "This document defines the MRT Lowpoint algorithm to be us= ed as a standard in the default MRT profile for MRT-FRR." I would like to = see a clarification on what the intended status is. 2. I found it interesting that, even though the document is defining an = algorithm that when implemented will need to have consistency across nodes,= there was no reference to RFC2119 =97 but some of the words were capitaliz= ed anyway. Even then, only 4 "MUST" and 1 "SHOULD" appeared. I realize tha= t the count of MUST/SHOULD is no indication of anything, but it doesn't fee= l right for a 40+ page document. I would appreciate if the authors would n= ot just add the 2119 reference (nit), but if they would also comb the text = for parts where a little more normative direction might help (which doesn't= necessarily translate into MUSTs). For example (all the text is from Sect= ion 4 (Algorithm Sections)): * "The different parts of this algorithm are described below. Thes= e work on a network graph after, for instance, its interfaces are ordered a= s per Figure 14." It sounds as if Figure 14 is optional or maybe ordering = the interfaces is not mandatory.. Later it is clarified: "To ensure consi= stency in computation, all routers MUST order interfaces identically. . . T= he required ordering . . . Is given in Figure 14." But the first read soun= ds not normative enough to me. * Figure 14 is not deterministic. The text says that the order does= n't matter in some cases, but then offers an example of a potential tie-bre= aker. * Root Selection. No algorithm is provided. There's a reference to = I-D.atlas-ospf-mrt, where a suggestion is made ("..the router with the high= est GADAG Root Selection Priority is picked to be the GADAG Root"). IMHO, = the algorithm should be specified in this draft, where the requirement to c= arry the Priority is defined so that the extensions draft(s) can show how t= o implement it in OSPF (or any other protocol)..not the other way around. * "Initially, all interfaces must be initialized to UNDIRECTED." S= hould that be "MUST"? * "It is possible that some links and nodes will be marked as unusab= le.." Same comment as the one above for the root selection: this draft sh= ould define the requirements ("Due to operational or other issues, the capa= bility to xxx SHOULD....") so that other docs (like I-D.atlas-ospf-mrt) can= then implement the extensions.. The text right now says: "because OSPF ca= n mark links as unusable then we'll do this.." * "There are two methods to find ears; both are required." REQUIRE= D? 3. Algorithm Alternatives and Evaluation. There are a couple of alterna= tives described in the appendices, but there is no evaluation as to why the= Lowpoint Algorithm is better. In fact, the text seems to read as if the a= ppendices describe options to the main algorithm (?) -- begging the questio= n, are there instances where these options would/could be used? Minor Issues: 1. Some important terms are not properly defined, or at least not define= d in Section 2. * "cut-edge" The term is not defined in Section 2. Later in the do= cument it is described as "The algorithm identifies cut-edges simply as lin= ks where both ends of the link are cut-vertices.", which is the definition = for cut-link. It looks like cut-edges is used more through out. * "MRT Island" I know it is defined in the architecture draft. It = would be nice to carry the definition over to Section 2. * "UNDIRECTED/OUTGOING/INCOMING" These are used in the algorithm in= various points, but are not really defined as to 2. I think that the algorithm in Figure 6 is not right =97 of course, I = may be misunderstanding it. When talking about the endpoints of the ear (X= and Y) it says "if Y is root"..but a couple of paragraphs above the text r= eads: "Once a partial ADAG is already present, we can always add ears to it= : just select a non-ready neighbor N of a ready node Q, such that Q is not = the root.." It then sounds like the starting point can't be the root.. 3. The explanation of the motivation of the low-point values (after Figu= re 9) needs either better examples or a better explanation =97 or maybe I g= ot lost. You first start explaining about when 'L(c) >=3D D(x)', but the e= xample mentions the 'L(x) < D(x)' case. An example for the second reason w= ould be nice. 4. Algorithm Evaluation. While it is interesting to see MRT compared to= rLFA, it would be much more interesting to see it compared to the options = in the appendices or to ARC. I would move the comparison to rLFA to an app= endix. Nits: 1. Section 2. "standard pseudo-node representation" Reference? 2. Section 2; in the definition of MRT-Red and MRT-Blue: s/described/de= scribe 3. Section 2; ADAG definition: "whith" ?? 4. "strictly greater/lower" These terms are used in a couple of places= , but the << or >> notation is used most of the time. It would be nice to = be consistent to avoid confusion. 5. Section 3.2: "If in the partial order where an ear's two ends are X a= nd Y, X << Y, then there must already be a directed path from X to Y alread= y in the ADAG." Too many "already". 6. It would be nice to include "partial ADAG" in the definitions section= . Yes, it is defined elsewhere, but a central place is nice in case you fo= rget. ;-) 7. I know sometimes it's hard, but please try to format the text so that= the figures are not split between pages. 8. Section 3.4, after Figure 10. "This observation means that if we want= to find a pair of MRTs rooted at R, then we need to build up a pair of RTs= in block 3 with K as a root. Similarly, we need to find another one in bl= ock 2 with C as a root, and finally, we need the last one in block 1 with R= as a root." When talking about blocks 1 and 2, you really mean a pair to = RTs (just like in block 3), not just "one", right? 9. Section 3.5: "The method for local-root computation is used in the MR= T Lowpoint algorithm for computing a GADAG using Low-Point inheritance and = the essence of it is given in Figure 12." s/is used/used and s/inheritanc= e and/inheritance, and To improve readability. 10. There are a couple of out of date references. --_000_BBD66FD99311804F80324E8139B3C94E395C2D51xmbalnx15ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <580248C922C31643B56A93679F3F7410@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 9/27/13 8:53 AM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

We want to hear from people who have read and understood the draft (besides= the authors!) about this topic.  Please provide some explanation as t= o why you support or not the adoption of the draft =97 avoid "+1&q= uot;.

<WG Chair Hat Off>

Hi!

I reviewed the draft and put some comments below.  In general, I think= the draft is well written and surprisingly (given the potential complexity= of the topic) relatively easy to follow..but not in one sitting!

I do need the authors to clarify one thing before I "cast my vote"= ; about adoption: it's Intended Status.  The draft has an intended status of Informational.  However, the = Introduction reads:  "This document defines the MRT Lowpoint = ;algorithm to be used as a standard in the default MRT profile for MRT-FRR."= ;  Which one is it?

IMHO, there's a significant difference in saying "this is an algorithm= than can be used" (informational) vs "this is the algorithm that= MUST be used" (standard).  For the record, I have no issues with= adopting this draft with an intended status of Informational.

Thanks!

Alvaro.


Major Issues:
  1. The draft has an intended status of Infor= mational.  However, the Introduction reads:  "This document = defines the MRT Lowpoint algorithm to be used as a standard in the default MRT profile for MRT-FRR."  I would like to see a clarification on what the i= ntended status is.
  2. I found it interesting that, even though = the document is defining an algorithm that when implemented will = need to have consistency across nodes, there was no reference to RFC2119&nb= sp;=97 but some of the words were capitalized anyway. Even then, only 4 "MUST" and 1 "SHOULD" appeared. &nbs= p;I realize that the count of MUST/SHOULD is no indication of anything, but= it doesn't feel right for a 40+ page document.  I would appreciat= e if the authors would not just add the 2119 reference (nit), but if they would also comb the text for parts where a little more normative d= irection might help (which doesn't necessarily translate into MUSTs).  = ;For example (all the text is from Section 4 (Algorithm Sections)):
    •  "The different parts of this algorithm are described below.  These work on a network graph after, for instance, its interfaces are ordere= d as per Figure 14."  It sounds as if Figure 14 is optional or ma= ybe ordering the interfaces is not mandatory..   Later it is clarified: "To ensure consistency in computation, all routers M= UST order interfaces identically. . . The required ordering . . .=  Is given in Figure 14."  But the first read sounds not norm= ative enough to me.
    • Figure 14 is not deterministic.  The= text says that the order doesn't matter in some cases, but then offers an = example of a potential tie-breaker.
    • Root Selection.  No algorithm is pro= vided. There's a reference to I-D.atlas-ospf-mrt, where a suggestion is mad= e ("..the router with the highest GADAG Root Selection Priority i= s picked to be the GADAG Root").  IMHO, the algorithm should be specified in this draft, where the requirement to carr= y the Priority is defined so that the extensions draft(s) can show how to i= mplement it in OSPF (or any other protocol)..not the other way around.
    • "Initially, all interfaces must be i= nitialized to UNDIRECTED."   Should that be "MUST"?
    • "It is possible that som= e links and nodes will be marked as unusable.."  Same comment as = the one above for the root selection:  this draft should def= ine the requirements ("Due to operational or other issues, the capabil= ity to xxx SHOULD....") so that other docs (like I-D.atlas-ospf-mrt)= can then implement the extensions..  The text right now says: "b= ecause OSPF can mark links as unusable then we'll do this.."
    • "There are two methods to= find ears; both are required."   REQUIRED?
  3. Algorithm Alternatives and Evalu= ation.  There are a couple of alternatives described in the appen= dices, but there is no evaluation as to why the Lowpoint Algorithm is bette= r.  In fact, the text seems to read as if the appendices describe options to the main algorithm (?) -- begging the question, are th= ere instances where these options would/could be used?

Minor Issues:
  1. Some important terms are not properly defined, or at least not defined in S= ection 2.
    • "cut-edge"  The term is not defined in Section 2.  Late= r in the document it is described as "The algorithm identifies cut-edg= es simply as links where both ends of the link are cut-vertices.", whi= ch is the definition for cut-link.  It looks like cut-edges is used more through out.
    • "MRT Island"  I know it is defined in the architecture draft= .  It would be nice to carry the definition over to Section 2.
      • "UNDIRECTED/OUTGOING/INCOMING"  These are used in the algor= ithm in various points, but are not really defined as to 
  2. I think that the algorithm in Figure 6 is not right =97 of course, I may be= misunderstanding it.  When talking about the endpoints of the ear (X = and Y) it says "if Y is root"..but a couple of paragraphs above t= he text reads: "Once a partial ADAG is already present, we can always add ears to it: just select a non-ready neighbor N of a= ready node Q, such that Q is not the root.."  It then sound= s like the starting point can't be the root..
  3. The explanation of the motivation of the low-point values (after Figure 9) = needs either better examples or a better explanation =97 or maybe I got los= t.  You first start explaining about when 'L(c) >=3D D(x)', but the= example mentions the 'L(x) < D(x)' case.  An example for the second reason would be nice.
  4. Algorithm Evaluation.  While it is interesting to see MRT compared to = rLFA, it would be much more interesting to see it compared to the options i= n the appendices or to ARC.  I would move the comparison to rLFA to an= appendix.

Nits:
  1. Section 2.  "standard pseudo-node representation"  Refe= rence?
  2. Section 2; in the definition of MRT-Red and MRT-Blue:  s/described/des= cribe
  3. Section 2; ADAG definition: "whith"  ??
  4. "strictly greater/lower"  These  terms are used in a co= uple of places, but the << or >> notation is used most of the t= ime.  It would be nice to be consistent to avoid confusion.
  5. Section 3.2: "If in the partial order where an ear's = two ends are X and Y, X << Y, then there must already be a directed path from X to Y already in the ADAG."   Too many "already".
  6. elsewhere, but a central place is nice in case you forget. ;-)
  7. Section 3.4, after Figure 10. "This observation means that if we = want to find a pair of MRTs rooted at R, then we need to build up a pair of RTs in block 3 with K as a root.  Similarly, we need to = find another one in block 2 with C as a root, and finally, we need the last one = in block 1 with R as a root."  When talking about blocks 1 and 2,= you really mean a pair to RTs (just like in block 3), not&n= bsp;just "one", right?
  8. Section 3.5: "The method for local-root = computation is used in the MRT Lowpoint algorithm for computing a GADAG using Low-Point inheritanc= e and the essence of it is given in Figure 12."  s/is used/used  and s/inheritance and/inheritance, and   To improve readability= .
  9. There are a couple of out of date references.
--_000_BBD66FD99311804F80324E8139B3C94E395C2D51xmbalnx15ciscoc_-- From internet-drafts@ietf.org Wed Oct 9 13:49:05 2013 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 B157821E81C0; Wed, 9 Oct 2013 13:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muErPqJelhw2; Wed, 9 Oct 2013 13:49:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 923AB21E81A2; Wed, 9 Oct 2013 13:49:04 -0700 (PDT) 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-cl-requirement-12.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131009204904.15919.27300.idtracker@ietfa.amsl.com> Date: Wed, 09 Oct 2013 13:49:04 -0700 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 20:49:05 -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 : Requirements for Advanced Multipath in MPLS Networks Author(s) : Curtis Villamizar Dave McDysan So Ning Andrew Malis Lucy Yong Filename : draft-ietf-rtgwg-cl-requirement-12.txt Pages : 16 Date : 2013-10-09 Abstract: This document provides a set of requirements for Advanced Multipath in MPLS Networks. Advanced Multipath is a formalization of multipath techniques currently in use in IP and MPLS networks and a set of extensions to existing multipath techniques. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-cl-requirement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-cl-requirement-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-cl-requirement-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From akatlas@gmail.com Wed Oct 9 14:06:10 2013 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 05F4F21F9DD5 for ; Wed, 9 Oct 2013 14:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzahcOu2gF5L for ; Wed, 9 Oct 2013 14:06:07 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 95F4221F9D46 for ; Wed, 9 Oct 2013 14:06:07 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id as1so2577071iec.41 for ; Wed, 09 Oct 2013 14:06:07 -0700 (PDT) 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=GjigNW965AscxzAoI2OAQHg1hvJU7F/LCj5/lMp0BPA=; b=BAN7TQWO+kHDBWeUtyv4TxhTPxH/wk5WPm3Ne5sCy8E2GUuQohK0lgsV4D/4fTIBDH PlpZja/xGYvta8ShmAzMOmz53eVfDcZhb2n8Bp1OKUGItQrUq3D9UnqhzA56aT1c87d5 UVBCItou6X7fu3Nh3egMnsyCEk180YlUzCYM2eDM1nLRVRMUYFvzA63eTLkTEAzsmrgA Vcs3rPSeJUfVavELnNax2keWIfqOB6gLig65u81TOvbQF2xsZozgERDQVrrEWt5aeFZy 8BEMOONCdWxHKI6W6HEL+BIEJ5dahE1IP1nRSyYlbhoxauwEBQpCvHEOao3hbk8I2fgd +aLg== MIME-Version: 1.0 X-Received: by 10.50.102.99 with SMTP id fn3mr3643092igb.5.1381352766896; Wed, 09 Oct 2013 14:06:06 -0700 (PDT) Received: by 10.64.78.72 with HTTP; Wed, 9 Oct 2013 14:06:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Oct 2013 17:06:06 -0400 Message-ID: Subject: Re: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm) From: Alia Atlas To: "Alvaro Retana (aretana)" Content-Type: multipart/alternative; boundary=e89a8ffbae3ffb04fa04e8554048 Cc: "draft-enyedi-rtgwg-mrt-frr-algorithm@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, 09 Oct 2013 21:06:10 -0000 --e89a8ffbae3ffb04fa04e8554048 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Alvaro, Some responses in-line. Thanks for taking the time to give a good review. Alia On Wed, Oct 9, 2013 at 2:49 PM, Alvaro Retana (aretana) wrote: > On 9/27/13 8:53 AM, "Alvaro Retana (aretana)" wrote: > > We want to hear from people who have read and understood the draft > (besides the authors!) about this topic. Please provide some explanation > as to why you support or not the adoption of the draft =97 avoid "+1". > > > > > Hi! > > I reviewed the draft and put some comments below. In general, I think > the draft is well written and surprisingly (given the potential complexit= y > of the topic) relatively easy to follow..but not in one sitting! > [Alia] It does take a couple reads to sink in. If you have suggestions on how to improve it, please do send them along. We've tried to make it as readable as possible - but after being heads-down in it for a while, it's hard to get that perspective. > I do need the authors to clarify one thing before I "cast my vote" about > adoption: it's Intended Status. The draft has an intended status of > Informational. However, the Introduction reads: "This document defines > the MRT Lowpoint algorithm to be used as a standard in the default MRT > profile for MRT-FRR." Which one is it? > [Alia] I think that the algorithm draft needs to be standards track. I apologize for not updating the intended status - I was focused on the contents. IMHO, there's a significant difference in saying "this is an algorithm > than can be used" (informational) vs "this is the algorithm that MUST be > used" (standard). For the record, I have no issues with adopting this > draft with an intended status of Informational. > [Alia] The intent is to have signaling that says this is the algorithm being used. There's capabilities to indicate different algorithms - but I do think that this particular algorithm and details must be standards-track for interoperability. Thanks! > > Alvaro. > > > Major Issues: > > 1. The draft has an intended status of Informational. However, the > Introduction reads: "This document defines the MRT Lowpoint algorithm > to be used as a standard in the default MRT profile for MRT-FRR." I > would like to see a clarification on what the intended status is. > > [Alia] Agreed - it should be Standards Track and I'll update the next version. > > 1. I found it interesting that, even though the document is defining > an algorithm that when implemented will need to have consistency acros= s > nodes, there was no reference to RFC2119 =97 but some of the words wer= e > capitalized anyway. Even then, only 4 "MUST" and 1 "SHOULD" appeared. = I > realize that the count of MUST/SHOULD is no indication of anything, bu= t it > doesn't feel right for a 40+ page document. I would appreciate if the > authors would not just add the 2119 reference (nit), but if they would= also > comb the text for parts where a little more normative direction might = help > (which doesn't necessarily translate into MUSTs). > > [Alia] Agreed - in general, what I intend to do is to have the explanator= y text that explains the logic of the algorithm and how it works much as it is - and then to pull together the different parts of the pseudo-code into a fully detailed algorithm (some by reference to the earlier parts) that indicates the MUST/SHOULD aspects. The specific request though seems more to be to take a careful read through and clarify what is MUST and what is SHOULD. > > 1. For example (all the text is from Section 4 (Algorithm Sections))= : > - "The different parts of this algorithm are described below. > These work on a network graph after, for instance, its interfaces > are ordered as per Figure 14." It sounds as if Figure 14 is option= al or > maybe ordering the interfaces is not mandatory.. Later it is clar= ified: > "To ensure consistency in computation, all routers MUST order inter= faces > identically. . . The required ordering . . . Is given in Figure 14.= " But > the first read sounds not normative enough to me. > > [Alia] Sure - I can clarify that one. > > 1. > - Figure 14 is not deterministic. The text says that the order > doesn't matter in some cases, but then offers an example of a poten= tial > tie-breaker. > > [Alia] Yes - which parallel link is used doesn't matter. That is a point to clarify - probably by breaking the function into the normative and optional parts. It's useful to have an interface-ordering function that always returns a result for use in data-structures and calling functions. > > 1. > - Root Selection. No algorithm is provided. There's a reference to > I-D.atlas-ospf-mrt, where a suggestion is made ("..the router with = the > highest GADAG Root Selection Priority is picked to be the GADAG Roo= t"). > IMHO, the algorithm should be specified in this draft, where the > requirement to carry the Priority is defined so that the extensions > draft(s) can show how to implement it in OSPF (or any other protoco= l)..not > the other way around. > > [Alia] The Root Selection is described in draft-ietf-rtgwg-mrt-frr-architecture in Sec 7 as '"GADAG Root Selection Priority: Among the routers in the MRT Island and with the highest priority advertised, an implementation MUST pick the router with the highest Router ID to be the GADAG root." > > 1. > - "Initially, all interfaces must be initialized to UNDIRECTED." > Should that be "MUST"? > - "It is possible that some links and nodes will be marked as > unusable.." Same comment as the one above for the root selection: = this > draft should define the requirements ("Due to operational or other = issues, > the capability to xxx SHOULD....") so that other docs (like > I-D.atlas-ospf-mrt) can then implement the extensions.. The text r= ight now > says: "because OSPF can mark links as unusable then we'll do this..= " > > [Alia] ?? The desire to be able to mark links as unusable comes out of th= e manageability draft and basic requirements. The general requirements are defined in the draft-ietf-rtgwg-mrt-frr-architecture - but you are right that this is only indirectly mentioned by " For any MRT profile, the MRT Island is created by starting from the compu= ting router. If the computing router supports the default MRT profile, add it to the MRT Island. Add a router to the MRT Island if the router supports the default MRT profile and is connected to th MRT Island via bidirectional links eligible for MRT." > > 1. > - "There are two methods to find ears; both are required." > REQUIRED? > > [Alia] Yes - both are part of the algorithm. In explanatory text, I don't think it needs normative language. That can/should be given with a reference to the pseudo-code. > > 1. Algorithm Alternatives and Evaluation. There are a couple of > alternatives described in the appendices, but there is no evaluation a= s to > why the Lowpoint Algorithm is better. In fact, the text seems to read= as > if the appendices describe options to the main algorithm (?) -- beggin= g the > question, are there instances where these options would/could be used? > > [Alia] True - in our initial evaluations, we didn't find significant differences in the path lengths for the alternates. Chris Bowers can comment on that a bit. I thought that I'd cleaned up the text in the main draft to clarify that the lowpoint algorithm - which has much less computation - is preferable. Can you point to where the algorithms in the appendices are considered equivalent? I will, of course, take another read through as well - trying to reduce that issue. Minor Issues: > > 1. Some important terms are not properly defined, or at least not > defined in Section 2. > - "cut-edge" The term is not defined in Section 2. Later in the > document it is described as "The algorithm identifies cut-edges sim= ply as > links where both ends of the link are cut-vertices.", which is the > definition for cut-link. It looks like cut-edges is used more thro= ugh out. > > [Alia] cut-edge and cut-link are the same thing. If we've got inconsistent terminology, I'll fix it. Vertex/edge come from graph theory while we talk about nodes and links. > > 1. > - "MRT Island" I know it is defined in the architecture draft. It > would be nice to carry the definition over to Section 2. > > [Alia] OK > > 1. > - "UNDIRECTED/OUTGOING/INCOMING" These are used in the algorithm > in various points, but are not really defined as to > > [Alia] umm, how would you define them beyond their obvious meaning? Outgoing is from the interface's router to the remote end. Incoming is from the remote router to the interface's router. > > 1. > 2. I think that the algorithm in Figure 6 is not right =97 of course, = I > may be misunderstanding it. When talking about the endpoints of the e= ar (X > and Y) it says "if Y is root"..but a couple of paragraphs above the te= xt > reads: "Once a partial ADAG is already present, we can always add ears= to > it: just select a non-ready neighbor N of a ready node Q, such that Q > is not the root.." It then sounds like the starting point can't be th= e > root.. > > [Alia] I believe this is a misunderstanding. The description of how an ear can be added is basically a proof that one can always add a new node into the ADAG (in a 2-connected graph) by starting from a neighbor N of a node Q that isn't the root. Then an SPF with Q removed can be done to find a path from Q to the root. The reason that Q can't be the root is just b/c Q is removed from the graph. Figure 6 accurately describes the high-level algorithm. An ear will have 2 ends. If the ear were found via an SPF to the root R and didn't intersect any other nodes already in the ADAG, then that ear would have two ends that are Q and R. > > 1. The explanation of the motivation of the low-point values (after > Figure 9) needs either better examples or a better explanation =97 or = maybe I > got lost. You first start explaining about when 'L(c) >=3D D(x)', but= the > example mentions the 'L(x) < D(x)' case. An example for the second re= ason > would be nice. > > [Alia] I am not yet sure where you got lost or how I could thus improve the explanation. There are two points that we tried to make. First, if the L(c) >=3D D(x) then the child c (and its descendents) have no paths to = an ancestor of the parent x except via that parent x. Thus x is a cut-vertex. The point with L(c) < D(x) (typo of L(x) ) is to describe a special case where x is a cut-vertex and has multiple DFS children which are in different blocks. As show in the example, some of those children of a node C - such as D in the example - will have L(D) < D(C) ( 0 < 3) while other children - such as F in the example will have L(F) >=3D D(C) ( 3 >=3D 3). = SO - to determine if a node is a cut-vertex, all of that node's DFS-children must be checked. [Alia] The second point is that by tracing where each node inherited its lowpoint value from, a path to attach to a node above the DFS parent can be found. This is critical - since this lowpoint inheritance path is used to find the ears for DFS children in the algorithm. It's a fast way to find a diverse path from the DFS tree. > > 1. Algorithm Evaluation. While it is interesting to see MRT compared > to rLFA, it would be much more interesting to see it compared to the > options in the appendices or to ARC. I would move the comparison to r= LFA > to an appendix. > > [Alia] It is being compared to other options that are being seriously used for fast-reroute. That includes rLFA. I don't understand why you think the comparison isn't relevant? We didn't quite have time to get the comparison fully done for MRT lowpoint compared to the SPF-based and hybrid versions. I think that is something we can add - but again, we didn't find a significant impvorement. > > > > Nits: > > 1. Section 2. "standard pseudo-node representation" Reference? > > [Alia] Do you just want me to refer to OSPFv2? I can go hunt a reference for better normative explanation or just describe transforming all broadcast interfaces into a pseudo-node with p2p links with appropriate costs. > > 1. Section 2; in the definition of MRT-Red and MRT-Blue: > s/described/describe > 2. Section 2; ADAG definition: "whith" ?? > 3. "strictly greater/lower" These terms are used in a couple of > places, but the << or >> notation is used most of the time. It would = be > nice to be consistent to avoid confusion. > 4. Section 3.2: "If in the partial order where an ear's two ends are X > and Y, X << Y, then there must already be a directed path from X to Y > already in the ADAG." Too many "already". > 5. It would be nice to include "partial ADAG" in the definitions > section. Yes, it is defined elsewhere, but a central place is nice in > case you forget. ;-) > > [Alia] Sure to all the above. > > 1. I know sometimes it's hard, but please try to format the text so > that the figures are not split between pages. > > [Alia] Do you know a magic xml2rfc method for doing that? > > 1. Section 3.4, after Figure 10. "This observation means that if we > want to find a pair of MRTs rooted at R, then we need to build up a > pair of RTs in block 3 with K as a root. Similarly, we need to find > another one in block 2 with C as a root, and finally, we need the last > one in block 1 with R as a root." When talking about blocks 1 and 2, = you > really mean a pair to RTs (just like in block 3), not just "one", righ= t? > > [Alia] Yes, probably rephrasing as "another pair of RTs" and "last pair o= f RTs" would help. > > 1. Section 3.5: "The method for local-root computation is used in the > MRT Lowpoint algorithm for computing a GADAG using Low-Point > inheritance and the essence of it is given in Figure 12." s/is > used/used and s/inheritance and/inheritance, and To improve readabi= lity. > 2. There are a couple of out of date references. > > [Alia] Sure - will fix. > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > > --e89a8ffbae3ffb04fa04e8554048 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
<WG Chair Hat Off also>

Hi Alvaro= ,

Some responses in-line.

Thanks for taking the time to give a good review.

Alia


On Wed, Oct 9, 2013 at 2:49 PM, Alvaro Retana (aretana) <aretana@cisco.c= om> wrote:
On 9/27/13 8:53 AM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:
We want to hear from people who have read and understood the draft (besides= the authors!) about this topic. =A0Please provide some explanation as to w= hy you support or not the adoption of the draft =97 avoid "+1".

<WG Chair Hat Off>

Hi!

I reviewed the draft and put some comments below. =A0In general, I think th= e draft is well written and surprisingly (given the potential complexity of= the topic) relatively easy to follow..but not in one sitting!

[Alia] It does take a couple reads to sink= in. =A0If you have suggestions on how to improve it, please do send them a= long. =A0We've tried to make it as readable as possible - but after bei= ng heads-down in it for a while, it's hard to get that perspective.
=A0
I do need the = authors to clarify one thing before I "cast my vote" about adopti= on: it's Intended Status. =A0The draf= t has an intended status of Informational. =A0However, the Introduction rea= ds: =A0"This document defines the MRT Lowpoint=A0algorithm to be used as a standard in the default MRT profile for=A0MRT-FRR." = =A0Which one is it?

[Alia] = I think that the algorithm draft needs to be standards track. =A0I apologiz= e for not updating the intended status - I was focused on the contents.

IMHO, there= 9;s a significant difference in saying "this is an algorithm than can = be used" (informational) vs "this is the algorithm that MUST be u= sed" (standard). =A0For the record, I have no issues with adopting thi= s draft with an intended status of Informational.

[Alia] The intent is to have s= ignaling that says this is the algorithm being used. There's capabiliti= es to indicate different algorithms - but I do think that this particular a= lgorithm and details must be standards-track for interoperability.

Thanks!

Alvaro.


Major Issues:
  1. The draft has an intended status of Infor= mational. =A0However, the Introduction reads: =A0"This document define= s the MRT Lowpoint=A0= algorithm to be used as a standard in the default MRT profile for=A0MR= T-FRR." =A0I would like to see a clarification on what the intended st= atus is.
[Alia] Agreed - it should = be Standards Track and I'll update the next version.
  1. I found it interesting that, even though = the document is=A0defining an=A0algorithm that when implemented will need t= o have consistency across nodes, there was no reference to RFC2119=A0=97=A0= but some of the words were capitalized anyway. Even then, only 4 "MUST" and 1 "SHOULD" appeared. =A0I= realize that the count of MUST/SHOULD is no indication of anything, but it= doesn't feel right for a 40+ page document. =A0I would appreciate if t= he authors would not just add the 2119 reference (nit), but if they would also comb the text for parts where a little more normative d= irection might help (which doesn't necessarily translate into MUSTs).
[Alia] Agreed - in general, what I i= ntend to do is to have the explanatory text that explains the logic of the = algorithm and how it works much as it is - and then to pull together the di= fferent parts of the pseudo-code into a fully detailed algorithm (some by r= eference to the earlier parts) that indicates the MUST/SHOULD aspects. =A0 = The specific request though seems more to be to take a careful read through= and clarify what is MUST and what is SHOULD.=A0
  1. =A0For example (all the text is from Sec= tion 4 (Algorithm Sections)):
    • =A0"The different parts of this=A0algorithm are described below. =A0These work on a network graph after,=A0for instance, its interfaces are ordered as p= er Figure 14." =A0It sounds as if Figure 14 is optional or maybe order= ing the interfaces is not=A0mandatory.. =A0 Later it is clarified: "To ensure consistency in computation, all routers M= UST order=A0interfaces identically. . . The=A0required ordering . . .=A0Is = given in Figure 14." =A0But the first read sounds not normative enough= to me.
[Alia] Sure - I can clarify that one= .
    • Figure 14 is not deterministic. =A0The te= xt says that the order doesn't matter in some cases, but then offers an= example of a potential tie-breaker.
[Alia] Yes - which parallel link is used doesn't matter. =A0That i= s a point to clarify - probably by breaking the function into the normative= and optional parts. =A0It's useful to have an interface-ordering funct= ion that always returns a result for use in data-structures and calling fun= ctions.
    • Root Selection. =A0No algorithm is provid= ed. There's a reference to I-D.atlas-ospf-mrt, where a suggestion is ma= de ("..the router=A0with the highest GADAG Root Selection Priority is = picked to be the GADAG Root"). =A0IMHO, the algorithm should be specified in this draft,=A0where=A0the requirement to carry the = Priority is defined so that the extensions draft(s) can show how to impleme= nt it in OSPF (or any other protocol)..not the other way around.
[Alia] The Root Selection is describ= ed in draft-ietf-rtgwg-mrt-frr-architecture in Sec 7 as=A0
'&= quot;GADAG Root Selection Priority: Among t= he routers in the MRT Island=A0and wit= h the highest priority advertised, an implementation MUST=A0=A0pick the router with the highest Router ID to be t= he GADAG root."=A0
    • "Initially, all interfaces must be i= nitialized to UNDIRECTED." =A0 Should that be "MUST"?=
    • "It is possible that some l= inks and nodes will be marked as unusable.." =A0Same comment as the on= e above for the root selection: =A0this draft=A0should=A0define the require= ments ("Due to operational or other issues, the capability to xxx SHOULD....") so that other=A0docs (like I-D.atlas-ospf-mrt) ca= n then implement the extensions.. =A0The text right now says: "because= =A0OSPF can mark links as unusable then we'll do this.."
[Alia] ?? The desire to be able to m= ark links as unusable comes out of the manageability draft and basic requir= ements. =A0The general requirements are defined in the draft-ietf-rtgwg-mrt= -frr-architecture - but you are right that this is only indirectly mentione= d by=A0

" For any MR= T profile, the MRT Island is created by starting from the=A0computing router. If the computing = router supports the default MRT=A0profile, add it to the MRT Island. Add a router to the MRT Is= land if=A0the router = supports the default MRT profile and is connected to th=A0=A0MRT Island via bidirectional links = eligible for MRT."
    • "There are two methods to find e= ars; both are required." =A0 REQUIRED?
[Alia] Yes - both are part of =A0the algorithm. =A0In ex= planatory text, I don't think it needs normative language. =A0That can/= should be given with a reference to the pseudo-code.
  1. Algorithm Alternatives and Evaluation. =A0There are a c= ouple of alternatives described in the=A0appendices, but there is no evalua= tion as to why the Lowpoint Algorithm is better. =A0In fact, the text seems= to read as if the appendices describe options to the main algorithm (?) -- begging the question, are th= ere instances where these options would/could be used?
=
[Alia] True - in our initial evaluations, we didn&#= 39;t find significant differences in the path lengths for the alternates. = =A0Chris Bowers can comment on that a bit. =A0I thought that I'd cleane= d up the text in the main draft to clarify that the lowpoint algorithm - wh= ich has much less computation - is preferable. =A0Can you point to where th= e algorithms in the appendices are considered equivalent? =A0I will, of cou= rse, take another read through as well - trying to reduce that issue.

Minor Issues:
  1. Some important terms are not properly defined, or at least not defined in S= ection 2.
    • "cut-edge" =A0The term is not defined in Section 2. =A0Later in t= he document it is described as "The algorithm identifies cut-edges sim= ply as links where both ends of the link are cut-vertices.", which is = the definition for cut-link. =A0It looks like cut-edges is used more through out.
[Alia] c= ut-edge and cut-link are the same thing. =A0If we've got inconsistent t= erminology, I'll fix it. =A0Vertex/edge come from graph theory while we= talk about nodes and links.=A0
    • "MRT Island" =A0I know it is defined in the architecture draft. = =A0It would be nice to carry the definition over to Section 2.
[Alia] OK=A0
    • "UNDIRECTED/OUTGOING/INCOMING" =A0These are used in the alg= orithm in various points, but are not really defined as to=A0
[Alia] =A0umm, = how would you define them beyond their obvious meaning? =A0Outgoing is from= the interface's router to the remote end. =A0 Incoming is from the rem= ote router to the interface's router. =A0=A0
  2. I think that the algorithm in Figure 6 is not right =97 of course, I may be= misunderstanding it. =A0When talking about the endpoints of the ear (X and= Y) it says "if Y is root"..but a couple of paragraphs above the = text reads: "Once a partial ADAG is already present, we can always add ears to it:=A0just select a non-ready neighbor N of a re= ady node Q, such that Q is=A0not the root.." =A0It then sounds like th= e starting point can't be the root..
[= Alia] I believe this is a misunderstanding. =A0The description of how an ea= r can be added is basically a proof that one can always add a new node into= the ADAG (in a 2-connected graph) by starting from a neighbor N =A0of a no= de Q =A0that isn't the root. =A0Then an SPF with Q removed can be done = to find a path from Q to the root. =A0 The reason that Q can't be the r= oot is just b/c Q is removed from the graph. =A0Figure 6 accurately describ= es the high-level algorithm. =A0An ear will have 2 ends. =A0If the ear were= found via an SPF to the root R and didn't intersect any other nodes al= ready in the ADAG, then that ear would have two ends that are Q and R.
  1. The explanation of the motivation of the low-point values (after Figure 9) = needs either better examples or a better explanation =97 or maybe I got los= t. =A0You first start explaining about when 'L(c) >=3D D(x)', bu= t the example mentions the 'L(x) < D(x)' case. =A0An example for the second reason would be nice.
<= div>[Alia] =A0I am not yet sure where you got lost or how I could thus impr= ove the explanation. =A0There are two points that we tried to make. =A0 Fir= st, if the L(c) >=3D D(x) then the child c (and its descendents) have no= paths to an ancestor of the parent x except via that parent x. =A0Thus x i= s a cut-vertex. =A0 The point with L(c) < D(x) (typo of L(x) ) is to des= cribe a special case where x is a cut-vertex and has multiple DFS children = which are in different blocks. =A0As show in the example, some of those chi= ldren of a node C - such as D in the example - will have L(D) < D(C) =A0= ( 0 < 3) while other children - such as F in the example will have L(F) = >=3D D(C) ( 3 >=3D 3). =A0SO - to determine if a node is a cut-vertex= , all of that node's DFS-children must be checked.

[Alia] The second point is that by tracing where each n= ode inherited its lowpoint value from, a path to attach to a node above the= DFS parent can be found. =A0This is critical - since this lowpoint inherit= ance path is used to find the ears for DFS children in the algorithm. =A0It= 's a fast way to find a diverse path from the DFS tree.
  1. Algorithm Evalu= ation. =A0While it is interesting to see MRT compared to rLFA, it would be = much more interesting to see it compared to the options in the appendices o= r to ARC. =A0I would move the comparison to rLFA to an appendix.
[Alia] =A0It is being compared to other option= s that are being seriously used for fast-reroute. =A0That includes rLFA. = =A0I don't understand why you think the comparison isn't relevant? = =A0 We didn't quite have time to get the comparison fully done for MRT = lowpoint compared to the SPF-based and hybrid versions. =A0I think that is = something we can add - but again, we didn't find a significant impvorem= ent.=A0

Nits:
  1. Section 2. =A0"standard pseudo-node representation" =A0Reference?=
[Alia] Do you just want me to refer to OS= PFv2? =A0I can go hunt a reference for better normative explanation or just= describe transforming all broadcast interfaces into a pseudo-node with p2p= links with appropriate costs.
=A0
  1. Section 2; in the definition of MRT-Red and MRT-Blue: =A0s/described/descri= be
  2. Section 2; ADAG definition: "whith" =A0??
  3. "strictly greater/lower" =A0These =A0terms are used in a couple o= f places, but the << or >> notation is used most of the time. = =A0It would be nice to be consistent to avoid confusion.
  4. Section 3.2: "If in the partial order where an ear's = two ends are X and Y, X << Y,=A0then there must already be a directed path from X to Y already in the ADAG." =A0 Too many "already".
  5. It would be nice to include &q= uot;partial ADAG" in the definitions section. =A0Yes, it is defined=A0= elsewhere, but a central place is nice in case you forget. ;-)
=
[Alia] Sure to all the above.=A0
  1. I know sometimes it's hard, but please try to format the text so that t= he figures are not split between pages.
[A= lia] Do you know a magic xml2rfc method for doing that?=A0
  1. Section 3.4, after Figure 10. "This=A0observation means that if we want to fi= nd a pair of MRTs rooted at R,=A0then we need to build up a pair of RTs in block 3 with K as a root. =A0<= span style=3D"font-family:Calibri,sans-serif">Similarly, we need to find an= other one in block 2 with C as a root, and finally, we need the last one = in block 1 with R as a root." =A0When talking about blocks 1 and 2, yo= u really mean a pair=A0to=A0RTs=A0(just like in block 3), not=A0just=A0&quo= t;one", right?
[Alia] Yes, probably rephrasing as "anoth= er pair of RTs" and "last pair of RTs" would help.=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
  1. Section 3.5: "The method for local-root=A0computation is used in the MRT Lowpoint algorithm for computing a=A0GADAG using Low-Point inheritance and t= he essence of it is given in=A0Figure 12." =A0s/is used/used =A0and s/inheritance and/inheritance, and =A0 To improve readability.
  2. There are a couple of out of date references.
[Alia] Sure - will fix.=A0

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


--e89a8ffbae3ffb04fa04e8554048-- From stbryant@cisco.com Wed Oct 9 21:30:30 2013 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 A96BB11E815A for ; Wed, 9 Oct 2013 21:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.936 X-Spam-Level: X-Spam-Status: No, score=-109.936 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TseFZ2NFDLNa for ; Wed, 9 Oct 2013 21:30:25 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4724211E8112 for ; Wed, 9 Oct 2013 21:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2429; q=dns/txt; s=iport; t=1381379424; x=1382589024; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=o/eJLKzFHzOi3eMh0ORJD+VSIjpCiQjb0w6pk/u9oy8=; b=XLcBTk79kOZYRCrT6j2PzqkMQuiszg7MenAeetHzPOWdcgRrHtiEnxMn U/aYzqXyj3th1MNXzmn7G5yRoyQGZ7esaJ1PZUqsuyFocCM/OpPTsaobQ Wy1ODTM493+a9kwRDzmm1DGg+SEPVvunZO2cMhjJbWBOOzjqpkLxoR85y w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwGAN8sVlKQ/khL/2dsb2JhbABZJ4JgOMFqgR4WdIIlAQEBBDIBBUABEAsYCRYPCQMCAQIBRQYNAQUCAQEXh2sMuUGNc4FSB4QjA5gDkgGDJQ X-IronPort-AV: E=Sophos;i="4.90,1068,1371081600"; d="scan'208";a="160512965" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 10 Oct 2013 04:30:01 +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 r9A4Tues028788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Oct 2013 04:29:58 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9A4TndY028641; Thu, 10 Oct 2013 05:29:51 +0100 (BST) Message-ID: <52558D00.2000404@cisco.com> Date: Wed, 09 Oct 2013 18:06:08 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hannes Gredler Subject: Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt References: <524C02D3.6050309@cisco.com> <18754_1381136403_52527813_18754_7041_1_EEE55384044474429A926C625D0FCC810966AAC932@PUEXCB2F.nanterre.francetelecom.fr> <5252D987.5050201@cisco.com> <28731_1381216021_5253AF15_28731_628_1_EEE55384044474429A926C625D0FCC810968F4D3E6@PUEXCB2F.nanterre.francetelecom.fr> <5253D25A.1020600@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , rogeriomariano , "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, 10 Oct 2013 04:30:30 -0000 On 09/10/2013 10:10, Hannes Gredler wrote: > hi stewart, > > i am not much in favor of 'lets try if we can bring-up TLDP, and if not > lets pick another PQ' strategy, mainly because it may create cross > dependencies. > > today the typical R-LFA flow between IGP and LSP is like this: > > 1. IGP determines PQ set > 2. IGP installs IP-FRR routes and gives LDP a hint > which PQ IP address shall be used for a given IP-FRR backup route > 3. LDP tries to bring up T-LDP to the PQ set > 4. LDP has learned PQ set LDP database(s) and sets the backup nexthop > for its MPLS tunnel and MPLS transit routes accordingly > > now if we need to add the PQ pruning logic it becomes like this: > > 1. IGP determines PQ set > 2. IGP installs IP-FRR routes and gives LDP a hint > which PQ IP address shall be used for a given IP-FRR backup route > 3. LDP tries to bring up T-LDP to the PQ set > 4. timeout for bringing up T-LDP to PQ set > 5. prune 'unwilling' PQ neighbor, goto 1 > > now my question: what event *removes* the unwilling PQ neighbor > from the PQ prune list, ever? - even if the PQ neighbor has been > reconfigured and it would now accept T-LDP sessions, > the calculating router would never try to establish a T-LDP session > after the PQ is on the prune list. > > and periodical fallback is not a good solution either, right ;-) > > to avoid the above i'd like to see simple protocol extensions > to the IGPs of a node willing or not willing to accept T-LDP > sessions and avoid the cross-dependencies. I agree, this is my preferred approach because it is certain to work. Let me see if I can craft some text. Stewart > > /hannes > > On Oct 8, 2013, at 11:37 AM, Stewart Bryant wrote: > [ … ] >> On 08/10/2013 08:06, stephane.litkowski@orange.com wrote: > [ .. ] >>> [SLI] Some nodes are not accepting any TLDP session at all and you cannot configure them to do it … >> So if the nodes to not accept the TLDP they you have a number of >> alternatives: >> >> 1) Take it on the chin (it is FRR not convergence) >> 2) Replace the nodes with nodes that do >> 3) Modify the nodes to accept the TLDP >> 4) Get all other nodes to advertise the capability and address >> 5) Test the candidate nodes as part of the selection process > > > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From stephane.litkowski@orange.com Thu Oct 10 01:08:28 2013 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 3C3BA21E80E9 for ; Thu, 10 Oct 2013 01:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVk6eVmBz8bd for ; Thu, 10 Oct 2013 01:08:23 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 411D921E80E0 for ; Thu, 10 Oct 2013 01:08:20 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 9F86D1B867E; Thu, 10 Oct 2013 10:08:18 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 17844158074; Thu, 10 Oct 2013 10:08:18 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.45]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 10 Oct 2013 10:08:17 +0200 From: To: "stbryant@cisco.com" , Hannes Gredler Date: Thu, 10 Oct 2013 10:08:16 +0200 Subject: RE: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt Thread-Topic: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt Thread-Index: Ac7FcXBA15ED9vG7QrOYcB/lNactDQAHi3oQ Message-ID: <20212_1381392498_52566072_20212_11110_1_EEE55384044474429A926C625D0FCC810968F4E004@PUEXCB2F.nanterre.francetelecom.fr> References: <524C02D3.6050309@cisco.com> <18754_1381136403_52527813_18754_7041_1_EEE55384044474429A926C625D0FCC810966AAC932@PUEXCB2F.nanterre.francetelecom.fr> <5252D987.5050201@cisco.com> <28731_1381216021_5253AF15_28731_628_1_EEE55384044474429A926C625D0FCC810968F4D3E6@PUEXCB2F.nanterre.francetelecom.fr> <5253D25A.1020600@cisco.com> <52558D00.2000404@cisco.com> In-Reply-To: <52558D00.2000404@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: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.10.10.13914 Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , rogeriomariano , "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, 10 Oct 2013 08:08:28 -0000 Stewart, Hannes I agree that a simple IGP extension is the best solution but to ensure back= ward compatibility with legacy node that will never support this extension,= there is still a need of tie breaker. =20 =20 Stephane Litkowski FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE Operational Engineering & Support IPTAC for RAEI network Orange Expert Network of Future t=E9l. +33 2 23 28 49 83 mob. +33 6 37 86 97 52 stephane.litkowski@orange.com =20 -----Message d'origine----- De=A0: Stewart Bryant [mailto:stbryant@cisco.com]=20 Envoy=E9=A0: mercredi 9 octobre 2013 19:06 =C0=A0: Hannes Gredler Cc=A0: LITKOWSKI Stephane DTF/DERX; draft-ietf-rtgwg-remote-lfa@tools.ietf.= org; rogeriomariano; rtgwg@ietf.org Objet=A0: Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt On 09/10/2013 10:10, Hannes Gredler wrote: > hi stewart, > > i am not much in favor of 'lets try if we can bring-up TLDP, and if=20 > not lets pick another PQ' strategy, mainly because it may create cross=20 > dependencies. > > today the typical R-LFA flow between IGP and LSP is like this: > > 1. IGP determines PQ set > 2. IGP installs IP-FRR routes and gives LDP a hint > which PQ IP address shall be used for a given IP-FRR backup route=20 > 3. LDP tries to bring up T-LDP to the PQ set 4. LDP has learned PQ set=20 > LDP database(s) and sets the backup nexthop > for its MPLS tunnel and MPLS transit routes accordingly > > now if we need to add the PQ pruning logic it becomes like this: > > 1. IGP determines PQ set > 2. IGP installs IP-FRR routes and gives LDP a hint > which PQ IP address shall be used for a given IP-FRR backup route=20 > 3. LDP tries to bring up T-LDP to the PQ set 4. timeout for bringing=20 > up T-LDP to PQ set 5. prune 'unwilling' PQ neighbor, goto 1 > > now my question: what event *removes* the unwilling PQ neighbor from=20 > the PQ prune list, ever? - even if the PQ neighbor has been=20 > reconfigured and it would now accept T-LDP sessions, the calculating=20 > router would never try to establish a T-LDP session after the PQ is on=20 > the prune list. > > and periodical fallback is not a good solution either, right ;-) > > to avoid the above i'd like to see simple protocol extensions to the=20 > IGPs of a node willing or not willing to accept T-LDP sessions and=20 > avoid the cross-dependencies. I agree, this is my preferred approach because it is certain to work. Let me see if I can craft some text. Stewart > > /hannes > > On Oct 8, 2013, at 11:37 AM, Stewart Bryant wrote: > [ . ] >> On 08/10/2013 08:06, stephane.litkowski@orange.com wrote: > [ .. ] >>> [SLI] Some nodes are not accepting any TLDP session at all and you=20 >>> cannot configure them to do it . >> So if the nodes to not accept the TLDP they you have a number of >> alternatives: >> >> 1) Take it on the chin (it is FRR not convergence) >> 2) Replace the nodes with nodes that do >> 3) Modify the nodes to accept the TLDP >> 4) Get all other nodes to advertise the capability and address >> 5) Test the candidate nodes as part of the selection process > > > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From aretana@cisco.com Thu Oct 10 07:13:28 2013 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 F2D5521F9634 for ; Thu, 10 Oct 2013 07:13:27 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nutvzw8eJasb for ; Thu, 10 Oct 2013 07:13:18 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE2811E8164 for ; Thu, 10 Oct 2013 07:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30807; q=dns/txt; s=iport; t=1381414352; x=1382623952; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=wBzxjQi/efihsRIUlEUwBwgPOMGp7r9UmFENIE29E7Y=; b=YPlj/ja4jXsVdh2auMg4xMrtM4bxcS2lorgazqlndiBkaAss69wfx3Ex afFlSpcOsJpl0VT5uHYBQjerKvz6E/CvDCt58nWcMbgJ2pZYPJ03lwFtg MguWLHskGFud0O62BMeILPUyAALOtD5QLCnUEF5O4dhhkTUodwcZ4CJuU A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFANC0VlKtJXG9/2dsb2JhbABZgkNEgQrBJ4EhFnSCJwEEZxISAQgOBBAWBygRFAMOAgQOBQiHbAMPr1cNiWuMWoI8MQeDH4EEA5YcjjWFNoMkgio X-IronPort-AV: E=Sophos;i="4.90,1072,1371081600"; d="scan'208,217";a="270478969" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 10 Oct 2013 14:12:27 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9AECRsM025776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Oct 2013 14:12:27 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.40]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 10 Oct 2013 09:12:27 -0500 From: "Alvaro Retana (aretana)" To: Alia Atlas Subject: Re: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm) Thread-Topic: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm) Thread-Index: AQHOxTNmZL/iaLG/tkG6UoZ1c4367ZnuC9gA Date: Thu, 10 Oct 2013 14:12:26 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.7] Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94E395D03F6xmbalnx15ciscoc_" MIME-Version: 1.0 Cc: "draft-enyedi-rtgwg-mrt-frr-algorithm@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: Thu, 10 Oct 2013 14:13:28 -0000 --_000_BBD66FD99311804F80324E8139B3C94E395D03F6xmbalnx15ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 10/9/13 5:06 PM, "Alia Atlas" > wrote: Alia: Hi! I pruned most of the text off to leave the relevant parts. Thanks!! Alvaro. . . . The draft has an intended status of Informational. However, the Introducti= on reads: "This document defines the MRT Lowpoint algorithm to be used as = a standard in the default MRT profile for MRT-FRR." Which one is it? [Alia] I think that the algorithm draft needs to be standards track. I apo= logize for not updating the intended status - I was focused on the contents= . IMHO, there's a significant difference in saying "this is an algorithm than= can be used" (informational) vs "this is the algorithm that MUST be used" = (standard). For the record, I have no issues with adopting this draft with= an intended status of Informational. [Alia] The intent is to have signaling that says this is the algorithm bein= g used. There's capabilities to indicate different algorithms - but I do th= ink that this particular algorithm and details must be standards-track for = interoperability. The capabilities you're talking about are in I-D.atlas-ospf-mrt, right? What I see in there is a way to indicate which profile is supported..which = I guess ties into the algorithm (for example, the Lowpoint is tied in the d= raft to the default profile).. It's not a direct way of indicating the alg= orithm, but that's what you mean, right? BTW, I have no problem in the indication being indirect.. BTW2, on the architecture draft (Section 7) the default profile is describe= d..but it took me a while to find it because the words "default MRT profile= " showed up 2-3 paragraphs before the profile was actually defined. It mig= ht be nice (for people like me) to clearly state: "This is the default MRT = profile:". I should read the architecture draft closer..but isn't it like putting the = carriage before the horse to specify there (and not in the algorithm draft)= that the Lowpoint algorithm is the one used in the default MRT profile? . . . 1. I found it interesting that, even though the document is defining an = algorithm that when implemented will need to have consistency across nodes,= there was no reference to RFC2119 =97 but some of the words were capitaliz= ed anyway. Even then, only 4 "MUST" and 1 "SHOULD" appeared. I realize tha= t the count of MUST/SHOULD is no indication of anything, but it doesn't fee= l right for a 40+ page document. I would appreciate if the authors would n= ot just add the 2119 reference (nit), but if they would also comb the text = for parts where a little more normative direction might help (which doesn't= necessarily translate into MUSTs). [Alia] Agreed - in general, what I intend to do is to have the explanatory = text that explains the logic of the algorithm and how it works much as it i= s - and then to pull together the different parts of the pseudo-code into a= fully detailed algorithm (some by reference to the earlier parts) that ind= icates the MUST/SHOULD aspects. The specific request though seems more to= be to take a careful read through and clarify what is MUST and what is SHO= ULD. I think the end result should be the same. All I want it to make sure that= the mandatory parts are clear for everyone to implement. . . . 1. * Root Selection. No algorithm is provided. There's a reference to = I-D.atlas-ospf-mrt, where a suggestion is made ("..the router with the high= est GADAG Root Selection Priority is picked to be the GADAG Root"). IMHO, = the algorithm should be specified in this draft, where the requirement to c= arry the Priority is defined so that the extensions draft(s) can show how t= o implement it in OSPF (or any other protocol)..not the other way around. [Alia] The Root Selection is described in draft-ietf-rtgwg-mrt-frr-architec= ture in Sec 7 as '"GADAG Root Selection Priority: Among the routers in the MRT Island and wi= th the highest priority advertised, an implementation MUST pick the router= with the highest Router ID to be the GADAG root." This goes back to my comment above about the capabilities and the default p= rofile definition: If this is part of the algorithm it should be specified = in the algorithm draft, not somewhere else. . . . 1. Algorithm Alternatives and Evaluation. There are a couple of alterna= tives described in the appendices, but there is no evaluation as to why the= Lowpoint Algorithm is better. In fact, the text seems to read as if the a= ppendices describe options to the main algorithm (?) -- begging the questio= n, are there instances where these options would/could be used? [Alia] True - in our initial evaluations, we didn't find significant differ= ences in the path lengths for the alternates. Chris Bowers can comment on = that a bit. I thought that I'd cleaned up the text in the main draft to cl= arify that the lowpoint algorithm - which has much less computation - is pr= eferable. Can you point to where the algorithms in the appendices are cons= idered equivalent? I will, of course, take another read through as well - = trying to reduce that issue. Where in the main draft? And by "main draft" do you mean the architecture = one? My point was that you are presenting options to the proposed algorithm that= are not used..but there is no clear explanation as to why not (at least no= t that I found in this draft). IOW, I think that if these options are not = part of the main algorithm then you should explain why not (but you already= said above that there weren't significant differences in the results), or = just take them out to avoid confusion. . . . 1. * "UNDIRECTED/OUTGOING/INCOMING" These are used in the algorithm in= various points, but are not really defined as to [Alia] umm, how would you define them beyond their obvious meaning? Outgo= ing is from the interface's router to the remote end. Incoming is from th= e remote router to the interface's router. :-) The text starts talking about marking the links (and even the pseudo-code u= ses the terms), but they are not defined. Yes, I can guess what they mean.= .but if we want consistency you don't want people guessing. . . . 1. Algorithm Evaluation. While it is interesting to see MRT compared to= rLFA, it would be much more interesting to see it compared to the options = in the appendices or to ARC. I would move the comparison to rLFA to an app= endix. [Alia] It is being compared to other options that are being seriously used= for fast-reroute. That includes rLFA. I don't understand why you think t= he comparison isn't relevant? We didn't quite have time to get the compar= ison fully done for MRT lowpoint compared to the SPF-based and hybrid versi= ons. I think that is something we can add - but again, we didn't find a si= gnificant impvorement. I didn't say that the comparison is irrelevant..I just said that I would mo= ve it to an appendix. In this draft you're proposing an algorithm to be used as the default in MR= T. We already know that rLFA can't always provide 100% coverage. I think = that comparing the proposed algorithm to something that we know doesn't pro= vide the same coverage is interesting, but it doesn't illustrate why this a= lgorithm should be the default =97 it just proves that "the 100% coverage p= rovided by MRT comes at the expense of a modest increase in alternate path = length." That is an interesting result..I just find it purely informationa= l wrt to the contents and objective of the draft. OTOH, if the algorithm was to be compared with other potential candidates (= including the options in the appendices) then it could provide better justi= fication..and it would fit better in a section titled "Algorithm Alternativ= es and Evaluation" that starts with the following text: "This specification= defines the MRT Lowpoint Algorithm, which is one option among several poss= ible MRT algorithms. Other alternatives are described in the appendices." Nits: 1. Section 2. "standard pseudo-node representation" Reference? [Alia] Do you just want me to refer to OSPFv2? I can go hunt a reference f= or better normative explanation or just describe transforming all broadcast= interfaces into a pseudo-node with p2p links with appropriate costs. I usually think about ISIS when I think about pseudo-nodes..which is why we= need a reference to that the "standard representation" is. ;-) --_000_BBD66FD99311804F80324E8139B3C94E395D03F6xmbalnx15ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1C9AC7B495C3FC40BE6BE31BADFD9F14@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 10/9/13 5:06 PM, "Alia Atlas" <akatlas@gmail.com> wrote:

<WG Chair Hat Off>

Alia:

Hi!

I pruned most of the text off to leave the relevant parts.

Thanks!!

Alvaro.

. . .
 
The draft has an intended status of Informational. &nbs= p;However, the Introduction reads:  "This document defines the MR= T Lowpoint algorithm to be used as a standard in the default MRT profile for MRT-FRR."  Which one is it?<= br>

[Alia] I think that the algorithm draft needs to be standards track. &= nbsp;I apologize for not updating the intended status - I was focused on th= e contents.

IMHO, there's = a significant difference in saying "this is an algorithm than can be u= sed" (informational) vs "this is the algorithm that MUST be used&= quot; (standard).  For the record, I have no issues with adopting this draft with an intended status of Informational.

[Alia] The intent is to have signaling that says this is the algorithm= being used. There's capabilities to indicate different algorithms - but I = do think that this particular algorithm and details must be standards-track= for interoperability.

The capabilities you're talking about are in I-D.atlas-ospf-mrt, right?

What I see in there is a way to indicate which profile is supported..which = I guess ties into the algorithm (for example, the Lowpoint is tied in the d= raft to the default profile)..  It's not a direct way of indicating th= e algorithm, but that's what you mean, right?

BTW, I have no problem in the indication being indirect..

BTW2, on the architecture draft (Section 7) the default profile is describe= d..but it took me a while to find it because the words "default MRT pr= ofile" showed up 2-3 paragraphs before the profile was actually define= d.  It might be nice (for people like me) to clearly state: "This is the default MRT profile:".

I should read the architecture draft closer..but isn't it like putting the = carriage before the horse to specify there (and not in the algorithm draft)= that the Lowpoint algorithm is the one used in the default MRT profile?

. . .

  1. I found it interesting that, even though the document is=  defining an algorithm that when implemented will need to have co= nsistency across nodes, there was no reference to RFC2119 =97 but some of the words were capitalized anyway. Ev= en then, only 4 "MUST" and 1 "SHOULD" appeared.  I= realize that the count of MUST/SHOULD is no indication of anything, but it= doesn't feel right for a 40+ page document.  I would appreciate i= f the authors would not just add the 2119 reference (nit), but if they would als= o comb the text for parts where a little more normative direction might hel= p (which doesn't necessarily translate into MUSTs).
[Alia] Agreed - in general, what I intend to do is to have the explana= tory text that explains the logic of the algorithm and how it works much as= it is - and then to pull together the different parts of the pseudo-code i= nto a fully detailed algorithm (some by reference to the earlier parts) that indicates the MUST/SHOULD aspects.=   The specific request though seems more to be to take a careful read= through and clarify what is MUST and what is SHOULD. 

I think the end result should be the same.  All I want it to make sure= that the mandatory parts are clear for everyone to implement.

. . .
    • Root Selection.  No algorithm is provided. There's = a reference to I-D.atlas-ospf-mrt, where a suggestion is made ("..the = router with the highest GADAG Root Selection Priority is picked to be the GADAG Root").  IMHO, the algorithm should be= specified in this draft, where the requirement to carry the Prio= rity is defined so that the extensions draft(s) can show how to implement i= t in OSPF (or any other protocol)..not the other way around.
[Alia] The Root Selection is described in draft-ietf-rtgwg-mrt-frr-arc= hitecture in Sec 7 as 
'"GADAG Root Selection Priority: Am= ong the routers in the MRT Island and with the highest priority advertised, an implementation MUST  pick the router with the highest Router ID to be the GADAG root."

This goes back to my comment above about the capabilities and the default p= rofile definition: If this is part of the algorithm it should be specified = in the algorithm draft, not somewhere else.

. . .

  1. Algorithm Alternatives and Evaluation= .  There are a couple of alternatives described in the appendices= , but there is no evaluation as to why the Lowpoint Algorithm is better. &n= bsp;In fact, the text seems to read as if the appendices describe options to the main algorithm (?) -- begging the question, are th= ere instances where these options would/could be used?
[Alia] True - in our initial evaluations, we didn't find significant d= ifferences in the path lengths for the alternates.  Chris Bowers can c= omment on that a bit.  I thought that I'd cleaned up the text in the m= ain draft to clarify that the lowpoint algorithm - which has much less computation - is preferable.  Can you point to = where the algorithms in the appendices are considered equivalent?  I w= ill, of course, take another read through as well - trying to reduce that i= ssue.

Where in the main draft?  And by "main draft" do you mean th= e architecture one?

My point was that you are presenting options to the proposed algorithm that= are not used..but there is no clear explanation as to why not (at least no= t that I found in this draft).  IOW, I think that if these options are= not part of the main algorithm then you should explain why not (but you already said above that there weren't = significant differences in the results), or just take them out to avoid con= fusion.

. . .
    • "UNDIRECTED/OUTGOING/INCO= MING"  These are used in the algorithm in various points, but are= not really defined as to 
[Alia]  umm, how would you define them beyond their obvious meani= ng?  Outgoing is from the interface's router to the remote end.  = Incoming is from the remote router to the interface's router.

:-)

The text starts talking about marking the links (and even the pseudo-code u= ses the terms), but they are not defined.  Yes, I can guess what they = mean..but if we want consistency you don't want people guessing.


. . .
  1. Algorithm Evalu= ation.  While it is interesting to see MRT compared to rLFA, it would = be much more interesting to see it compared to the options in the appendice= s or to ARC.  I would move the comparison to rLFA to an appendix.
[Alia]  It is being compared to other options that are being seri= ously used for fast-reroute.  That includes rLFA.  I don't unders= tand why you think the comparison isn't relevant?   We didn't quite ha= ve time to get the comparison fully done for MRT lowpoint compared to the SPF-based and hybrid versions.  I think that is somet= hing we can add - but again, we didn't find a significant impvorement. = ;

I didn't say that the comparison is irrelevant..I just said that I would mo= ve it to an appendix.

In this draft you're proposing an algorithm to be used as the default in MR= T.  We already know that rLFA can't always provide 100% coverage. &nbs= p;I think that comparing the proposed algorithm to something that we know d= oesn't provide the same coverage is interesting, but it doesn't illustrate why this algorithm should be the default =97 it = just proves that "the 100% coverage provided by MRT comes at the = expense of a modest increase in alternate path length."  Tha= t is an interesting result..I just find it purely informational wrt to the contents and objective of the draft.

OTOH, if the algorithm was to be com= pared with other potential candidates (including the options in the appendi= ces) then it could provide better justification..and it would fit better in= a section titled "Algorithm Alternatives and Evaluation" that starts with the following text: "This specification defines = the MRT Lowpoint Algorithm, which is one option among several possible MRT algorithms.  Other alternatives are described in the appendices."=


Nits:
  1. Section 2. &nbs= p;"standard pseudo-node representation"  Reference?
[Alia] Do you just want me to refer to OSPFv2?  I can go hunt a r= eference for better normative explanation or just describe transforming all= broadcast interfaces into a pseudo-node with p2p links with appropriate co= sts.

I usually think about ISIS when I think about pseudo-nodes..which is w= hy we need a reference to that the "standard representation" is. =  ;-)
--_000_BBD66FD99311804F80324E8139B3C94E395D03F6xmbalnx15ciscoc_-- From stbryant@cisco.com Thu Oct 10 08:15:37 2013 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 8BC6211E8186 for ; Thu, 10 Oct 2013 08:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.49 X-Spam-Level: X-Spam-Status: No, score=-110.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8DADlWjEO+y for ; Thu, 10 Oct 2013 08:15:30 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id F3B8521F9C6B for ; Thu, 10 Oct 2013 08:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1508; q=dns/txt; s=iport; t=1381418120; x=1382627720; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=yJbLN/3V1Cu1raQV4Euhajtj95AwAIYOYkyqi2pcXiA=; b=StSissqsKIOQwJKeRmhu+vL8ETf5EeASPYGPJgs4fPwRMilQMMq+rUXL s64N0cJHccc7Twd1PeGbbWLUZ8/D/p7/Me5J2ysBJNIsAe43tWv5ql5hQ fNS+zjTyH6yL4xve5CTKC/99UqMlgBr+xbm2MD/1CKFjzvzjkKDtCmbBf 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIFAJjDVlKQ/khN/2dsb2JhbABZgwc4wXuBIhZtB4IlAQEBBAEBATU2ChELGAkWDwkDAgECARUwBg0GAgEBh3ADDwyvcBeJYY8lKYQjA5gFgS+QU4Ml X-IronPort-AV: E=Sophos;i="4.93,467,1378857600"; d="scan'208";a="18194247" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 10 Oct 2013 15:14:18 +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 r9AFED7K017948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Oct 2013 15:14:15 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9AFECKV005359; Thu, 10 Oct 2013 16:14:12 +0100 (BST) Message-ID: <5256C443.4000705@cisco.com> Date: Thu, 10 Oct 2013 16:14:11 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "rtgwg@ietf.org" Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt References: <60DEDD93F5E54B4AB55647B8B6C74839947187@eusaamb109.ericsson.se> In-Reply-To: <60DEDD93F5E54B4AB55647B8B6C74839947187@eusaamb109.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 10 Oct 2013 15:15:38 -0000 Without doing a whole load of investigation, we should assume that the IPR disclosures that apply to rlfa apply to this draft. I will therefore set in place the process to extend the disclosure. Stewart On 01/10/2013 19:07, Jeff Tantsura wrote: > Hi, > > Question to the authors of the draft about their intentions, obviously the > basic node protection equation(D_opt(Npq, Dst) < D_opt(Npq, Np) + > Distance_opt(Np, Dst)) is correct, however the rest is more or less > implementation details. > So if the authors would like to share the details about their > implementation should not the Intended Status be Informational? > > Cheers, > Jeff > > >>>> Folks, >>>> >>>> Does anyone know whether the draft deal will be treated in the IETF 88? >>>> >>>> Regards, >>>> >>>> Rogerio Mariano >>>> >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://ietf.10.n7.nabble.com/Request-for-review-draft-psarkar-rtgwg-rlfa >>>> - >>>> n >>>> ode-protection-01-txt-tp375714p386321.html >>>> Sent from the IETF - Rtgwg mailing list archive at Nabble.com. >>>> _______________________________________________ >>>> 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 > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From hannes@juniper.net Thu Oct 10 08:24:40 2013 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 CE50611E819F for ; Thu, 10 Oct 2013 08:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9DWIOeIabn6 for ; Thu, 10 Oct 2013 08:24:30 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id D82FC21E8130 for ; Thu, 10 Oct 2013 08:23:26 -0700 (PDT) Received: from mail123-co1-R.bigfish.com (10.243.78.237) by CO1EHSOBE022.bigfish.com (10.243.66.85) with Microsoft SMTP Server id 14.1.225.22; Thu, 10 Oct 2013 15:23:24 +0000 Received: from mail123-co1 (localhost [127.0.0.1]) by mail123-co1-R.bigfish.com (Postfix) with ESMTP id 81E6D4000B3; Thu, 10 Oct 2013 15:23:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.242.197; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0512HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VPS-19(zzbb2dI98dI9371I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail123-co1: domain of juniper.net designates 157.56.242.197 as permitted sender) client-ip=157.56.242.197; envelope-from=hannes@juniper.net; helo=BL2PRD0512HT001.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail123-co1 (localhost.localdomain [127.0.0.1]) by mail123-co1 (MessageSwitch) id 138141860316786_12866; Thu, 10 Oct 2013 15:23:23 +0000 (UTC) Received: from CO1EHSMHS021.bigfish.com (unknown [10.243.78.241]) by mail123-co1.bigfish.com (Postfix) with ESMTP id F3D98B40051; Thu, 10 Oct 2013 15:23:22 +0000 (UTC) Received: from BL2PRD0512HT001.namprd05.prod.outlook.com (157.56.242.197) by CO1EHSMHS021.bigfish.com (10.243.66.31) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 10 Oct 2013 15:23:23 +0000 Received: from hannes-sslvpn-nc.jnpr.net (193.110.54.36) by pod51010.outlook.com (10.255.233.34) with Microsoft SMTP Server (TLS) id 14.16.359.1; Thu, 10 Oct 2013 15:23:20 +0000 Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Hannes Gredler In-Reply-To: <5256C443.4000705@cisco.com> Date: Thu, 10 Oct 2013 17:23:07 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <550F6326-E75C-468C-8FCE-A8BD63A4718F@juniper.net> References: <60DEDD93F5E54B4AB55647B8B6C74839947187@eusaamb109.ericsson.se> <5256C443.4000705@cisco.com> To: X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.54.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 10 Oct 2013 15:24:40 -0000 one more reason for making it part of the base spec ;-) - /hannes On Oct 10, 2013, at 5:14 PM, Stewart Bryant wrote: > Without doing a whole load of investigation, we should assume > that the IPR disclosures that apply to rlfa apply to this draft. > I will therefore set in place the process to extend the > disclosure. >=20 > Stewart >=20 > On 01/10/2013 19:07, Jeff Tantsura wrote: >> Hi, >>=20 >> Question to the authors of the draft about their intentions, = obviously the >> basic node protection equation(D_opt(Npq, Dst) < D_opt(Npq, Np) + >> Distance_opt(Np, Dst)) is correct, however the rest is more or less >> implementation details. >> So if the authors would like to share the details about their >> implementation should not the Intended Status be Informational? >>=20 >> Cheers, >> Jeff >>=20 >>=20 >>>>> Folks, >>>>>=20 >>>>> Does anyone know whether the draft deal will be treated in the = IETF 88? >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Rogerio Mariano >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> View this message in context: >>>>> = http://ietf.10.n7.nabble.com/Request-for-review-draft-psarkar-rtgwg-rlfa >>>>> - >>>>> n >>>>> ode-protection-01-txt-tp375714p386321.html >>>>> Sent from the IETF - Rtgwg mailing list archive at Nabble.com. >>>>> _______________________________________________ >>>>> 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 >>=20 >=20 >=20 > --=20 > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg >=20 >=20 From cbowers@juniper.net Thu Oct 10 10:00:25 2013 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 6134321E8136 for ; Thu, 10 Oct 2013 10:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwmMxlMVuilR for ; Thu, 10 Oct 2013 10:00:18 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0187.outbound.messaging.microsoft.com [213.199.154.187]) by ietfa.amsl.com (Postfix) with ESMTP id C36F621E8119 for ; Thu, 10 Oct 2013 10:00:17 -0700 (PDT) Received: from mail69-db8-R.bigfish.com (10.174.8.249) by DB8EHSOBE023.bigfish.com (10.174.4.86) with Microsoft SMTP Server id 14.1.225.22; Thu, 10 Oct 2013 17:00:16 +0000 Received: from mail69-db8 (localhost [127.0.0.1]) by mail69-db8-R.bigfish.com (Postfix) with ESMTP id 0E002C20127 for ; Thu, 10 Oct 2013 17:00:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zzbb2dI9371Ic85fh4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah18c673h1de097h186068h8275bh8275dhz2fh2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h9a9j1155h) Received-SPF: pass (mail69-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=cbowers@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(164054003)(377454003)(479174003)(199002)(189002)(69226001)(49866001)(47736001)(50986001)(47976001)(19300405004)(15202345003)(74706001)(83072001)(76576001)(81542001)(76786001)(76796001)(74316001)(33646001)(77096001)(56816003)(81342001)(54356001)(46102001)(53806001)(51856001)(74662001)(74502001)(4396001)(19580405001)(83322001)(47446002)(19580395003)(80976001)(31966008)(76482001)(81686001)(16236675002)(65816001)(56776001)(54316002)(85306002)(15975445006)(59766001)(74876001)(81816001)(80022001)(66066001)(63696002)(79102001)(74366001)(77982001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB528; H:DM2PR05MB528.namprd05.prod.outlook.com; CLIP:66.129.224.54; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail69-db8 (localhost.localdomain [127.0.0.1]) by mail69-db8 (MessageSwitch) id 1381424413510304_14580; Thu, 10 Oct 2013 17:00:13 +0000 (UTC) Received: from DB8EHSMHS020.bigfish.com (unknown [10.174.8.230]) by mail69-db8.bigfish.com (Postfix) with ESMTP id 6E6F1DC0048 for ; Thu, 10 Oct 2013 17:00:13 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS020.bigfish.com (10.174.4.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 10 Oct 2013 17:00:08 +0000 Received: from DM2PR05MB528.namprd05.prod.outlook.com (10.141.99.156) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 10 Oct 2013 17:00:03 +0000 Received: from DM2PR05MB528.namprd05.prod.outlook.com (10.141.99.156) by DM2PR05MB528.namprd05.prod.outlook.com (10.141.99.156) with Microsoft SMTP Server (TLS) id 15.0.775.9; Thu, 10 Oct 2013 17:00:00 +0000 Received: from DM2PR05MB528.namprd05.prod.outlook.com ([169.254.8.76]) by DM2PR05MB528.namprd05.prod.outlook.com ([169.254.8.76]) with mapi id 15.00.0775.005; Thu, 10 Oct 2013 17:00:00 +0000 From: Chris Bowers To: "rtgwg@ietf.org" Subject: RE: algorithm description for draft-ietf-rtgwg-remote-lfa Thread-Topic: algorithm description for draft-ietf-rtgwg-remote-lfa Thread-Index: Ac6ptHQ7OAnN8935QeKjlomkchLu2wcGXUCg Date: Thu, 10 Oct 2013 16:59:59 +0000 Message-ID: References: <8987a924cffe4af1b2bc2f94a7950a6e@BL2PR05MB113.namprd05.prod.outlook.com> In-Reply-To: <8987a924cffe4af1b2bc2f94a7950a6e@BL2PR05MB113.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.54] x-forefront-prvs: 0995196AA2 Content-Type: multipart/alternative; boundary="_000_f69a9d7081394036ac5aa65f6b17461cDM2PR05MB528namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 10 Oct 2013 17:00:25 -0000 --_000_f69a9d7081394036ac5aa65f6b17461cDM2PR05MB528namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart proposed in another thread making this algorithm text part of an ap= pendix (see snippet below.) I want to emphasize the importance of adding m= ore quantitative content to the normative sections of the text, by illustra= ting an example of the confusion created by some of the current text. Today I was in a discussion regarding the criteria for evaluating for use a= s a tunnel endpoint, a node Y in extended-P space which is reachable from s= ource S by way of S's neighbor N1. Some confusion arose during the discuss= ion over whether or not the node Y should be rejected for consideration if = policy had been applied rejecting N1 as a (local)LFA for reaching Y. We ag= reed that the evaluation of Y as a tunnel endpoint for remote LFA should no= t depend on the policy applied to the (local)LFA to reach Y. However, the text below in section 4.2.2 leads to confusion on this point. "Another way to describe extended P-space is that it is the union of ( un-extended ) P-space and the set of destinations for which S has a per-prefix LFA protecting the link S-E." I think this text should be removed and replaced with precise quantitative = criteria for membership in extended P-space. It is likely that remote LFA = will be deployed together with (local)LFA with policy determining which typ= e of alternate to use (draft-litkowski-rtgwg-lfa-manageability). Describin= g remote LFA in terms of (local)LFA will create confusion for someone tryin= g to apply policy. Quantitative criteria avoid this confusion. If this text creates such confusion among experts, it is likely to create e= ven more confusion among end-users of the technology, when trying to figure= out what is really going on in their network. While one might argue that = this behavior is up to the vendor to document, confusing text in the base r= lfa draft will make that task much more difficult. --------- A response to this algorithm text showed up in another thread so I am cutti= ng and pasting Stewart Bryant's response from 10/2/13 to this thread to keep t= hings organized. [SB] "I plan to put in the algorithm text, although having discussed this with Mike, our inclination is to include this as an appendix since it is not required for interoperability that you do the computation that way." --------- Chris From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of C= hris Bowers Sent: Wednesday, September 04, 2013 4:22 PM To: rtgwg@ietf.org Subject: algorithm description for draft-ietf-rtgwg-remote-lfa As has been pointed out in other email threads, the current version of draft-ietf-rtgwg-remote-lfa-02.txt lacks a formal description of the algorithm being proposed. Below is a such a formal algorithm description, based on my reading of the current draft. It would help progress this draft forward if the authors would correct any errors in this pseudo-code representation of the algorithm. The pseudo-code below avoids unnecessary SPF computations, but for the sake of readability, it does not otherwise try to optimize the code. Remote LFA algorithm Compute_and_Store_Forward_SPF(node root) Compute_Forward_SPF(root) foreach node z in network store D_opt(root,z) Compute_and_Store_Reverse_SPF(node root) Compute_Reverse_SPF(root) foreach node z in network store D_opt(z,root) Compute_Neighbor_SPFs() foreach interface intf in self if (intf.remote_node !=3D fail_intf.remote_node) Compute_and_Store_Forward_SPF(intf.remote_node) Compute_Extended_P_Space() foreach node y in network y.in_extended_P_space =3D false if (D_opt(self, y) < D_opt(self, fail_intf.remote_node) + D_opt(fail_intf.remote= _node,y)) y.in_extended_P_space =3D true foreach interface intf in self if (intf.remote_node !=3D fail_intf.remote_node) if ( D_opt(intf.remote_node, y) < D_opt(intf.remote_node, s= elf) + D_opt(self,fail_intf.remote_node) + D_opt(fail_intf.remote_node,y) ) y.in_extended_P_space =3D true Compute_Q_Space() Compute_and_Store_Reverse_SPF(fail_intf.remote_node) foreach node y in network if ( D_opt(y,fail_intf.remote_node) < D_opt(y,self) + D_opt(self,fail_intf.remote_node) ) y.in_Q_space =3D true else y.in_Q_space =3D false Intersect_Extended_P_and_Q_Space() foreach node y in network if ( y.in_extended_P_space && y.in_Q_space ) y.valid_tunnel_endpoint =3D true else y.valid_tunnel_endpoint =3D false Apply_Downstream_Constraint() foreach node y in network if (y.valid_tunnel_endpoint) Compute_and_Store_Forward_SPF(y) if ((D_opt(y,dest) < D_opt(self,dest)) y.valid_tunnel_endpoint =3D true else y.valid_tunnel_endpoint =3D false Compute_Neighbor_SPFs() Compute_Extended_P_Space() Compute_Q_Space() Intersect_Extended_P_and_Q_Space() if (guarantee_no_looping_on_worse_than_protected_failure) Apply_Downstream_Constraint() ********** I would also like to propose that the following text to be inserted after the last paragraph of section 4.2.1. "Computing Repair Paths". It should be noted that using the Q-space of E as a proxy for the Q-space of each destination can result in failing to identify valid remote LFAs. The extent to which this reduces the effective protection coverage is topology dependent. *********** Thanks, Chris --_000_f69a9d7081394036ac5aa65f6b17461cDM2PR05MB528namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stewart proposed in anothe= r thread making this algorithm text part of an appendix (see snippet below.= )  I want to emphasize the importance of adding more quantitative content to the normative sections of the text, by illustrating an example = of the confusion created by some of the current text.

 

Today I was in a discussio= n regarding the criteria for evaluating for use as a tunnel endpoint, a nod= e Y in extended-P space which is reachable from source S by way of S’s neighbor N1.  Some confusion arose during the dis= cussion over whether or not the node Y should be rejected for consideration= if policy had been applied rejecting N1 as a (local)LFA for reaching Y.&nb= sp; We agreed that the evaluation of Y as a tunnel endpoint for remote LFA should not depend on the policy applied to the (lo= cal)LFA to reach Y.

 

However, the text below in= section 4.2.2 leads to confusion on this point. 

 

“Another way to desc= ribe extended P-space is that it is the union of (

un-extended ) P-space and = the set of destinations for which S has a

per-prefix LFA protecting = the link S-E.”

 

I think this text should b= e removed and replaced with precise quantitative criteria for membership in= extended P-space.  It is likely that remote LFA will be deployed together with (local)LFA with policy determining which type of al= ternate to use (draft-litkowski-rtgwg-lfa-manageability).  Describing = remote LFA in terms of (local)LFA will create confusion for someone trying = to apply policy. Quantitative criteria avoid this confusion. 

 

If this text creates such = confusion among experts, it is likely to create even more confusion among e= nd-users of the technology, when trying to figure out what is really going on in their network.  While one might argue that this= behavior is up to the vendor to document, confusing text in the base rlfa = draft will make that task much more difficult.

---------

A response to this algorit= hm text showed up in another thread so I am cutting

and pasting Stewart Bryant= ’s response from 10/2/13 to this thread to keep things organized.

 

[SB] “I plan to put = in the algorithm text, although having discussed

this with Mike, our inclin= ation is to include this as an

appendix since it is not r= equired for interoperability that

you do the computation tha= t way.”

---------

 

Chris

 

 

From: rtgwg-bo= unces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Chris Bowers
Sent: Wednesday, September 04, 2013 4:22 PM
To: rtgwg@ietf.org
Subject: algorithm description for draft-ietf-rtgwg-remote-lfa<= /o:p>

 

As has been pointed out in other email t= hreads,

the current version of draft-ietf-rtgwg-= remote-lfa-02.txt

lacks a formal description of the algori= thm being proposed.

Below is a such a formal algorithm descr= iption, based on my

reading of the current draft.  It w= ould help progress this

draft forward if the authors would corre= ct any errors

in this pseudo-code representation of th= e algorithm.

 

The pseudo-code below avoids unnecessary= SPF computations, but

for the sake of readability, it does not= otherwise try to

optimize the code.

 

Remote LFA algorithm

 

Compute_and_Store_Forward_SPF(node root)=

    Compute_Forward_SPF(r= oot)

    foreach node z in net= work

      &nbs= p; store D_opt(root,z)

      &nbs= p;

Compute_and_Store_Reverse_SPF(node root)=

    Compute_Reverse_SPF(r= oot)

    foreach node z in net= work

      &nbs= p; store D_opt(z,root)

 

Compute_Neighbor_SPFs()

    foreach interface int= f in self

      &nbs= p; if (intf.remote_node !=3D fail_intf.remote_node)

      &nbs= p;     Compute_and_Store_Forward_SPF(intf.remote_node)<= o:p>

 

Compute_Extended_P_Space()

    foreach node y in net= work

      &nbs= p; y.in_extended_P_space =3D false

      &nbs= p; if (D_opt(self, y) <

      &nbs= p;         D_opt(self, fail_intf.re= mote_node) + D_opt(fail_intf.remote_node,y))

      &nbs= p;     y.in_extended_P_space =3D true=

      &nbs= p; foreach interface intf in self

      &nbs= p;     if (intf.remote_node !=3D fail_intf.remote_node)=

      &nbs= p;         if ( D_opt(intf.remote_n= ode, y) < D_opt(intf.remote_node, self) +

      &nbs= p;            &= nbsp;    D_opt(self,fail_intf.remote_node) +<= /span>

      &nbs= p;            &= nbsp;    D_opt(fail_intf.remote_node,y) )<= /p>

      &nbs= p;             = y.in_extended_P_space =3D true       &nb= sp;       

 

Compute_Q_Space()

    Compute_and_Store_Rev= erse_SPF(fail_intf.remote_node)

    foreach node y in net= work

      &nbs= p; if ( D_opt(y,fail_intf.remote_node) < D_opt(y,self) +<= /span>

      &nbs= p;         D_opt(self,fail_intf.rem= ote_node) )

      &nbs= p;     y.in_Q_space =3D true

      &nbs= p; else

      &nbs= p;     y.in_Q_space =3D false

      &nbs= p;            &= nbsp;   

Intersect_Extended_P_and_Q_Space()<= /o:p>

    foreach node y in net= work

      &nbs= p; if ( y.in_extended_P_space && y.in_Q_space )

      &nbs= p;     y.valid_tunnel_endpoint =3D true

      &nbs= p; else

      &nbs= p;     y.valid_tunnel_endpoint =3D false

      &nbs= p;            &= nbsp;           &nbs= p;       

Apply_Downstream_Constraint()=

    foreach node y in net= work

      &nbs= p; if (y.valid_tunnel_endpoint)

      &nbs= p;     Compute_and_Store_Forward_SPF(y)

      &nbs= p;     if ((D_opt(y,dest) < D_opt(self,dest))

      &nbs= p;         y.valid_tunnel_endpoint = =3D true

      &nbs= p;    else

      &nbs= p;         y.valid_tunnel_endpoint = =3D false

      &nbs= p;            &= nbsp;           

Compute_Neighbor_SPFs()

Compute_Extended_P_Space()

Compute_Q_Space()

Intersect_Extended_P_and_Q_Space()<= /o:p>

if (guarantee_no_looping_on_worse_than_p= rotected_failure)

    Apply_Downstream_Cons= traint()

 

**********     

 

I would also like to propose that the fo= llowing text to be

inserted after the last paragraph of

section 4.2.1. "Computing Repair Pa= ths".

 

It should be noted that using the Q-spac= e of E as a proxy for the Q-space

of each destination can result in failin= g to identify valid remote LFAs. 

The extent to which this reduces the eff= ective protection coverage is

topology dependent.

 

***********

 

Thanks,

Chris

 

 

--_000_f69a9d7081394036ac5aa65f6b17461cDM2PR05MB528namprd05pro_-- From stbryant@cisco.com Thu Oct 10 10:03:12 2013 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 79DD921F9473 for ; Thu, 10 Oct 2013 10:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.493 X-Spam-Level: X-Spam-Status: No, score=-110.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zv2iajG-+Bbp for ; Thu, 10 Oct 2013 10:03:07 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id CE48521F90FD for ; Thu, 10 Oct 2013 10:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2153; q=dns/txt; s=iport; t=1381424586; x=1382634186; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=b8nHJTC5DSqqhl8nGjm0/JJJduaeZuk/iK5Hov0gAbw=; b=M+v91YxAmEKEjcC8i9HWGQjg+tUuUXPT8zqLtglveIOrGzltra6eK9sl NQ4VYEtwIvepCjX0Cte1zDAlmUnj0tuoSAC8nrvt6xtofPYu0yV7A147P zmefyD5BuR55/dncwZD0+NsIqkPaSxNRgfSa/CXvZD2HrYy0eetpxkhmL A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAJvdVlKQ/khL/2dsb2JhbABZgwc4wXuBIxZ0giUBAQEEAQEBNTYLEAsYCSUPAhYwBg0BBQIBAYdwAw8MsDMXiWGPJSIHhCMDmAWBL5BTgyU X-IronPort-AV: E=Sophos;i="4.93,468,1378857600"; d="scan'208";a="18196418" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 10 Oct 2013 17:02:49 +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 r9AH2iTd008753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Oct 2013 17:02:46 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9AH2g6a012570; Thu, 10 Oct 2013 18:02:43 +0100 (BST) Message-ID: <5256DDB2.80000@cisco.com> Date: Thu, 10 Oct 2013 18:02:42 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hannes Gredler Subject: Re: Request for review - draft-psarkar-rtgwg-rlfa-node-protection-01.txt References: <60DEDD93F5E54B4AB55647B8B6C74839947187@eusaamb109.ericsson.se> <5256C443.4000705@cisco.com> <550F6326-E75C-468C-8FCE-A8BD63A4718F@juniper.net> In-Reply-To: <550F6326-E75C-468C-8FCE-A8BD63A4718F@juniper.net> 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: Thu, 10 Oct 2013 17:03:12 -0000 I really would like to get the base done - it's been a long time. Stewart On 10/10/2013 16:23, Hannes Gredler wrote: > one more reason for making it part of the base spec ;-) - /hannes > > On Oct 10, 2013, at 5:14 PM, Stewart Bryant wrote: > >> Without doing a whole load of investigation, we should assume >> that the IPR disclosures that apply to rlfa apply to this draft. >> I will therefore set in place the process to extend the >> disclosure. >> >> Stewart >> >> On 01/10/2013 19:07, Jeff Tantsura wrote: >>> Hi, >>> >>> Question to the authors of the draft about their intentions, obviously the >>> basic node protection equation(D_opt(Npq, Dst) < D_opt(Npq, Np) + >>> Distance_opt(Np, Dst)) is correct, however the rest is more or less >>> implementation details. >>> So if the authors would like to share the details about their >>> implementation should not the Intended Status be Informational? >>> >>> Cheers, >>> Jeff >>> >>> >>>>>> Folks, >>>>>> >>>>>> Does anyone know whether the draft deal will be treated in the IETF 88? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Rogerio Mariano >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> View this message in context: >>>>>> http://ietf.10.n7.nabble.com/Request-for-review-draft-psarkar-rtgwg-rlfa >>>>>> - >>>>>> n >>>>>> ode-protection-01-txt-tp375714p386321.html >>>>>> Sent from the IETF - Rtgwg mailing list archive at Nabble.com. >>>>>> _______________________________________________ >>>>>> 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 >>> >> >> -- >> For corporate legal information go to: >> >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> >> _______________________________________________ >> 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 akatlas@gmail.com Thu Oct 10 14:08:01 2013 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 EC69E11E80E9 for ; Thu, 10 Oct 2013 14:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+vn-LSlbGAc for ; Thu, 10 Oct 2013 14:08:00 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 09B3411E80EE for ; Thu, 10 Oct 2013 14:07:59 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id ar20so6293387iec.4 for ; Thu, 10 Oct 2013 14:07:59 -0700 (PDT) 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=nrYEa0ZCx8etHNetrSqYhidtap4Xko/iu9zjFZ5j38Q=; b=hxSBYNmIB5TJo9GtBLFdkFqUiRNpWOULMfYqBch/g8qrf/n2DpzUejOReetRVLC+xg ldnONe1nyz9pSKjb0vpHg1i6mzoqrfkiqd6AbOIOuBXLpQjMn8/3LS1O0IeRFbQLtmQr FyZg1SZDbxgJOjICeB8g4w9QLkq7r8bjeBInm9sZd9g7q38csc8B9nV0zGnIvG9Sl/IL ywIWDBzbfTdk2cpGHxdRUnHQBKZelYdat4sijzTHPTw7+haWzeV/3fwIXBZVN+ADtdkI EindJ/n1Z0tOYz0odkR3RWHb83Vff7TrN6nTee+ho2y6GiAISc6X/DrjGzXe7b1X1GFF g7WA== MIME-Version: 1.0 X-Received: by 10.43.172.4 with SMTP id nw4mr9546286icc.25.1381439279441; Thu, 10 Oct 2013 14:07:59 -0700 (PDT) Received: by 10.64.78.72 with HTTP; Thu, 10 Oct 2013 14:07:59 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Oct 2013 17:07:59 -0400 Message-ID: Subject: Re: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm) From: Alia Atlas To: "Alvaro Retana (aretana)" Content-Type: multipart/alternative; boundary=001a11c2fe3c87b35304e86965db Cc: "draft-enyedi-rtgwg-mrt-frr-algorithm@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: Thu, 10 Oct 2013 21:08:02 -0000 --001a11c2fe3c87b35304e86965db Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Replies in-line as always... On Thu, Oct 10, 2013 at 10:12 AM, Alvaro Retana (aretana) wrote: > On 10/9/13 5:06 PM, "Alia Atlas" wrote: > > > > Alia: > > Hi! > > I pruned most of the text off to leave the relevant parts. > > Thanks!! > > Alvaro. > > . . . > > > >> The draft has an intended status of Informational. However, the >> Introduction reads: "This document defines the MRT Lowpoint algorithm >> to be used as a standard in the default MRT profile for MRT-FRR." Which >> one is it? >> > > [Alia] I think that the algorithm draft needs to be standards track. I > apologize for not updating the intended status - I was focused on the > contents. > > IMHO, there's a significant difference in saying "this is an algorithm >> than can be used" (informational) vs "this is the algorithm that MUST be >> used" (standard). For the record, I have no issues with adopting this >> draft with an intended status of Informational. >> > > [Alia] The intent is to have signaling that says this is the algorithm > being used. There's capabilities to indicate different algorithms - but I > do think that this particular algorithm and details must be standards-tra= ck > for interoperability. > > > The capabilities you're talking about are in I-D.atlas-ospf-mrt, right? > > What I see in there is a way to indicate which profile is > supported..which I guess ties into the algorithm (for example, the Lowpoi= nt > is tied in the draft to the default profile).. It's not a direct way of > indicating the algorithm, but that's what you mean, right? > > BTW, I have no problem in the indication being indirect.. > [Alia] Right - the algorithm is one aspect of a profile - and different profiles can be specified. > BTW2, on the architecture draft (Section 7) the default profile is > described..but it took me a while to find it because the words "default M= RT > profile" showed up 2-3 paragraphs before the profile was actually defined= . > It might be nice (for people like me) to clearly state: "This is the > default MRT profile:". > [Alia] Sure - I expect that we co-authors should go over the arch draft and make sure that the normative details are clearly specified as such and clearly. In this case, I think it's just reordering a bit - since the architecture draft talks about the concept of MRT profiles and that there is a default MRT profile before defining what that default is. I don't expect to have that done for this IETF - unless there is serious concern about a lack of clarity. > I should read the architecture draft closer..but isn't it like putting th= e > carriage before the horse to specify there (and not in the algorithm draf= t) > that the Lowpoint algorithm is the one used in the default MRT profile? > [Alia] I didn't think so (but you knew that ;-) - having it make sense to define the default MRT profile where the concept of MRT profiles is defined. I do agree that it makes sense to have the algorithm draft reference the architecture draft and that the lowpoint algorithm is used in the default MRT profile - so basically say it in both places :-) > > . . . > > > >> 1. I found it interesting that, even though the document is defining >> an algorithm that when implemented will need to have consistency acro= ss >> nodes, there was no reference to RFC2119 =97 but some of the words we= re >> capitalized anyway. Even then, only 4 "MUST" and 1 "SHOULD" appeared.= I >> realize that the count of MUST/SHOULD is no indication of anything, b= ut it >> doesn't feel right for a 40+ page document. I would appreciate if th= e >> authors would not just add the 2119 reference (nit), but if they woul= d also >> comb the text for parts where a little more normative direction might= help >> (which doesn't necessarily translate into MUSTs). >> >> [Alia] Agreed - in general, what I intend to do is to have the > explanatory text that explains the logic of the algorithm and how it work= s > much as it is - and then to pull together the different parts of the > pseudo-code into a fully detailed algorithm (some by reference to the > earlier parts) that indicates the MUST/SHOULD aspects. The specific > request though seems more to be to take a careful read through and clarif= y > what is MUST and what is SHOULD. > > > I think the end result should be the same. All I want it to make sure > that the mandatory parts are clear for everyone to implement. > [Alia] Absolutely. > . . . > > >> 1. >> - Root Selection. No algorithm is provided. There's a reference >> to I-D.atlas-ospf-mrt, where a suggestion is made ("..the router w= ith the >> highest GADAG Root Selection Priority is picked to be the GADAG Ro= ot"). >> IMHO, the algorithm should be specified in this draft, where the >> requirement to carry the Priority is defined so that the extension= s >> draft(s) can show how to implement it in OSPF (or any other protoc= ol)..not >> the other way around. >> >> [Alia] The Root Selection is described in > draft-ietf-rtgwg-mrt-frr-architecture in Sec 7 as > '"GADAG Root Selection Priority: Among the routers in the MRT Island and > with the highest priority advertised, an implementation MUST pick the > router with the highest Router ID to be the GADAG root." > > > This goes back to my comment above about the capabilities and the > default profile definition: If this is part of the algorithm it should be > specified in the algorithm draft, not somewhere else. > [Alia] Ah - the GADAG root selection is part of the MRT profile but not, IMHO, part of the algorithm... The same Lowpoint algorithm can be used with different GADAG root selection. For example, for multicast, one might do an MRT profile where the multicast S is picked to be the GADAG root - and the same Lowpoint algorithm is run. > > . . . > > > >> 1. Algorithm Alternatives and Evaluation. There are a couple of >> alternatives described in the appendices, but there is no evaluation = as to >> why the Lowpoint Algorithm is better. In fact, the text seems to rea= d as >> if the appendices describe options to the main algorithm (?) -- beggi= ng the >> question, are there instances where these options would/could be used= ? >> >> [Alia] True - in our initial evaluations, we didn't find significant > differences in the path lengths for the alternates. Chris Bowers can > comment on that a bit. I thought that I'd cleaned up the text in the mai= n > draft to clarify that the lowpoint algorithm - which has much less > computation - is preferable. Can you point to where the algorithms in th= e > appendices are considered equivalent? I will, of course, take another re= ad > through as well - trying to reduce that issue. > > > Where in the main draft? And by "main draft" do you mean the > architecture one? > [Alia] Sorry to have been unclear - by main draft I meant the algorithm draft that isn't in the appendices. My point was that you are presenting options to the proposed algorithm that > are not used..but there is no clear explanation as to why not (at least n= ot > that I found in this draft). IOW, I think that if these options are not > part of the main algorithm then you should explain why not (but you alrea= dy > said above that there weren't significant differences in the results), or > just take them out to avoid confusion. > [Alia] Sure - I put them in an appendix while we decided which to do :-) . . . > > >> 1. >> - "UNDIRECTED/OUTGOING/INCOMING" These are used in the algorithm >> in various points, but are not really defined as to >> >> [Alia] umm, how would you define them beyond their obvious meaning? > Outgoing is from the interface's router to the remote end. Incoming is > from the remote router to the interface's router. > > > :-) > > The text starts talking about marking the links (and even the > pseudo-code uses the terms), but they are not defined. Yes, I can guess > what they mean..but if we want consistency you don't want people guessing= . > [Alia] True... I do describe everything about how they are used - but I'll try for better text too. . . . > > >> 1. Algorithm Evaluation. While it is interesting to see MRT compared >> to rLFA, it would be much more interesting to see it compared to the >> options in the appendices or to ARC. I would move the comparison to = rLFA >> to an appendix. >> >> [Alia] It is being compared to other options that are being seriously > used for fast-reroute. That includes rLFA. I don't understand why you > think the comparison isn't relevant? We didn't quite have time to get t= he > comparison fully done for MRT lowpoint compared to the SPF-based and hybr= id > versions. I think that is something we can add - but again, we didn't fi= nd > a significant impvorement. > > > I didn't say that the comparison is irrelevant..I just said that I would > move it to an appendix. > > In this draft you're proposing an algorithm to be used as the default in > MRT. We already know that rLFA can't always provide 100% coverage. I > think that comparing the proposed algorithm to something that we know > doesn't provide the same coverage is interesting, but it doesn't illustra= te > why this algorithm should be the default =97 it just proves that "the 100= % > coverage provided by MRT comes at the expense of a modest increase in > alternate path length." That is an interesting result..I just find it > purely informational wrt to the contents and objective of the draft. > [Alia] AH - I am trying to show that MRT Lowpoint is a good fast-reroute mechanism that offers 100% coverage with good computation and without causing absurdly long alternates (in most/many networks). In that context, the comparison is to the "optimal" and Remote-LFA is to help show what the trade-offf for alternate length is. If we want to see if a different MRT algorithm gives better alternate lengths, that is also interesting but comes at a computational cost. > > OTOH, if the algorithm was to be compared with other potential > candidates (including the options in the appendices) then it could provid= e > better justification..and it would fit better in a > section titled "Algorithm Alternatives and Evaluation" that starts with t= he > following text: "This specification defines the MRT Lowpoint Algorithm, > which is one option among several possible MRT algorithms. Other > alternatives are described in the appendices." > [Alia] Yes - I should have cleaned that text up. We'll try for some comparison results - if not in time for this IETF - then shortly after. > >> Nits: >> >> 1. Section 2. "standard pseudo-node representation" Reference? >> >> [Alia] Do you just want me to refer to OSPFv2? I can go hunt a > reference for better normative explanation or just describe transforming > all broadcast interfaces into a pseudo-node with p2p links with appropria= te > costs. > > > I usually think about ISIS when I think about pseudo-nodes..which is why > we need a reference to that the "standard representation" is. ;-) > Sounds like spelling it out to be a representation where all links are p2p and the necessary pseudo-nodes are added to make it so - basically the same network graph as an SPF is run on.... Alia --001a11c2fe3c87b35304e86965db Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Replies in-line as always...


On Thu, Oct 10, 2013 at 10:12 AM, Alvar= o Retana (aretana) <aretana@cisco.com> wrote:
On 10/9/13 5:06 PM, "Alia Atlas" <akatlas@gmail.com> wrote:

<WG Chair Hat Off>

Alia:

Hi!

I pruned most of the text off to leave the relevant parts.

Thanks!!

Alvaro.

. . .
=A0
The draft has an intended status of Informational. =A0H= owever, the Introduction reads: =A0"This document defines the MRT Lowp= oint=A0algorithm to be used as a standard in the default MRT profile for=A0MRT-FRR." =A0Which one is it?

[Alia] I think that the algorithm draft needs to be standards track. = =A0I apologize for not updating the intended status - I was focused on the = contents.

IMHO, there= 9;s a significant difference in saying "this is an algorithm than can = be used" (informational) vs "this is the algorithm that MUST be u= sed" (standard). =A0For the record, I have no issues with adopting this draft with an intended status of Informational.

[Alia] The intent is to have signaling that says this is the algorithm= being used. There's capabilities to indicate different algorithms - bu= t I do think that this particular algorithm and details must be standards-t= rack for interoperability.

The capabilities you're talking about are in I-D.atlas-ospf-mrt, right?=

What I see in there is a way to indicate which profile is supported..which = I guess ties into the algorithm (for example, the Lowpoint is tied in the d= raft to the default profile).. =A0It's not a direct way of indicating t= he algorithm, but that's what you mean, right?

BTW, I have no problem in the indication being indirect..

[Alia] Right - the algorithm is one aspect of a = profile - and different profiles can be specified.=A0
=A0
BTW2, on the architecture draft (Section 7) the default profile is describe= d..but it took me a while to find it because the words "default MRT pr= ofile" showed up 2-3 paragraphs before the profile was actually define= d. =A0It might be nice (for people like me) to clearly state: "This is the default MRT profile:".

[Alia] =A0Sure - =A0I expect that we co-a= uthors should go over the arch draft and make sure that the normative detai= ls are clearly specified as such and clearly. =A0In this case, I think it&#= 39;s just reordering a bit - since the architecture draft talks about the c= oncept of MRT profiles and that there is a default MRT profile before defin= ing what that default is. =A0I don't expect to have that done for this = IETF - unless there is serious concern about a lack of clarity.
=A0
I should read = the architecture draft closer..but isn't it like putting the carriage b= efore the horse to specify there (and not in the algorithm draft) that the = Lowpoint algorithm is the one used in the default MRT profile?

[Alia] I didn't think so (= but you knew that ;-) - having it make sense to define the default MRT prof= ile where the concept of MRT profiles is defined. =A0I do agree that it mak= es sense to have the algorithm draft reference the architecture draft and t= hat the lowpoint algorithm is used in the default MRT profile - so basicall= y say it in both places :-)
=A0

. . .

  1. I found it interesting that, even though the document is= =A0defining an=A0algorithm that when implemented will need to have consiste= ncy across nodes, there was no reference to RFC2119=A0=97=A0but some of the words were capitalized anyway. Even the= n, only 4 "MUST" and 1 "SHOULD" appeared. =A0I realize = that the count of MUST/SHOULD is no indication of anything, but it doesn= 9;t feel right for a 40+ page document. =A0I would appreciate if the authors would not just add the 2119 reference (nit), but if they would als= o comb the text for parts where a little more normative direction might hel= p (which doesn't necessarily translate into MUSTs).
[Alia] Agreed - in general, what I intend to do is to have the explana= tory text that explains the logic of the algorithm and how it works much as= it is - and then to pull together the different parts of the pseudo-code i= nto a fully detailed algorithm (some by reference to the earlier parts) that indicates the MUST/SHOULD aspects.= =A0 The specific request though seems more to be to take a careful read th= rough and clarify what is MUST and what is SHOULD.=A0

I think the end result should be the same. =A0All I want it to make sure th= at the mandatory parts are clear for everyone to implement.

[Alia] Absolutely.=A0
. . .
    • Root Selection. =A0No algorithm is provided. There's= a reference to I-D.atlas-ospf-mrt, where a suggestion is made ("..the= router=A0with the highest GADAG Root Selection Priority is picked to be the GADAG Root"). =A0IMHO, the algorithm should be sp= ecified in this draft,=A0where=A0the requirement to carry the Priority is d= efined so that the extensions draft(s) can show how to implement it in OSPF= (or any other protocol)..not the other way around.
[Alia] The Root Selection is described in draft-ietf-rtgwg-mrt-frr-arc= hitecture in Sec 7 as=A0
'"GADAG Root Selection Priority= : Among the routers in the MRT Island=A0and with the highest priority advertised, an implementation MUST=A0=A0pick the router with the highest Router ID to be the GADAG root."

This goes back to my comment above about the capabilities and the default p= rofile definition: If this is part of the algorithm it should be specified = in the algorithm draft, not somewhere else.

[Alia] Ah - the GADAG root selection is part of the MRT prof= ile but not, IMHO, part of the algorithm... =A0The same Lowpoint algorithm = can be used with different GADAG root selection. =A0For example, for multic= ast, one might do an MRT profile where the multicast S is picked to be the = GADAG root - and the same Lowpoint algorithm is run.

=A0

. . .

  1. Algorithm Alternatives and Evaluation= . =A0There are a couple of alternatives described in the=A0appendices, but = there is no evaluation as to why the Lowpoint Algorithm is better. =A0In fa= ct, the text seems to read as if the appendices describe options to the main algorithm (?) -- begging the question, are th= ere instances where these options would/could be used?
[Alia] True - in our initial evaluations, we didn't find significa= nt differences in the path lengths for the alternates. =A0Chris Bowers can = comment on that a bit. =A0I thought that I'd cleaned up the text in the= main draft to clarify that the lowpoint algorithm - which has much less computation - is preferable. =A0Can you point to whe= re the algorithms in the appendices are considered equivalent? =A0I will, o= f course, take another read through as well - trying to reduce that issue.<= /div>

Where in the main draft? =A0And by "main draft" do you mean the a= rchitecture one?
[Alia] Sorry to have been unc= lear - by main draft I meant the algorithm draft that isn't in the appe= ndices.=A0

My point was t= hat you are presenting options to the proposed algorithm that are not used.= .but there is no clear explanation as to why not (at least not that I found= in this draft). =A0IOW, I think that if these options are not part of the = main algorithm then you should explain why not (but you already said above that there weren= 9;t significant differences in the results), or just take them out to avoid= confusion.

[Alia] Sure - I= put them in an appendix while we decided which to do :-)=A0

. . .
    • "UNDIRECTED/OUTGOING/INCO= MING" =A0These are used in the algorithm in various points, but are no= t really defined as to=A0
[Alia] =A0umm, how would you define them beyond their obvious meaning?= =A0Outgoing is from the interface's router to the remote end. =A0 Inco= ming is from the remote router to the interface's router.

:-)

The text starts talking about marking the links (and even the pseudo-code u= ses the terms), but they are not defined. =A0Yes, I can guess what they mea= n..but if we want consistency you don't want people guessing.

[Alia] True... =A0I do describe everything= about how they are used - but I'll try for better text too.=A0

. . .
  1. Algorithm Evalu= ation. =A0While it is interesting to see MRT compared to rLFA, it would be = much more interesting to see it compared to the options in the appendices o= r to ARC. =A0I would move the comparison to rLFA to an appendix.
[Alia] =A0It is being compared to other options that are being serious= ly used for fast-reroute. =A0That includes rLFA. =A0I don't understand = why you think the comparison isn't relevant? =A0 We didn't quite ha= ve time to get the comparison fully done for MRT lowpoint compared to the SPF-based and hybrid versions. =A0I think that is somethin= g we can add - but again, we didn't find a significant impvorement.=A0<= /div>

I didn't say that the comparison is irrelevant..I just said that I woul= d move it to an appendix.

In this draft you're proposing an algorithm to be used as the default i= n MRT. =A0We already know that rLFA can't always provide 100% coverage.= =A0I think that comparing the proposed algorithm to something that we know= doesn't provide the same coverage is interesting, but it doesn't illustrate why this algorithm should be the default =97= it just proves that "the=A0100% coverage provided by MRT comes at the= expense of a modest=A0increase in alternate path length." =A0That is = an interesting result..I just find it purely informational wrt to the contents and objective of the draft.

[Alia] AH - I am trying to show that MRT Lowpoint is a go= od fast-reroute mechanism that offers 100% coverage with good computation a= nd without causing absurdly long alternates (in most/many networks). =A0 = =A0In that context, the comparison is to the "optimal"
and Remote-LFA is to help show what the trade-offf for alternate lengt= h is. =A0If we want to see if a different MRT algorithm gives better altern= ate lengths, that is also interesting but comes at a computational cost.
=A0

OTOH, if the algorithm was to be com= pared with other potential candidates (including the options in the appendi= ces) then it could provide better justification..and it would fit better in= a section=A0titled=A0"Algorithm Alternatives and Evaluation" that starts with the following text: "This specification defines the = MRT Lowpoint Algorithm, which is one=A0option among several possible MRT algorithms. =A0Other alternatives are=A0described in the appendices."

[Alia] Yes - I should have cleaned that = text up. =A0We'll try for some comparison results - if not in time for = this IETF - then shortly after.
=A0

Nits:
  1. Section 2. =A0&= quot;standard pseudo-node representation" =A0Reference?
[Alia] Do you just want me to refer to OSPFv2? =A0I can go hunt a refe= rence for better normative explanation or just describe transforming all br= oadcast interfaces into a pseudo-node with p2p links with appropriate costs= .

I usually think about ISIS when I think about pseudo-nodes..whic= h is why we need a reference to that the "standard representation"= ; is. =A0;-)

Sounds like spellin= g it out to be a representation where all links are p2p and the necessary p= seudo-nodes are added to make it so - basically the same network graph as a= n SPF is run on....

Alia
<= /div> --001a11c2fe3c87b35304e86965db-- From stephane.litkowski@orange.com Fri Oct 11 06:30:09 2013 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 11E0721E8108 for ; Fri, 11 Oct 2013 06:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agtoFDZyHJ9w for ; Fri, 11 Oct 2013 06:30:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3333421E8102 for ; Fri, 11 Oct 2013 06:30:02 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 0F0D326455A; Fri, 11 Oct 2013 15:30:01 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id DD7E835C069; Fri, 11 Oct 2013 15:30:00 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.45]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Fri, 11 Oct 2013 15:30:00 +0200 From: To: Chris Bowers , "rtgwg@ietf.org" Date: Fri, 11 Oct 2013 15:29:59 +0200 Subject: RE: algorithm description for draft-ietf-rtgwg-remote-lfa Thread-Topic: algorithm description for draft-ietf-rtgwg-remote-lfa Thread-Index: Ac6ptHQ7OAnN8935QeKjlomkchLu2wcGXUCgAC3F9PA= Message-ID: <29995_1381498201_5257FD58_29995_11275_1_EEE55384044474429A926C625D0FCC8109693082C7@PUEXCB2F.nanterre.francetelecom.fr> References: <8987a924cffe4af1b2bc2f94a7950a6e@BL2PR05MB113.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_EEE55384044474429A926C625D0FCC8109693082C7PUEXCB2Fnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.10.11.110614 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, 11 Oct 2013 13:30:09 -0000 --_000_EEE55384044474429A926C625D0FCC8109693082C7PUEXCB2Fnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Completely agree with Chris. Moreover having the algorithm part described clearly inside the main paragr= aphs of the document rather than the appendix is completely inline with wha= t has been done for basic LFA specification (RFC 5286 Paragraph 3.6 - Selec= tion procedure). As mentioned by Chris, it is important to mention that rLFA alternate must = not be dependant on any direct LFA selection. rLFA must be able to rely on = any LFA (Extended P Space) whatever this LFA is best or not. Stephane De : rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] De la part de C= hris Bowers Envoy=E9 : jeudi 10 octobre 2013 19:00 =C0 : rtgwg@ietf.org Objet : RE: algorithm description for draft-ietf-rtgwg-remote-lfa Stewart proposed in another thread making this algorithm text part of an ap= pendix (see snippet below.) I want to emphasize the importance of adding m= ore quantitative content to the normative sections of the text, by illustra= ting an example of the confusion created by some of the current text. Today I was in a discussion regarding the criteria for evaluating for use a= s a tunnel endpoint, a node Y in extended-P space which is reachable from s= ource S by way of S's neighbor N1. Some confusion arose during the discuss= ion over whether or not the node Y should be rejected for consideration if = policy had been applied rejecting N1 as a (local)LFA for reaching Y. We ag= reed that the evaluation of Y as a tunnel endpoint for remote LFA should no= t depend on the policy applied to the (local)LFA to reach Y. However, the text below in section 4.2.2 leads to confusion on this point. "Another way to describe extended P-space is that it is the union of ( un-extended ) P-space and the set of destinations for which S has a per-prefix LFA protecting the link S-E." I think this text should be removed and replaced with precise quantitative = criteria for membership in extended P-space. It is likely that remote LFA = will be deployed together with (local)LFA with policy determining which typ= e of alternate to use (draft-litkowski-rtgwg-lfa-manageability). Describin= g remote LFA in terms of (local)LFA will create confusion for someone tryin= g to apply policy. Quantitative criteria avoid this confusion. If this text creates such confusion among experts, it is likely to create e= ven more confusion among end-users of the technology, when trying to figure= out what is really going on in their network. While one might argue that = this behavior is up to the vendor to document, confusing text in the base r= lfa draft will make that task much more difficult. --------- A response to this algorithm text showed up in another thread so I am cutti= ng and pasting Stewart Bryant's response from 10/2/13 to this thread to keep t= hings organized. [SB] "I plan to put in the algorithm text, although having discussed this with Mike, our inclination is to include this as an appendix since it is not required for interoperability that you do the computation that way." --------- Chris From: rtgwg-bounces@ietf.org [mailto:rtgwg-b= ounces@ietf.org] On Behalf Of Chris Bowers Sent: Wednesday, September 04, 2013 4:22 PM To: rtgwg@ietf.org Subject: algorithm description for draft-ietf-rtgwg-remote-lfa As has been pointed out in other email threads, the current version of draft-ietf-rtgwg-remote-lfa-02.txt lacks a formal description of the algorithm being proposed. Below is a such a formal algorithm description, based on my reading of the current draft. It would help progress this draft forward if the authors would correct any errors in this pseudo-code representation of the algorithm. The pseudo-code below avoids unnecessary SPF computations, but for the sake of readability, it does not otherwise try to optimize the code. Remote LFA algorithm Compute_and_Store_Forward_SPF(node root) Compute_Forward_SPF(root) foreach node z in network store D_opt(root,z) Compute_and_Store_Reverse_SPF(node root) Compute_Reverse_SPF(root) foreach node z in network store D_opt(z,root) Compute_Neighbor_SPFs() foreach interface intf in self if (intf.remote_node !=3D fail_intf.remote_node) Compute_and_Store_Forward_SPF(intf.remote_node) Compute_Extended_P_Space() foreach node y in network y.in_extended_P_space =3D false if (D_opt(self, y) < D_opt(self, fail_intf.remote_node) + D_opt(fail_intf.remote= _node,y)) y.in_extended_P_space =3D true foreach interface intf in self if (intf.remote_node !=3D fail_intf.remote_node) if ( D_opt(intf.remote_node, y) < D_opt(intf.remote_node, s= elf) + D_opt(self,fail_intf.remote_node) + D_opt(fail_intf.remote_node,y) ) y.in_extended_P_space =3D true Compute_Q_Space() Compute_and_Store_Reverse_SPF(fail_intf.remote_node) foreach node y in network if ( D_opt(y,fail_intf.remote_node) < D_opt(y,self) + D_opt(self,fail_intf.remote_node) ) y.in_Q_space =3D true else y.in_Q_space =3D false Intersect_Extended_P_and_Q_Space() foreach node y in network if ( y.in_extended_P_space && y.in_Q_space ) y.valid_tunnel_endpoint =3D true else y.valid_tunnel_endpoint =3D false Apply_Downstream_Constraint() foreach node y in network if (y.valid_tunnel_endpoint) Compute_and_Store_Forward_SPF(y) if ((D_opt(y,dest) < D_opt(self,dest)) y.valid_tunnel_endpoint =3D true else y.valid_tunnel_endpoint =3D false Compute_Neighbor_SPFs() Compute_Extended_P_Space() Compute_Q_Space() Intersect_Extended_P_and_Q_Space() if (guarantee_no_looping_on_worse_than_protected_failure) Apply_Downstream_Constraint() ********** I would also like to propose that the following text to be inserted after the last paragraph of section 4.2.1. "Computing Repair Paths". It should be noted that using the Q-space of E as a proxy for the Q-space of each destination can result in failing to identify valid remote LFAs. The extent to which this reduces the effective protection coverage is topology dependent. *********** Thanks, Chris ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_EEE55384044474429A926C625D0FCC8109693082C7PUEXCB2Fnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Completely agree with Chris.

 

= Moreover having the algorithm part described clearly in= side the main paragraphs of the document rather than the appendix is comple= tely inline with what has been done for basic LFA specification (RFC 5286 P= aragraph 3.6 – Selection procedure).

 

As mentioned by Chris, it is important to mention t= hat rLFA alternate must not be dependant on any direct LFA selection. rLFA = must be able to rely on any LFA (Extended P Space) whatever this LFA is bes= t or not.

 

&nbs= p;

Stephane

=

 

 

De : rtgwg-bounces@ietf.org [mailto:rtgwg-bou= nces@ietf.org] De la part de Chris Bowers
Envoy=E9 : = jeudi 10 octobre 2013 19:00
=C0 : rtgwg@ietf.org
Objet=  : RE: algorithm description for draft-ietf-rtgwg-remote-lfa<= /o:p>

 

Stewart proposed in another thread making this a= lgorithm text part of an appendix (see snippet below.)  I want to emph= asize the importance of adding more quantitative content to the normative s= ections of the text, by illustrating an example of the confusion created by= some of the current text.

 

Today I wa= s in a discussion regarding the criteria for evaluating for use as a tunnel= endpoint, a node Y in extended-P space which is reachable from source S by= way of S’s neighbor N1.  Some confusion arose during the discus= sion over whether or not the node Y should be rejected for consideration if= policy had been applied rejecting N1 as a (local)LFA for reaching Y. = We agreed that the evaluation of Y as a tunnel endpoint for remote LFA sho= uld not depend on the policy applied to the (local)LFA to reach Y.

 

However, the text below in section 4.2.2 lead= s to confusion on this point. 

 

“Another way to describe extended P-space is that it is the union of= (

un-extended ) P-spa= ce and the set of destinations for which S has a

per-prefix LFA protecting the link S-E.”

 

I think this text should be removed an= d replaced with precise quantitative criteria for membership in extended P-= space.  It is likely that remote LFA will be deployed together with (l= ocal)LFA with policy determining which type of alternate to use (draft-litk= owski-rtgwg-lfa-manageability).  Describing remote LFA in terms of (lo= cal)LFA will create confusion for someone trying to apply policy. Quantitat= ive criteria avoid this confusion. 

 

If this text creates such confusion among experts, it is likely to cre= ate even more confusion among end-users of the technology, when trying to f= igure out what is really going on in their network.  While one might a= rgue that this behavior is up to the vendor to document, confusing text in = the base rlfa draft will make that task much more difficult.

 

---------

A response to this algorithm text showed up in another thread s= o I am cutting

and pas= ting Stewart Bryant’s response from 10/2/13 to this thread to keep th= ings organized.

&= nbsp;

[SB] “I plan to= put in the algorithm text, although having discussed

=

this with Mike, our inclination is to inclu= de this as an

appendix= since it is not required for interoperability that

<= p class=3DMsoNormal>you do the computation that way.”=

---------

 

Chris

 

&n= bsp;

 

As has been pointed out in other email threads,

the current version of draft-ietf-rtgwg-remote-l= fa-02.txt

lacks a forma= l description of the algorithm being proposed.

<= div>

Below is a such a formal algorithm description, based= on my

reading of the cu= rrent draft.  It would help progress this

=

draft forward if the authors would correct any error= s

in this pseudo-code re= presentation of the algorithm.

 

The pseudo-c= ode below avoids unnecessary SPF computations, but

for the sake of readability, it does not otherwis= e try to

optimize the = code.

 

Remote LFA algorithm

 

Compute_and_Store_Forward_SPF(node root)<= /p>

    Compute_Forward_SPF(root= )

    fore= ach node z in network

= &nb= sp;       store D_opt(root,z)

      &nbs= p;

Compute_and_Store_Rev= erse_SPF(node root)

 = ;   Compute_Reverse_SPF(root)

    foreach node z in network

      &nbs= p; store D_opt(z,root)

&n= bsp;

Compute_Neighbor_SPF= s()

    f= oreach interface intf in self

        if (intf.remote_node !=3D f= ail_intf.remote_node)

= &nb= sp;           Compute_and= _Store_Forward_SPF(intf.remote_node)

 

Comput= e_Extended_P_Space()

<= span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Courier New"'>&nbs= p;   foreach node y in network

        y.in_extended_P_= space =3D false

 &nb= sp;      if (D_opt(self, y) <

       = ;         D_opt(self, fail_intf.rem= ote_node) + D_opt(fail_intf.remote_node,y))

         &n= bsp;  y.in_extended_P_space =3D true

<= p class=3DMsoNormal>        foreach interfa= ce intf in self

 &nb= sp;          if (intf.remote_n= ode !=3D fail_intf.remote_node)

           &n= bsp;    if ( D_opt(intf.remote_node, y) < D_opt(intf.remo= te_node, self) +

 &n= bsp;            = ;          D_opt(self,fail_int= f.remote_node) +

 &n= bsp;            = ;          D_opt(fail_intf.rem= ote_node,y) )

  = ;            &n= bsp;     y.in_extended_P_space =3D true  &nbs= p;             =

 =

Compute_Q_Space()

    Compute_and_Store_Reverse_SPF(= fail_intf.remote_node)

&n= bsp;   foreach node y in network

=

        if ( D_opt(y,f= ail_intf.remote_node) < D_opt(y,self) +

=

         &nb= sp;      D_opt(self,fail_intf.remote_node) )<= /o:p>

     =        y.in_Q_space =3D true

       = ; else

   =          y.in_Q_space =3D false

    &nb= sp;            =       

Intersect_Extended_P_and_Q_Space()

=

    foreach node y in network

     &n= bsp;  if ( y.in_extended_P_space && y.in_Q_space )<= /span>

      =       y.valid_tunnel_endpoint =3D true<= /span>

      =   else

  &= nbsp;         y.valid_tunnel_endpoi= nt =3D false

  =             &nb= sp;            =             

Apply_Downstream_Constrain= t()

    fo= reach node y in network

&= nbsp;       if (y.valid_tunnel_endpoint)=

    &nb= sp;       Compute_and_Store_Forward_SPF(y)

    &nb= sp;       if ((D_opt(y,dest) < D_opt(self,= dest))

   =              y.= valid_tunnel_endpoint =3D true

           else

    &nb= sp;           y.valid_tun= nel_endpoint =3D false

&n= bsp;            = ;            &n= bsp;     

Compute_Neighbor_SPFs()

Compute_Extended_P_Space()

Compute_Q_Space()

Intersect_Extended_P_and_Q_Space()

if (guarantee_no_looping_on_worse_than_protected_failure)

    Apply_Do= wnstream_Constraint()

= &nb= sp;

**********  = ;   

<= span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Courier New"'>&nbs= p;

I would also like to p= ropose that the following text to be

inserted after the last paragraph of

section 4.2.1. "Computing Repair Paths"= .

 

It should be noted that using the Q-space= of E as a proxy for the Q-space

of each destination can result in failing to identify valid remot= e LFAs. 

The extent= to which this reduces the effective protection coverage is

topology dependent.

 

***********

 

Thank= s,

Chris

 

=

 

_______________________________________________________________=
__________________________________________________________

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,
Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
= --_000_EEE55384044474429A926C625D0FCC8109693082C7PUEXCB2Fnante_-- From aretana@cisco.com Fri Oct 11 11:04:48 2013 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 226BA11E812F for ; Fri, 11 Oct 2013 11:04:48 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOo7M+iRYava for ; Fri, 11 Oct 2013 11:04:42 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 520E111E812B for ; Fri, 11 Oct 2013 11:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8335; q=dns/txt; s=iport; t=1381514681; x=1382724281; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=J5ah7R6xCilWmJA6N0FmEumAhJfzfiJOZyjmAa8wSnE=; b=gngZps2nQDDpdxTfrmUdTFyWsbcNe9Iz22VnFf4KpmjPtvXYHDWW2ZoJ pDMZoWbRwrj+Yq9NHEPk9A2j7TS8B5UEXF2y+8AxHKxhlKHj9Ebw2WmTj rmz0G845lQVxArvTYTf8IYIPLlxMiJp842Ze8mm+rzuv6Trfc5jHPUmpQ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAII8WFKtJXG8/2dsb2JhbABagkNEgQrBWIEkFnSCJwEEeRIBCA4EEB0oERQDDgIEDgUIh2wDD7EbDYlrjFqCPDEHgx+BBAOWHI41hTaDJIIq X-IronPort-AV: E=Sophos;i="4.93,1082,1378857600"; d="scan'208,217";a="271087280" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 11 Oct 2013 18:04:41 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9BI4eSU012704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Oct 2013 18:04:40 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.40]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Fri, 11 Oct 2013 13:04:40 -0500 From: "Alvaro Retana (aretana)" To: Alia Atlas Subject: Re: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm) Thread-Topic: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm) Thread-Index: AQHOxfzTs75/+HuThkGNg/U9+2YuGpnv3XuA Date: Fri, 11 Oct 2013 18:04:39 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.7] Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94E395E12B9xmbalnx15ciscoc_" MIME-Version: 1.0 Cc: "draft-enyedi-rtgwg-mrt-frr-algorithm@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: Fri, 11 Oct 2013 18:04:48 -0000 --_000_BBD66FD99311804F80324E8139B3C94E395E12B9xmbalnx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! On 10/10/13 5:07 PM, "Alia Atlas" > wrote: . . . 1. * Root Selection. No algorithm is provided. There's a reference to = I-D.atlas-ospf-mrt, where a suggestion is made ("..the router with the high= est GADAG Root Selection Priority is picked to be the GADAG Root"). IMHO, = the algorithm should be specified in this draft, where the requirement to c= arry the Priority is defined so that the extensions draft(s) can show how t= o implement it in OSPF (or any other protocol)..not the other way around. [Alia] The Root Selection is described in draft-ietf-rtgwg-mrt-frr-architec= ture in Sec 7 as '"GADAG Root Selection Priority: Among the routers in the MRT Island and wi= th the highest priority advertised, an implementation MUST pick the router= with the highest Router ID to be the GADAG root." This goes back to my comment above about the capabilities and the default p= rofile definition: If this is part of the algorithm it should be specified = in the algorithm draft, not somewhere else. [Alia] Ah - the GADAG root selection is part of the MRT profile but not, IM= HO, part of the algorithm... The same Lowpoint algorithm can be used with = different GADAG root selection. For example, for multicast, one might do a= n MRT profile where the multicast S is picked to be the GADAG root - and th= e same Lowpoint algorithm is run. But the performance of the algorithm can be affected by the selection of th= e root. In 6.1 you wrote: "The particular choice of a common GADAG root is= expected to affect the quality of the MRT alternate paths, with a more cen= tral common GADAG root resulting in shorter MRT alternate path lengths." F= or the results you chose a centrally located node to be the root. What wou= ld have happened if the root had been selected randomly? (Or the equivalen= t which would be to assign random Priorities.) I guess my point here is that one of the reasons the Lowpoint algorithm per= forms well is because of how the root is selected. We could go back and fo= rth all day about whether the root selection should be part of the "default= algorithm" or just part of the "default profile"..but I think it would be = more important to stress (even mandate) that the location of the nodes be c= onsidered when assigning the Priority. Note that the current text ("Off-line analysis that considers the centralit= y of a router may help determine how good a choice a particular router is f= or the role of GADAG root." -- which is too soft for my taste) is in the al= gorithm draft, not in the architecture draft (which defines the profile), s= o it may not be completely clear.. Thanks! Alvaro. --_000_BBD66FD99311804F80324E8139B3C94E395E12B9xmbalnx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
<WG Chair Hat Off>

Hi!

On 10/10/13 5:07 PM, "Alia Atlas" <akatlas@gmail.com> wrote:

. . .
    • Root Selection.=  No algorithm is provided. There's a reference to I-D.atlas-ospf-mrt,= where a suggestion is made ("..the router with the highest GADAG= Root Selection Priority is picked to be the GADAG Root").  IMHO, the algorithm should be specified in this draft,&= nbsp;where the requirement to carry the Priority is defined so that th= e extensions draft(s) can show how to implement it in OSPF (or any other pr= otocol)..not the other way around.
[Alia] The Root Selection is described in draft-ietf-rtgwg-mrt-frr-arc= hitecture in Sec 7 as 
'"GADAG Root Selection Priority: Am= ong the routers in the MRT Island and with the highest priority advertised, an implementation MUST  pick the router with the highest Router ID to be the GADAG root."

This goes back= to my comment above about the capabilities and the default profile definit= ion: If this is part of the algorithm it should be specified in the algorit= hm draft, not somewhere else.

[Alia] Ah - the GADAG root selection is part of the MRT profile but no= t, IMHO, part of the algorithm...  The same Lowpoint algorithm can be = used with different GADAG root selection.  For example, for multicast,= one might do an MRT profile where the multicast S is picked to be the GADAG root - and the same Lowpoint algorithm is run.=

But the performance of the algorithm can be affected by the selection = of the root.  In 6.1 you wrote: "The particular choice of a = common GADAG root is expected to affect the quality of the MRT alterna= te paths, with a more central common GADAG root resulting in shorter MRT alternate path lengths."  For the results you cho= se a centrally located node to be the root.  What would have happened = if the root had been selected randomly?  (Or the equivalent which woul= d be to assign random Priorities.)

I guess my point here is that one of the reasons the Lowpoint algorith= m performs well is because of how the root is selected.  We could go b= ack and forth all day about whether the root selection should be part of th= e "default algorithm" or just part of the "default profile"..but I think it would be more important to= stress (even mandate) that the location of the nodes be considered when as= signing the Priority.

Note that the current text ("Off-line analysis that considers the= centrality of a router may help determine how good a choice a particu= lar router is for the role of GADAG root." -- which is too soft f= or my taste) is in the algorithm draft, not in the architecture draft (which defines the profile), so it may not be completely clear..

Thanks!

Alvaro.
--_000_BBD66FD99311804F80324E8139B3C94E395E12B9xmbalnx15ciscoc_-- From akatlas@gmail.com Fri Oct 11 11:15:09 2013 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 4AA4F21F8EA8 for ; Fri, 11 Oct 2013 11:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkanGK8qHIfy for ; Fri, 11 Oct 2013 11:15:07 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5696411E812F for ; Fri, 11 Oct 2013 11:14:59 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id to1so9082714ieb.37 for ; Fri, 11 Oct 2013 11:14:58 -0700 (PDT) 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=RDz9+lJKK11Cxh0KxoUHFJM/BlhuSjo5Fr9PHbxGEAw=; b=QUb2j8SVXtzjk6U2chYuUI2vU3FkMGfkCt68jn7GclA4SFSFpFQotiSIDF08jwVHz0 dBaAnkWo1Ph/UFx4jlPQAAIdIaDS0g+W8511qX6eJe5YG1DBfwAkeVfHJTWnfyvby2vq QaInUb0ELFyARa7y/VqrFDC0MlAGDfv7GHJJi5GnDej6VDCTqbK7tCCkL/GwhoLzzfbA eegCwXB2sbyPcGr6Dh4culxSSZpbmQskhIKfeEon9xNGKK06hjveG0aKvhxqGNJO6oYg y8+5myuB8irO70vGzItdBOZqVoJCAmpe+eW/ypgVVFNyD/zevMAq4cSK3UzUHterJJHM pPfw== MIME-Version: 1.0 X-Received: by 10.50.119.70 with SMTP id ks6mr3845075igb.22.1381515298734; Fri, 11 Oct 2013 11:14:58 -0700 (PDT) Received: by 10.64.78.72 with HTTP; Fri, 11 Oct 2013 11:14:58 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 Oct 2013 14:14:58 -0400 Message-ID: Subject: Re: WG Adoption of MRT Algorithms Draft (draft-enyedi-rtgwg-mrt-frr-algorithm) From: Alia Atlas To: "Alvaro Retana (aretana)" Content-Type: multipart/alternative; boundary=089e0111d9b8a20ce204e87b18bf Cc: "draft-enyedi-rtgwg-mrt-frr-algorithm@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: Fri, 11 Oct 2013 18:15:09 -0000 --089e0111d9b8a20ce204e87b18bf Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 11, 2013 at 2:04 PM, Alvaro Retana (aretana) wrote: > > > Hi! > > On 10/10/13 5:07 PM, "Alia Atlas" wrote: > > . . . > > >>> 1. >>> - Root Selection. No algorithm is provided. There's a reference >>> to I-D.atlas-ospf-mrt, where a suggestion is made ("..the router with the >>> highest GADAG Root Selection Priority is picked to be the GADAG Root"). >>> IMHO, the algorithm should be specified in this draft, where the >>> requirement to carry the Priority is defined so that the extensions >>> draft(s) can show how to implement it in OSPF (or any other protocol)..not >>> the other way around. >>> >>> [Alia] The Root Selection is described in >> draft-ietf-rtgwg-mrt-frr-architecture in Sec 7 as >> '"GADAG Root Selection Priority: Among the routers in the MRT Island and >> with the highest priority advertised, an implementation MUST pick the >> router with the highest Router ID to be the GADAG root." >> >> >> This goes back to my comment above about the capabilities and the >> default profile definition: If this is part of the algorithm it should be >> specified in the algorithm draft, not somewhere else. >> > > [Alia] Ah - the GADAG root selection is part of the MRT profile but not, > IMHO, part of the algorithm... The same Lowpoint algorithm can be used > with different GADAG root selection. For example, for multicast, one might > do an MRT profile where the multicast S is picked to be the GADAG root - > and the same Lowpoint algorithm is run. > > > But the performance of the algorithm can be affected by the selection of > the root. In 6.1 you wrote: "The particular choice of a common GADAG root > is expected to affect the quality of the MRT alternate paths, with a more > central common GADAG root resulting in shorter MRT alternate path lengths." > For the results you chose a centrally located node to be the root. What > would have happened if the root had been selected randomly? (Or the > equivalent which would be to assign random Priorities.) > [Alia] There is variability, of course, but we found that up to the first 50th percentile of centrality nodes were fairly similar. This is really a "don't locate it in Timbuktu" if your network is mostly in NA kind of thing. > I guess my point here is that one of the reasons the Lowpoint algorithm > performs well is because of how the root is selected. We could go back and > forth all day about whether the root selection should be part of the > "default algorithm" or just part of the "default profile"..but I think it > would be more important to stress (even mandate) that the location of the > nodes be considered when assigning the Priority. > [Alia] Absolutely - the operator should do some basic analysis and pick a node for GADAG root that is basically well connected and in the spine/core of the network. I'm sorry if the difference between "default algorithm" and "default profile" seems like pedantry - I'm trying to set up MRT to work for multiple purposes (multicast live-live and MRT-FRR) and keep the right parts separated. Note that the current text ("Off-line analysis that considers the > centrality of a router may help determine how good a choice a particular > router is for the role of GADAG root." -- which is too soft for my taste) > is in the algorithm draft, not in the architecture draft (which defines the > profile), so it may not be completely clear.. > [Alia] Sure - I see your point and would be happy to add in some comments there. I'm afraid that the analysis giving clue as to importance of GADAG root selection came while I was updating drafts and may not have gone through them sufficiently. Alia > Thanks! > > Alvaro. > --089e0111d9b8a20ce204e87b18bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 11, 2013 at 2:04 PM, Alvaro Retana (aretana) <= span dir=3D"ltr"><aretana@cisco.com> wrote:
<WG Chair Hat Off>

Hi!

On 10/10/13 5:07 PM, "Alia Atlas" &l= t;akatlas@gmail.com<= /a>> wrote:

. . .
    • Root Selection.= =A0No algorithm is provided. There's a reference to I-D.atlas-ospf-mrt= , where a suggestion is made ("..the router=A0with the highest GADAG R= oot Selection Priority is picked to be the GADAG Root"). =A0IMHO, the algorithm should be specified in this draft,=A0w= here=A0the requirement to carry the Priority is defined so that the extensi= ons draft(s) can show how to implement it in OSPF (or any other protocol)..= not the other way around.
[Alia] The Root Selection is described in draft-ietf-rtgwg-mrt-frr-arc= hitecture in Sec 7 as=A0
'"GADAG Root Selection Priority= : Among the routers in the MRT Island=A0and with the highest priority advertised, an implementation MUST=A0=A0pick the router with the highest Router ID to be the GADAG root."

This goes back= to my comment above about the capabilities and the default profile definit= ion: If this is part of the algorithm it should be specified in the algorit= hm draft, not somewhere else.

[Alia] Ah - the GADAG root selection is part of the MRT profile but no= t, IMHO, part of the algorithm... =A0The same Lowpoint algorithm can be use= d with different GADAG root selection. =A0For example, for multicast, one m= ight do an MRT profile where the multicast S is picked to be the GADAG root - and the same Lowpoint algorithm is run.=


=A0
I guess my point here is that one of the reasons the Lowpoint algorith= m performs well is because of how the root is selected. =A0We could go back= and forth all day about whether the root selection should be part of the &= quot;default algorithm" or just part of the "default profile"..but I think it would be more important to= stress (even mandate) that the location of the nodes be considered when as= signing the Priority.

[Alia] Absolutely - the operator should do some basic analysis and pick a n= ode for GADAG root that is basically well connected and in the spine/core o= f the network. =A0 I'm sorry if the difference between "default al= gorithm" and "default profile" seems like pedantry - =A0I= 9;m trying to set up MRT to work for multiple purposes (multicast live-live= and MRT-FRR) and keep the right parts separated.

Note that the current text ("Off-line analysis that considers the= centrality of a router may help=A0determine how good a choice a particular= router is for the role of=A0GADAG root." -- which is too soft for my = taste) is in the algorithm draft, not in the architecture draft (which defines the profile), so it may not be completely clear..
=

[Alia] Sure - I see your point= and would be happy to add in some comments there. =A0I'm afraid that t= he analysis giving clue as to importance of GADAG root selection came while= I was updating drafts and may not have gone through them sufficiently.
=A0
Alia

=

Thanks!

Alvaro.

--089e0111d9b8a20ce204e87b18bf-- From arun.arumuganainar@tatacommunications.com Tue Oct 15 11:45:50 2013 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 343B311E81E0 for ; Tue, 15 Oct 2013 11:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 317m0AZ2fbEk for ; Tue, 15 Oct 2013 11:45:39 -0700 (PDT) Received: from vmx3.tatacommunications.com (vmx3.tatacommunications.com [66.198.167.208]) by ietfa.amsl.com (Postfix) with ESMTP id A2DE011E81A4 for ; Tue, 15 Oct 2013 11:45:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.93,501,1378872000"; d="scan'208,217";a="19320315" Received: from unknown (HELO wv1-cas-01.vsnl.co.in) ([64.86.157.137]) by mx3-2.tatacommunications.com with ESMTP; 15 Oct 2013 14:45:31 -0400 Received: from USWV1VCAS02.vsnl.co.in (64.86.157.180) by wv1-cas-01.vsnl.co.in (64.86.157.137) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 15 Oct 2013 14:45:31 -0400 Received: from USWV1VDAG02.vsnl.co.in ([fe80::7c6a:fd71:7022:40b6]) by uswv1vcas02.vsnl.co.in ([fe80::14e7:a24:f48:e268%12]) with mapi id 14.02.0342.003; Tue, 15 Oct 2013 14:45:31 -0400 From: Arun Arumuganainar To: "rtgwg@ietf.org" Subject: Requesting Comments about the Draft : draft-aumuganainar-rtgwg-dps-00 Thread-Topic: Requesting Comments about the Draft : draft-aumuganainar-rtgwg-dps-00 Thread-Index: Ac7DoFhRYvNsuNrSQcykr4ZRzrlhmQGNiFkA Date: Tue, 15 Oct 2013 18:45:30 +0000 Message-ID: <8E0F17CF07213C4882E85670E17849E170FB7BA0@uswv1vdag02.vsnl.co.in> References: <8E0F17CF07213C4882E85670E17849E170FAF9A4@uswv1vdag02.vsnl.co.in> In-Reply-To: <8E0F17CF07213C4882E85670E17849E170FAF9A4@uswv1vdag02.vsnl.co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.86.157.8] Content-Type: multipart/alternative; boundary="_000_8E0F17CF07213C4882E85670E17849E170FB7BA0uswv1vdag02vsnl_" 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, 15 Oct 2013 18:45:50 -0000 --_000_8E0F17CF07213C4882E85670E17849E170FB7BA0uswv1vdag02vsnl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, I have posted a following draft - Dynamic Path selection ( Based on Applica= tion ). http://www.ietf.org/internet-drafts/draft-aumuganainar-rtgwg-dps-00= .txt In the draft I have proposed a network design architecture for routing pack= ets via different paths available in the network based on application port = number. Primarily, this is targeted for Enterprise customers who have built= up redundancy at their WAN edge but are suffering from a congested primary= link whilst the secondary is idle. The objective of this architecture is as follows 1) Offload bulky application on to the secondary link 2) Achieve the above without introducing asymmetric routing in the netwo= rk It would be great if you can review this draft and respond back with any co= mments. Thanks very much. Thanks and Regards Arun Arun Arumuganainar CCIE#16918 ( R&S and SP ) Technical Design Authority Advanced Solution Delivery Tata Communications Limited Direct +44 207 029 9513 | Fax +44 207 519 4609 | Mobile +44 7771 831 = 052 | IP 709513 arun.arumuganainar@tatacommunications.com --_000_8E0F17CF07213C4882E85670E17849E170FB7BA0uswv1vdag02vsnl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello all,
 
&nbs= p;
In the draft I have proposed a network design architecture for routing= packets via different paths available in the network based on application = port number. Primarily, this is targeted for Enterprise customers who have = built up redundancy at their WAN edge but are suffering from a congested primary link whilst the secondary i= s idle.
 
The objective of this architecture is as follows
 
   1) Offload bulky application on to the secondary link&nbs= p;            &= nbsp; 
   2) Achieve the above without introducing asymmetric routi= ng in the network
 
It would be great if you can review this draft and respond back with a= ny comments.
 
Thanks very much.
 
Thanks and Regards
Arun
&nbs= p;
Ar= un Arumuganainar
C= CIE#16918 ( R&S and SP )   &nb= sp;
Te= chnical Design Authority
Advanced Solution Delivery
T= ata Communications Limited
Direct +44 207 029 9513   |  Fax +44 2= 07 519 4609   |  Mobile +44 7771 831 052 =   |  IP 709513
arun.arumuganainar@tatacommunications.com
&nbs= p;
&nbs= p;
&nbs= p;
 --_000_8E0F17CF07213C4882E85670E17849E170FB7BA0uswv1vdag02vsnl_-- From akatlas@gmail.com Thu Oct 17 07:28:13 2013 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 C7D5E11E8267 for ; Thu, 17 Oct 2013 07:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.237 X-Spam-Level: X-Spam-Status: No, score=-1.237 tagged_above=-999 required=5 tests=[AWL=-0.948, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_URGBIZ=0.725, URG_BIZ=1.585] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KaJuyh9UlyH for ; Thu, 17 Oct 2013 07:28:12 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id AC5C111E8263 for ; Thu, 17 Oct 2013 07:27:24 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id e14so3856497iej.25 for ; Thu, 17 Oct 2013 07:27:21 -0700 (PDT) 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 :content-type; bh=8kBJFa02+kfIa40rwuxXXnqYwKhb3OOhp5FgdVzaWgY=; b=lVQAqYqAkz+dS20R20s25//zxDRUQQAXiezNGXhDx5NHMRJYIaRKNrkr0n0LQzDsry NbJU8/qJbf3svzZL2yb8fzs/61zAZtrc5osDggHrth5jSSJoNix1PxyStRL75nd9ELEu W2pkj8AEfofc94hhRlVFD20VD1LzouyTrimynUOWUGgR4OvOnvDLLC5/5NDaTJQiLi8G 71cbe9JNR/lqxQ+FNice6JK673zpzFGI4ooUhT2P7lFkNkzccwz4SqxUWZjbrf8WPD2Z lORm528fiquDRNFVJdIfFv2zuRWiCCKa5x4rLm3DnglZWUcubAXzo4BMdmLe2cvF/EeB h0cg== MIME-Version: 1.0 X-Received: by 10.43.73.197 with SMTP id yt5mr5735165icb.0.1382020041127; Thu, 17 Oct 2013 07:27:21 -0700 (PDT) Received: by 10.64.78.72 with HTTP; Thu, 17 Oct 2013 07:27:21 -0700 (PDT) Received: by 10.64.78.72 with HTTP; Thu, 17 Oct 2013 07:27:21 -0700 (PDT) In-Reply-To: <20131017142434.21877.63746.idtracker@ietfa.amsl.com> References: <20131017142434.21877.63746.idtracker@ietfa.amsl.com> Date: Thu, 17 Oct 2013 10:27:21 -0400 Message-ID: Subject: Fwd: NOMCOM - Critical shortage of nominees for multiple areas From: Alia Atlas To: rtgwg@ietf.org Content-Type: multipart/alternative; boundary=001a11c2190a9fc34304e8f09d13 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, 17 Oct 2013 14:28:13 -0000 --001a11c2190a9fc34304e8f09d13 Content-Type: text/plain; charset=ISO-8859-1 ---------- Forwarded message ---------- From: "NomCom Chair 2013" Date: Oct 17, 2013 10:25 AM Subject: NOMCOM - Critical shortage of nominees for multiple areas To: "IETF Announcement List" Cc: "IETF Discuss" [Catchier Subject line - apologies to those offended by a duplicate] A critically low number of people have accepted nominations for some of the IESG open positions. There is only one nominee per slot in APP, OPS and TSV, only two in INT and RAI. Many folks have declined nominations. While the Nomcom appreciates that support for two years of intense service is hard to assure, and while we are aware that there is much support for the incumbents who are standing, the IETF should continually be considering which new talent is available for our leadership, and the Nomcom process needs for there to be some review and deliberation. Therefore, we urgently request that more nominees come forward. DEADLINES Nominations - October 18 Questionnaires from nominees - October 25 Not coincidentally, this is a good time to think over and send your comments about the current statements of desired expertise of positions - this is part of the Nomcom's annual review process as well. Send them to nomcom13@ietf.org. Definitive location [*] of the current statements on desired expertise: https://datatracker.ietf.org/nomcom/2013/expertise/ Instructions and details on nomination [**]: https://datatracker.ietf.org/ann/nomcom/60602/ Thanks, everyone, Allison for the Nomcom [*] This year the Nomcom tools were recoded, and also transitioned into the datatracker. Apologies for a number of places where we didn't catch reference errors. [**] Yes, alas, the previous call for nominations used "OAM" instead of "OPS," but we have* corrected this (chair's pilot) error where it occurred in the Nomcom pages. --001a11c2190a9fc34304e8f09d13 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
---------- Forwarded message ----------
From:= "NomCom Chair 2013" <nomcom-chair-2013@ietf.org>
Date: Oct 17, 2013 10:25 AM
= Subject: NOMCOM - Critical shortage of nominees for multiple areas
To: "IETF Announcement List" <ietf-announce@ietf.org>
Cc: "IETF Discuss" &l= t;ietf@ietf.org>

[Catchier Subject line - apologies to those offended by a duplicate]

A critically low number of people have accepted nominations for some of the=
IESG open positions. =A0There is only one nominee per slot in APP, OPS and = TSV,
only two in INT and RAI. =A0Many folks have declined nominations.

While the Nomcom appreciates that support for two years of intense service<= br> is hard to assure, and while we are aware that there is much support for th= e
incumbents who are standing, the IETF should continually be considering
which new talent is available for our leadership, and the Nomcom process needs for there to be some review and deliberation.

Therefore, we urgently request that more nominees come forward.

DEADLINES
Nominations - October 18
Questionnaires from nominees - October 25

Not coincidentally, this is a good time to think over and send your comment= s
about the current statements of desired expertise of positions - this is pa= rt of
the Nomcom's annual review process as well. =A0Send them to nomcom13@ietf.org.

Definitive location [*] of the current statements on desired expertise:
=A0 =A0 =A0 https://datatracker.ietf.org/nomcom/2013/expertise/<= br>
Instructions and details on nomination [**]:
=A0 =A0 =A0 https://datatracker.ietf.org/ann/nomcom/60602/

Thanks, everyone,

Allison for the Nomcom

[*] This year the Nomcom tools were recoded, and also transitioned into the=
datatracker. =A0Apologies for a number of places where we didn't catch = reference
errors.

[**] Yes, alas, the previous call for nominations used "OAM" inst= ead of "OPS," but
we have* corrected this (chair's pilot) error where it occurred in the = Nomcom
pages.
--001a11c2190a9fc34304e8f09d13-- From arun.arumuganainar@tatacommunications.com Fri Oct 18 13:52:08 2013 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 052EC21F9E45 for ; Fri, 18 Oct 2013 13:52:08 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8IOEQMSmaGJ for ; Fri, 18 Oct 2013 13:52:02 -0700 (PDT) Received: from vmx3.tatacommunications.com (vmx3.tatacommunications.com [66.198.167.208]) by ietfa.amsl.com (Postfix) with ESMTP id 63A5D11E80E3 for ; Fri, 18 Oct 2013 13:52:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.93,525,1378872000"; d="scan'208";a="19765666" Received: from unknown (HELO wv1-cas-02.vsnl.co.in) ([64.86.157.138]) by mx3-2.tatacommunications.com with ESMTP; 18 Oct 2013 16:51:57 -0400 Received: from USWV1VCAS01.vsnl.co.in (64.86.157.177) by wv1-cas-02.vsnl.co.in (64.86.157.138) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 18 Oct 2013 16:51:57 -0400 Received: from USWV1VDAG02.vsnl.co.in ([fe80::7c6a:fd71:7022:40b6]) by uswv1vcas01.vsnl.co.in ([fe80::6521:bbe2:f2e4:7b9b%11]) with mapi id 14.02.0342.003; Fri, 18 Oct 2013 16:51:57 -0400 From: Arun Arumuganainar To: Anton Smirnov Subject: RE: Requesting Comments about the Draft : draft-aumuganainar-rtgwg-dps-00 Thread-Topic: Requesting Comments about the Draft : draft-aumuganainar-rtgwg-dps-00 Thread-Index: Ac7DoFhRYvNsuNrSQcykr4ZRzrlhmQGNiFkAAJqQD4AAB7o9YA== Date: Fri, 18 Oct 2013 20:51:56 +0000 Message-ID: <8E0F17CF07213C4882E85670E17849E170FBD0AE@uswv1vdag02.vsnl.co.in> References: <8E0F17CF07213C4882E85670E17849E170FAF9A4@uswv1vdag02.vsnl.co.in> <8E0F17CF07213C4882E85670E17849E170FB7BA0@uswv1vdag02.vsnl.co.in> <526161E1.2070206@cisco.com> In-Reply-To: <526161E1.2070206@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.86.157.8] Content-Type: text/plain; charset="iso-8859-1" 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: Fri, 18 Oct 2013 20:52:08 -0000 Hi Anton, Thanks very much for reviewing my draft. I am not an expert in MTR . But from what I read about MTR, I understand th= is an routing enhancement. Here all the routers in network should understan= d MTR( Pls correct me if I am wrong). MTR type of implementation makes sen= se in large campus environment where in all the network devices and links a= re under single administrative control. However, I will not be able to ext= end my MTR topology on to my WAN. For example consider the following scenar= io. I am large enterprise customer . My network spread across 100+ location in = 3 continents. I need to set up a global wan network.=20 Now I decide go for MPLS provider. In most cases I will not be able to get = a single MPLS provider to service all locations. I will be going for multip= le MPLS providers to optimize my cost. And where MPLS reach is not there, I= would also be forced to go for an internet circuit and built IPSEC VPN. N= ow I will end up having to manage larger network which is a mix of MPLS and= Internet-IPSEC VPN. In the this scenario, I do not have option of doing M= TR . My MPLS network providers simply won't agree to run MTR . Hence I do not think MTR is practical on large scale diverse wan environmen= ts. Under DPS I am simply suggesting to build a DMVPN overlay. I will not have = any problem building such an overlay network on any type of WAN network. Ad= ditionally DPS is not at all about routing across two topologies based on I= P precedence or DSCP. It attempts to achieve following objectives . 1) When two sites communicates, DPS provides a mechanism for participating = sites exchange signaling information regarding the application that they wa= nted to send over DPS routing domain 2) Once information is exchanged , it separates the traffic meant to be rou= ted over DPS domain ( only non-critical application going to DPS capable si= tes pushed to DPS domain ) =09 Once it is pushed on to DPS domain, routing happens over the pre-built over= lay network. It should be noted that , in DPS , traffic does not comes marked. Instead t= raffic is marked once it hits the router( based on DPS profile of site to w= hich destination IP belongs to ). Again the marking that is done by the rou= ter is locally significant . Once the decision is taken and traffic pushed = in to DPS routing domain( or normal routing domain), the marking are never = looked at. In fact We can remark the traffic once the decision is taken wit= hout any issues. To summarize, objective of Multi-topology Routing and DPS are different an= d it resolves different problems.=20 Pls. mail me back in case you have any clarification. Thanks and Regards Arun Arun Arumuganainar CCIE#16918 ( R&S and SP ) =20 Technical Design Authority=20 Advanced Solution Delivery Tata Communications Limited Direct +44 207 029 9513=A0=A0=A0|=A0=A0Fax +44 207 519 4609=A0=A0=A0|=A0=A0= Mobile +44 7771 831 052=A0=A0=A0|=A0=A0IP 709513 arun.arumuganainar@tatacommunications.com -----Original Message----- From: Anton Smirnov [mailto:asmirnov@cisco.com]=20 Sent: 18 October 2013 17:29 To: Arun Arumuganainar Subject: Re: Requesting Comments about the Draft : draft-aumuganainar-rtgwg= -dps-00 Hi Arun, how is this different from MTR (multitopology routing)? I mean I see th= e difference in how it is implemented but it looks like if MTR was properly= and widely supported then one could do all that DPS does. Anton On 10/15/2013 08:45 PM, Arun Arumuganainar wrote: > Hello all, > I have posted a following draft - Dynamic Path selection ( Based on=20 > Application=20 > )._http://www.ietf.org/internet-drafts/draft-aumuganainar-rtgwg-dps-00 > .txt_ In the draft I have proposed a network design architecture for=20 > routing packets via different paths available in the network based on=20 > application port number. Primarily, this is targeted for Enterprise=20 > customers who have built up redundancy at their WAN edge but are=20 > suffering from a congested primary link whilst the secondary is idle. > The objective of this architecture is as follows > 1) Offload bulky application on to the secondary link > 2) Achieve the above without introducing asymmetric routing in the=20 > network It would be great if you can review this draft and respond=20 > back with any comments. > Thanks very much. > Thanks and Regards > Arun > *Arun Arumuganainar* > *CCIE#16918 ( R&S and SP )* > Technical Design Authority > Advanced Solution Delivery > > *Tata Communications Limited > *Direct +44 207 029 9513 | Fax +44 207 519 4609 | Mobile +44 7771 > 831 052 | IP 709513 > _arun.arumuganainar@tatacommunications.com_ > > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > From yangang@huawei.com Sun Oct 20 18:49:47 2013 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 CC91011E8314 for ; Sun, 20 Oct 2013 18:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.489 X-Spam-Level: X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[AWL=1.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paUiEVzOgyFL for ; Sun, 20 Oct 2013 18:49:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4672011E80EE for ; Sun, 20 Oct 2013 18:49:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZG78206; Mon, 21 Oct 2013 01:49:42 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 21 Oct 2013 02:48:44 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 21 Oct 2013 02:49:39 +0100 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.136]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0146.000; Mon, 21 Oct 2013 09:49:27 +0800 From: Yangang To: "rtgwg@ietf.org" Subject: Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00 Thread-Topic: Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00 Thread-Index: AQHOzf/GzJU1wXMyskyzrVWgwEKZ4Q== Date: Mon, 21 Oct 2013 01:49:26 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.72.210] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Zhangxudong \(zhangxudong, VRP\)" , Yangang 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, 21 Oct 2013 01:49:47 -0000 SGk6DQoNCldlIGhhZCBzdWJtaXR0ZWQgdGhlIGEgbmV3IGRyYWZ0OiBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0wMCwg d2Ugd2FudCB0byBkaXNjdXNzIHRoZSBtaWNyby1sb29wIHByb2JsZW0gdGhyb3VnaCBhbm90aGVy IG1ldGhvZC4gWW91ciBmZWVkYmFjayBhbmQgY29tbWVudHMgb24gdGhlIHJ0Z3dnIG1haWxpbmcg bGlzdCBhcmUgYXBwcmVjaWF0ZWQuIA0KDQpUaGFua3MsDQpSYWh1bC5ZYW4NCg0KLS0tLS3pgq7k u7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0K5Y+R6YCB5pe26Ze0OiAyMDEz5bm0MTDmnIgx OOaXpSAxNTo0Nw0K5pS25Lu25Lq6OiBaaGFuZ3h1ZG9uZyAoemhhbmd4dWRvbmcsIFZSUCk7IFlh bmdhbmcNCuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC16eGQtcnRn d2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQtenhkLXJ0Z3dnLW9yZGVyZWQtbWV0cmljLWFkanVzdG1lbnQtMDAudHh0DQpo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFh1ZG9uZyBaaGFuZyBhbmQgcG9zdGVk IHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LXp4ZC1ydGd3Zy1v cmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50DQpSZXZpc2lvbjoJIDAwDQpUaXRsZToJCSBBbGdvcml0 aG0gZm9yIE9yZGVyZWQgTWV0cmljIEFkanVzdG1lbnQNCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTEw LTE4DQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTAN ClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtenhkLXJ0Z3dnLW9yZGVyZWQtbWV0cmljLWFkanVzdG1lbnQtMDAudHh0DQpTdGF0dXM6ICAg ICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtenhkLXJ0Z3dnLW9y ZGVyZWQtbWV0cmljLWFkanVzdG1lbnQNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtenhkLXJ0Z3dnLW9yZGVyZWQtbWV0cmljLWFkanVzdG1lbnQtMDAN Cg0KDQpBYnN0cmFjdDoNCiAgIFVwb24gbGluayBkb3duIGV2ZW50IG9yIGxpbmsgdXAgZXZlbnQs IGVhY2ggZGV2aWNlIGluIG5ldHdvcmsNCiAgIGluZGl2aWR1YWxseSBzY2hlZHVsZXMgcm91dGUg Y2FsY3VsYXRpb24uICBCZWNhdXNlIG9mIGRpZmZlcmVudA0KICAgaGFyZHdhcmUgY2FwYWJpbGl0 aWVzIGFuZCBpbnRlcm5hbC9leHRlcm5hbCBlbnZpcm9ubWVudHMsIHRoZSB0aW1lIHRvDQogICB1 cGRhdGUgZm9yd2FyZGluZyBlbnRyaWVzIG9uIHRoZXNlIGRldmljZXMgYXJlIGRpc29yZGVyZWQg d2hpY2ggY2FuDQogICBjYXVzZSBhIHRyYW5zaWVudCBmb3J3YXJkaW5nIGxvb3AuICBUaGlzIGRv Y3VtZW50IGludHJvZHVjZXMgYSBtZXRob2QNCiAgIHRvIHByZXZlbnQgZm9yd2FyZGluZyBsb29w IGJ5IGFkanVzdGluZyBsaW5rIG1ldHJpYyBncmFkdWFsbHkgZm9yDQogICBzZXZlcmFsIHRpbWVz Lg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9u DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv b2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From acee.lindem@ericsson.com Sun Oct 20 19:07:07 2013 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 D8F1611E8357 for ; Sun, 20 Oct 2013 19:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJv+fXXtlrrY for ; Sun, 20 Oct 2013 19:06:55 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 0688611E8312 for ; Sun, 20 Oct 2013 19:06:53 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-3a-52648c286a6a Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 58.FB.03458.82C84625; Mon, 21 Oct 2013 04:06:33 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Sun, 20 Oct 2013 22:06:32 -0400 From: Acee Lindem To: Yangang Subject: Re: Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00 Thread-Topic: Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00 Thread-Index: AQHOzf/GzJU1wXMyskyzrVWgwEKZ4Zn+q2CA Date: Mon, 21 Oct 2013 02:06:32 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470309F337@eusaamb101.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="utf-8" Content-ID: <9B80CCA09391AE46B71087D649979D0D@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyuXRPlK5mT0qQwazzAhYX3vxmtuh5coXZ 4s23G2wOzB4tR96yeixZ8pMpgCmKyyYlNSezLLVI3y6BK+Pc270sBWskKvbe+8TcwHhHvIuR k0NCwETiSdtKVghbTOLCvfVsXYxcHEICRxklemc9hnKWM0psenmKDaSKTUBH4vmjf8wgtoiA gkTD/X4WEJtZIEli8Y42dhBbGMieO7GNFaImWaLp+GOoeiOJRRsbwGpYBFQlWiceA4vzCvhK LD+xCGyOkECoxOTmp2C9nAJhEpvWfwGLMwJd9/3UGiaIXeISt57MZ4K4WkBiyZ7zzBC2qMTL x/+gvlGWWPJkP1AvB1C9psT6XfoQrdYSi/Z2sULYihJTuh+yQ5wgKHFy5hOWCYzis5BsmIXQ PQtJ9ywk3bOQdC9gZF3FyFFanFqWm25kuIkRGF3HJNgcdzAu+GR5iFGag0VJnPfLW+cgIYH0 xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYyCD6rfmj/MtbdW/1S/8srWXwpffZ65te2ZsnbqNe86 B9GSJ9vib/1rPiqp73H+uK5h0Pt/n64nKhp7c3Z97G49eebdvumJNyPWr5QO8nYMeLk+9oG5 /jwNzohHuyJDXiS9cK5dL7b2V46JG9fLCcFb/j733V65MkDm5spFH0qOnN1pNO+P2sxGJZbi jERDLeai4kQAZPpEInwCAAA= Cc: "Zhangxudong \(zhangxudong, VRP\)" , "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, 21 Oct 2013 02:07:10 -0000 Q2FuIHlvdSBjb250cmFzdCB0aGlzIHdpdGggUkZDIDY5NzY/IFlvdSBpbmNsdWRlIFJGQyA2OTc2 IGluIHRoZSBOb3JtYXRpdmUgUmVmZXJlbmNlcyBidXQgaXQgaXMgbmV2ZXIgcmVmZXJlbmNlZCAo dGhpcyB3aWxsIHNob3cgdXAgaWYgeW91IHJ1biBpZG5pdHMpLiANCkFjZWUgDQpPbiBPY3QgMjAs IDIwMTMsIGF0IDk6NDkgUE0sIFlhbmdhbmcgd3JvdGU6DQoNCj4gSGk6DQo+IA0KPiBXZSBoYWQg c3VibWl0dGVkIHRoZSBhIG5ldyBkcmFmdDogaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtenhkLXJ0Z3dnLW9yZGVyZWQtbWV0cmljLWFkanVzdG1lbnQtMDAsIHdlIHdhbnQgdG8gZGlz Y3VzcyB0aGUgbWljcm8tbG9vcCBwcm9ibGVtIHRocm91Z2ggYW5vdGhlciBtZXRob2QuIFlvdXIg ZmVlZGJhY2sgYW5kIGNvbW1lbnRzIG9uIHRoZSBydGd3ZyBtYWlsaW5nIGxpc3QgYXJlIGFwcHJl Y2lhdGVkLiANCj4gDQo+IFRoYW5rcywNCj4gUmFodWwuWWFuDQo+IA0KPiAtLS0tLemCruS7tuWO n+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCj4g5Y+R6YCB5pe26Ze0OiAyMDEz5bm0MTDmnIgx OOaXpSAxNTo0Nw0KPiDmlLbku7bkuro6IFpoYW5neHVkb25nICh6aGFuZ3h1ZG9uZywgVlJQKTsg WWFuZ2FuZw0KPiDkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtenhk LXJ0Z3dnLW9yZGVyZWQtbWV0cmljLWFkanVzdG1lbnQtMDAudHh0DQo+IA0KPiANCj4gQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXp4ZC1ydGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50 LTAwLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFh1ZG9uZyBaaGFu ZyBhbmQgcG9zdGVkIHRvIHRoZQ0KPiBJRVRGIHJlcG9zaXRvcnkuDQo+IA0KPiBGaWxlbmFtZToJ IGRyYWZ0LXp4ZC1ydGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50DQo+IFJldmlzaW9uOgkg MDANCj4gVGl0bGU6CQkgQWxnb3JpdGhtIGZvciBPcmRlcmVkIE1ldHJpYyBBZGp1c3RtZW50DQo+ IENyZWF0aW9uIGRhdGU6CSAyMDEzLTEwLTE4DQo+IEdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlz c2lvbg0KPiBOdW1iZXIgb2YgcGFnZXM6IDEwDQo+IFVSTDogICAgICAgICAgICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtenhkLXJ0Z3dnLW9yZGVyZWQtbWV0cmlj LWFkanVzdG1lbnQtMDAudHh0DQo+IFN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudA0K PiBIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXp4ZC1y dGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50LTAwDQo+IA0KPiANCj4gQWJzdHJhY3Q6DQo+ ICAgVXBvbiBsaW5rIGRvd24gZXZlbnQgb3IgbGluayB1cCBldmVudCwgZWFjaCBkZXZpY2UgaW4g bmV0d29yaw0KPiAgIGluZGl2aWR1YWxseSBzY2hlZHVsZXMgcm91dGUgY2FsY3VsYXRpb24uICBC ZWNhdXNlIG9mIGRpZmZlcmVudA0KPiAgIGhhcmR3YXJlIGNhcGFiaWxpdGllcyBhbmQgaW50ZXJu YWwvZXh0ZXJuYWwgZW52aXJvbm1lbnRzLCB0aGUgdGltZSB0bw0KPiAgIHVwZGF0ZSBmb3J3YXJk aW5nIGVudHJpZXMgb24gdGhlc2UgZGV2aWNlcyBhcmUgZGlzb3JkZXJlZCB3aGljaCBjYW4NCj4g ICBjYXVzZSBhIHRyYW5zaWVudCBmb3J3YXJkaW5nIGxvb3AuICBUaGlzIGRvY3VtZW50IGludHJv ZHVjZXMgYSBtZXRob2QNCj4gICB0byBwcmV2ZW50IGZvcndhcmRpbmcgbG9vcCBieSBhZGp1c3Rp bmcgbGluayBtZXRyaWMgZ3JhZHVhbGx5IGZvcg0KPiAgIHNldmVyYWwgdGltZXMuDQo+IA0KPiAN Cj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4g VGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IHJ0Z3dnIG1haWxpbmcgbGlzdA0KPiBydGd3Z0BpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Z3dnDQoNCg== From akatlas@gmail.com Sun Oct 20 19:27:48 2013 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 BBE3A11E845E for ; Sun, 20 Oct 2013 19:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[AWL=-1.140, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUGw43jCpyne for ; Sun, 20 Oct 2013 19:27:48 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id BD0E411E845C for ; Sun, 20 Oct 2013 19:27:45 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id ar20so10715961iec.12 for ; Sun, 20 Oct 2013 19:27:45 -0700 (PDT) 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=UWNgYJtS2x+SJ76AtOiqIwL3AatjwBJai7Bl77x7QF0=; b=bNG5ordBn+83KOnZxg12qxKGfVO/SM3ivCW8/e7u9v5LnWmeQ9D0CoIzrl56c0Qn1I RWhOeukr4rbIV7iKsgV2vn0u7BVqREWwZzC+/TJANhzIOzhZpfIPFBGeNPzeS5abU7e7 am5NZmXv1XNjkfxNU0sQIBSLd9xt/2l5YNMHNIAAJ7JD6QiuM8AUnvGZQqTFbuGWydTz 3kvscLjY5/jykBW9zbgfIq5y88drEW/kROEikpPT6tJh0h4i85vZPm3FBIXiX3y4idDq D9nyYSQbpHuYy8O65r5dgwguyqWUn/C9iUBsF5BmPtjqrQ8vIhvY3ExDSrgPurjinq52 /GWg== MIME-Version: 1.0 X-Received: by 10.50.106.20 with SMTP id gq20mr7786654igb.36.1382322465115; Sun, 20 Oct 2013 19:27:45 -0700 (PDT) Received: by 10.64.78.72 with HTTP; Sun, 20 Oct 2013 19:27:45 -0700 (PDT) In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE470309F337@eusaamb101.ericsson.se> References: <94A203EA12AECE4BA92D42DBFFE0AE470309F337@eusaamb101.ericsson.se> Date: Sun, 20 Oct 2013 22:27:45 -0400 Message-ID: Subject: Re: Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00 From: Alia Atlas To: Acee Lindem Content-Type: multipart/alternative; boundary=047d7bea34347f980204e9370722 Cc: "rtgwg@ietf.org" , "Zhangxudong \(zhangxudong, VRP\)" , Yangang 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, 21 Oct 2013 02:27:48 -0000 --047d7bea34347f980204e9370722 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Please also look at RFC 5710 and Sec 6.1 with the Incremental Cost Adjustment. It would be helpful to understand where your draft has changes and improvements. Alia On Sun, Oct 20, 2013 at 10:06 PM, Acee Lindem wro= te: > Can you contrast this with RFC 6976? You include RFC 6976 in the Normativ= e > References but it is never referenced (this will show up if you run idnit= s). > Acee > On Oct 20, 2013, at 9:49 PM, Yangang wrote: > > > Hi: > > > > We had submitted the a new draft: > http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustment-00, > we want to discuss the micro-loop problem through another method. Your > feedback and comments on the rtgwg mailing list are appreciated. > > > > Thanks, > > Rahul.Yan > > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: internet-drafts@ietf.org [mailto:internet-drafts@ie= tf.org] > > =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA10=D4=C218=C8=D5 15:47 > > =CA=D5=BC=FE=C8=CB: Zhangxudong (zhangxudong, VRP); Yangang > > =D6=F7=CC=E2: New Version Notification for > draft-zxd-rtgwg-ordered-metric-adjustment-00.txt > > > > > > A new version of I-D, draft-zxd-rtgwg-ordered-metric-adjustment-00.txt > > has been successfully submitted by Xudong Zhang and posted to the > > IETF repository. > > > > Filename: draft-zxd-rtgwg-ordered-metric-adjustment > > Revision: 00 > > Title: Algorithm for Ordered Metric Adjustment > > Creation date: 2013-10-18 > > Group: Individual Submission > > Number of pages: 10 > > URL: > http://www.ietf.org/internet-drafts/draft-zxd-rtgwg-ordered-metric-adjust= ment-00.txt > > Status: > http://datatracker.ietf.org/doc/draft-zxd-rtgwg-ordered-metric-adjustment > > Htmlized: > http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustment-00 > > > > > > Abstract: > > Upon link down event or link up event, each device in network > > individually schedules route calculation. Because of different > > hardware capabilities and internal/external environments, the time to > > update forwarding entries on these devices are disordered which can > > cause a transient forwarding loop. This document introduces a method > > to prevent forwarding loop by adjusting link metric gradually for > > several times. > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > --047d7bea34347f980204e9370722 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Please also look at RFC 5710 and Sec 6.1 with the Incremen= tal Cost Adjustment.
It would be helpful to understand where your draft= has changes and improvements.

Alia


On Sun, Oct 20, 2013 at 10:06 PM, Acee L= indem <acee.lindem@ericsson.com> wrote:
Can you contrast this with RFC 6976? You include RFC 6976 in the Normative = References but it is never referenced (this will show up if you run idnits)= .
Acee
On Oct 20, 2013, at 9= :49 PM, Yangang wrote:

> Hi:
>
> We had submitted the a new draft: http://to= ols.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustment-00, we want= to discuss the micro-loop problem through another method. Your feedback an= d comments on the rtgwg mailing list are appreciated.
>
> Thanks,
> Rahul.Yan
>
> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=CB: intern= et-drafts@ietf.org [mailto:= internet-drafts@ietf.org]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA10=D4=C218=C8=D5 15:47
> =CA=D5=BC=FE=C8=CB: Zhangxudong (zhangxudong, VRP); Yangang
> =D6=F7=CC=E2: New Version Notification for draft-zxd-rtgwg-ordered-met= ric-adjustment-00.txt
>
>
> A new version of I-D, draft-zxd-rtgwg-ordered-metric-adjustment-00.txt=
> has been successfully submitted by Xudong Zhang and posted to the
> IETF repository.
>
> Filename:      draft-zxd-rtgwg-ordered-metric-adjustmen= t
> Revision:      00
> Title:                 Algorit= hm for Ordered Metric Adjustment
> Creation date:         2013-10-18
> Group:                 Individ= ual Submission
> Number of pages: 10
> URL:             http://www.ietf.org/internet-drafts/draft-zxd-rtgwg-ordere= d-metric-adjustment-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-zxd-rtgwg-ordered-metric-adjustment<= /a>
> Htmlized:        http:/= /tools.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustment-00
>
>
> Abstract:
>   Upon link down event or link up event, each device in network >   individually schedules route calculation.  Because of diff= erent
>   hardware capabilities and internal/external environments, the t= ime to
>   update forwarding entries on these devices are disordered which= can
>   cause a transient forwarding loop.  This document introduc= es a method
>   to prevent forwarding loop by adjusting link metric gradually f= or
>   several times.
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg

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

--047d7bea34347f980204e9370722-- From lizhenbin@huawei.com Mon Oct 21 08:23:40 2013 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 D1A4F11E8586 for ; Mon, 21 Oct 2013 08:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=4.609, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8nadDNuWYBQ for ; Mon, 21 Oct 2013 08:23:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D3E7211E85B4 for ; Mon, 21 Oct 2013 08:23:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXA47984; Mon, 21 Oct 2013 15:23:26 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 21 Oct 2013 16:21:58 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 21 Oct 2013 16:22:54 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.141]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0146.000; Mon, 21 Oct 2013 23:22:42 +0800 From: Lizhenbin To: "rtgwg@ietf.org" Subject: [RTGWG] Soliciting WG feedback and comments on draft-li-rtgwg-cc-igp-arch-00.txt Thread-Topic: [RTGWG] Soliciting WG feedback and comments on draft-li-rtgwg-cc-igp-arch-00.txt Thread-Index: AQHOznFiF+74ijBxnUWEkbziX5GFfQ== Date: Mon, 21 Oct 2013 15:22:41 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D081C7E70@nkgeml506-mbx.china.huawei.com> References: <20131021022049.22740.1931.idtracker@ietfa.amsl.com> In-Reply-To: <20131021022049.22740.1931.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.77] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Yangang 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, 21 Oct 2013 15:23:41 -0000 SGkgYWxsLA0KDQpXZSBoYWQgc3VibWl0dGVkIGEgbmV3IGRyYWZ0OiBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC8gZHJhZnQtbGktcnRnd2ctY2MtaWdwLWFyY2gtMDAsIFlvdXIgZmVlZGJhY2sg YW5kIGNvbW1lbnRzIG9uIHRoZSBSVEdXRyBtYWlsaW5nIGxpc3QgYXJlIGFwcHJlY2lhdGVkLiBQ bGVhc2UgcmVmZXIgdG8gZm9sbG93aW5nIGludHJvZHVjdGlvbiBvbiB0aGUgZHJhZnQ6DQoNCiAg IEFzIHRoZSBTb2Z0d2FyZSBEZWZpbmVkIE5ldHdvcmtzIChTRE4pIHNvbHV0aW9uIGRldmVsb3Bz LCBJR1Agd2lsbCBiZQ0KICAgZXh0ZW5kZWQgdG8gc3VwcG9ydCBjZW50cmFsIGNvbnRyb2wuICBU aGlzIGRvY3VtZW50IGludHJvZHVjZXMgYW4NCiAgIGFyY2hpdGVjdHVyZSBvZiB1c2luZyBJR1Ag Zm9yIGNlbnRyYWwgY29udHJvbGxpbmcuIA0KDQogICBDZW50cmFsIENvbnRyb2wgQXJjaGl0ZWN0 dXJlIHByb3Bvc2UgZm9sbG93aW5nIHJlcXVpcmVtZW50cyByZWxhdGVkIHdpdGggSUdQOg0KICAg MS4gIEJ1aWxkIHRoZSBjZW50cmFsIGNvbnRyb2wgYXJjaGl0ZWN0dXJlIGJldHdlZW4gdGhlIGNv bnRyb2xsZXIgYW5kDQogICB0aGUgY2xpZW50LiAgSXQgaW5jbHVkZXMgYnVpbGRpbmcgY29ubmVj dGl2aXR5LCBjb2xsZWN0aW5nIHRoZQ0KICAgdG9wb2xvZ3ksIGFuZCBkaXZpZGluZyBtdWx0aXBs ZSBhcmVhcyBhdXRvbWF0aWNhbGx5LCBldGMuDQoNCiAgIDIuICBNYW55IG5ldyBhcHBsaWNhdGlv bnMgYXJlIGVtZXJnaW5nIHVuZGVyIHRoZSBjZW50cmFsIGNvbnRyb2xsZWQNCiAgIGZyYW1ld29y aywgc3VjaCBhcyBuZXR3b3JrIHZpcnR1YWxpemF0aW9uLCBjZW50cmFsaXplZCBNUExTIFRFDQog ICBjYWxjdWxhdGlvbiwgc2VnbWVudCByb3V0aW5nLCBldGMuICBUaGVzZSBuZXcgYXBwbGljYXRp b25zIGJyaW5nDQogICBleHRlbnNpb24gcmVxdWlyZW1lbnQgdG8gSUdQLg0KDQpXZSBjYW4gbG9v ayBvbiBbSS1ELmNoZW4tb3NwZi10dHpdLCBbSS1ELnlsei1vc3BmLWxzZGItc3luYy1ncm91cF0s IFtJLUQubGktb3NwZi1leHQtZ3JlZW4tdGVdLCBldGMuIGFzIHRoZSBjb25jcmV0ZSB1c2UgY2Fz ZXMgb2YgdGhlIGNlbnRyYWwgY29udHJvbGxlZCBJR1AuIFdlIGhvcGUgdGhlIGFyY2hpdGVjdHVy ZSBkcmFmdCB0byBoZWxwIHVuZGVyc3RhbmQgSUdQIHVzYWdlIGluIHRoZSBjZW50cmFsIGNvbnRy b2wgZ2xvYmFsbHkgYW5kIG5ldyByZXF1aXJlbWVudHMgYXJlIHByb3Bvc2VkIGZvciB0aGUgZnV0 dXJlIGRldmVsb3BtZW50Lg0KDQpJbiBhZGRpdGlvbiwgSSByZWNvbW1lbmQgeW91IGNvdWxkIHJl YWQgYW5vdGhlciBkcmFmdCAiIGRyYWZ0LWxpLWlkci1jYy1iZ3AtYXJjaC0wMCIgZm9yIGJldHRl ciB1bmRlcnN0YW5kaW5nIGRpZmZlcmVudCBwcm90b2NvbCB1c2FnZSBpbiB0aGUgY2VudHJhbCBj b250cm9sIGFyY2hpdGVjdHVyZSwNCg0KDQpUaGFua3MsDQpSb2Jpbg0KDQoNCg0KDQotLS0tLemC ruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQrlj5HpgIHml7bpl7Q6IDIwMTPlubQxMOac iDIx5pelIDEwOjIxDQrmlLbku7bkuro6IEh1YWltbyBDaGVuOyBMaXpoZW5iaW47IFlhbmdhbmcN CuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saS1ydGd3Zy1jYy1p Z3AtYXJjaC0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGktcnRnd2ct Y2MtaWdwLWFyY2gtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFpo ZW5iaW4gTGkgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6 CSBkcmFmdC1saS1ydGd3Zy1jYy1pZ3AtYXJjaA0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkgQW4g QXJjaGl0ZWN0dXJlIG9mIENlbnRyYWwgQ29udHJvbGxlZCBJbnRlcmlvciBHYXRld2F5IFByb3Rv Y29sIChJR1ApDQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0xMC0yMQ0KR3JvdXA6CQkgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDExDQpVUkw6ICAgICAgICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxpLXJ0Z3dnLWNjLWlncC1hcmNo LTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWxpLXJ0Z3dnLWNjLWlncC1hcmNoDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpLXJ0Z3dnLWNjLWlncC1hcmNoLTAwDQoNCg0KQWJzdHJh Y3Q6DQogICBBcyB0aGUgU29mdHdhcmUgRGVmaW5lZCBOZXR3b3JrcyAoU0ROKSBzb2x1dGlvbiBk ZXZlbG9wcywgSUdQIHdpbGwgYmUNCiAgIGV4dGVuZGVkIHRvIHN1cHBvcnQgY2VudHJhbCBjb250 cm9sLiAgVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIGFuDQogICBhcmNoaXRlY3R1cmUgb2YgdXNp bmcgSUdQIGZvciBjZW50cmFsIGNvbnRyb2xsaW5nLiAgU29tZSB1c2UgY2FzZXMNCiAgIHVuZGVy IHRoaXMgbmV3IGZyYW1ld29yayBhcmUgYWxzbyBkaXNjdXNzZWQuICBGb3Igc3BlY2lmaWMgdXNl IGNhc2VzLA0KICAgbWFraW5nIG5lY2Vzc2FyeSBleHRlbnNpb25zIGluIElHUCBhcmUgcmVxdWly ZWQuDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np b24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg dG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From yangang@huawei.com Mon Oct 21 18:30:42 2013 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 8AC6711E81A4 for ; Mon, 21 Oct 2013 18:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.003 X-Spam-Level: X-Spam-Status: No, score=-6.003 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRRgcVvqYNLh for ; Mon, 21 Oct 2013 18:30:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C364811E80E4 for ; Mon, 21 Oct 2013 18:30:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXA76330; Tue, 22 Oct 2013 01:30:35 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 22 Oct 2013 02:30:25 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 22 Oct 2013 02:30:33 +0100 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.136]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0146.000; Tue, 22 Oct 2013 09:30:24 +0800 From: Yangang To: Acee Lindem Subject: =?utf-8?B?562U5aSNOiBTb2xpY2l0aW5nIFdHIGZlZWRiYWNrIGFuZCBjb21tZW50cyBv?= =?utf-8?B?bglkcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0w?= =?utf-8?Q?0?= Thread-Topic: Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00 Thread-Index: AQHOzgIv4guyxEeFtUyQN+XoFoY3tZn/7JRw Date: Tue, 22 Oct 2013 01:30:23 +0000 Message-ID: References: <94A203EA12AECE4BA92D42DBFFE0AE470309F337@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE470309F337@eusaamb101.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.72.210] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Zhangxudong \(zhangxudong, VRP\)" , "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, 22 Oct 2013 01:30:42 -0000 T3VyIGRyYWZ0IGlzIHNpbWlsYXIgd2l0aCBzZWN0aW9uIDYuMSBpbiBSRkM1NzE1LCB0aGUgY29z dCBvZiBjaGFuZ2VkIGxpbmsgd2lsbCBiZSBhZGp1c3RlZCBhbmQgYWR2ZXJ0aXNlZCwgbWF5YmUg bW9yZSB0aGFuIG9uZSB0aW1lLCB0aGlzIHNlcXVlbmNlIHdpbGwgYmFzZSBvbiBzb21lIHByZS1j YWxjdWxhdGlvbnMuIEJ1dCBpbiBSRkMgNjk3NiwgZWFjaCBkZXZpY2Ugc2hvdWxkIGNhbGN1bGF0 ZSB0aGUgZGlzdGFuY2Ugd2l0aCB0aGUgZmFpbHVlIGxpbmssIGJhc2Ugb24gdGhpcyBkaXN0YW5j ZSwgZWFjaCBkZXZpY2UgZGVjaWRlIHdoZW4gdGhlIEZJQiB3aWxsIGJlIHVwZGF0ZWQuDQoNCi0t LS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogQWNlZSBMaW5kZW0gW21haWx0bzphY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb21dIA0K5Y+R6YCB5pe26Ze0OiAyMDEz5bm0MTDmnIgyMeaXpSAx MDowNw0K5pS25Lu25Lq6OiBZYW5nYW5nDQrmioTpgIE6IHJ0Z3dnQGlldGYub3JnOyBaaGFuZ3h1 ZG9uZyAoemhhbmd4dWRvbmcsIFZSUCkNCuS4u+mimDogUmU6IFNvbGljaXRpbmcgV0cgZmVlZGJh Y2sgYW5kIGNvbW1lbnRzIG9uIGRyYWZ0LXp4ZC1ydGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1c3Rt ZW50LTAwDQoNCkNhbiB5b3UgY29udHJhc3QgdGhpcyB3aXRoIFJGQyA2OTc2PyBZb3UgaW5jbHVk ZSBSRkMgNjk3NiBpbiB0aGUgTm9ybWF0aXZlIFJlZmVyZW5jZXMgYnV0IGl0IGlzIG5ldmVyIHJl ZmVyZW5jZWQgKHRoaXMgd2lsbCBzaG93IHVwIGlmIHlvdSBydW4gaWRuaXRzKS4gDQpBY2VlIA0K T24gT2N0IDIwLCAyMDEzLCBhdCA5OjQ5IFBNLCBZYW5nYW5nIHdyb3RlOg0KDQo+IEhpOg0KPiAN Cj4gV2UgaGFkIHN1Ym1pdHRlZCB0aGUgYSBuZXcgZHJhZnQ6IGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXp4ZC1ydGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50LTAwLCB3ZSB3 YW50IHRvIGRpc2N1c3MgdGhlIG1pY3JvLWxvb3AgcHJvYmxlbSB0aHJvdWdoIGFub3RoZXIgbWV0 aG9kLiBZb3VyIGZlZWRiYWNrIGFuZCBjb21tZW50cyBvbiB0aGUgcnRnd2cgbWFpbGluZyBsaXN0 IGFyZSBhcHByZWNpYXRlZC4gDQo+IA0KPiBUaGFua3MsDQo+IFJhaHVsLllhbg0KPiANCj4gLS0t LS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQo+IOWPkemAgeaXtumXtDogMjAx M+W5tDEw5pyIMTjml6UgMTU6NDcNCj4g5pS25Lu25Lq6OiBaaGFuZ3h1ZG9uZyAoemhhbmd4dWRv bmcsIFZSUCk7IFlhbmdhbmcNCj4g5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LXp4ZC1ydGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50LTAwLnR4dA0KPiANCj4g DQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMt YWRqdXN0bWVudC0wMC50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBY dWRvbmcgWmhhbmcgYW5kIHBvc3RlZCB0byB0aGUNCj4gSUVURiByZXBvc2l0b3J5Lg0KPiANCj4g RmlsZW5hbWU6CSBkcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudA0KPiBS ZXZpc2lvbjoJIDAwDQo+IFRpdGxlOgkJIEFsZ29yaXRobSBmb3IgT3JkZXJlZCBNZXRyaWMgQWRq dXN0bWVudA0KPiBDcmVhdGlvbiBkYXRlOgkgMjAxMy0xMC0xOA0KPiBHcm91cDoJCSBJbmRpdmlk dWFsIFN1Ym1pc3Npb24NCj4gTnVtYmVyIG9mIHBhZ2VzOiAxMA0KPiBVUkw6ICAgICAgICAgICAg IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXp4ZC1ydGd3Zy1vcmRl cmVkLW1ldHJpYy1hZGp1c3RtZW50LTAwLnR4dA0KPiBTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtenhkLXJ0Z3dnLW9yZGVyZWQtbWV0cmljLWFk anVzdG1lbnQNCj4gSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0wMA0KPiANCj4gDQo+IEFi c3RyYWN0Og0KPiAgIFVwb24gbGluayBkb3duIGV2ZW50IG9yIGxpbmsgdXAgZXZlbnQsIGVhY2gg ZGV2aWNlIGluIG5ldHdvcmsNCj4gICBpbmRpdmlkdWFsbHkgc2NoZWR1bGVzIHJvdXRlIGNhbGN1 bGF0aW9uLiAgQmVjYXVzZSBvZiBkaWZmZXJlbnQNCj4gICBoYXJkd2FyZSBjYXBhYmlsaXRpZXMg YW5kIGludGVybmFsL2V4dGVybmFsIGVudmlyb25tZW50cywgdGhlIHRpbWUgdG8NCj4gICB1cGRh dGUgZm9yd2FyZGluZyBlbnRyaWVzIG9uIHRoZXNlIGRldmljZXMgYXJlIGRpc29yZGVyZWQgd2hp Y2ggY2FuDQo+ICAgY2F1c2UgYSB0cmFuc2llbnQgZm9yd2FyZGluZyBsb29wLiAgVGhpcyBkb2N1 bWVudCBpbnRyb2R1Y2VzIGEgbWV0aG9kDQo+ICAgdG8gcHJldmVudCBmb3J3YXJkaW5nIGxvb3Ag YnkgYWRqdXN0aW5nIGxpbmsgbWV0cmljIGdyYWR1YWxseSBmb3INCj4gICBzZXZlcmFsIHRpbWVz Lg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y Zy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBydGd3ZyBtYWlsaW5nIGxpc3QNCj4gcnRn d2dAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGd3 Zw0KDQo= From acee.lindem@ericsson.com Mon Oct 21 18:41:56 2013 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 31F3F11E82E1 for ; Mon, 21 Oct 2013 18:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsXJ0816VKaJ for ; Mon, 21 Oct 2013 18:41:50 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id AEA3411E80F9 for ; Mon, 21 Oct 2013 18:41:50 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-5d-5265d7de3545 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 07.F9.03458.ED7D5625; Tue, 22 Oct 2013 03:41:50 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Mon, 21 Oct 2013 21:41:49 -0400 From: Acee Lindem To: Yangang Subject: =?utf-8?B?UmU6IOetlOWkjTogU29saWNpdGluZyBXRyBmZWVkYmFjayBhbmQgY29tbWVu?= =?utf-8?B?dHMgb24JZHJhZnQtenhkLXJ0Z3dnLW9yZGVyZWQtbWV0cmljLWFkanVzdG1l?= =?utf-8?Q?nt-00?= Thread-Topic: =?utf-8?B?562U5aSNOiBTb2xpY2l0aW5nIFdHIGZlZWRiYWNrIGFuZCBjb21tZW50cyBv?= =?utf-8?B?bglkcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0w?= =?utf-8?Q?0?= Thread-Index: AQHOzf/GzJU1wXMyskyzrVWgwEKZ4Zn+q2CAgAGIPICAAAMvgA== Date: Tue, 22 Oct 2013 01:41:49 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030A2579@eusaamb101.ericsson.se> References: <94A203EA12AECE4BA92D42DBFFE0AE470309F337@eusaamb101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyuXRPgu6966lBBqdmSltcePOb2aLnyRVm izffbrA5MHu0HHnL6rFkyU+mAKYoLpuU1JzMstQifbsErow500+yFpxTqljw9S97A+MdxS5G Tg4JAROJL5OOskHYYhIX7q0Hsrk4hASOMko83nWHBcJZzijReWsGC0gVm4COxPNH/5hBbBEB BYmG+/1gcWaBJInFO9rYQRqEBTYwSnRsuArmiAhsZJS4/n8uYxcjB5DjJLF9VzpIA4uAqsSa lx/AmnkFfCWmTTzJBLHtKVD9hwawDZwCYRK/17eBFTEC3ff91BomiG3iEreezGeCuFtAYsme 88wQtqjEy8f/WCFsZYklT/azgOxlFtCUWL9LH8K0lui7lAoxRVFiSvdDdogTBCVOznzCMoFR fBaSBbMQmmchNM9C0jwLSfMCRtZVjBylxalluelGhpsYgdF1TILNcQfjgk+WhxilOViUxHm/ vHUOEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cBozrB3auGu+lBxn+qXJVMEVJPuvtWYfWOD 9pVCFlfm9yqmzc3TJgm7rdHrWjmtjOdfTOP6ow+myvVu6+dKKu+XnH1syw3F18x3o8/fe5Tt 4LpF4WXW/ucva48z9STOZpdKVHw3n9/TPTn+YvpuSy7e5SfPynoxfXumLav661X7lGuJO3va ZhxQYinOSDTUYi4qTgQA3R4W+XwCAAA= Cc: "Zhangxudong \(zhangxudong, VRP\)" , "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, 22 Oct 2013 01:41:56 -0000 SSdtIGF3YXJlIG9mIHRoZSBiYXNpYyBwcmVtaXNlIG9mIHRoZSB0d28gZHJhZnRzIGFuZCB3YXMg bm90IGFza2luZyBmb3IgeW91IHRvIHJlc3RhdGUgdGhlIG9idmlvdXMuIFNwZWNpZmljYWxseSwg d2hhdCBhcmUgdGhlIGJlbmVmaXRzIGFuZCBkZXRlcm1lbnRzIG9mIHlvdXIgZHJhZnQgd2hlbiBj b21wYXJlZCB0byBSRkMgNjk3Nj8gDQpBY2VlDQoNCk9uIE9jdCAyMSwgMjAxMywgYXQgOTozMCBQ TSwgWWFuZ2FuZyB3cm90ZToNCg0KPiBPdXIgZHJhZnQgaXMgc2ltaWxhciB3aXRoIHNlY3Rpb24g Ni4xIGluIFJGQzU3MTUsIHRoZSBjb3N0IG9mIGNoYW5nZWQgbGluayB3aWxsIGJlIGFkanVzdGVk IGFuZCBhZHZlcnRpc2VkLCBtYXliZSBtb3JlIHRoYW4gb25lIHRpbWUsIHRoaXMgc2VxdWVuY2Ug d2lsbCBiYXNlIG9uIHNvbWUgcHJlLWNhbGN1bGF0aW9ucy4gQnV0IGluIFJGQyA2OTc2LCBlYWNo IGRldmljZSBzaG91bGQgY2FsY3VsYXRlIHRoZSBkaXN0YW5jZSB3aXRoIHRoZSBmYWlsdWUgbGlu aywgYmFzZSBvbiB0aGlzIGRpc3RhbmNlLCBlYWNoIGRldmljZSBkZWNpZGUgd2hlbiB0aGUgRklC IHdpbGwgYmUgdXBkYXRlZC4NCj4gDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu2 5Lq6OiBBY2VlIExpbmRlbSBbbWFpbHRvOmFjZWUubGluZGVtQGVyaWNzc29uLmNvbV0gDQo+IOWP kemAgeaXtumXtDogMjAxM+W5tDEw5pyIMjHml6UgMTA6MDcNCj4g5pS25Lu25Lq6OiBZYW5nYW5n DQo+IOaKhOmAgTogcnRnd2dAaWV0Zi5vcmc7IFpoYW5neHVkb25nICh6aGFuZ3h1ZG9uZywgVlJQ KQ0KPiDkuLvpopg6IFJlOiBTb2xpY2l0aW5nIFdHIGZlZWRiYWNrIGFuZCBjb21tZW50cyBvbiBk cmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0wMA0KPiANCj4gQ2FuIHlv dSBjb250cmFzdCB0aGlzIHdpdGggUkZDIDY5NzY/IFlvdSBpbmNsdWRlIFJGQyA2OTc2IGluIHRo ZSBOb3JtYXRpdmUgUmVmZXJlbmNlcyBidXQgaXQgaXMgbmV2ZXIgcmVmZXJlbmNlZCAodGhpcyB3 aWxsIHNob3cgdXAgaWYgeW91IHJ1biBpZG5pdHMpLiANCj4gQWNlZSANCj4gT24gT2N0IDIwLCAy MDEzLCBhdCA5OjQ5IFBNLCBZYW5nYW5nIHdyb3RlOg0KPiANCj4+IEhpOg0KPj4gDQo+PiBXZSBo YWQgc3VibWl0dGVkIHRoZSBhIG5ldyBkcmFmdDogaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtenhkLXJ0Z3dnLW9yZGVyZWQtbWV0cmljLWFkanVzdG1lbnQtMDAsIHdlIHdhbnQgdG8g ZGlzY3VzcyB0aGUgbWljcm8tbG9vcCBwcm9ibGVtIHRocm91Z2ggYW5vdGhlciBtZXRob2QuIFlv dXIgZmVlZGJhY2sgYW5kIGNvbW1lbnRzIG9uIHRoZSBydGd3ZyBtYWlsaW5nIGxpc3QgYXJlIGFw cHJlY2lhdGVkLiANCj4+IA0KPj4gVGhhbmtzLA0KPj4gUmFodWwuWWFuDQo+PiANCj4+IC0tLS0t 6YKu5Lu25Y6f5Lu2LS0tLS0NCj4+IOWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCj4+IOWPkemAgeaXtumXtDogMjAx M+W5tDEw5pyIMTjml6UgMTU6NDcNCj4+IOaUtuS7tuS6ujogWmhhbmd4dWRvbmcgKHpoYW5neHVk b25nLCBWUlApOyBZYW5nYW5nDQo+PiDkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtenhkLXJ0Z3dnLW9yZGVyZWQtbWV0cmljLWFkanVzdG1lbnQtMDAudHh0DQo+PiAN Cj4+IA0KPj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXp4ZC1ydGd3Zy1vcmRlcmVkLW1l dHJpYy1hZGp1c3RtZW50LTAwLnR4dA0KPj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBYdWRvbmcgWmhhbmcgYW5kIHBvc3RlZCB0byB0aGUNCj4+IElFVEYgcmVwb3NpdG9yeS4N Cj4+IA0KPj4gRmlsZW5hbWU6CSBkcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0 bWVudA0KPj4gUmV2aXNpb246CSAwMA0KPj4gVGl0bGU6CQkgQWxnb3JpdGhtIGZvciBPcmRlcmVk IE1ldHJpYyBBZGp1c3RtZW50DQo+PiBDcmVhdGlvbiBkYXRlOgkgMjAxMy0xMC0xOA0KPj4gR3Jv dXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+PiBOdW1iZXIgb2YgcGFnZXM6IDEwDQo+PiBV Ukw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LXp4ZC1ydGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50LTAwLnR4dA0KPj4gU3RhdHVzOiAg ICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXp4ZC1ydGd3Zy1v cmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50DQo+PiBIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXp4ZC1ydGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50 LTAwDQo+PiANCj4+IA0KPj4gQWJzdHJhY3Q6DQo+PiAgVXBvbiBsaW5rIGRvd24gZXZlbnQgb3Ig bGluayB1cCBldmVudCwgZWFjaCBkZXZpY2UgaW4gbmV0d29yaw0KPj4gIGluZGl2aWR1YWxseSBz Y2hlZHVsZXMgcm91dGUgY2FsY3VsYXRpb24uICBCZWNhdXNlIG9mIGRpZmZlcmVudA0KPj4gIGhh cmR3YXJlIGNhcGFiaWxpdGllcyBhbmQgaW50ZXJuYWwvZXh0ZXJuYWwgZW52aXJvbm1lbnRzLCB0 aGUgdGltZSB0bw0KPj4gIHVwZGF0ZSBmb3J3YXJkaW5nIGVudHJpZXMgb24gdGhlc2UgZGV2aWNl cyBhcmUgZGlzb3JkZXJlZCB3aGljaCBjYW4NCj4+ICBjYXVzZSBhIHRyYW5zaWVudCBmb3J3YXJk aW5nIGxvb3AuICBUaGlzIGRvY3VtZW50IGludHJvZHVjZXMgYSBtZXRob2QNCj4+ICB0byBwcmV2 ZW50IGZvcndhcmRpbmcgbG9vcCBieSBhZGp1c3RpbmcgbGluayBtZXRyaWMgZ3JhZHVhbGx5IGZv cg0KPj4gIHNldmVyYWwgdGltZXMuDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbg0KPj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4+IA0KPj4gVGhlIElFVEYgU2VjcmV0YXJp YXQNCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+IHJ0Z3dnIG1haWxpbmcgbGlzdA0KPj4gcnRnd2dAaWV0Zi5vcmcNCj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnd2cNCj4gDQoNCg== From yangang@huawei.com Mon Oct 21 20:40:19 2013 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 7875111E812F for ; Mon, 21 Oct 2013 20:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.039 X-Spam-Level: X-Spam-Status: No, score=-6.039 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sPc1I9hD0dW for ; Mon, 21 Oct 2013 20:40:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 714A911E830F for ; Mon, 21 Oct 2013 20:40:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXA84060; Tue, 22 Oct 2013 03:40:10 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 22 Oct 2013 04:40:00 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 22 Oct 2013 04:40:08 +0100 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.136]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0146.000; Tue, 22 Oct 2013 11:39:56 +0800 From: Yangang To: Acee Lindem Subject: =?utf-8?B?562U5aSNOiDnrZTlpI06IFNvbGljaXRpbmcgV0cgZmVlZGJhY2sgYW5kIGNv?= =?utf-8?B?bW1lbnRzIG9uCWRyYWZ0LXp4ZC1ydGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1?= =?utf-8?Q?stment-00?= Thread-Topic: =?utf-8?B?562U5aSNOiBTb2xpY2l0aW5nIFdHIGZlZWRiYWNrIGFuZCBjb21tZW50cyBv?= =?utf-8?B?bglkcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0w?= =?utf-8?Q?0?= Thread-Index: AQHOzgIv4guyxEeFtUyQN+XoFoY3tZn/7JRw//+BC4CAAJ9N0A== Date: Tue, 22 Oct 2013 03:39:55 +0000 Message-ID: References: <94A203EA12AECE4BA92D42DBFFE0AE470309F337@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47030A2579@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47030A2579@eusaamb101.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.72.210] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Zhangxudong \(zhangxudong, VRP\)" , "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, 22 Oct 2013 03:40:19 -0000 T0ssIEkgZ290IGl0Lg0KDQpBY3R1YWxseSwgd2UgcGF5IGF0dGVudGlvbiB0byB0d28gcG9pbnQ6 DQoNCjEuIFdoaWNoIG1ldGhvZCB3aWxsIGJlIG1vcmUgbmljZXR5PyBJbiBSRkM2OTc2LCBhbGwg ZGV2aWNlcyBpbiBuZXR3b3JrIG5lZWQgY2FsY3VsYXRlIHRoZSBzY2hlZHVsZSB0aW1lLCBiYXNl IG9uIHRoZSBkaWZmZXJlbnQgaGFyZHdhcmUgYW5kIGVudmlyb25tZW50LCB3ZSB3b3JyeSBhYm91 dCBpdHMgZWZmZWN0LiBJbiBvdXIgZHJhZnQsIG9ubHkgZmFpbHVyZSBwb2ludCBhZGp1c3QgdGhl IGNvc3QsIHRoZSBvdGhlciBkZXZpY2UganVzdCByZXNwb25zZSB0aGUgY29zdCBjaGFuZ2UuIEkg dGhpbmsgdGhlIGVmZmVjdCBvZiB0aGlzIGtpbmQgb2YgZGlmZmVyZW5jZSB3aWxsIGJlIGxlc3Mu DQoNCjIuIER1ZSB0byBubyBuZXcgZXh0ZW5zaW9uLCBtYXliZSB0aGUgZGlzdHJpYnV0aW9uIHdp bGwgYmUgbW9yZSBzbW9vdGhseS4NCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6 OiBBY2VlIExpbmRlbSBbbWFpbHRvOmFjZWUubGluZGVtQGVyaWNzc29uLmNvbV0gDQrlj5HpgIHm l7bpl7Q6IDIwMTPlubQxMOaciDIy5pelIDk6NDINCuaUtuS7tuS6ujogWWFuZ2FuZw0K5oqE6YCB OiBydGd3Z0BpZXRmLm9yZzsgWmhhbmd4dWRvbmcgKHpoYW5neHVkb25nLCBWUlApDQrkuLvpopg6 IFJlOiDnrZTlpI06IFNvbGljaXRpbmcgV0cgZmVlZGJhY2sgYW5kIGNvbW1lbnRzIG9uIGRyYWZ0 LXp4ZC1ydGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50LTAwDQoNCkknbSBhd2FyZSBvZiB0 aGUgYmFzaWMgcHJlbWlzZSBvZiB0aGUgdHdvIGRyYWZ0cyBhbmQgd2FzIG5vdCBhc2tpbmcgZm9y IHlvdSB0byByZXN0YXRlIHRoZSBvYnZpb3VzLiBTcGVjaWZpY2FsbHksIHdoYXQgYXJlIHRoZSBi ZW5lZml0cyBhbmQgZGV0ZXJtZW50cyBvZiB5b3VyIGRyYWZ0IHdoZW4gY29tcGFyZWQgdG8gUkZD IDY5NzY/IA0KQWNlZQ0KDQpPbiBPY3QgMjEsIDIwMTMsIGF0IDk6MzAgUE0sIFlhbmdhbmcgd3Jv dGU6DQoNCj4gT3VyIGRyYWZ0IGlzIHNpbWlsYXIgd2l0aCBzZWN0aW9uIDYuMSBpbiBSRkM1NzE1 LCB0aGUgY29zdCBvZiBjaGFuZ2VkIGxpbmsgd2lsbCBiZSBhZGp1c3RlZCBhbmQgYWR2ZXJ0aXNl ZCwgbWF5YmUgbW9yZSB0aGFuIG9uZSB0aW1lLCB0aGlzIHNlcXVlbmNlIHdpbGwgYmFzZSBvbiBz b21lIHByZS1jYWxjdWxhdGlvbnMuIEJ1dCBpbiBSRkMgNjk3NiwgZWFjaCBkZXZpY2Ugc2hvdWxk IGNhbGN1bGF0ZSB0aGUgZGlzdGFuY2Ugd2l0aCB0aGUgZmFpbHVlIGxpbmssIGJhc2Ugb24gdGhp cyBkaXN0YW5jZSwgZWFjaCBkZXZpY2UgZGVjaWRlIHdoZW4gdGhlIEZJQiB3aWxsIGJlIHVwZGF0 ZWQuDQo+IA0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogQWNlZSBMaW5k ZW0gW21haWx0bzphY2VlLmxpbmRlbUBlcmljc3Nvbi5jb21dIA0KPiDlj5HpgIHml7bpl7Q6IDIw MTPlubQxMOaciDIx5pelIDEwOjA3DQo+IOaUtuS7tuS6ujogWWFuZ2FuZw0KPiDmioTpgIE6IHJ0 Z3dnQGlldGYub3JnOyBaaGFuZ3h1ZG9uZyAoemhhbmd4dWRvbmcsIFZSUCkNCj4g5Li76aKYOiBS ZTogU29saWNpdGluZyBXRyBmZWVkYmFjayBhbmQgY29tbWVudHMgb24gZHJhZnQtenhkLXJ0Z3dn LW9yZGVyZWQtbWV0cmljLWFkanVzdG1lbnQtMDANCj4gDQo+IENhbiB5b3UgY29udHJhc3QgdGhp cyB3aXRoIFJGQyA2OTc2PyBZb3UgaW5jbHVkZSBSRkMgNjk3NiBpbiB0aGUgTm9ybWF0aXZlIFJl ZmVyZW5jZXMgYnV0IGl0IGlzIG5ldmVyIHJlZmVyZW5jZWQgKHRoaXMgd2lsbCBzaG93IHVwIGlm IHlvdSBydW4gaWRuaXRzKS4gDQo+IEFjZWUgDQo+IE9uIE9jdCAyMCwgMjAxMywgYXQgOTo0OSBQ TSwgWWFuZ2FuZyB3cm90ZToNCj4gDQo+PiBIaToNCj4+IA0KPj4gV2UgaGFkIHN1Ym1pdHRlZCB0 aGUgYSBuZXcgZHJhZnQ6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXp4ZC1ydGd3 Zy1vcmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50LTAwLCB3ZSB3YW50IHRvIGRpc2N1c3MgdGhlIG1p Y3JvLWxvb3AgcHJvYmxlbSB0aHJvdWdoIGFub3RoZXIgbWV0aG9kLiBZb3VyIGZlZWRiYWNrIGFu ZCBjb21tZW50cyBvbiB0aGUgcnRnd2cgbWFpbGluZyBsaXN0IGFyZSBhcHByZWNpYXRlZC4gDQo+ PiANCj4+IFRoYW5rcywNCj4+IFJhaHVsLllhbg0KPj4gDQo+PiAtLS0tLemCruS7tuWOn+S7ti0t LS0tDQo+PiDlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQo+PiDlj5HpgIHml7bpl7Q6IDIwMTPlubQxMOaciDE45pel IDE1OjQ3DQo+PiDmlLbku7bkuro6IFpoYW5neHVkb25nICh6aGFuZ3h1ZG9uZywgVlJQKTsgWWFu Z2FuZw0KPj4g5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXp4ZC1y dGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50LTAwLnR4dA0KPj4gDQo+PiANCj4+IEEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVu dC0wMC50eHQNCj4+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWHVkb25nIFpo YW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQo+PiBJRVRGIHJlcG9zaXRvcnkuDQo+PiANCj4+IEZpbGVu YW1lOgkgZHJhZnQtenhkLXJ0Z3dnLW9yZGVyZWQtbWV0cmljLWFkanVzdG1lbnQNCj4+IFJldmlz aW9uOgkgMDANCj4+IFRpdGxlOgkJIEFsZ29yaXRobSBmb3IgT3JkZXJlZCBNZXRyaWMgQWRqdXN0 bWVudA0KPj4gQ3JlYXRpb24gZGF0ZToJIDIwMTMtMTAtMTgNCj4+IEdyb3VwOgkJIEluZGl2aWR1 YWwgU3VibWlzc2lvbg0KPj4gTnVtYmVyIG9mIHBhZ2VzOiAxMA0KPj4gVVJMOiAgICAgICAgICAg ICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16eGQtcnRnd2ctb3Jk ZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0wMC50eHQNCj4+IFN0YXR1czogICAgICAgICAgaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMt YWRqdXN0bWVudA0KPj4gSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0wMA0KPj4gDQo+PiAN Cj4+IEFic3RyYWN0Og0KPj4gIFVwb24gbGluayBkb3duIGV2ZW50IG9yIGxpbmsgdXAgZXZlbnQs IGVhY2ggZGV2aWNlIGluIG5ldHdvcmsNCj4+ICBpbmRpdmlkdWFsbHkgc2NoZWR1bGVzIHJvdXRl IGNhbGN1bGF0aW9uLiAgQmVjYXVzZSBvZiBkaWZmZXJlbnQNCj4+ICBoYXJkd2FyZSBjYXBhYmls aXRpZXMgYW5kIGludGVybmFsL2V4dGVybmFsIGVudmlyb25tZW50cywgdGhlIHRpbWUgdG8NCj4+ ICB1cGRhdGUgZm9yd2FyZGluZyBlbnRyaWVzIG9uIHRoZXNlIGRldmljZXMgYXJlIGRpc29yZGVy ZWQgd2hpY2ggY2FuDQo+PiAgY2F1c2UgYSB0cmFuc2llbnQgZm9yd2FyZGluZyBsb29wLiAgVGhp cyBkb2N1bWVudCBpbnRyb2R1Y2VzIGEgbWV0aG9kDQo+PiAgdG8gcHJldmVudCBmb3J3YXJkaW5n IGxvb3AgYnkgYWRqdXN0aW5nIGxpbmsgbWV0cmljIGdyYWR1YWxseSBmb3INCj4+ICBzZXZlcmFs IHRpbWVzLg0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IFBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24N Cj4+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg dG9vbHMuaWV0Zi5vcmcuDQo+PiANCj4+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+PiANCj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBydGd3ZyBt YWlsaW5nIGxpc3QNCj4+IHJ0Z3dnQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3J0Z3dnDQo+IA0KDQo= From imc.shand@gmail.com Tue Oct 22 02:20:18 2013 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 1A8DF11E8328 for ; Tue, 22 Oct 2013 02:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcyEU6xYWNM9 for ; Tue, 22 Oct 2013 02:20:17 -0700 (PDT) Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id E908511E82E8 for ; Tue, 22 Oct 2013 02:20:16 -0700 (PDT) Received: by mail-bk0-f48.google.com with SMTP id my13so1147926bkb.7 for ; Tue, 22 Oct 2013 02:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=NjCP5FY7wVCmNGGgAzohRszL70iczONzDwH68i44FFU=; b=Dxe0D9rnhzaTD1rZq8XpMkHiO/crwCmPzj1oAgWB4vVexFb7TwojYItLoTOtE7gxwZ LArjAzkfFY4iRXJ28jWiFsAh9e61s7Xgi+0VfAMf2QDoEl7gTn6fXOTej9Bx9Ca+OGYg p270IC3cWyyqFpI+Z43Kg5vbwIly0+IAaoz8xue1hHb+T7Nobz2wjWIv/5oyOKtYJuOi FwNfcMVNAB3UWRlrePMXL8NOwFiMBgoeqdQfCjePC9aZ+oIEbFKukgYqo51ePAsMKY/s Iw8WrciMGGZgp8kFQn8D06ICNhL90i0a1AbdDQIxDiUydt5DicMNoK5ti+mfqOKOLs2C EHOQ== X-Received: by 10.204.103.199 with SMTP id l7mr11360811bko.11.1382433615568; Tue, 22 Oct 2013 02:20:15 -0700 (PDT) Received: from [192.168.2.183] (46-65-61-13.zone16.bethere.co.uk. [46.65.61.13]) by mx.google.com with ESMTPSA id qg7sm12219905bkb.6.2013.10.22.02.20.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Oct 2013 02:20:15 -0700 (PDT) Message-ID: <5266434B.4050309@gmail.com> Date: Tue, 22 Oct 2013 10:20:11 +0100 From: Mike Shand User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: rtgwg@ietf.org Subject: Re: =?UTF-8?B?562U5aSNOiDnrZTlpI06IFNvbGljaXRpbmcgV0cgZmVlZGJhY2s=?= =?UTF-8?B?IGFuZCBjb21tZW50cyBvbiBkcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWM=?= =?UTF-8?B?LWFkanVzdG1lbnQtMDA=?= References: <94A203EA12AECE4BA92D42DBFFE0AE470309F337@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47030A2579@eusaamb101.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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, 22 Oct 2013 09:20:18 -0000 So you have described the difference with OFIB (RFC 6976), but how does your proposal differ from "incremental cost advertisement" as described in RFC 5715 section 6.1? Mike On 22/10/2013 04:39, Yangang wrote: > OK, I got it. > > Actually, we pay attention to two point: > > 1. Which method will be more nicety? In RFC6976, all devices in network need calculate the schedule time, base on the different hardware and environment, we worry about its effect. In our draft, only failure point adjust the cost, the other device just response the cost change. I think the effect of this kind of difference will be less. > > 2. Due to no new extension, maybe the distribution will be more smoothly. > > -----邮件原件----- > å‘件人: Acee Lindem [mailto:acee.lindem@ericsson.com] > å‘é€æ—¶é—´: 2013å¹´10月22æ—¥ 9:42 > 收件人: Yangang > 抄é€: rtgwg@ietf.org; Zhangxudong (zhangxudong, VRP) > 主题: Re: ç­”å¤: Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00 > > I'm aware of the basic premise of the two drafts and was not asking for you to restate the obvious. Specifically, what are the benefits and determents of your draft when compared to RFC 6976? > Acee > > On Oct 21, 2013, at 9:30 PM, Yangang wrote: > >> Our draft is similar with section 6.1 in RFC5715, the cost of changed link will be adjusted and advertised, maybe more than one time, this sequence will base on some pre-calculations. But in RFC 6976, each device should calculate the distance with the failue link, base on this distance, each device decide when the FIB will be updated. >> >> -----邮件原件----- >> å‘件人: Acee Lindem [mailto:acee.lindem@ericsson.com] >> å‘é€æ—¶é—´: 2013å¹´10月21æ—¥ 10:07 >> 收件人: Yangang >> 抄é€: rtgwg@ietf.org; Zhangxudong (zhangxudong, VRP) >> 主题: Re: Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00 >> >> Can you contrast this with RFC 6976? You include RFC 6976 in the Normative References but it is never referenced (this will show up if you run idnits). >> Acee >> On Oct 20, 2013, at 9:49 PM, Yangang wrote: >> >>> Hi: >>> >>> We had submitted the a new draft: http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustment-00, we want to discuss the micro-loop problem through another method. Your feedback and comments on the rtgwg mailing list are appreciated. >>> >>> Thanks, >>> Rahul.Yan >>> >>> -----邮件原件----- >>> å‘件人: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> å‘é€æ—¶é—´: 2013å¹´10月18æ—¥ 15:47 >>> 收件人: Zhangxudong (zhangxudong, VRP); Yangang >>> 主题: New Version Notification for draft-zxd-rtgwg-ordered-metric-adjustment-00.txt >>> >>> >>> A new version of I-D, draft-zxd-rtgwg-ordered-metric-adjustment-00.txt >>> has been successfully submitted by Xudong Zhang and posted to the >>> IETF repository. >>> >>> Filename: draft-zxd-rtgwg-ordered-metric-adjustment >>> Revision: 00 >>> Title: Algorithm for Ordered Metric Adjustment >>> Creation date: 2013-10-18 >>> Group: Individual Submission >>> Number of pages: 10 >>> URL: http://www.ietf.org/internet-drafts/draft-zxd-rtgwg-ordered-metric-adjustment-00.txt >>> Status: http://datatracker.ietf.org/doc/draft-zxd-rtgwg-ordered-metric-adjustment >>> Htmlized: http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustment-00 >>> >>> >>> Abstract: >>> Upon link down event or link up event, each device in network >>> individually schedules route calculation. Because of different >>> hardware capabilities and internal/external environments, the time to >>> update forwarding entries on these devices are disordered which can >>> cause a transient forwarding loop. This document introduces a method >>> to prevent forwarding loop by adjusting link metric gradually for >>> several times. >>> >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> _______________________________________________ >>> rtgwg mailing list >>> rtgwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtgwg > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From aretana@cisco.com Tue Oct 22 10:22:54 2013 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 1F09011E8202 for ; Tue, 22 Oct 2013 10:22:54 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGjba+4NpnN6 for ; Tue, 22 Oct 2013 10:22:48 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id BE3E511E81CC for ; Tue, 22 Oct 2013 10:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2577; q=dns/txt; s=iport; t=1382462566; x=1383672166; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=X7SXmu1CdndA4Fk6tvLdaYdsdPNVeqdySkomo8c+/MM=; b=YRCRFhn3JznVoxWxkk2IP+SIfjMEugHAA3lFJ9/wpqv8zcPhwMvbqKiO V1cqoTFxDTyw1EqkWv+AM6aVITPa1O3Q5qC3ILIZJRoArJ9/YGccvh2Gl 7kxTR/ZcCruPTH8q0cDv94A/3Sr5bh3TVM5vsnrwvnbs2kqYqPLKSMzt+ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUGANSzZlKtJXG+/2dsb2JhbABZgkNEgQy+SoEnFm0HgicBBHkSAQgEAR0dORQRAgQOBQiHfrpVjx0xB4MfgQoDqhCDJIIq X-IronPort-AV: E=Sophos;i="4.93,549,1378857600"; d="scan'208,217";a="275298552" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 22 Oct 2013 17:22:45 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9MHMj3Q000919 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Oct 2013 17:22:45 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.40]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Tue, 22 Oct 2013 12:22:45 -0500 From: "Alvaro Retana (aretana)" To: "draft-enyedi-rtgwg-mrt-frr-algorithm@tools.ietf.org" Subject: Re: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algorithm Thread-Topic: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algorithm Thread-Index: AQHOxFQejz6lsVRV/UKb2dqFz2SbTpoBHruA Date: Tue, 22 Oct 2013 17:22:45 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.7] Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94E396A73A7xmbalnx15ciscoc_" 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: Tue, 22 Oct 2013 17:22:54 -0000 --_000_BBD66FD99311804F80324E8139B3C94E396A73A7xmbalnx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ping! So far none of the authors have replied. Alvaro. On 10/8/13 2:28 PM, "Alvaro Retana (aretana)" > wrote: Hi! In parallel to the WG Adoption Call, I want to formally ask the authors (no= additional contributors are listed in the latest version of the draft) to = please respond to this message indicating whether or not you are aware of a= ny relevant IPR. The draft will not progress (pending the results of the W= G Adoption Call) until we have received a response from each author. Thanks! Alvaro. --_000_BBD66FD99311804F80324E8139B3C94E396A73A7xmbalnx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <794F604C938AB54D8F3ECE0A60CFE298@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Ping!

So far none of the authors have replied.

Alvaro.

On 10/8/13 2:28 PM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

Hi!

In parallel to the WG Adoption Call, I want to formally ask the author= s (no additional contributors are listed in the latest version of the draft= ) to please respond to this message indicating whether or not you are aware= of any relevant IPR.  The draft will not progress (pending the results of the WG Adoption Call) until we h= ave received a response from each author.

Thanks!

Alvaro.
 --_000_BBD66FD99311804F80324E8139B3C94E396A73A7xmbalnx15ciscoc_-- From akatlas@juniper.net Tue Oct 22 10:34:28 2013 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 58C6111E8200 for ; Tue, 22 Oct 2013 10:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUnF9YpL9pjs for ; Tue, 22 Oct 2013 10:34:18 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1B90111E81BF for ; Tue, 22 Oct 2013 10:34:18 -0700 (PDT) Received: from mail74-tx2-R.bigfish.com (10.9.14.229) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.22; Tue, 22 Oct 2013 17:34:14 +0000 Received: from mail74-tx2 (localhost [127.0.0.1]) by mail74-tx2-R.bigfish.com (Postfix) with ESMTP id 7F1ED1C01DF; Tue, 22 Oct 2013 17:34:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zzbb2dI98dI9371Ic85fh103dKzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh18c673h1de097h8275bhz2fh2a8h839hd24hf0ah10d2h1288h12a5h12bdh137ah1441h1537h153bh162dh1631h1758h18deh18e1h1946h19b5h1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h17ej1155h) Received-SPF: pass (mail74-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=akatlas@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(24454002)(377454003)(479174003)(41574002)(19580395003)(63666003)(83072001)(81342001)(80976001)(59766001)(80022001)(33646001)(65816001)(79102001)(19580405001)(83322001)(4396001)(51856001)(43066001)(49866001)(50986001)(46102001)(47736001)(47976001)(47446002)(74662001)(74502001)(74366001)(54356001)(81542001)(74876001)(69226001)(74706001)(81816001)(76796001)(16236675002)(77096001)(56816003)(76786001)(81686001)(77982001)(56776001)(76482001)(54316002)(63696002)(85306002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB196; H:BL2PR05MB193.namprd05.prod.outlook.com; CLIP:::; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail74-tx2 (localhost.localdomain [127.0.0.1]) by mail74-tx2 (MessageSwitch) id 1382463252453542_6671; Tue, 22 Oct 2013 17:34:12 +0000 (UTC) Received: from TX2EHSMHS043.bigfish.com (unknown [10.9.14.252]) by mail74-tx2.bigfish.com (Postfix) with ESMTP id 668E8100040; Tue, 22 Oct 2013 17:34:12 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS043.bigfish.com (10.9.99.143) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 22 Oct 2013 17:34:09 +0000 Received: from BL2PR05MB196.namprd05.prod.outlook.com (10.242.198.155) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.371.2; Tue, 22 Oct 2013 17:34:05 +0000 Received: from BL2PR05MB193.namprd05.prod.outlook.com (10.242.198.143) by BL2PR05MB196.namprd05.prod.outlook.com (10.242.198.155) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 22 Oct 2013 17:34:04 +0000 Received: from BL2PR05MB193.namprd05.prod.outlook.com ([169.254.9.140]) by BL2PR05MB193.namprd05.prod.outlook.com ([169.254.9.140]) with mapi id 15.00.0785.001; Tue, 22 Oct 2013 17:34:04 +0000 From: Alia Atlas To: "Alvaro Retana (aretana)" , "draft-enyedi-rtgwg-mrt-frr-algorithm@tools.ietf.org" Subject: Re: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algorithm Thread-Topic: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algorithm Thread-Index: AQHOxFQejz6lsVRV/UKb2dqFz2SbTpoBHruA///yaqw= Date: Tue, 22 Oct 2013 17:34:04 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [::] x-forefront-prvs: 00073DB75F Content-Type: multipart/alternative; boundary="_000_nv32n2ptsjvoxvucedotr5im1382463239351emailandroidcom_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Alia Atlas List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 17:34:30 -0000 --_000_nv32n2ptsjvoxvucedotr5im1382463239351emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry! I don't believe that I know of any IPR claims by Juniper on draft-e= nyedi-rtgwg-mrt-algorithm-04, but I can't speak for Gabor or Andras as far = as their IPR goes. Alia -------- Original message -------- From: "Alvaro Retana (aretana)" Date: 10/22/2013 1:23 PM (GMT-05:00) To: draft-enyedi-rtgwg-mrt-frr-algorithm@tools.ietf.org Cc: rtgwg@ietf.org Subject: Re: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algorithm Ping! So far none of the authors have replied. Alvaro. On 10/8/13 2:28 PM, "Alvaro Retana (aretana)" > wrote: Hi! In parallel to the WG Adoption Call, I want to formally ask the authors (no= additional contributors are listed in the latest version of the draft) to = please respond to this message indicating whether or not you are aware of a= ny relevant IPR. The draft will not progress (pending the results of the W= G Adoption Call) until we have received a response from each author. Thanks! Alvaro. --_000_nv32n2ptsjvoxvucedotr5im1382463239351emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry!  I don't believe that I know of any IPR claims by Juniper on dr= aft-enyedi-rtgwg-mrt-algorithm-04, but I can't speak for Gabor or Andras as= far as their IPR goes.

Alia



-------- Original message --------
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
Date: 10/22/2013 1:23 PM (GMT-05:00)
To: draft-enyedi-rtgwg-mrt-frr-algorithm@tools.ietf.org
Cc: rtgwg@ietf.org
Subject: Re: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algorithm

Ping!

So far none of the authors have replied.

Alvaro.

On 10/8/13 2:28 PM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

Hi!

In parallel to the WG Adoption Call, I want to formally ask the author= s (no additional contributors are listed in the latest version of the draft= ) to please respond to this message indicating whether or not you are aware= of any relevant IPR.  The draft will not progress (pending the results of the WG Adoption Call) until we h= ave received a response from each author.

Thanks!

Alvaro.
--_000_nv32n2ptsjvoxvucedotr5im1382463239351emailandroidcom_-- From cbowers@juniper.net Tue Oct 22 10:39:58 2013 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 446D211E8200 for ; Tue, 22 Oct 2013 10:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueINC54Vwemv for ; Tue, 22 Oct 2013 10:39:48 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 7796A11E81BF for ; Tue, 22 Oct 2013 10:39:43 -0700 (PDT) Received: from mail31-am1-R.bigfish.com (10.3.201.254) by AM1EHSOBE018.bigfish.com (10.3.207.140) with Microsoft SMTP Server id 14.1.225.22; Tue, 22 Oct 2013 17:39:42 +0000 Received: from mail31-am1 (localhost [127.0.0.1]) by mail31-am1-R.bigfish.com (Postfix) with ESMTP id C2DAA2A0209; Tue, 22 Oct 2013 17:39:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zzbb2dI98dI9371Ic85fh103dKzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzc2hz1d7338h1de098h1033IL17326ah8275dh18c673h1de097h186068h8275bhz2fh2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h9a9j1155h) Received-SPF: pass (mail31-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=cbowers@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(41574002)(24454002)(479174003)(189002)(199002)(377454003)(79102001)(80022001)(66066001)(77096001)(56816003)(74662001)(15975445006)(74706001)(15202345003)(81542001)(81342001)(80976001)(1941001)(31966008)(19580395003)(83072001)(74366001)(65816001)(83322001)(74502001)(19609705001)(54316002)(81816001)(63696002)(54356001)(77982001)(85306002)(53806001)(56776001)(59766001)(19300405004)(33646001)(69226001)(16236675002)(49866001)(50986001)(74876001)(4396001)(81686001)(47446002)(74316001)(47976001)(76796001)(76482001)(19580405001)(47736001)(46102001)(76576001)(76786001)(51856001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB201; H:DM2PR05MB528.namprd05.prod.outlook.com; CLIP:66.129.224.52; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail31-am1 (localhost.localdomain [127.0.0.1]) by mail31-am1 (MessageSwitch) id 1382463580652192_19359; Tue, 22 Oct 2013 17:39:40 +0000 (UTC) Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.226]) by mail31-am1.bigfish.com (Postfix) with ESMTP id 9BBA9340063; Tue, 22 Oct 2013 17:39:40 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 22 Oct 2013 17:39:40 +0000 Received: from BN1PR05MB201.namprd05.prod.outlook.com (10.255.206.23) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.371.2; Tue, 22 Oct 2013 17:39:37 +0000 Received: from DM2PR05MB528.namprd05.prod.outlook.com (10.141.99.156) by BN1PR05MB201.namprd05.prod.outlook.com (10.255.206.23) with Microsoft SMTP Server (TLS) id 15.0.785.10; Tue, 22 Oct 2013 17:39:36 +0000 Received: from DM2PR05MB528.namprd05.prod.outlook.com ([169.254.8.76]) by DM2PR05MB528.namprd05.prod.outlook.com ([169.254.8.21]) with mapi id 15.00.0775.005; Tue, 22 Oct 2013 17:39:35 +0000 From: Chris Bowers To: Alia Atlas , "Alvaro Retana (aretana)" , "draft-enyedi-rtgwg-mrt-frr-algorithm@tools.ietf.org" Subject: RE: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algorithm Thread-Topic: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algorithm Thread-Index: AQHOxFQejz6lsVRV/UKb2dqFz2SbTpoBHruA///yaqyAAAFLUA== Date: Tue, 22 Oct 2013 17:39:35 +0000 Message-ID: <57307add47454f4387509d21380d4464@DM2PR05MB528.namprd05.prod.outlook.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.52] x-forefront-prvs: 00073DB75F Content-Type: multipart/alternative; boundary="_000_57307add47454f4387509d21380d4464DM2PR05MB528namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 22 Oct 2013 17:39:58 -0000 --_000_57307add47454f4387509d21380d4464DM2PR05MB528namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't know of any IPR claims by Juniper on draft-enyedi-rtgwg-mrt-algorit= hm-04, either. Chris From: Alia Atlas [mailto:akatlas@juniper.net] Sent: Tuesday, October 22, 2013 12:34 PM To: Alvaro Retana (aretana); draft-enyedi-rtgwg-mrt-frr-algorithm@tools.iet= f.org Cc: rtgwg@ietf.org Subject: Re: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algorithm Sorry! I don't believe that I know of any IPR claims by Juniper on draft-e= nyedi-rtgwg-mrt-algorithm-04, but I can't speak for Gabor or Andras as far = as their IPR goes. Alia -------- Original message -------- From: "Alvaro Retana (aretana)" > Date: 10/22/2013 1:23 PM (GMT-05:00) To: draft-enyedi-rtgwg-mrt-frr-algorithm@tools.ietf.org Cc: rtgwg@ietf.org Subject: Re: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algorithm Ping! So far none of the authors have replied. Alvaro. On 10/8/13 2:28 PM, "Alvaro Retana (aretana)" > wrote: Hi! In parallel to the WG Adoption Call, I want to formally ask the authors (no= additional contributors are listed in the latest version of the draft) to = please respond to this message indicating whether or not you are aware of a= ny relevant IPR. The draft will not progress (pending the results of the W= G Adoption Call) until we have received a response from each author. Thanks! Alvaro. --_000_57307add47454f4387509d21380d4464DM2PR05MB528namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t know of any= IPR claims by Juniper on draft-enyedi-rtgwg-mrt-algorithm-04, either.=

 <= /p>

Chris

 <= /p>

From: Alia A= tlas [mailto:akatlas@juniper.net]
Sent: Tuesday, October 22, 2013 12:34 PM
To: Alvaro Retana (aretana); draft-enyedi-rtgwg-mrt-frr-algorithm@to= ols.ietf.org
Cc: rtgwg@ietf.org
Subject: Re: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algori= thm

 

Sorry!  I don't believ= e that I know of any IPR claims by Juniper on draft-enyedi-rtgwg-mrt-algori= thm-04, but I can't speak for Gabor or Andras as far as their IPR goes.

 

Alia




-------- Original message --------
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
Date: 10/22/2013 1:23 PM (GMT-05:00)
To: = draft-enyedi-rtgwg-mrt-frr-algorithm@tools.ietf.org
Cc: rtgwg@ietf.org
Subject: Re: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algorithm

Ping!

 

So far none of the authors = have replied.

 

Alvaro.

 

On 10/8/13 2:28 PM, "A= lvaro Retana (aretana)" <areta= na@cisco.com> wrote:

 

Hi!

 

In parallel to the WG Adopt= ion Call, I want to formally ask the authors (no additional contributors ar= e listed in the latest version of the draft) to please respond to this message indicating whether or not you are aware of any relevant IP= R.  The draft will not progress (pending the results of the WG Adoptio= n Call) until we have received a response from each author.

 

Thanks!

 

Alvaro.

--_000_57307add47454f4387509d21380d4464DM2PR05MB528namprd05pro_-- From gabor.sandor.enyedi@ericsson.com Tue Oct 22 13:13:41 2013 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 D02C111E824A for ; Tue, 22 Oct 2013 13:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOC7IodL9ZGw for ; Tue, 22 Oct 2013 13:13:36 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED8111E810A for ; Tue, 22 Oct 2013 13:13:35 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-d8-5266dc6d7f0e Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 3F.67.25272.D6CD6625; Tue, 22 Oct 2013 22:13:34 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.88]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Tue, 22 Oct 2013 22:13:33 +0200 From: =?iso-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= To: Alia Atlas , "Alvaro Retana (aretana)" , "draft-enyedi-rtgwg-mrt-frr-algorithm@tools.ietf.org" Subject: Re: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algorithm Thread-Topic: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algorithm Thread-Index: AQHOxFQejz6lsVRV/UKb2dqFz2SbTpoBHruA///yaqyAACyNKA== Date: Tue, 22 Oct 2013 20:13:32 +0000 Message-ID: <3nnp0tksa44ug1ke5bx53og3.1382472669658@email.android.com> References: , , In-Reply-To: Accept-Language: hu-HU, en-US Content-Language: hu-HU X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3nnp0tksa44ug1ke5bx53og31382472669658emailandroidcom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+JvjW7enbQgg/ZjrBZfr6VZ/P25ldHi ceN5dosLb34zO7B4TPm9kdVjyZKfTB7Xm66ye3y5/JktgCWKyyYlNSezLLVI3y6BK2NyewNT wX+5ijMdS9gbGKdKdTFyckgImEj8fLeXHcIWk7hwbz1bFyMXh5DAUUaJOd1b2EASQgKLGSXW TqsCsdkEgiW2P9gAFhcROMIosWaBcxcjBwezgKrE5m22IGFhAXeJ/taNjBAlHhJnelayQ9hO EutOTwWzWYDKd526zQpi8wq4STz//pMdYtUJRon9K/JAbE6gOVeX3WIHGc8oICvxcK0FSJhZ QFxi4uInjBAnC0gs2XOeGcIWlXj5+B8rxDU5EnuPq0BMF5Q4OfMJywRGkVlIumchVM1CUgVR oidxY+oUNghbW2LZwtfMELauxIx/h1iQxRcwsq9i5ChOLU7KTTcy2MQIjK2DW35b7GC8/Nfm EKM0B4uSOO/Ht85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgVM33F929JtHO+8djR+Bfr ERa3R/ElnZXSsUKPbBT0H+lvOTO/pd24ao/DXAMe9/+WtjcrvjH9bu1oK7/DJpX3/94MSe89 Uo4WbEEVWtdsT27K4Pa1YUzUOJsZ9dhZpt/j8wsJ5/qkxgIurtpiqdW3d2j3luycL3a/+jkb k52Mb9zMK2LOSizFGYmGWsxFxYkAj5e8knsCAAA= 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, 22 Oct 2013 20:13:41 -0000 --_000_3nnp0tksa44ug1ke5bx53og31382472669658emailandroidcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I sorry too. I don't know about any IPR by Ericsson. Ericsson doesn't like = software patents, and this draft is only describing algorithms. BR, Gabor Alia Atlas wrote: Sorry! I don't believe that I know of any IPR claims by Juniper on draft-e= nyedi-rtgwg-mrt-algorithm-04, but I can't speak for Gabor or Andras as far = as their IPR goes. Alia -------- Original message -------- From: "Alvaro Retana (aretana)" Date: 10/22/2013 1:23 PM (GMT-05:00) To: draft-enyedi-rtgwg-mrt-frr-algorithm@tools.ietf.org Cc: rtgwg@ietf.org Subject: Re: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algorithm Ping! So far none of the authors have replied. Alvaro. On 10/8/13 2:28 PM, "Alvaro Retana (aretana)" > wrote: Hi! In parallel to the WG Adoption Call, I want to formally ask the authors (no= additional contributors are listed in the latest version of the draft) to = please respond to this message indicating whether or not you are aware of a= ny relevant IPR. The draft will not progress (pending the results of the W= G Adoption Call) until we have received a response from each author. Thanks! Alvaro. --_000_3nnp0tksa44ug1ke5bx53og31382472669658emailandroidcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
I sorry too. I don't know about any IPR by Ericsson. Ericsson d=
oesn't like software patents, and this draft is only describing algorithms.=
=0A=
BR,=0A=
=0A=
Gabor=0A=
=0A=
Alia Atlas <akatlas@juniper.net> wrote:=0A=
=0A=
Sorry!  I don't believe that I know of any IPR claims by Juniper = on draft-enyedi-rtgwg-mrt-algorithm-04, but I can't speak for Gabor or Andr= as as far as their IPR goes.

Alia



-------- Original message --------
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
Date: 10/22/2013 1:23 PM (GMT-05:00)
To: draft-enyedi-rtgwg-mrt-frr-algorithm@tools.ietf.org
Cc: rtgwg@ietf.org
Subject: Re: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algorithm

Ping!

So far none of the authors have replied.

Alvaro.

On 10/8/13 2:28 PM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

Hi!

In parallel to the WG Adoption Call, I want to formally ask the author= s (no additional contributors are listed in the latest version of the draft= ) to please respond to this message indicating whether or not you are aware= of any relevant IPR.  The draft will not progress (pending the results of the WG Adoption Call) until we h= ave received a response from each author.

Thanks!

Alvaro.
--_000_3nnp0tksa44ug1ke5bx53og31382472669658emailandroidcom_-- From yangang@huawei.com Wed Oct 23 02:49:38 2013 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 8552211E833F for ; Wed, 23 Oct 2013 02:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.293 X-Spam-Level: X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[AWL=-4.681, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0IPpMQ3tkLH for ; Wed, 23 Oct 2013 02:49:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8BD11E8330 for ; Wed, 23 Oct 2013 02:49:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZJ19979; Wed, 23 Oct 2013 09:49:32 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Oct 2013 10:49:26 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Oct 2013 10:49:26 +0100 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.136]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0146.000; Wed, 23 Oct 2013 17:48:30 +0800 From: Yangang To: Mike Shand Subject: =?gb2312?B?tPC4tDogcnRnd2cgRGlnZXN0LCBWb2wgMTA2LCBJc3N1ZSAzNw==?= Thread-Topic: rtgwg Digest, Vol 106, Issue 37 Thread-Index: AQHOzwf8mowVMc0KBEicBJ38BEYzwpoCCxWw Date: Wed, 23 Oct 2013 09:48:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.72.210] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Zhangxudong \(zhangxudong, VRP\)" , "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, 23 Oct 2013 09:49:38 -0000 SGksIE1pa2U6DQoNCldlIGRvdWJsZSBjaGVjayB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIG91ciBk cmFmdCBhbmQgdGhlIFJGQyA1NzE1LCBhbmQgcmVhZCB0aGUgcGFwZXIgb2YgW09QVF0gYWdhaW4u IA0KDQpZZXMsIHRoZWlyIGNvbmNlcHRzIGFyZSBzaW1pbGFyLiBUaGUgc2VjdGlvbiA2LjEgb2Yg UkZDNTcxNSBwb2ludCBvdXQgdGhlICJpbmNyZW1lbnRhbCBjb3N0IGFkdmVydGlzZW1lbnQiIGlz IGEgcG9zc2libGUgbWV0aG9kLCBhbmQgb3VyIGRyYWZ0IHByb3ZpZGVzIGFuIGFsZ29yaXRobSBp biBkZXRhaWwgZm9yIHRoaXMgbWV0aG9kLg0KDQpDb21wYXJlIHdpdGggcGFwZXIgb2YgW09QVF0s IEkgdGhpbmsgdGhlcmUgYXJlIHNvbWUgZGlmZmVyZW5jZXMuDQoNClRoZSBwYXBlcjoNCg0KMS4g dHJpZXMgdG8gZ2V0IGEgbWV0cmljIGFkanVzdG1lbnQgc2VxdWVuY2UoUk1TKSBmb3IgZWFjaCBw b3NzaWJsZSBkZXN0aW5hdGlvbiwgYW5kIHRoZW4gb3B0aW1pemVzIHRoaXMgc2VxdWVuY2UgdG8g T1JNUy4NCjIuIGNvbWJpbmVzIHRoZXNlIE9STVNzIGFuZCBwcnVuZXMgdW5uZWNlc3NhcnkgbWV0 cmljcy4NCg0KQXMgaW1wbGVtZW50ZXJzLCB3ZSBjb21wb3NlIHRoZSBkcmFmdCBpbiBhIHN0eWxl IHRoYXQgaXQgaXMgZWFzaWx5IHRvIGJlIHJlYWxpemVkIG9uIHJvdXRlciBwbGF0Zm9ybXMuIFRo aXMgZHJhZnQ6DQoNCigxKSBDYWxjdWxhdGVzIGEgbWV0cmljIGFkanVzdG1lbnQgc2NvcGUobGlu ayB1cCksIGFuZCBmb2xsb3dzIHRoZXNlIHJ1bGVzOg0KICAgMS5hKSB0aGlzIG5ldyBtZXRyaWMg d2lsbCBtYWtlIHRoZSBub2RlIGkgc3dpdGNoIHRvIHRoZSBmaW5hbCBiZXN0IHBhdGguDQogICAx LmIpIHRoaXMgbmV3IG1ldHJpYyBkb2Vzbid0IG1ha2Ugb3RoZXIgdW5hZmZlY3RlZCBub2RlcyBz d2l0Y2ggdGhlaXIgcGF0aHMuDQooMikgQmFzZSBvbiB0aGUgUlNQRiBvZiBsaW5rdXAgYW5kIFJT UEYgb2YgbGlua2Rvd24sIGNhbGN1bGF0ZXMgdGhlIGJlc3QgbWV0cmljIGFkanVzdG1lbnQgc2Vx dWVuY2UgaW4ganVzdCBvbmUgcm91bmQuDQoNClNvLCB3ZSB0aGluayB0aGUgb3ZlcmhlYWQgb2Yg dGhlIGFsZ29yaXRobSBpbiB0aGUgZHJhZnQgY2FuIGJlIGxlc3Mgc2luY2UgaXQgY2FsY3VsYXRl cyB0aGUgU1BGIG9ubHkgdHdpY2UuDQoNCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IHJ0 Z3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGd3Zy1ib3VuY2VzQGlldGYub3JnXSC0+rHt IHJ0Z3dnLXJlcXVlc3RAaWV0Zi5vcmcNCreiy83KsbzkOiAyMDEzxOoxMNTCMjLI1SAxNzoyMA0K ytW8/sjLOiBydGd3Z0BpZXRmLm9yZw0K1vfM4jogcnRnd2cgRGlnZXN0LCBWb2wgMTA2LCBJc3N1 ZSAzNw0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGRpZ2VzdCB3aXRob3V0IGFsbCB0aGUg aW5kaXZpZHVhbCBtZXNzYWdlDQphdHRhY2htZW50cyB5b3Ugd2lsbCBuZWVkIHRvIHVwZGF0ZSB5 b3VyIGRpZ2VzdCBvcHRpb25zIGluIHlvdXIgbGlzdA0Kc3Vic2NyaXB0aW9uLiAgVG8gZG8gc28s IGdvIHRvIA0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Z3dnDQoN CkNsaWNrIHRoZSAnVW5zdWJzY3JpYmUgb3IgZWRpdCBvcHRpb25zJyBidXR0b24sIGxvZyBpbiwg YW5kIHNldCAiR2V0DQpNSU1FIG9yIFBsYWluIFRleHQgRGlnZXN0cz8iIHRvIE1JTUUuICBZb3Ug Y2FuIHNldCB0aGlzIG9wdGlvbg0KZ2xvYmFsbHkgZm9yIGFsbCB0aGUgbGlzdCBkaWdlc3RzIHlv dSByZWNlaXZlIGF0IHRoaXMgcG9pbnQuDQoNCg0KDQpTZW5kIHJ0Z3dnIG1haWxpbmcgbGlzdCBz dWJtaXNzaW9ucyB0bw0KCXJ0Z3dnQGlldGYub3JnDQoNClRvIHN1YnNjcmliZSBvciB1bnN1YnNj cmliZSB2aWEgdGhlIFdvcmxkIFdpZGUgV2ViLCB2aXNpdA0KCWh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcnRnd2cNCm9yLCB2aWEgZW1haWwsIHNlbmQgYSBtZXNzYWdlIHdp dGggc3ViamVjdCBvciBib2R5ICdoZWxwJyB0bw0KCXJ0Z3dnLXJlcXVlc3RAaWV0Zi5vcmcNCg0K WW91IGNhbiByZWFjaCB0aGUgcGVyc29uIG1hbmFnaW5nIHRoZSBsaXN0IGF0DQoJcnRnd2ctb3du ZXJAaWV0Zi5vcmcNCg0KV2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0IGxp bmUgc28gaXQgaXMgbW9yZSBzcGVjaWZpYw0KdGhhbiAiUmU6IENvbnRlbnRzIG9mIHJ0Z3dnIGRp Z2VzdC4uLiINCg0KDQpUb2RheSdzIFRvcGljczoNCg0KICAgMS4gPz86IFNvbGljaXRpbmcgV0cg ZmVlZGJhY2sgYW5kIGNvbW1lbnRzIG9uDQogICAgICBkcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1t ZXRyaWMtYWRqdXN0bWVudC0wMCAoWWFuZ2FuZykNCiAgIDIuIFJlOiA/PzogU29saWNpdGluZyBX RyBmZWVkYmFjayBhbmQgY29tbWVudHMgb24NCiAgICAgIGRyYWZ0LXp4ZC1ydGd3Zy1vcmRlcmVk LW1ldHJpYy1hZGp1c3RtZW50LTAwIChBY2VlIExpbmRlbSkNCiAgIDMuID8/OiA/PzogU29saWNp dGluZyBXRyBmZWVkYmFjayBhbmQgY29tbWVudHMgb24NCiAgICAgIGRyYWZ0LXp4ZC1ydGd3Zy1v cmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50LTAwIChZYW5nYW5nKQ0KICAgNC4gUmU6ID8/OiA/Pzog U29saWNpdGluZyBXRyBmZWVkYmFjayBhbmQgY29tbWVudHMgb24NCiAgICAgIGRyYWZ0LXp4ZC1y dGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50LTAwIChNaWtlIFNoYW5kKQ0KDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCg0KTWVzc2FnZTogMQ0KRGF0ZTogVHVlLCAyMiBPY3QgMjAxMyAwMTozMDoyMyAr MDAwMA0KRnJvbTogWWFuZ2FuZyA8eWFuZ2FuZ0BodWF3ZWkuY29tPg0KVG86IEFjZWUgTGluZGVt IDxhY2VlLmxpbmRlbUBlcmljc3Nvbi5jb20+DQpDYzogIlpoYW5neHVkb25nIFwoemhhbmd4dWRv bmcsIFZSUFwpIiA8emhhbmd4dWRvbmdAaHVhd2VpLmNvbT4sDQoJInJ0Z3dnQGlldGYub3JnIiA8 cnRnd2dAaWV0Zi5vcmc+DQpTdWJqZWN0OiA/PzogU29saWNpdGluZyBXRyBmZWVkYmFjayBhbmQg Y29tbWVudHMgb24NCglkcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0w MA0KTWVzc2FnZS1JRDoNCgk8RDQ5NkM5NzJEMUExMzU0MEE3MzA3MjA2MzFFQzczNDEzQTM5RUY2 MEBua2dlbWw1MDctbWJzLmNoaW5hLmh1YXdlaS5jb20+DQoJDQpDb250ZW50LVR5cGU6IHRleHQv cGxhaW47IGNoYXJzZXQ9InV0Zi04Ig0KDQpPdXIgZHJhZnQgaXMgc2ltaWxhciB3aXRoIHNlY3Rp b24gNi4xIGluIFJGQzU3MTUsIHRoZSBjb3N0IG9mIGNoYW5nZWQgbGluayB3aWxsIGJlIGFkanVz dGVkIGFuZCBhZHZlcnRpc2VkLCBtYXliZSBtb3JlIHRoYW4gb25lIHRpbWUsIHRoaXMgc2VxdWVu Y2Ugd2lsbCBiYXNlIG9uIHNvbWUgcHJlLWNhbGN1bGF0aW9ucy4gQnV0IGluIFJGQyA2OTc2LCBl YWNoIGRldmljZSBzaG91bGQgY2FsY3VsYXRlIHRoZSBkaXN0YW5jZSB3aXRoIHRoZSBmYWlsdWUg bGluaywgYmFzZSBvbiB0aGlzIGRpc3RhbmNlLCBlYWNoIGRldmljZSBkZWNpZGUgd2hlbiB0aGUg RklCIHdpbGwgYmUgdXBkYXRlZC4NCg0KLS0tLS0/Pz8/LS0tLS0NCj8/PzogQWNlZSBMaW5kZW0g W21haWx0bzphY2VlLmxpbmRlbUBlcmljc3Nvbi5jb21dIA0KPz8/PzogMjAxMz8xMD8yMT8gMTA6 MDcNCj8/PzogWWFuZ2FuZw0KPz86IHJ0Z3dnQGlldGYub3JnOyBaaGFuZ3h1ZG9uZyAoemhhbmd4 dWRvbmcsIFZSUCkNCj8/OiBSZTogU29saWNpdGluZyBXRyBmZWVkYmFjayBhbmQgY29tbWVudHMg b24gZHJhZnQtenhkLXJ0Z3dnLW9yZGVyZWQtbWV0cmljLWFkanVzdG1lbnQtMDANCg0KQ2FuIHlv dSBjb250cmFzdCB0aGlzIHdpdGggUkZDIDY5NzY/IFlvdSBpbmNsdWRlIFJGQyA2OTc2IGluIHRo ZSBOb3JtYXRpdmUgUmVmZXJlbmNlcyBidXQgaXQgaXMgbmV2ZXIgcmVmZXJlbmNlZCAodGhpcyB3 aWxsIHNob3cgdXAgaWYgeW91IHJ1biBpZG5pdHMpLiANCkFjZWUgDQpPbiBPY3QgMjAsIDIwMTMs IGF0IDk6NDkgUE0sIFlhbmdhbmcgd3JvdGU6DQoNCj4gSGk6DQo+IA0KPiBXZSBoYWQgc3VibWl0 dGVkIHRoZSBhIG5ldyBkcmFmdDogaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtenhk LXJ0Z3dnLW9yZGVyZWQtbWV0cmljLWFkanVzdG1lbnQtMDAsIHdlIHdhbnQgdG8gZGlzY3VzcyB0 aGUgbWljcm8tbG9vcCBwcm9ibGVtIHRocm91Z2ggYW5vdGhlciBtZXRob2QuIFlvdXIgZmVlZGJh Y2sgYW5kIGNvbW1lbnRzIG9uIHRoZSBydGd3ZyBtYWlsaW5nIGxpc3QgYXJlIGFwcHJlY2lhdGVk LiANCj4gDQo+IFRoYW5rcywNCj4gUmFodWwuWWFuDQo+IA0KPiAtLS0tLT8/Pz8tLS0tLQ0KPiA/ Pz86IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZ10gDQo+ID8/Pz86IDIwMTM/MTA/MTg/IDE1OjQ3DQo+ID8/PzogWmhhbmd4dWRvbmcgKHpo YW5neHVkb25nLCBWUlApOyBZYW5nYW5nDQo+ID8/OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LXp4ZC1ydGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50LTAwLnR4dA0KPiAN Cj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRy aWMtYWRqdXN0bWVudC0wMC50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBYdWRvbmcgWmhhbmcgYW5kIHBvc3RlZCB0byB0aGUNCj4gSUVURiByZXBvc2l0b3J5Lg0KPiAN Cj4gRmlsZW5hbWU6CSBkcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudA0K PiBSZXZpc2lvbjoJIDAwDQo+IFRpdGxlOgkJIEFsZ29yaXRobSBmb3IgT3JkZXJlZCBNZXRyaWMg QWRqdXN0bWVudA0KPiBDcmVhdGlvbiBkYXRlOgkgMjAxMy0xMC0xOA0KPiBHcm91cDoJCSBJbmRp dmlkdWFsIFN1Ym1pc3Npb24NCj4gTnVtYmVyIG9mIHBhZ2VzOiAxMA0KPiBVUkw6ICAgICAgICAg ICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXp4ZC1ydGd3Zy1v cmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50LTAwLnR4dA0KPiBTdGF0dXM6ICAgICAgICAgIGh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtenhkLXJ0Z3dnLW9yZGVyZWQtbWV0cmlj LWFkanVzdG1lbnQNCj4gSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0wMA0KPiANCj4gDQo+ IEFic3RyYWN0Og0KPiAgIFVwb24gbGluayBkb3duIGV2ZW50IG9yIGxpbmsgdXAgZXZlbnQsIGVh Y2ggZGV2aWNlIGluIG5ldHdvcmsNCj4gICBpbmRpdmlkdWFsbHkgc2NoZWR1bGVzIHJvdXRlIGNh bGN1bGF0aW9uLiAgQmVjYXVzZSBvZiBkaWZmZXJlbnQNCj4gICBoYXJkd2FyZSBjYXBhYmlsaXRp ZXMgYW5kIGludGVybmFsL2V4dGVybmFsIGVudmlyb25tZW50cywgdGhlIHRpbWUgdG8NCj4gICB1 cGRhdGUgZm9yd2FyZGluZyBlbnRyaWVzIG9uIHRoZXNlIGRldmljZXMgYXJlIGRpc29yZGVyZWQg d2hpY2ggY2FuDQo+ICAgY2F1c2UgYSB0cmFuc2llbnQgZm9yd2FyZGluZyBsb29wLiAgVGhpcyBk b2N1bWVudCBpbnRyb2R1Y2VzIGEgbWV0aG9kDQo+ICAgdG8gcHJldmVudCBmb3J3YXJkaW5nIGxv b3AgYnkgYWRqdXN0aW5nIGxpbmsgbWV0cmljIGdyYWR1YWxseSBmb3INCj4gICBzZXZlcmFsIHRp bWVzLg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+IA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBydGd3ZyBtYWlsaW5nIGxpc3QNCj4g cnRnd2dAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y dGd3Zw0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpNZXNzYWdlOiAyDQpE YXRlOiBUdWUsIDIyIE9jdCAyMDEzIDAxOjQxOjQ5ICswMDAwDQpGcm9tOiBBY2VlIExpbmRlbSA8 YWNlZS5saW5kZW1AZXJpY3Nzb24uY29tPg0KVG86IFlhbmdhbmcgPHlhbmdhbmdAaHVhd2VpLmNv bT4NCkNjOiAiWmhhbmd4dWRvbmcgXCh6aGFuZ3h1ZG9uZywgVlJQXCkiIDx6aGFuZ3h1ZG9uZ0Bo dWF3ZWkuY29tPiwNCgkicnRnd2dAaWV0Zi5vcmciIDxydGd3Z0BpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiA/PzogU29saWNpdGluZyBXRyBmZWVkYmFjayBhbmQgY29tbWVudHMgb24NCglkcmFmdC16 eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0wMA0KTWVzc2FnZS1JRDoNCgk8OTRB MjAzRUExMkFFQ0U0QkE5MkQ0MkRCRkZFMEFFNDcwMzBBMjU3OUBldXNhYW1iMTAxLmVyaWNzc29u LnNlPg0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ1dGYtOCINCg0KSSdtIGF3 YXJlIG9mIHRoZSBiYXNpYyBwcmVtaXNlIG9mIHRoZSB0d28gZHJhZnRzIGFuZCB3YXMgbm90IGFz a2luZyBmb3IgeW91IHRvIHJlc3RhdGUgdGhlIG9idmlvdXMuIFNwZWNpZmljYWxseSwgd2hhdCBh cmUgdGhlIGJlbmVmaXRzIGFuZCBkZXRlcm1lbnRzIG9mIHlvdXIgZHJhZnQgd2hlbiBjb21wYXJl ZCB0byBSRkMgNjk3Nj8gDQpBY2VlDQoNCk9uIE9jdCAyMSwgMjAxMywgYXQgOTozMCBQTSwgWWFu Z2FuZyB3cm90ZToNCg0KPiBPdXIgZHJhZnQgaXMgc2ltaWxhciB3aXRoIHNlY3Rpb24gNi4xIGlu IFJGQzU3MTUsIHRoZSBjb3N0IG9mIGNoYW5nZWQgbGluayB3aWxsIGJlIGFkanVzdGVkIGFuZCBh ZHZlcnRpc2VkLCBtYXliZSBtb3JlIHRoYW4gb25lIHRpbWUsIHRoaXMgc2VxdWVuY2Ugd2lsbCBi YXNlIG9uIHNvbWUgcHJlLWNhbGN1bGF0aW9ucy4gQnV0IGluIFJGQyA2OTc2LCBlYWNoIGRldmlj ZSBzaG91bGQgY2FsY3VsYXRlIHRoZSBkaXN0YW5jZSB3aXRoIHRoZSBmYWlsdWUgbGluaywgYmFz ZSBvbiB0aGlzIGRpc3RhbmNlLCBlYWNoIGRldmljZSBkZWNpZGUgd2hlbiB0aGUgRklCIHdpbGwg YmUgdXBkYXRlZC4NCj4gDQo+IC0tLS0tPz8/Py0tLS0tDQo+ID8/PzogQWNlZSBMaW5kZW0gW21h aWx0bzphY2VlLmxpbmRlbUBlcmljc3Nvbi5jb21dIA0KPiA/Pz8/OiAyMDEzPzEwPzIxPyAxMDow Nw0KPiA/Pz86IFlhbmdhbmcNCj4gPz86IHJ0Z3dnQGlldGYub3JnOyBaaGFuZ3h1ZG9uZyAoemhh bmd4dWRvbmcsIFZSUCkNCj4gPz86IFJlOiBTb2xpY2l0aW5nIFdHIGZlZWRiYWNrIGFuZCBjb21t ZW50cyBvbiBkcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0wMA0KPiAN Cj4gQ2FuIHlvdSBjb250cmFzdCB0aGlzIHdpdGggUkZDIDY5NzY/IFlvdSBpbmNsdWRlIFJGQyA2 OTc2IGluIHRoZSBOb3JtYXRpdmUgUmVmZXJlbmNlcyBidXQgaXQgaXMgbmV2ZXIgcmVmZXJlbmNl ZCAodGhpcyB3aWxsIHNob3cgdXAgaWYgeW91IHJ1biBpZG5pdHMpLiANCj4gQWNlZSANCj4gT24g T2N0IDIwLCAyMDEzLCBhdCA5OjQ5IFBNLCBZYW5nYW5nIHdyb3RlOg0KPiANCj4+IEhpOg0KPj4g DQo+PiBXZSBoYWQgc3VibWl0dGVkIHRoZSBhIG5ldyBkcmFmdDogaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtenhkLXJ0Z3dnLW9yZGVyZWQtbWV0cmljLWFkanVzdG1lbnQtMDAsIHdl IHdhbnQgdG8gZGlzY3VzcyB0aGUgbWljcm8tbG9vcCBwcm9ibGVtIHRocm91Z2ggYW5vdGhlciBt ZXRob2QuIFlvdXIgZmVlZGJhY2sgYW5kIGNvbW1lbnRzIG9uIHRoZSBydGd3ZyBtYWlsaW5nIGxp c3QgYXJlIGFwcHJlY2lhdGVkLiANCj4+IA0KPj4gVGhhbmtzLA0KPj4gUmFodWwuWWFuDQo+PiAN Cj4+IC0tLS0tPz8/Py0tLS0tDQo+PiA/Pz86IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQo+PiA/Pz8/OiAyMDEzPzEwPzE4PyAxNTo0 Nw0KPj4gPz8/OiBaaGFuZ3h1ZG9uZyAoemhhbmd4dWRvbmcsIFZSUCk7IFlhbmdhbmcNCj4+ID8/ OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXp4ZC1ydGd3Zy1vcmRlcmVkLW1l dHJpYy1hZGp1c3RtZW50LTAwLnR4dA0KPj4gDQo+PiANCj4+IEEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0wMC50eHQNCj4+IGhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWHVkb25nIFpoYW5nIGFuZCBwb3N0ZWQg dG8gdGhlDQo+PiBJRVRGIHJlcG9zaXRvcnkuDQo+PiANCj4+IEZpbGVuYW1lOgkgZHJhZnQtenhk LXJ0Z3dnLW9yZGVyZWQtbWV0cmljLWFkanVzdG1lbnQNCj4+IFJldmlzaW9uOgkgMDANCj4+IFRp dGxlOgkJIEFsZ29yaXRobSBmb3IgT3JkZXJlZCBNZXRyaWMgQWRqdXN0bWVudA0KPj4gQ3JlYXRp b24gZGF0ZToJIDIwMTMtMTAtMTgNCj4+IEdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0K Pj4gTnVtYmVyIG9mIHBhZ2VzOiAxMA0KPj4gVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRq dXN0bWVudC0wMC50eHQNCj4+IFN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudA0KPj4g SHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16eGQtcnRn d2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0wMA0KPj4gDQo+PiANCj4+IEFic3RyYWN0Og0K Pj4gIFVwb24gbGluayBkb3duIGV2ZW50IG9yIGxpbmsgdXAgZXZlbnQsIGVhY2ggZGV2aWNlIGlu IG5ldHdvcmsNCj4+ICBpbmRpdmlkdWFsbHkgc2NoZWR1bGVzIHJvdXRlIGNhbGN1bGF0aW9uLiAg QmVjYXVzZSBvZiBkaWZmZXJlbnQNCj4+ICBoYXJkd2FyZSBjYXBhYmlsaXRpZXMgYW5kIGludGVy bmFsL2V4dGVybmFsIGVudmlyb25tZW50cywgdGhlIHRpbWUgdG8NCj4+ICB1cGRhdGUgZm9yd2Fy ZGluZyBlbnRyaWVzIG9uIHRoZXNlIGRldmljZXMgYXJlIGRpc29yZGVyZWQgd2hpY2ggY2FuDQo+ PiAgY2F1c2UgYSB0cmFuc2llbnQgZm9yd2FyZGluZyBsb29wLiAgVGhpcyBkb2N1bWVudCBpbnRy b2R1Y2VzIGEgbWV0aG9kDQo+PiAgdG8gcHJldmVudCBmb3J3YXJkaW5nIGxvb3AgYnkgYWRqdXN0 aW5nIGxpbmsgbWV0cmljIGdyYWR1YWxseSBmb3INCj4+ICBzZXZlcmFsIHRpbWVzLg0KPj4gDQo+ PiANCj4+IA0KPj4gDQo+PiANCj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4+IHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQo+PiANCj4+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+PiANCj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBydGd3ZyBtYWlsaW5nIGxpc3QNCj4+ IHJ0Z3dnQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3J0Z3dnDQo+IA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpNZXNzYWdl OiAzDQpEYXRlOiBUdWUsIDIyIE9jdCAyMDEzIDAzOjM5OjU1ICswMDAwDQpGcm9tOiBZYW5nYW5n IDx5YW5nYW5nQGh1YXdlaS5jb20+DQpUbzogQWNlZSBMaW5kZW0gPGFjZWUubGluZGVtQGVyaWNz c29uLmNvbT4NCkNjOiAiWmhhbmd4dWRvbmcgXCh6aGFuZ3h1ZG9uZywgVlJQXCkiIDx6aGFuZ3h1 ZG9uZ0BodWF3ZWkuY29tPiwNCgkicnRnd2dAaWV0Zi5vcmciIDxydGd3Z0BpZXRmLm9yZz4NClN1 YmplY3Q6ID8/OiA/PzogU29saWNpdGluZyBXRyBmZWVkYmFjayBhbmQgY29tbWVudHMgb24NCglk cmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0wMA0KTWVzc2FnZS1JRDoN Cgk8RDQ5NkM5NzJEMUExMzU0MEE3MzA3MjA2MzFFQzczNDEzQTM5RUY3Q0Bua2dlbWw1MDctbWJz LmNoaW5hLmh1YXdlaS5jb20+DQoJDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9 InV0Zi04Ig0KDQpPSywgSSBnb3QgaXQuDQoNCkFjdHVhbGx5LCB3ZSBwYXkgYXR0ZW50aW9uIHRv IHR3byBwb2ludDoNCg0KMS4gV2hpY2ggbWV0aG9kIHdpbGwgYmUgbW9yZSBuaWNldHk/IEluIFJG QzY5NzYsIGFsbCBkZXZpY2VzIGluIG5ldHdvcmsgbmVlZCBjYWxjdWxhdGUgdGhlIHNjaGVkdWxl IHRpbWUsIGJhc2Ugb24gdGhlIGRpZmZlcmVudCBoYXJkd2FyZSBhbmQgZW52aXJvbm1lbnQsIHdl IHdvcnJ5IGFib3V0IGl0cyBlZmZlY3QuIEluIG91ciBkcmFmdCwgb25seSBmYWlsdXJlIHBvaW50 IGFkanVzdCB0aGUgY29zdCwgdGhlIG90aGVyIGRldmljZSBqdXN0IHJlc3BvbnNlIHRoZSBjb3N0 IGNoYW5nZS4gSSB0aGluayB0aGUgZWZmZWN0IG9mIHRoaXMga2luZCBvZiBkaWZmZXJlbmNlIHdp bGwgYmUgbGVzcy4NCg0KMi4gRHVlIHRvIG5vIG5ldyBleHRlbnNpb24sIG1heWJlIHRoZSBkaXN0 cmlidXRpb24gd2lsbCBiZSBtb3JlIHNtb290aGx5Lg0KDQotLS0tLT8/Pz8tLS0tLQ0KPz8/OiBB Y2VlIExpbmRlbSBbbWFpbHRvOmFjZWUubGluZGVtQGVyaWNzc29uLmNvbV0gDQo/Pz8/OiAyMDEz PzEwPzIyPyA5OjQyDQo/Pz86IFlhbmdhbmcNCj8/OiBydGd3Z0BpZXRmLm9yZzsgWmhhbmd4dWRv bmcgKHpoYW5neHVkb25nLCBWUlApDQo/PzogUmU6ID8/OiBTb2xpY2l0aW5nIFdHIGZlZWRiYWNr IGFuZCBjb21tZW50cyBvbiBkcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVu dC0wMA0KDQpJJ20gYXdhcmUgb2YgdGhlIGJhc2ljIHByZW1pc2Ugb2YgdGhlIHR3byBkcmFmdHMg YW5kIHdhcyBub3QgYXNraW5nIGZvciB5b3UgdG8gcmVzdGF0ZSB0aGUgb2J2aW91cy4gU3BlY2lm aWNhbGx5LCB3aGF0IGFyZSB0aGUgYmVuZWZpdHMgYW5kIGRldGVybWVudHMgb2YgeW91ciBkcmFm dCB3aGVuIGNvbXBhcmVkIHRvIFJGQyA2OTc2PyANCkFjZWUNCg0KT24gT2N0IDIxLCAyMDEzLCBh dCA5OjMwIFBNLCBZYW5nYW5nIHdyb3RlOg0KDQo+IE91ciBkcmFmdCBpcyBzaW1pbGFyIHdpdGgg c2VjdGlvbiA2LjEgaW4gUkZDNTcxNSwgdGhlIGNvc3Qgb2YgY2hhbmdlZCBsaW5rIHdpbGwgYmUg YWRqdXN0ZWQgYW5kIGFkdmVydGlzZWQsIG1heWJlIG1vcmUgdGhhbiBvbmUgdGltZSwgdGhpcyBz ZXF1ZW5jZSB3aWxsIGJhc2Ugb24gc29tZSBwcmUtY2FsY3VsYXRpb25zLiBCdXQgaW4gUkZDIDY5 NzYsIGVhY2ggZGV2aWNlIHNob3VsZCBjYWxjdWxhdGUgdGhlIGRpc3RhbmNlIHdpdGggdGhlIGZh aWx1ZSBsaW5rLCBiYXNlIG9uIHRoaXMgZGlzdGFuY2UsIGVhY2ggZGV2aWNlIGRlY2lkZSB3aGVu IHRoZSBGSUIgd2lsbCBiZSB1cGRhdGVkLg0KPiANCj4gLS0tLS0/Pz8/LS0tLS0NCj4gPz8/OiBB Y2VlIExpbmRlbSBbbWFpbHRvOmFjZWUubGluZGVtQGVyaWNzc29uLmNvbV0gDQo+ID8/Pz86IDIw MTM/MTA/MjE/IDEwOjA3DQo+ID8/PzogWWFuZ2FuZw0KPiA/PzogcnRnd2dAaWV0Zi5vcmc7IFpo YW5neHVkb25nICh6aGFuZ3h1ZG9uZywgVlJQKQ0KPiA/PzogUmU6IFNvbGljaXRpbmcgV0cgZmVl ZGJhY2sgYW5kIGNvbW1lbnRzIG9uIGRyYWZ0LXp4ZC1ydGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1 c3RtZW50LTAwDQo+IA0KPiBDYW4geW91IGNvbnRyYXN0IHRoaXMgd2l0aCBSRkMgNjk3Nj8gWW91 IGluY2x1ZGUgUkZDIDY5NzYgaW4gdGhlIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIGJ1dCBpdCBpcyBu ZXZlciByZWZlcmVuY2VkICh0aGlzIHdpbGwgc2hvdyB1cCBpZiB5b3UgcnVuIGlkbml0cykuIA0K PiBBY2VlIA0KPiBPbiBPY3QgMjAsIDIwMTMsIGF0IDk6NDkgUE0sIFlhbmdhbmcgd3JvdGU6DQo+ IA0KPj4gSGk6DQo+PiANCj4+IFdlIGhhZCBzdWJtaXR0ZWQgdGhlIGEgbmV3IGRyYWZ0OiBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRq dXN0bWVudC0wMCwgd2Ugd2FudCB0byBkaXNjdXNzIHRoZSBtaWNyby1sb29wIHByb2JsZW0gdGhy b3VnaCBhbm90aGVyIG1ldGhvZC4gWW91ciBmZWVkYmFjayBhbmQgY29tbWVudHMgb24gdGhlIHJ0 Z3dnIG1haWxpbmcgbGlzdCBhcmUgYXBwcmVjaWF0ZWQuIA0KPj4gDQo+PiBUaGFua3MsDQo+PiBS YWh1bC5ZYW4NCj4+IA0KPj4gLS0tLS0/Pz8/LS0tLS0NCj4+ID8/PzogaW50ZXJuZXQtZHJhZnRz QGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCj4+ID8/Pz86IDIw MTM/MTA/MTg/IDE1OjQ3DQo+PiA/Pz86IFpoYW5neHVkb25nICh6aGFuZ3h1ZG9uZywgVlJQKTsg WWFuZ2FuZw0KPj4gPz86IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtenhkLXJ0 Z3dnLW9yZGVyZWQtbWV0cmljLWFkanVzdG1lbnQtMDAudHh0DQo+PiANCj4+IA0KPj4gQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXp4ZC1ydGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50 LTAwLnR4dA0KPj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBYdWRvbmcgWmhh bmcgYW5kIHBvc3RlZCB0byB0aGUNCj4+IElFVEYgcmVwb3NpdG9yeS4NCj4+IA0KPj4gRmlsZW5h bWU6CSBkcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudA0KPj4gUmV2aXNp b246CSAwMA0KPj4gVGl0bGU6CQkgQWxnb3JpdGhtIGZvciBPcmRlcmVkIE1ldHJpYyBBZGp1c3Rt ZW50DQo+PiBDcmVhdGlvbiBkYXRlOgkgMjAxMy0xMC0xOA0KPj4gR3JvdXA6CQkgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQo+PiBOdW1iZXIgb2YgcGFnZXM6IDEwDQo+PiBVUkw6ICAgICAgICAgICAg IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXp4ZC1ydGd3Zy1vcmRl cmVkLW1ldHJpYy1hZGp1c3RtZW50LTAwLnR4dA0KPj4gU3RhdHVzOiAgICAgICAgICBodHRwOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXp4ZC1ydGd3Zy1vcmRlcmVkLW1ldHJpYy1h ZGp1c3RtZW50DQo+PiBIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXp4ZC1ydGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50LTAwDQo+PiANCj4+IA0K Pj4gQWJzdHJhY3Q6DQo+PiAgVXBvbiBsaW5rIGRvd24gZXZlbnQgb3IgbGluayB1cCBldmVudCwg ZWFjaCBkZXZpY2UgaW4gbmV0d29yaw0KPj4gIGluZGl2aWR1YWxseSBzY2hlZHVsZXMgcm91dGUg Y2FsY3VsYXRpb24uICBCZWNhdXNlIG9mIGRpZmZlcmVudA0KPj4gIGhhcmR3YXJlIGNhcGFiaWxp dGllcyBhbmQgaW50ZXJuYWwvZXh0ZXJuYWwgZW52aXJvbm1lbnRzLCB0aGUgdGltZSB0bw0KPj4g IHVwZGF0ZSBmb3J3YXJkaW5nIGVudHJpZXMgb24gdGhlc2UgZGV2aWNlcyBhcmUgZGlzb3JkZXJl ZCB3aGljaCBjYW4NCj4+ICBjYXVzZSBhIHRyYW5zaWVudCBmb3J3YXJkaW5nIGxvb3AuICBUaGlz IGRvY3VtZW50IGludHJvZHVjZXMgYSBtZXRob2QNCj4+ICB0byBwcmV2ZW50IGZvcndhcmRpbmcg bG9vcCBieSBhZGp1c3RpbmcgbGluayBtZXRyaWMgZ3JhZHVhbGx5IGZvcg0KPj4gIHNldmVyYWwg dGltZXMuDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBt YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0K Pj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0 b29scy5pZXRmLm9yZy4NCj4+IA0KPj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4+IA0KPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHJ0Z3dnIG1h aWxpbmcgbGlzdA0KPj4gcnRnd2dAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcnRnd2cNCj4gDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQoNCk1lc3NhZ2U6IDQNCkRhdGU6IFR1ZSwgMjIgT2N0IDIwMTMgMTA6MjA6MTEgKzAxMDAN CkZyb206IE1pa2UgU2hhbmQgPGltYy5zaGFuZEBnbWFpbC5jb20+DQpUbzogcnRnd2dAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiA/PzogPz86IFNvbGljaXRpbmcgV0cgZmVlZGJhY2sgYW5kIGNvbW1l bnRzIG9uDQoJZHJhZnQtenhkLXJ0Z3dnLW9yZGVyZWQtbWV0cmljLWFkanVzdG1lbnQtMDANCk1l c3NhZ2UtSUQ6IDw1MjY2NDM0Qi40MDUwMzA5QGdtYWlsLmNvbT4NCkNvbnRlbnQtVHlwZTogdGV4 dC9wbGFpbjsgY2hhcnNldD1VVEYtODsgZm9ybWF0PWZsb3dlZA0KDQpTbyB5b3UgaGF2ZSBkZXNj cmliZWQgdGhlIGRpZmZlcmVuY2Ugd2l0aCBPRklCIChSRkMgNjk3NiksIGJ1dCBob3cgZG9lcyAN CnlvdXIgcHJvcG9zYWwgZGlmZmVyIGZyb20gImluY3JlbWVudGFsIGNvc3QgYWR2ZXJ0aXNlbWVu dCIgYXMgZGVzY3JpYmVkIA0KaW4gUkZDIDU3MTUgc2VjdGlvbiA2LjE/DQoNCk1pa2UNCg0KDQoN Ck9uIDIyLzEwLzIwMTMgMDQ6MzksIFlhbmdhbmcgd3JvdGU6DQo+IE9LLCBJIGdvdCBpdC4NCj4N Cj4gQWN0dWFsbHksIHdlIHBheSBhdHRlbnRpb24gdG8gdHdvIHBvaW50Og0KPg0KPiAxLiBXaGlj aCBtZXRob2Qgd2lsbCBiZSBtb3JlIG5pY2V0eT8gSW4gUkZDNjk3NiwgYWxsIGRldmljZXMgaW4g bmV0d29yayBuZWVkIGNhbGN1bGF0ZSB0aGUgc2NoZWR1bGUgdGltZSwgYmFzZSBvbiB0aGUgZGlm ZmVyZW50IGhhcmR3YXJlIGFuZCBlbnZpcm9ubWVudCwgd2Ugd29ycnkgYWJvdXQgaXRzIGVmZmVj dC4gSW4gb3VyIGRyYWZ0LCBvbmx5IGZhaWx1cmUgcG9pbnQgYWRqdXN0IHRoZSBjb3N0LCB0aGUg b3RoZXIgZGV2aWNlIGp1c3QgcmVzcG9uc2UgdGhlIGNvc3QgY2hhbmdlLiBJIHRoaW5rIHRoZSBl ZmZlY3Qgb2YgdGhpcyBraW5kIG9mIGRpZmZlcmVuY2Ugd2lsbCBiZSBsZXNzLg0KPg0KPiAyLiBE dWUgdG8gbm8gbmV3IGV4dGVuc2lvbiwgbWF5YmUgdGhlIGRpc3RyaWJ1dGlvbiB3aWxsIGJlIG1v cmUgc21vb3RobHkuDQo+DQo+IC0tLS0tPz8/Py0tLS0tDQo+ID8/PzogQWNlZSBMaW5kZW0gW21h aWx0bzphY2VlLmxpbmRlbUBlcmljc3Nvbi5jb21dDQo+ID8/Pz86IDIwMTM/MTA/MjI/IDk6NDIN Cj4gPz8/OiBZYW5nYW5nDQo+ID8/OiBydGd3Z0BpZXRmLm9yZzsgWmhhbmd4dWRvbmcgKHpoYW5n eHVkb25nLCBWUlApDQo+ID8/OiBSZTogPz86IFNvbGljaXRpbmcgV0cgZmVlZGJhY2sgYW5kIGNv bW1lbnRzIG9uIGRyYWZ0LXp4ZC1ydGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50LTAwDQo+ DQo+IEknbSBhd2FyZSBvZiB0aGUgYmFzaWMgcHJlbWlzZSBvZiB0aGUgdHdvIGRyYWZ0cyBhbmQg d2FzIG5vdCBhc2tpbmcgZm9yIHlvdSB0byByZXN0YXRlIHRoZSBvYnZpb3VzLiBTcGVjaWZpY2Fs bHksIHdoYXQgYXJlIHRoZSBiZW5lZml0cyBhbmQgZGV0ZXJtZW50cyBvZiB5b3VyIGRyYWZ0IHdo ZW4gY29tcGFyZWQgdG8gUkZDIDY5NzY/DQo+IEFjZWUNCj4NCj4gT24gT2N0IDIxLCAyMDEzLCBh dCA5OjMwIFBNLCBZYW5nYW5nIHdyb3RlOg0KPg0KPj4gT3VyIGRyYWZ0IGlzIHNpbWlsYXIgd2l0 aCBzZWN0aW9uIDYuMSBpbiBSRkM1NzE1LCB0aGUgY29zdCBvZiBjaGFuZ2VkIGxpbmsgd2lsbCBi ZSBhZGp1c3RlZCBhbmQgYWR2ZXJ0aXNlZCwgbWF5YmUgbW9yZSB0aGFuIG9uZSB0aW1lLCB0aGlz IHNlcXVlbmNlIHdpbGwgYmFzZSBvbiBzb21lIHByZS1jYWxjdWxhdGlvbnMuIEJ1dCBpbiBSRkMg Njk3NiwgZWFjaCBkZXZpY2Ugc2hvdWxkIGNhbGN1bGF0ZSB0aGUgZGlzdGFuY2Ugd2l0aCB0aGUg ZmFpbHVlIGxpbmssIGJhc2Ugb24gdGhpcyBkaXN0YW5jZSwgZWFjaCBkZXZpY2UgZGVjaWRlIHdo ZW4gdGhlIEZJQiB3aWxsIGJlIHVwZGF0ZWQuDQo+Pg0KPj4gLS0tLS0/Pz8/LS0tLS0NCj4+ID8/ PzogQWNlZSBMaW5kZW0gW21haWx0bzphY2VlLmxpbmRlbUBlcmljc3Nvbi5jb21dDQo+PiA/Pz8/ OiAyMDEzPzEwPzIxPyAxMDowNw0KPj4gPz8/OiBZYW5nYW5nDQo+PiA/PzogcnRnd2dAaWV0Zi5v cmc7IFpoYW5neHVkb25nICh6aGFuZ3h1ZG9uZywgVlJQKQ0KPj4gPz86IFJlOiBTb2xpY2l0aW5n IFdHIGZlZWRiYWNrIGFuZCBjb21tZW50cyBvbiBkcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRy aWMtYWRqdXN0bWVudC0wMA0KPj4NCj4+IENhbiB5b3UgY29udHJhc3QgdGhpcyB3aXRoIFJGQyA2 OTc2PyBZb3UgaW5jbHVkZSBSRkMgNjk3NiBpbiB0aGUgTm9ybWF0aXZlIFJlZmVyZW5jZXMgYnV0 IGl0IGlzIG5ldmVyIHJlZmVyZW5jZWQgKHRoaXMgd2lsbCBzaG93IHVwIGlmIHlvdSBydW4gaWRu aXRzKS4NCj4+IEFjZWUNCj4+IE9uIE9jdCAyMCwgMjAxMywgYXQgOTo0OSBQTSwgWWFuZ2FuZyB3 cm90ZToNCj4+DQo+Pj4gSGk6DQo+Pj4NCj4+PiBXZSBoYWQgc3VibWl0dGVkIHRoZSBhIG5ldyBk cmFmdDogaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtenhkLXJ0Z3dnLW9yZGVyZWQt bWV0cmljLWFkanVzdG1lbnQtMDAsIHdlIHdhbnQgdG8gZGlzY3VzcyB0aGUgbWljcm8tbG9vcCBw cm9ibGVtIHRocm91Z2ggYW5vdGhlciBtZXRob2QuIFlvdXIgZmVlZGJhY2sgYW5kIGNvbW1lbnRz IG9uIHRoZSBydGd3ZyBtYWlsaW5nIGxpc3QgYXJlIGFwcHJlY2lhdGVkLg0KPj4+DQo+Pj4gVGhh bmtzLA0KPj4+IFJhaHVsLllhbg0KPj4+DQo+Pj4gLS0tLS0/Pz8/LS0tLS0NCj4+PiA/Pz86IGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10N Cj4+PiA/Pz8/OiAyMDEzPzEwPzE4PyAxNTo0Nw0KPj4+ID8/PzogWmhhbmd4dWRvbmcgKHpoYW5n eHVkb25nLCBWUlApOyBZYW5nYW5nDQo+Pj4gPz86IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtenhkLXJ0Z3dnLW9yZGVyZWQtbWV0cmljLWFkanVzdG1lbnQtMDAudHh0DQo+Pj4N Cj4+Pg0KPj4+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1t ZXRyaWMtYWRqdXN0bWVudC0wMC50eHQNCj4+PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IFh1ZG9uZyBaaGFuZyBhbmQgcG9zdGVkIHRvIHRoZQ0KPj4+IElFVEYgcmVwb3NpdG9y eS4NCj4+Pg0KPj4+IEZpbGVuYW1lOgkgZHJhZnQtenhkLXJ0Z3dnLW9yZGVyZWQtbWV0cmljLWFk anVzdG1lbnQNCj4+PiBSZXZpc2lvbjoJIDAwDQo+Pj4gVGl0bGU6CQkgQWxnb3JpdGhtIGZvciBP cmRlcmVkIE1ldHJpYyBBZGp1c3RtZW50DQo+Pj4gQ3JlYXRpb24gZGF0ZToJIDIwMTMtMTAtMTgN Cj4+PiBHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4+PiBOdW1iZXIgb2YgcGFnZXM6 IDEwDQo+Pj4gVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0wMC50eHQNCj4+ PiBTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt enhkLXJ0Z3dnLW9yZGVyZWQtbWV0cmljLWFkanVzdG1lbnQNCj4+PiBIdG1saXplZDogICAgICAg IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXp4ZC1ydGd3Zy1vcmRlcmVkLW1ldHJp Yy1hZGp1c3RtZW50LTAwDQo+Pj4NCj4+Pg0KPj4+IEFic3RyYWN0Og0KPj4+ICAgVXBvbiBsaW5r IGRvd24gZXZlbnQgb3IgbGluayB1cCBldmVudCwgZWFjaCBkZXZpY2UgaW4gbmV0d29yaw0KPj4+ ICAgaW5kaXZpZHVhbGx5IHNjaGVkdWxlcyByb3V0ZSBjYWxjdWxhdGlvbi4gIEJlY2F1c2Ugb2Yg ZGlmZmVyZW50DQo+Pj4gICBoYXJkd2FyZSBjYXBhYmlsaXRpZXMgYW5kIGludGVybmFsL2V4dGVy bmFsIGVudmlyb25tZW50cywgdGhlIHRpbWUgdG8NCj4+PiAgIHVwZGF0ZSBmb3J3YXJkaW5nIGVu dHJpZXMgb24gdGhlc2UgZGV2aWNlcyBhcmUgZGlzb3JkZXJlZCB3aGljaCBjYW4NCj4+PiAgIGNh dXNlIGEgdHJhbnNpZW50IGZvcndhcmRpbmcgbG9vcC4gIFRoaXMgZG9jdW1lbnQgaW50cm9kdWNl cyBhIG1ldGhvZA0KPj4+ICAgdG8gcHJldmVudCBmb3J3YXJkaW5nIGxvb3AgYnkgYWRqdXN0aW5n IGxpbmsgbWV0cmljIGdyYWR1YWxseSBmb3INCj4+PiAgIHNldmVyYWwgdGltZXMuDQo+Pj4NCj4+ Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4+PiB1bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3Jn Lg0KPj4+DQo+Pj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4+Pg0KPj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gcnRnd2cgbWFpbGluZyBsaXN0 DQo+Pj4gcnRnd2dAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3J0Z3dnDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IHJ0Z3dnIG1haWxpbmcgbGlzdA0KPiBydGd3Z0BpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Z3dnDQoNCg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCnJ0Z3dnIG1haWxpbmcgbGlzdA0KcnRnd2dAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnd2cNCg0KDQpFbmQgb2YgcnRnd2cgRGln ZXN0LCBWb2wgMTA2LCBJc3N1ZSAzNw0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioNCg== From stephane.litkowski@orange.com Wed Oct 23 04:54:25 2013 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 BD4AC11E839E for ; Wed, 23 Oct 2013 04:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRhKHffk2NcB for ; Wed, 23 Oct 2013 04:54:21 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 30A4311E82CA for ; Wed, 23 Oct 2013 04:54:20 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 61D8F2648A6; Wed, 23 Oct 2013 13:54:19 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 4515B27C0F8; Wed, 23 Oct 2013 13:54:19 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.46]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Wed, 23 Oct 2013 13:54:19 +0200 From: To: Mike Shand , "rtgwg@ietf.org" Date: Wed, 23 Oct 2013 13:54:17 +0200 Subject: =?utf-8?B?UkU6IOetlOWkjTog562U5aSNOiBTb2xpY2l0aW5nIFdHIGZlZWRiYWNrIGFu?= =?utf-8?B?ZCBjb21tZW50cyBvbiBkcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXQ=?= =?utf-8?B?cmljLWFkanVzdG1lbnQtMDA=?= Thread-Topic: =?utf-8?B?562U5aSNOiDnrZTlpI06IFNvbGljaXRpbmcgV0cgZmVlZGJhY2sgYW5kIGNv?= =?utf-8?B?bW1lbnRzIG9uIGRyYWZ0LXp4ZC1ydGd3Zy1vcmRlcmVkLW1ldHJpYy1h?= =?utf-8?B?ZGp1c3RtZW50LTAw?= Thread-Index: Ac7PB/BIxUzgMQEgTeuWkcfklnRq5wA3pVJg Message-ID: <13379_1382529259_5267B8EB_13379_1342_1_EEE55384044474429A926C625D0FCC81098FE657CB@PUEXCB2F.nanterre.francetelecom.fr> References: <94A203EA12AECE4BA92D42DBFFE0AE470309F337@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47030A2579@eusaamb101.ericsson.se> <5266434B.4050309@gmail.com> In-Reply-To: <5266434B.4050309@gmail.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.82422 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, 23 Oct 2013 11:54:25 -0000 KzENCg0KRG9uJ3Qgc2VlIGFsc28gdGhlIGRpZmZlcmVuY2Ugd2l0aCBSRkMgNTcxNSBzZWN0aW9u IDYuMS4NCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBydGd3Zy1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86cnRnd2ctYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBN aWtlIFNoYW5kDQpFbnZvecOpwqA6IG1hcmRpIDIyIG9jdG9icmUgMjAxMyAxMToyMA0Kw4DCoDog cnRnd2dAaWV0Zi5vcmcNCk9iamV0wqA6IFJlOiDnrZTlpI06IOetlOWkjTogU29saWNpdGluZyBX RyBmZWVkYmFjayBhbmQgY29tbWVudHMgb24gZHJhZnQtenhkLXJ0Z3dnLW9yZGVyZWQtbWV0cmlj LWFkanVzdG1lbnQtMDANCg0KU28geW91IGhhdmUgZGVzY3JpYmVkIHRoZSBkaWZmZXJlbmNlIHdp dGggT0ZJQiAoUkZDIDY5NzYpLCBidXQgaG93IGRvZXMgeW91ciBwcm9wb3NhbCBkaWZmZXIgZnJv bSAiaW5jcmVtZW50YWwgY29zdCBhZHZlcnRpc2VtZW50IiBhcyBkZXNjcmliZWQgaW4gUkZDIDU3 MTUgc2VjdGlvbiA2LjE/DQoNCk1pa2UNCg0KDQoNCk9uIDIyLzEwLzIwMTMgMDQ6MzksIFlhbmdh bmcgd3JvdGU6DQo+IE9LLCBJIGdvdCBpdC4NCj4NCj4gQWN0dWFsbHksIHdlIHBheSBhdHRlbnRp b24gdG8gdHdvIHBvaW50Og0KPg0KPiAxLiBXaGljaCBtZXRob2Qgd2lsbCBiZSBtb3JlIG5pY2V0 eT8gSW4gUkZDNjk3NiwgYWxsIGRldmljZXMgaW4gbmV0d29yayBuZWVkIGNhbGN1bGF0ZSB0aGUg c2NoZWR1bGUgdGltZSwgYmFzZSBvbiB0aGUgZGlmZmVyZW50IGhhcmR3YXJlIGFuZCBlbnZpcm9u bWVudCwgd2Ugd29ycnkgYWJvdXQgaXRzIGVmZmVjdC4gSW4gb3VyIGRyYWZ0LCBvbmx5IGZhaWx1 cmUgcG9pbnQgYWRqdXN0IHRoZSBjb3N0LCB0aGUgb3RoZXIgZGV2aWNlIGp1c3QgcmVzcG9uc2Ug dGhlIGNvc3QgY2hhbmdlLiBJIHRoaW5rIHRoZSBlZmZlY3Qgb2YgdGhpcyBraW5kIG9mIGRpZmZl cmVuY2Ugd2lsbCBiZSBsZXNzLg0KPg0KPiAyLiBEdWUgdG8gbm8gbmV3IGV4dGVuc2lvbiwgbWF5 YmUgdGhlIGRpc3RyaWJ1dGlvbiB3aWxsIGJlIG1vcmUgc21vb3RobHkuDQo+DQo+IC0tLS0t6YKu 5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBBY2VlIExpbmRlbSBbbWFpbHRvOmFjZWUubGlu ZGVtQGVyaWNzc29uLmNvbV0NCj4g5Y+R6YCB5pe26Ze0OiAyMDEz5bm0MTDmnIgyMuaXpSA5OjQy DQo+IOaUtuS7tuS6ujogWWFuZ2FuZw0KPiDmioTpgIE6IHJ0Z3dnQGlldGYub3JnOyBaaGFuZ3h1 ZG9uZyAoemhhbmd4dWRvbmcsIFZSUCkNCj4g5Li76aKYOiBSZTog562U5aSNOiBTb2xpY2l0aW5n IFdHIGZlZWRiYWNrIGFuZCBjb21tZW50cyBvbiANCj4gZHJhZnQtenhkLXJ0Z3dnLW9yZGVyZWQt bWV0cmljLWFkanVzdG1lbnQtMDANCj4NCj4gSSdtIGF3YXJlIG9mIHRoZSBiYXNpYyBwcmVtaXNl IG9mIHRoZSB0d28gZHJhZnRzIGFuZCB3YXMgbm90IGFza2luZyBmb3IgeW91IHRvIHJlc3RhdGUg dGhlIG9idmlvdXMuIFNwZWNpZmljYWxseSwgd2hhdCBhcmUgdGhlIGJlbmVmaXRzIGFuZCBkZXRl cm1lbnRzIG9mIHlvdXIgZHJhZnQgd2hlbiBjb21wYXJlZCB0byBSRkMgNjk3Nj8NCj4gQWNlZQ0K Pg0KPiBPbiBPY3QgMjEsIDIwMTMsIGF0IDk6MzAgUE0sIFlhbmdhbmcgd3JvdGU6DQo+DQo+PiBP dXIgZHJhZnQgaXMgc2ltaWxhciB3aXRoIHNlY3Rpb24gNi4xIGluIFJGQzU3MTUsIHRoZSBjb3N0 IG9mIGNoYW5nZWQgbGluayB3aWxsIGJlIGFkanVzdGVkIGFuZCBhZHZlcnRpc2VkLCBtYXliZSBt b3JlIHRoYW4gb25lIHRpbWUsIHRoaXMgc2VxdWVuY2Ugd2lsbCBiYXNlIG9uIHNvbWUgcHJlLWNh bGN1bGF0aW9ucy4gQnV0IGluIFJGQyA2OTc2LCBlYWNoIGRldmljZSBzaG91bGQgY2FsY3VsYXRl IHRoZSBkaXN0YW5jZSB3aXRoIHRoZSBmYWlsdWUgbGluaywgYmFzZSBvbiB0aGlzIGRpc3RhbmNl LCBlYWNoIGRldmljZSBkZWNpZGUgd2hlbiB0aGUgRklCIHdpbGwgYmUgdXBkYXRlZC4NCj4+DQo+ PiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+PiDlj5Hku7bkuro6IEFjZWUgTGluZGVtIFttYWls dG86YWNlZS5saW5kZW1AZXJpY3Nzb24uY29tXQ0KPj4g5Y+R6YCB5pe26Ze0OiAyMDEz5bm0MTDm nIgyMeaXpSAxMDowNw0KPj4g5pS25Lu25Lq6OiBZYW5nYW5nDQo+PiDmioTpgIE6IHJ0Z3dnQGll dGYub3JnOyBaaGFuZ3h1ZG9uZyAoemhhbmd4dWRvbmcsIFZSUCkNCj4+IOS4u+mimDogUmU6IFNv bGljaXRpbmcgV0cgZmVlZGJhY2sgYW5kIGNvbW1lbnRzIG9uIA0KPj4gZHJhZnQtenhkLXJ0Z3dn LW9yZGVyZWQtbWV0cmljLWFkanVzdG1lbnQtMDANCj4+DQo+PiBDYW4geW91IGNvbnRyYXN0IHRo aXMgd2l0aCBSRkMgNjk3Nj8gWW91IGluY2x1ZGUgUkZDIDY5NzYgaW4gdGhlIE5vcm1hdGl2ZSBS ZWZlcmVuY2VzIGJ1dCBpdCBpcyBuZXZlciByZWZlcmVuY2VkICh0aGlzIHdpbGwgc2hvdyB1cCBp ZiB5b3UgcnVuIGlkbml0cykuDQo+PiBBY2VlDQo+PiBPbiBPY3QgMjAsIDIwMTMsIGF0IDk6NDkg UE0sIFlhbmdhbmcgd3JvdGU6DQo+Pg0KPj4+IEhpOg0KPj4+DQo+Pj4gV2UgaGFkIHN1Ym1pdHRl ZCB0aGUgYSBuZXcgZHJhZnQ6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXp4ZC1y dGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50LTAwLCB3ZSB3YW50IHRvIGRpc2N1c3MgdGhl IG1pY3JvLWxvb3AgcHJvYmxlbSB0aHJvdWdoIGFub3RoZXIgbWV0aG9kLiBZb3VyIGZlZWRiYWNr IGFuZCBjb21tZW50cyBvbiB0aGUgcnRnd2cgbWFpbGluZyBsaXN0IGFyZSBhcHByZWNpYXRlZC4N Cj4+Pg0KPj4+IFRoYW5rcywNCj4+PiBSYWh1bC5ZYW4NCj4+Pg0KPj4+IC0tLS0t6YKu5Lu25Y6f 5Lu2LS0tLS0NCj4+PiDlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4+PiDlj5HpgIHml7bpl7Q6IDIwMTPlubQxMOac iDE45pelIDE1OjQ3DQo+Pj4g5pS25Lu25Lq6OiBaaGFuZ3h1ZG9uZyAoemhhbmd4dWRvbmcsIFZS UCk7IFlhbmdhbmcNCj4+PiDkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+ Pj4gZHJhZnQtenhkLXJ0Z3dnLW9yZGVyZWQtbWV0cmljLWFkanVzdG1lbnQtMDAudHh0DQo+Pj4N Cj4+Pg0KPj4+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCANCj4+PiBkcmFmdC16eGQtcnRnd2ctb3Jk ZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0wMC50eHQNCj4+PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IFh1ZG9uZyBaaGFuZyBhbmQgcG9zdGVkIHRvIHRoZSANCj4+PiBJRVRGIHJl cG9zaXRvcnkuDQo+Pj4NCj4+PiBGaWxlbmFtZToJIGRyYWZ0LXp4ZC1ydGd3Zy1vcmRlcmVkLW1l dHJpYy1hZGp1c3RtZW50DQo+Pj4gUmV2aXNpb246CSAwMA0KPj4+IFRpdGxlOgkJIEFsZ29yaXRo bSBmb3IgT3JkZXJlZCBNZXRyaWMgQWRqdXN0bWVudA0KPj4+IENyZWF0aW9uIGRhdGU6CSAyMDEz LTEwLTE4DQo+Pj4gR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+Pj4gTnVtYmVyIG9m IHBhZ2VzOiAxMA0KPj4+IFVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtenhkLXJ0Z3dnLW9yZGVyZWQtbWV0cmljLWFkanVzdG1lbnQtMDAu dHh0DQo+Pj4gU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LXp4ZC1ydGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50DQo+Pj4gSHRtbGl6ZWQ6 ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16eGQtcnRnd2ctb3JkZXJl ZC1tZXRyaWMtYWRqdXN0bWVudC0wMA0KPj4+DQo+Pj4NCj4+PiBBYnN0cmFjdDoNCj4+PiAgIFVw b24gbGluayBkb3duIGV2ZW50IG9yIGxpbmsgdXAgZXZlbnQsIGVhY2ggZGV2aWNlIGluIG5ldHdv cmsNCj4+PiAgIGluZGl2aWR1YWxseSBzY2hlZHVsZXMgcm91dGUgY2FsY3VsYXRpb24uICBCZWNh dXNlIG9mIGRpZmZlcmVudA0KPj4+ICAgaGFyZHdhcmUgY2FwYWJpbGl0aWVzIGFuZCBpbnRlcm5h bC9leHRlcm5hbCBlbnZpcm9ubWVudHMsIHRoZSB0aW1lIHRvDQo+Pj4gICB1cGRhdGUgZm9yd2Fy ZGluZyBlbnRyaWVzIG9uIHRoZXNlIGRldmljZXMgYXJlIGRpc29yZGVyZWQgd2hpY2ggY2FuDQo+ Pj4gICBjYXVzZSBhIHRyYW5zaWVudCBmb3J3YXJkaW5nIGxvb3AuICBUaGlzIGRvY3VtZW50IGlu dHJvZHVjZXMgYSBtZXRob2QNCj4+PiAgIHRvIHByZXZlbnQgZm9yd2FyZGluZyBsb29wIGJ5IGFk anVzdGluZyBsaW5rIG1ldHJpYyBncmFkdWFsbHkgZm9yDQo+Pj4gICBzZXZlcmFsIHRpbWVzLg0K Pj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiANCj4+PiBzdWJtaXNzaW9uIHVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu aWV0Zi5vcmcuDQo+Pj4NCj4+PiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPj4+DQo+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBydGd3ZyBtYWls aW5nIGxpc3QNCj4+PiBydGd3Z0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcnRnd2cNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gcnRnd2cgbWFpbGluZyBsaXN0DQo+IHJ0Z3dnQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnd2cNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Z3dnIG1haWxpbmcgbGlz dA0KcnRnd2dAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cnRnd2cNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50 IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVl cyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3Bp ZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVy cmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUg YWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVz cG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lm aWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVj dGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGll ZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBp cyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdl ZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From stephane.litkowski@orange.com Wed Oct 23 05:01:59 2013 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 38EC611E83BF for ; Wed, 23 Oct 2013 05:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycZUD0ye6g71 for ; Wed, 23 Oct 2013 05:01:55 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 080AF11E82CA for ; Wed, 23 Oct 2013 05:01:55 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 9967818C6D1; Wed, 23 Oct 2013 14:01:53 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 746274C116; Wed, 23 Oct 2013 14:01:50 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.46]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Wed, 23 Oct 2013 14:01:49 +0200 From: To: Yangang , "rtgwg@ietf.org" Date: Wed, 23 Oct 2013 14:01:48 +0200 Subject: RE: Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00 Thread-Topic: Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00 Thread-Index: AQHOzf/GzJU1wXMyskyzrVWgwEKZ4ZoCMhng Message-ID: <16236_1382529710_5267BAAE_16236_1925_1_EEE55384044474429A926C625D0FCC81098FE657D2@PUEXCB2F.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.82422 Cc: "Zhangxudong \(zhangxudong, VRP\)" 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, 23 Oct 2013 12:01:59 -0000 SGksDQoNCkkgd291bGQgbmVlZCBtb3JlIHRpbWUgdG8gcmV2aWV3IHlvdXIgYWxnbyBwYXJ0LiBC dXQgYW55d2F5LCBjb3VsZCB5b3UgZXhwbGFpbiB0aGUgZGlmZmVyZW5jZSB3aXRoIHNvbWUgb2xk IHB1YmxpYyBhcHByb2FjaCBsaWtlIHRoZSBwYXBlciBmcm9tIFBpZXJyZSwgTWlrZSBhbmQgT2xp dmllciA6ICBodHRwOi8vY2l0ZXNlZXJ4LmlzdC5wc3UuZWR1L3ZpZXdkb2MvZG93bmxvYWQ/ZG9p PTEwLjEuMS42Ny44MjYzJnJlcD1yZXAxJnR5cGU9cGRmDQoNCk1vcmVvdmVyIEkgd291bGQgYmUg aW50ZXJlc3RlZCB0byBzZWUgaW4geW91ciBkcmFmdCBzb21lIHNpbXVsYXRpb24gcHJvdmluZyB0 aGUgbWV0cmljIGxpc3QgaXMgcXVpdGUgbG93IC4uLg0KSSBjYW4gcmVtZW1iZXIgaW4gdGhlIHBh cGVyIEknbSByZWZlcmVuY2luZyB0aGF0IHRoZSBjaGFsbGVuZ2Ugd2FzIHRvIGNvbXByZXNzIHRo ZSBLTVMgbGlzdCBpbiBvcmRlciB0byBwcmV2ZW50IGEgdmVyeSB2ZXJ5IGxvbmcgbGlzdCB3aGlj aCB3b3VsZCBub3QgYmUgYXBwbGljYWJsZSBpbiBhIGxpdmUgbmV0d29yay4NCg0KVGhhbmtzDQoN ClN0ZXBoYW5lDQoNCg0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IHJ0Z3dn LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGd3Zy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBw YXJ0IGRlIFlhbmdhbmcNCkVudm95w6nCoDogbHVuZGkgMjEgb2N0b2JyZSAyMDEzIDAzOjQ5DQrD gMKgOiBydGd3Z0BpZXRmLm9yZw0KQ2PCoDogWmhhbmd4dWRvbmcgKHpoYW5neHVkb25nLCBWUlAp OyBZYW5nYW5nDQpPYmpldMKgOiBTb2xpY2l0aW5nIFdHIGZlZWRiYWNrIGFuZCBjb21tZW50cyBv biBkcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0wMA0KDQpIaToNCg0K V2UgaGFkIHN1Ym1pdHRlZCB0aGUgYSBuZXcgZHJhZnQ6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXp4ZC1ydGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50LTAwLCB3ZSB3YW50 IHRvIGRpc2N1c3MgdGhlIG1pY3JvLWxvb3AgcHJvYmxlbSB0aHJvdWdoIGFub3RoZXIgbWV0aG9k LiBZb3VyIGZlZWRiYWNrIGFuZCBjb21tZW50cyBvbiB0aGUgcnRnd2cgbWFpbGluZyBsaXN0IGFy ZSBhcHByZWNpYXRlZC4gDQoNClRoYW5rcywNClJhaHVsLllhbg0KDQotLS0tLemCruS7tuWOn+S7 ti0tLS0tDQrlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQrlj5HpgIHml7bpl7Q6IDIwMTPlubQxMOaciDE45pelIDE1 OjQ3DQrmlLbku7bkuro6IFpoYW5neHVkb25nICh6aGFuZ3h1ZG9uZywgVlJQKTsgWWFuZ2FuZw0K 5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXp4ZC1ydGd3Zy1vcmRl cmVkLW1ldHJpYy1hZGp1c3RtZW50LTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0wMC50eHQNCmhhcyBiZWVu IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWHVkb25nIFpoYW5nIGFuZCBwb3N0ZWQgdG8gdGhl DQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtenhkLXJ0Z3dnLW9yZGVyZWQt bWV0cmljLWFkanVzdG1lbnQNClJldmlzaW9uOgkgMDANClRpdGxlOgkJIEFsZ29yaXRobSBmb3Ig T3JkZXJlZCBNZXRyaWMgQWRqdXN0bWVudA0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMTAtMTgNCkdy b3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxMA0KVVJMOiAg ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16eGQt cnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0wMC50eHQNClN0YXR1czogICAgICAgICAg aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1t ZXRyaWMtYWRqdXN0bWVudA0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0wMA0KDQoNCkFi c3RyYWN0Og0KICAgVXBvbiBsaW5rIGRvd24gZXZlbnQgb3IgbGluayB1cCBldmVudCwgZWFjaCBk ZXZpY2UgaW4gbmV0d29yaw0KICAgaW5kaXZpZHVhbGx5IHNjaGVkdWxlcyByb3V0ZSBjYWxjdWxh dGlvbi4gIEJlY2F1c2Ugb2YgZGlmZmVyZW50DQogICBoYXJkd2FyZSBjYXBhYmlsaXRpZXMgYW5k IGludGVybmFsL2V4dGVybmFsIGVudmlyb25tZW50cywgdGhlIHRpbWUgdG8NCiAgIHVwZGF0ZSBm b3J3YXJkaW5nIGVudHJpZXMgb24gdGhlc2UgZGV2aWNlcyBhcmUgZGlzb3JkZXJlZCB3aGljaCBj YW4NCiAgIGNhdXNlIGEgdHJhbnNpZW50IGZvcndhcmRpbmcgbG9vcC4gIFRoaXMgZG9jdW1lbnQg aW50cm9kdWNlcyBhIG1ldGhvZA0KICAgdG8gcHJldmVudCBmb3J3YXJkaW5nIGxvb3AgYnkgYWRq dXN0aW5nIGxpbmsgbWV0cmljIGdyYWR1YWxseSBmb3INCiAgIHNldmVyYWwgdGltZXMuDQoNCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0 Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpydGd3ZyBtYWlsaW5nIGxpc3QNCnJ0Z3dnQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Z3dnDQoKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMg aW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVu dCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jp c2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6 IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMg cGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRp YmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNp IGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBv ciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRo ZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRo b3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBm b3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk LgpUaGFuayB5b3UuCgo= From swatkatzin@gmail.com Tue Oct 22 11:25:48 2013 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 E094A11E8178 for ; Tue, 22 Oct 2013 11:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id la0Ig-SXx52C for ; Tue, 22 Oct 2013 11:25:48 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id CA5BE11E8142 for ; Tue, 22 Oct 2013 11:25:46 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id gq1so3749202obb.17 for ; Tue, 22 Oct 2013 11:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+6meOjNwbQa+oDpI1ekue71p5nOLwdz0Ue78QWamWt4=; b=zPPiTZJU2Dv5ThmS7txNR1yLF4d5/gtgd9S3nv4WUXTiJmAGh6D3c/Ttayqfugx8Dr 5jC7ANL2JE/zMP9ioYn4YRbcDAixxhjjRVtOKZDTnCUEOxwHN/LhPWYguRf1GyI/nNr/ C2qRiraUzY8pfMladHJU6l+TurH0czt0mywBwLmzcDrUwlTWREw1AFEvcdwkK/zv5i1I iibLYDuqbor8OodOHLRXUSDZ+CCs0c8H+mHfkVp6V8H2z2zSNJVyx4CQzcV2HTA9ayRX SNXDMc9hAM/pIxHro3JH2GEYZKdhYuQIw/VZle6bBu75HxTNNbD2/on456Vunj67t2qV fuuA== MIME-Version: 1.0 X-Received: by 10.182.81.65 with SMTP id y1mr699040obx.89.1382466346289; Tue, 22 Oct 2013 11:25:46 -0700 (PDT) Sender: swatkatzin@gmail.com Received: by 10.182.243.129 with HTTP; Tue, 22 Oct 2013 11:25:46 -0700 (PDT) In-Reply-To: <57307add47454f4387509d21380d4464@DM2PR05MB528.namprd05.prod.outlook.com> References: <57307add47454f4387509d21380d4464@DM2PR05MB528.namprd05.prod.outlook.com> Date: Tue, 22 Oct 2013 11:25:46 -0700 X-Google-Sender-Auth: ItdxybjLWTeEQvGSvkY_cz9QI24 Message-ID: Subject: Re: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algorithm From: Abishek Gopalan To: Chris Bowers Content-Type: multipart/alternative; boundary=047d7b2e4d327c109404e9588784 X-Mailman-Approved-At: Wed, 23 Oct 2013 08:13:58 -0700 Cc: "rtgwg@ietf.org" , Alia Atlas , "draft-enyedi-rtgwg-mrt-frr-algorithm@tools.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, 22 Oct 2013 22:32:44 -0000 --047d7b2e4d327c109404e9588784 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I am not aware of any IPR cliams on draft-enyedi-rtgwg-mrt-algorithm-04 either. Thanks, Abishek On Tue, Oct 22, 2013 at 10:39 AM, Chris Bowers wrote: > I don=92t know of any IPR claims by Juniper on > draft-enyedi-rtgwg-mrt-algorithm-04, either.**** > > ** ** > > Chris**** > > ** ** > > *From:* Alia Atlas [mailto:akatlas@juniper.net] > *Sent:* Tuesday, October 22, 2013 12:34 PM > *To:* Alvaro Retana (aretana); > draft-enyedi-rtgwg-mrt-frr-algorithm@tools.ietf.org > > *Cc:* rtgwg@ietf.org > *Subject:* Re: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algorithm= * > *** > > ** ** > > Sorry! I don't believe that I know of any IPR claims by Juniper on > draft-enyedi-rtgwg-mrt-algorithm-04, but I can't speak for Gabor or Andra= s > as far as their IPR goes. **** > > ** ** > > Alia**** > > > > > -------- Original message -------- > From: "Alvaro Retana (aretana)" > Date: 10/22/2013 1:23 PM (GMT-05:00) > To: draft-enyedi-rtgwg-mrt-frr-algorithm@tools.ietf.org > Cc: rtgwg@ietf.org > Subject: Re: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algorithm > > **** > > Ping!**** > > ** ** > > So far none of the authors have replied.**** > > ** ** > > Alvaro.**** > > ** ** > > On 10/8/13 2:28 PM, "Alvaro Retana (aretana)" wrote:*= * > ** > > ** ** > > Hi!**** > > ** ** > > In parallel to the WG Adoption Call, I want to formally ask the authors > (no additional contributors are listed in the latest version of the draft= ) > to please respond to this message indicating whether or not you are aware > of any relevant IPR. The draft will not progress (pending the results of > the WG Adoption Call) until we have received a response from each author.= * > *** > > ** ** > > Thanks!**** > > ** ** > > Alvaro.**** > > --047d7b2e4d327c109404e9588784 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I am not aware of any IPR cliams on=A0draft-enyedi-rtgwg-mrt-algorithm-04 eit= her.

Thanks,
Abishek




On Tue, Oct 22, 2013 at 10:39 AM, Chris Bowers <cbo= wers@juniper.net> wrote:

I don=92t know of any IPR= claims by Juniper on draft-enyedi-rtgwg-mrt-algorithm-04, either.

=A0<= /p>

Chris

=A0<= /p>

From: Alia A= tlas [mailto:akatl= as@juniper.net]
Sent: Tuesday, October 22, 2013 12:34 PM
To: Alvaro Retana (aretana); draft-enyedi-rtgwg-mrt-fr= r-algorithm@tools.ietf.org


Cc: rtgwg@ietf.o= rg
Subject: Re: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algori= thm

=A0

Sorry! =A0I don't believe that I kn= ow of any IPR claims by Juniper on draft-enyedi-rtgwg-mrt-algorithm-04, but= I can't speak for Gabor or Andras as far as their IPR goes.

=A0

Alia




-------- Original message --------
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
Date: 10/22/2013 1:23 PM (GMT-05:00)
To: draft-enyedi-rtgwg-mrt-frr-algorithm@tools.ietf.org
Cc: rtgwg@ietf.org =
Subject: Re: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algorithm

Ping!

=A0

So far none of the authors have replied= .

=A0

Alvaro.

=A0

On 10/8/13 2:28 PM, "Alvaro Retana= (aretana)" <aretana@cisco.com> wrote:

=A0

Hi!

=A0

In parallel to the WG Adoption Call, I = want to formally ask the authors (no additional contributors are listed in = the latest version of the draft) to please respond to this message indicating whether or not you are aware of any relevant IP= R. =A0The draft will not progress (pending the results of the WG Adoption C= all) until we have received a response from each author.

=A0

Thanks!

=A0

Alvaro.


--047d7b2e4d327c109404e9588784-- From aretana@cisco.com Wed Oct 23 12:16:41 2013 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 D13B311E8210 for ; Wed, 23 Oct 2013 12:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pV789Xhl0KJE for ; Wed, 23 Oct 2013 12:16:37 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6D37711E8358 for ; Wed, 23 Oct 2013 12:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5630; q=dns/txt; s=iport; t=1382555793; x=1383765393; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=3hzv5Pq02kHn2RzsB3ZIBIYngJ3uj8sfMrvf3b2Ocdo=; b=R/Zo16T20MvjfVL7AI4ejkdiLng4CxADZ1adEPOAaXuA1pXwO3H8VLQA SggV8D+O8Jf7mv3T2hbslgumsWqXBOZQXO4FFGoMmjEcfK5GBEUxrwpBU yVwHDzXODfE6Hl1E45Onmy3PXyBm2nyFnIO5uxqQrliR2F2BaaIRmkxoZ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAEMgaFKtJV2Y/2dsb2JhbABZgkNEOFS+V4EuFnSCJwEEeRIBCBIQHTkUAw4CBAENBQgBh30NuyqPHS0EB4MfgQsDiQehCYMkgio X-IronPort-AV: E=Sophos;i="4.93,556,1378857600"; d="scan'208,217";a="275598082" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 23 Oct 2013 19:16:02 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9NJG2SE010495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Oct 2013 19:16:02 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.40]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Wed, 23 Oct 2013 14:16:02 -0500 From: "Alvaro Retana (aretana)" To: =?iso-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= , Alia Atlas , "draft-enyedi-rtgwg-mrt-frr-algorithm@tools.ietf.org" Subject: Re: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algorithm Thread-Topic: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algorithm Thread-Index: AQHOxFQejz6lsVRV/UKb2dqFz2SbTpoBHruA///yaqyAACyNKIABkwWA Date: Wed, 23 Oct 2013 19:16:02 +0000 Message-ID: In-Reply-To: <3nnp0tksa44ug1ke5bx53og3.1382472669658@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.7] Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94E396B86EBxmbalnx15ciscoc_" 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: Wed, 23 Oct 2013 19:16:42 -0000 --_000_BBD66FD99311804F80324E8139B3C94E396B86EBxmbalnx15ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 10/22/13 4:13 PM, "G=E1bor S=E1ndor Enyedi" > wrote: [WG Chair Hat Off] Gabor (and Andras, and Alia and Chris): I don't know about any IPR . . . his draft is only describing algorithms. It's interesting to me that there are IPR disclosures (from both Ericsson a= nd Juniper) attached to the architecture draft, but not to this draft. https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&document_= search=3Ddraft-ietf-rtgwg-mrt-frr-architecture I would have thought that the IPR would be attached here (in the algorithm = draft) since it provides the details of how the architecture can be impleme= nted. Given the discussion (in the thread where I made some comments to the algor= ithm draft) about where the limits of the algorithm vs the profile are, and= whether one is part of the other or not, it surprises me that no one has c= laimed any IPR on this draft: there seems to be significant leakage and ove= rlap between what's in the architecture and how the algorithm operates. I= n my mind, that either means that the claims over the architecture are very= narrow, or that something should be declared for the algorithm. It would be nice if you checked again about the overlap, or if you clarifie= d what specifically is covered in the architecture draft. Of concern to me= are the terms from Ericsson ("Reasonable and Non-Discriminatory License to= All Implementers with Possible Royalty/Fee."). I realize that it is out o= f the scope of the WG to talk about the applicability of terms, but this is= not the first time that this topic comes up; take a look at the minutes fr= om IETF 82: http://www.ietf.org/proceedings/82/minutes/rtgwg.txt Thanks! Alvaro. --_000_BBD66FD99311804F80324E8139B3C94E396B86EBxmbalnx15ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <23F51BF6E5C392428F534F07F0585CB6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 10/22/13 4:13 PM, "G=E1bor S=E1ndor Enyedi" <gabor.sandor.enyedi@ericsson.c= om> wrote:

[WG Chair Hat Off]

Gabor (and Andras, and Alia and Chris):
 
I do=
n't know about any IPR . . . his draft is only describing algorithms.
It's interesting to me that there are IPR disclosures (from both Erics= son and Juniper) attached to the architecture draft, but not to this draft.=



I would have thought that the IPR would be attached here (in the algor= ithm draft) since it provides the details of how the architecture can be im= plemented.

Given the discussion (in the thread where I made some comments to the = algorithm draft) about where the limits of the algorithm vs the profile are= , and whether one is part of the other or not, it surprises me that no one = has claimed any IPR on this draft: there seems to be significant leakage and overlap  between what's in = the architecture and how the algorithm operates.  In my mind, that eit= her means that the claims over the architecture are very narrow, or that something s= hould be declared for the algorithm.

It would be nice if you checked again about the overlap, or if you cla= rified what specifically is covered in the architecture draft.  Of con= cern to me are the terms from Ericsson ("Reasonable and Non-Discrimina= tory License to All Implementers with Possible Royalty/Fee.").  I realize that it is out of the scope of the WG= to talk about the applicability of terms, but this is not the first time t= hat this topic comes up; take a look at the minutes from IETF 82:  http://www.ie= tf.org/proceedings/82/minutes/rtgwg.txt

Thanks!

Alvaro.
--_000_BBD66FD99311804F80324E8139B3C94E396B86EBxmbalnx15ciscoc_-- From akatlas@gmail.com Wed Oct 23 12:28:47 2013 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 49DA811E8203 for ; Wed, 23 Oct 2013 12:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSIolGKw-GGe for ; Wed, 23 Oct 2013 12:28:46 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2676411E8213 for ; Wed, 23 Oct 2013 12:28:46 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id aq17so2123583iec.38 for ; Wed, 23 Oct 2013 12:28:45 -0700 (PDT) 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=1S/+FOmZRns84kzR2Lszvd2wT/oWOuzPmbTBet1xXTU=; b=ANp4imMgoQ1Yl0huBxIdAuhnH4stsAwB40J55NLK4ZSNgICpf7s1Ck7jVL1Dl6x8ao lrP7pS3RjZiIQUbhtBnjg/Sm+rxHH+GSZuKAlt3wTleqrNQftE/fkrOnjbQ1Ja63tWEo OF7GHFhDULwLS8nsHA3NN9yW8k/K7O3UrS+TLhKroxo1XUKFLYWEarNI3RoJQs+tm+Sy dsWxZ889K4YaIQdzNYQD/r03FqGIK6wuR26RN2WAbHL4xCUIlWfhMCRe9TPDtbVcnnux AU5dN75q1GuV0f50mRM5qHoDhP8QrCob1KA41EywFENysF5JLIyfwy81grhIeuu3McGW FIQA== MIME-Version: 1.0 X-Received: by 10.50.106.20 with SMTP id gq20mr2059629igb.36.1382556525711; Wed, 23 Oct 2013 12:28:45 -0700 (PDT) Received: by 10.64.78.72 with HTTP; Wed, 23 Oct 2013 12:28:45 -0700 (PDT) In-Reply-To: References: <3nnp0tksa44ug1ke5bx53og3.1382472669658@email.android.com> Date: Wed, 23 Oct 2013 15:28:45 -0400 Message-ID: Subject: Re: IRP Claims related to draft-enyedi-rtgwg-mrt-frr-algorithm From: Alia Atlas To: "Alvaro Retana (aretana)" Content-Type: multipart/alternative; boundary=047d7bea343498dab604e96d86b0 Cc: "draft-enyedi-rtgwg-mrt-frr-algorithm@tools.ietf.org" , Alia Atlas , "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, 23 Oct 2013 19:28:47 -0000 --047d7bea343498dab604e96d86b0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable [WG Chair Hat off] Hi Alvaro, To my knowledge, there are various IPR claims on the architecture draft. Obviously, people must read the various IPR claims andi make their own decisions. a) On using the MRT algorithm for fast-reroute with trying MRT-BLUE and going to MRT-RED if that fails. (Initial approach in the first versions of the draft). b) MRT forwarding encapsulations c) Partial deployment computations for MRT-FRR - but the part in the algorithm draft is just a simplification of the MRT algorithm so it can be called. d) Various multicast-related aspects. draft-enyedi-rtgwg-mrt-algorithm is based on Gabor's dissertation work. The extensions to that for computing which MRT to use for an alternate were developed jointly in the IETF context. I don't believe that (b), (c), or (d) apply to the algorithm draft. Andras and Gabor can answer more whether they think that (a) applies. Alia On Wed, Oct 23, 2013 at 3:16 PM, Alvaro Retana (aretana) wrote: > On 10/22/13 4:13 PM, "G=E1bor S=E1ndor Enyedi" < > gabor.sandor.enyedi@ericsson.com> wrote: > > [WG Chair Hat Off] > > Gabor (and Andras, and Alia and Chris): > > I don't know about any IPR . . . his draft is only describing algorithms. > > It's interesting to me that there are IPR disclosures (from both > Ericsson and Juniper) attached to the architecture draft, but not to this > draft. > > > https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&documen= t_search=3Ddraft-ietf-rtgwg-mrt-frr-architecture > > > I would have thought that the IPR would be attached here (in the > algorithm draft) since it provides the details of how the architecture ca= n > be implemented. > > Given the discussion (in the thread where I made some comments to the > algorithm draft) about where the limits of the algorithm vs the profile > are, and whether one is part of the other or not, it surprises me that no > one has claimed any IPR on this draft: there seems to be significant > leakage and overlap between what's in the architecture and how the > algorithm operates. In my mind, that either means that the claims over t= he > architecture are very narrow, or that something should be declared for > the algorithm. > > It would be nice if you checked again about the overlap, or if you > clarified what specifically is covered in the architecture draft. Of > concern to me are the terms from Ericsson ("Reasonable and > Non-Discriminatory License to All Implementers with Possible > Royalty/Fee."). I realize that it is out of the scope of the WG to talk > about the applicability of terms, but this is not the first time that thi= s > topic comes up; take a look at the minutes from IETF 82: > http://www.ietf.org/proceedings/82/minutes/rtgwg.txt > > Thanks! > > Alvaro. > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > > --047d7bea343498dab604e96d86b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
[WG Chair Hat off]

Hi Alvaro,
To my knowledge, there are various IPR claims on the archit= ecture draft. =A0Obviously, people must read the various
IPR clai= ms andi make their own decisions.

a) On using the MRT algorithm for fast-reroute with try= ing MRT-BLUE and going to MRT-RED if that fails. =A0(Initial approach
=
=A0 =A0 in the first versions of the draft).
b) MRT forwardi= ng encapsulations
c) Partial deployment computations for MRT-FRR - but the part in the a= lgorithm draft is just a simplification of the MRT algorithm
=A0 = =A0 so it can be called.
d) Various multicast-related aspects.

draft-enyedi-rtgwg-mrt-algorithm is based on Gabor'= s dissertation work. =A0The extensions to that for computing which MRT to u= se
for an alternate were developed jointly in the IETF context. = =A0

I don't believe that (b), (c), or (d) apply to the = algorithm draft. =A0Andras and Gabor can answer more whether they think tha= t (a)
applies.=A0

Alia


On Wed, Oct 23, 2013 at 3:16 PM, Alvaro = Retana (aretana) <aretana@cisco.com> wrote:
On 10/22/13 4:13 PM, "G=E1bor S=E1ndor Enyedi" <gabor.sandor= .enyedi@ericsson.com> wrote:

[WG Chair Hat Off]

Gabor (and Andras, and Alia and Chris):
 
I don't know about any IPR . . . his draft is only describing algorithm=
s.
It's interesting to me that there are IPR disclosures (from both E= ricsson and Juniper) attached to the architecture draft, but not to this dr= aft.



I would have thought that the IPR would be attached here (in the algor= ithm draft) since it provides the details of how the architecture can be im= plemented.

Given the discussion (in the thread where I made some comments to the = algorithm draft) about where the limits of the algorithm vs the profile are= , and whether one is part of the other or not, it surprises me that no one = has claimed any IPR on this draft: there seems to be significant leakage and overlap =A0between what's in= the architecture and how the algorithm operates. =A0In my mind, that eithe= r means that the claims over the architecture are very narrow, or that something shou= ld be declared for the algorithm.

It would be nice if you checked again about the overlap, or if you cla= rified what specifically is covered in the architecture draft. =A0Of concer= n to me are the terms from Ericsson ("Reasonable and Non-Discriminator= y License to All Implementers with Possible Royalty/Fee."). =A0I realize that it is out of the scope of the WG to= talk about the applicability of terms, but this is not the first time that= this topic comes up; take a look at the minutes from IETF 82: =A0http://www.ietf.org/proceedings/82/minutes/rtgwg.txt

Thanks!

Alvaro.

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


--047d7bea343498dab604e96d86b0-- From ietf-secretariat-reply@ietf.org Wed Oct 23 13:59:33 2013 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 0613311E8122 for ; Wed, 23 Oct 2013 13:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+ea5UVb1N8R for ; Wed, 23 Oct 2013 13:59:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7DD11E81F8 for ; Wed, 23 Oct 2013 13:59:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: rtgwg@ietf.org Subject: Milestones changed for rtgwg WG X-Test-IDTracker: no X-IETF-IDTracker: 4.81 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131023205931.28007.84819.idtracker@ietfa.amsl.com> Date: Wed, 23 Oct 2013 13:59:31 -0700 From: IETF Secretariat X-Mailman-Approved-At: Wed, 23 Oct 2013 14:33:12 -0700 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 20:59:33 -0000 Changed milestone "Submit IP Fast Re-Route Using Not-via Addresses to IESG for publication as Informational", resolved as "Done", added draft-ietf-rtgwg-ipfrr-notvia-addresses to milestone. Changed milestone "Submit Ordered FIB architecture to IESG for publication as Informational", resolved as "Done", added draft-ietf-rtgwg-ordered-fib to milestone. URL: http://datatracker.ietf.org/wg/rtgwg/charter/ From aretana@cisco.com Wed Oct 23 14:43:19 2013 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 6BE0911E8205 for ; Wed, 23 Oct 2013 14:43:19 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gpBHTyxcEKP for ; Wed, 23 Oct 2013 14:43:14 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 39C0F11E826F for ; Wed, 23 Oct 2013 14:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6161; q=dns/txt; s=iport; t=1382564589; x=1383774189; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=nknDA9GeMQsZ3sHbMIQrtAYaDe7KI1NkFfx9zvr0thg=; b=QRE2m0iZWPZmdO5WWxRpoc4yi0+DPjkPi4y7+D0kAiaVTuWI2MF2urLc ZqTCohf34474cbVvjCTFydJro175RBp67l/n3sS8Q2yPghf1RhrKBfe94 LfiKJGpCN3kffzCnRln8EghLCapVj85coDpjPVOK3+KrnqaFQoudBfKhW 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigGAEtCaFKtJXG//2dsb2JhbABZgkNEOFS+VoEuFm0HgicBBIELAQgiHTkUEQIEEwiHfg2ZVaFcBI8dLQuDH4ELA5QqlWaDJIIq X-IronPort-AV: E=Sophos;i="4.93,557,1378857600"; d="scan'208,217";a="272850259" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 23 Oct 2013 21:43:08 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9NLh8lS031640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 23 Oct 2013 21:43:08 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.40]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Wed, 23 Oct 2013 16:43:07 -0500 From: "Alvaro Retana (aretana)" To: "rtgwg@ietf.org" Subject: Re: IETF 88 Agenda Items Thread-Topic: IETF 88 Agenda Items Thread-Index: AQHOvu+xvvXhYYVgF0uuaDZky93MeJoDBJsA Date: Wed, 23 Oct 2013 21:43:07 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.7] Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94E396BA6FDxmbalnx15ciscoc_" 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: Wed, 23 Oct 2013 21:43:19 -0000 --_000_BBD66FD99311804F80324E8139B3C94E396BA6FDxmbalnx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! I just published the draft agenda here: https://datatracker.ietf.org/meeti= ng/88/agenda/rtgwg/ The revised agenda is due on Monday. Thanks! Alvaro. On 10/1/13 5:46 PM, "Alvaro Retana (aretana)" > wrote: Hi! As I'm sure many of you have noticed, the cut-off date for ID submission is= Oct/21 (for all drafts, including -00). You may have also noticed the fol= lowing dates related to WG agendas: 2013-10-23 (Wednesday): Draft Working Group agendas due 2013-10-28 (Monday): Revised Working Group agendas ..resulting in very little time between them. We have requested our usual slot for Vancouver (the preliminary agenda shou= ld come out later this week), and would like you to start thinking about ag= enda items. In order to avoid an avalanche of requests at the last possibl= e minute we want to set some ground rules ahead of time. Please send requests by Monday Oct/21 to be included in the Draft WG Agenda= . Note that the draft MUST have been published already to be considered. = See other considerations below. For a draft to be considered for the final WG agenda: 1. It MUST have been published already. 2. The authors SHOULD start a discussion on the list highlighting the ma= in points of the draft (don't just send a copy of the announcement and/or p= aste the abstract). We will prioritize existing WG items first, followed by work explicitly ide= ntified in the WG charter. For other new work, if time permits, we will sc= hedule it on a first-come basis with preference given to items for which th= ere has already been a discussion on the list. Thanks! Alvaro + Alia. --_000_BBD66FD99311804F80324E8139B3C94E396BA6FDxmbalnx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <8DCEC549E3782941BC0719A2E3E4C1E6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi!

I just published the draft agenda here:  https://datatracker.ietf.org/meeti= ng/88/agenda/rtgwg/

The revised agenda is due on Monday.

Thanks!

Alvaro.

On 10/1/13 5:46 PM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

Hi!
 
As I'm sure many of you have noticed= , the cut-off date for ID submission is Oct/21 (for all drafts, including -= 00).  You may have also noticed the following dates related to WG agen= das:
 
2013-10-23 (Wednesday): Draft Workin= g Group agendas due
2013-10-28 (Monday): Revised Working= Group agendas
 
..resulting in very little time betw= een them.
 
 
We have requested our usual slot for= Vancouver (the preliminary agenda should come out later this week), and wo= uld like you to start thinking about agenda items.  In order to avoid = an avalanche of requests at the last possible minute we want to set some ground rules ahead of time.

Please send requests by Monday Oct/2= 1 to be included in the Draft WG Agenda.  Note that the draft MUST hav= e been published already to be considered.  See other considerations b= elow.

For a draft to be considered for the= final WG agenda:
  1. It MUST have been published already.<= /font>
  2. The autho= rs SHOULD start a discussion on the list highlighting the main points of th= e draft (don't just send a copy of the announcement and/or paste the abstra= ct).

We will prioritize = existing WG items first, followed by work explicitly identified in the WG c= harter.  For other new work, if time permits, we will schedule it on a= first-come basis with preference given to items for which there has already been a discussion on the list.=
 
Thanks!
 
Alvaro + Alia.
 --_000_BBD66FD99311804F80324E8139B3C94E396BA6FDxmbalnx15ciscoc_-- From cbowers@juniper.net Wed Oct 23 15:12:28 2013 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 8551C11E8278 for ; Wed, 23 Oct 2013 15:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.848 X-Spam-Level: X-Spam-Status: No, score=-4.848 tagged_above=-999 required=5 tests=[AWL=1.750, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QW3Wx3REQJ9x for ; Wed, 23 Oct 2013 15:12:23 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4038F11E826C for ; Wed, 23 Oct 2013 15:12:23 -0700 (PDT) Received: from mail87-co9-R.bigfish.com (10.236.132.227) by CO9EHSOBE031.bigfish.com (10.236.130.94) with Microsoft SMTP Server id 14.1.225.22; Wed, 23 Oct 2013 22:12:22 +0000 Received: from mail87-co9 (localhost [127.0.0.1]) by mail87-co9-R.bigfish.com (Postfix) with ESMTP id 9E58A4C01DA; Wed, 23 Oct 2013 22:12:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VPS-29(zzbb2dI98dI9371I936eIc85fh103dKc25dLzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2fh2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h9a9j1155h) Received-SPF: pass (mail87-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=cbowers@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(479174003)(189002)(199002)(41574002)(24454002)(377424004)(497574002)(15975445006)(56776001)(54316002)(54356001)(47976001)(50986001)(49866001)(47736001)(19300405004)(76482001)(63696002)(80976001)(76796001)(76786001)(83072001)(74876001)(81816001)(65816001)(47446002)(74502001)(74706001)(46102001)(31966008)(66066001)(74662001)(80022001)(74366001)(33646001)(83322001)(79102001)(77982001)(4396001)(59766001)(19580405001)(19580395003)(19609705001)(51856001)(53806001)(81686001)(74316001)(76576001)(69226001)(81542001)(81342001)(16236675002)(56816003)(77096001)(15202345003)(85306002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB527; H:DM2PR05MB528.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail87-co9 (localhost.localdomain [127.0.0.1]) by mail87-co9 (MessageSwitch) id 1382566340625114_30629; Wed, 23 Oct 2013 22:12:20 +0000 (UTC) Received: from CO9EHSMHS012.bigfish.com (unknown [10.236.132.249]) by mail87-co9.bigfish.com (Postfix) with ESMTP id 8AB9A22005F; Wed, 23 Oct 2013 22:12:20 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS012.bigfish.com (10.236.130.22) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 23 Oct 2013 22:12:20 +0000 Received: from DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.371.2; Wed, 23 Oct 2013 22:12:11 +0000 Received: from DM2PR05MB528.namprd05.prod.outlook.com (10.141.99.156) by DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) with Microsoft SMTP Server (TLS) id 15.0.775.9; Wed, 23 Oct 2013 22:12:10 +0000 Received: from DM2PR05MB528.namprd05.prod.outlook.com ([169.254.8.76]) by DM2PR05MB528.namprd05.prod.outlook.com ([169.254.8.21]) with mapi id 15.00.0775.005; Wed, 23 Oct 2013 22:12:10 +0000 From: Chris Bowers To: "Alvaro Retana (aretana)" , "rtgwg@ietf.org" Subject: RE: IETF 88 Agenda Items Thread-Topic: IETF 88 Agenda Items Thread-Index: AQHOvu+xvvXhYYVgF0uuaDZky93MeJoDBJsA///2ZyA= Date: Wed, 23 Oct 2013 22:12:09 +0000 Message-ID: <4142ff97a05948b2ada46a2bc5c0c9c3@DM2PR05MB528.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 000800954F Content-Type: multipart/alternative; boundary="_000_4142ff97a05948b2ada46a2bc5c0c9c3DM2PR05MB528namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 23 Oct 2013 22:12:28 -0000 --_000_4142ff97a05948b2ada46a2bc5c0c9c3DM2PR05MB528namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to suggest a 10 minute time slot focusing on the base RLFA dra= ft. Chris From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of A= lvaro Retana (aretana) Sent: Wednesday, October 23, 2013 4:43 PM To: rtgwg@ietf.org Subject: Re: IETF 88 Agenda Items Hi! I just published the draft agenda here: https://datatracker.ietf.org/meeti= ng/88/agenda/rtgwg/ The revised agenda is due on Monday. Thanks! Alvaro. On 10/1/13 5:46 PM, "Alvaro Retana (aretana)" > wrote: Hi! As I'm sure many of you have noticed, the cut-off date for ID submission is= Oct/21 (for all drafts, including -00). You may have also noticed the fol= lowing dates related to WG agendas: 2013-10-23 (Wednesday): Draft Working Group agendas due 2013-10-28 (Monday): Revised Working Group agendas ..resulting in very little time between them. We have requested our usual slot for Vancouver (the preliminary agenda shou= ld come out later this week), and would like you to start thinking about ag= enda items. In order to avoid an avalanche of requests at the last possibl= e minute we want to set some ground rules ahead of time. Please send requests by Monday Oct/21 to be included in the Draft WG Agenda= . Note that the draft MUST have been published already to be considered. = See other considerations below. For a draft to be considered for the final WG agenda: 1. It MUST have been published already. 2. The authors SHOULD start a discussion on the list highlighting the ma= in points of the draft (don't just send a copy of the announcement and/or p= aste the abstract). We will prioritize existing WG items first, followed by work explicitly ide= ntified in the WG charter. For other new work, if time permits, we will sc= hedule it on a first-come basis with preference given to items for which th= ere has already been a discussion on the list. Thanks! Alvaro + Alia. --_000_4142ff97a05948b2ada46a2bc5c0c9c3DM2PR05MB528namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would like to suggest a= 10 minute time slot focusing on the base RLFA draft.

 <= /p>

Chris

 <= /p>

From: rtgwg-= bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Alvaro Retana (aretana)
Sent: Wednesday, October 23, 2013 4:43 PM
To: rtgwg@ietf.org
Subject: Re: IETF 88 Agenda Items

 

Hi!

 

I just published the draft = agenda here:  https://datatracker.ietf.org/meeting/88/agenda/rtgwg/

 

The revised agenda is due o= n Monday.

 

Thanks!

 

Alvaro.

 

On 10/1/13 5:46 PM, "A= lvaro Retana (aretana)" <areta= na@cisco.com> wrote:

 

Hi!

 

As I'm sure many of you hav= e noticed, the cut-off date for ID submission is Oct/21 (for all drafts, in= cluding -00).  You may have also noticed the following dates related to WG agendas:

 

2013-10-23 (Wednesday): Dra= ft Working Group agendas due

2013-10-28 (Monday): Revise= d Working Group agendas

 

..resulting in very little = time between them.

 

 

We have requested our usual= slot for Vancouver (the preliminary agenda should come out later this week= ), and would like you to start thinking about agenda items.  In order to avoid an avalanche of requests at the last possible minu= te we want to set some ground rules ahead of time.

 

Please send requests by Mon= day Oct/21 to be included in the Draft WG Agenda.  Note that the draft= MUST have been published already to be considered.  See other considerations below.

 

For a draft to be considere= d for the final WG agenda:

  1. It MUST have been published already.
    2. The authors SHOULD start a discussion on the list highlighting= the main points of the draft (don't just send a copy of the announcement a= nd/or paste the abstract).

 

We will prioritize existing= WG items first, followed by work explicitly identified in the WG charter. =  For other new work, if time permits, we will schedule it on a first-come basis with preference given to items for which there has a= lready been a discussion on the list.

 

Thanks!

 

Alvaro + Alia.

--_000_4142ff97a05948b2ada46a2bc5c0c9c3DM2PR05MB528namprd05pro_-- From aretana@cisco.com Wed Oct 23 18:04:52 2013 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 7D61411E82A7 for ; Wed, 23 Oct 2013 18:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.584 X-Spam-Level: X-Spam-Status: No, score=-10.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSM6gTFY73F0 for ; Wed, 23 Oct 2013 18:04:47 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8208711E80E8 for ; Wed, 23 Oct 2013 18:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=395; q=dns/txt; s=iport; t=1382576687; x=1383786287; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vVyuxwWbkPgTMyJ97Es6WMvpbeumTC6IxTRKhrhU3bY=; b=adW/OwGKJUs+wbh5pwk8Pc/OJhAWxd4jN2VN7EwT90cU9Dlw5UbMqxm4 0zqfhnNhvyhDd3qx+2AzO/aIWO7B3TqkXpFsXo9YQG6bcjiq5wlJTuas9 W9urU+fB8Vlr4wPa95LQOKcPvqe5ZLorhaCxFME6grKg8gDETauldagFw 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOhwaFKtJV2d/2dsb2JhbABZgwe/Y4EsFnSCJQEBAQMBOj8FCwIBCA4KHhAyJQIEDgWIAAa7RI8bMweDH4ELA5gJkgeDJA X-IronPort-AV: E=Sophos;i="4.93,558,1378857600"; d="scan'208";a="275900097" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 24 Oct 2013 01:04:36 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9O14ac2000688 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Oct 2013 01:04:36 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.40]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Wed, 23 Oct 2013 20:04:36 -0500 From: "Alvaro Retana (aretana)" To: Chris Bowers Subject: Re: IETF 88 Agenda Items Thread-Topic: IETF 88 Agenda Items Thread-Index: AQHOvu+xvvXhYYVgF0uuaDZky93MeJoDBJsA///2ZyCAADEizQ== Date: Thu, 24 Oct 2013 01:04:36 +0000 Message-ID: <54718288-D8CD-44E1-A640-6A0214BA6D19@cisco.com> References: , <4142ff97a05948b2ada46a2bc5c0c9c3@DM2PR05MB528.namprd05.prod.outlook.com> In-Reply-To: <4142ff97a05948b2ada46a2bc5c0c9c3@DM2PR05MB528.namprd05.prod.outlook.com> 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" 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, 24 Oct 2013 01:04:52 -0000 Chris: Hi! What exactly do you want to get from this slot? Are you looking for an upd= ate from the authors or for some time to continue the list discussion face-= to-face? Thanks! Alvaro. Sent from my iPad > On Oct 23, 2013, at 6:12 PM, "Chris Bowers" wrote: >=20 > I would like to suggest a 10 minute time slot focusing on the base RLFA d= raft. From cbowers@juniper.net Thu Oct 24 05:32:11 2013 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 5C61511E815E for ; Thu, 24 Oct 2013 05:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOWstAcyHWBJ for ; Thu, 24 Oct 2013 05:32:01 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0250.outbound.messaging.microsoft.com [213.199.154.250]) by ietfa.amsl.com (Postfix) with ESMTP id E0B7811E8260 for ; Thu, 24 Oct 2013 05:31:36 -0700 (PDT) Received: from mail175-db9-R.bigfish.com (10.174.16.236) by DB9EHSOBE028.bigfish.com (10.174.14.91) with Microsoft SMTP Server id 14.1.225.22; Thu, 24 Oct 2013 12:31:34 +0000 Received: from mail175-db9 (localhost [127.0.0.1]) by mail175-db9-R.bigfish.com (Postfix) with ESMTP id A85CB16017D; Thu, 24 Oct 2013 12:31:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zz98dI9371I103dK542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL8275dh1de097hz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail175-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=cbowers@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(377454003)(189002)(199002)(13464003)(41574002)(24454002)(54316002)(74876001)(56776001)(76482001)(50986001)(4396001)(81342001)(53806001)(81542001)(77982001)(66066001)(85306002)(33646001)(63696002)(69226001)(80976001)(79102001)(19580395003)(19580405001)(47736001)(47976001)(49866001)(83322001)(65816001)(80022001)(74366001)(51856001)(81816001)(76796001)(76786001)(74316001)(77096001)(56816003)(81686001)(76576001)(74706001)(59766001)(46102001)(54356001)(74662001)(74502001)(31966008)(83072001)(47446002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB525; H:DM2PR05MB528.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail175-db9 (localhost.localdomain [127.0.0.1]) by mail175-db9 (MessageSwitch) id 1382617891538743_8681; Thu, 24 Oct 2013 12:31:31 +0000 (UTC) Received: from DB9EHSMHS020.bigfish.com (unknown [10.174.16.242]) by mail175-db9.bigfish.com (Postfix) with ESMTP id 7FB0D460089; Thu, 24 Oct 2013 12:31:31 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS020.bigfish.com (10.174.14.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 24 Oct 2013 12:31:30 +0000 Received: from DM2PR05MB525.namprd05.prod.outlook.com (10.141.99.147) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 24 Oct 2013 12:31:30 +0000 Received: from DM2PR05MB528.namprd05.prod.outlook.com (10.141.99.156) by DM2PR05MB525.namprd05.prod.outlook.com (10.141.99.147) with Microsoft SMTP Server (TLS) id 15.0.775.9; Thu, 24 Oct 2013 12:31:28 +0000 Received: from DM2PR05MB528.namprd05.prod.outlook.com ([169.254.8.76]) by DM2PR05MB528.namprd05.prod.outlook.com ([169.254.8.21]) with mapi id 15.00.0775.005; Thu, 24 Oct 2013 12:31:28 +0000 From: Chris Bowers To: "Alvaro Retana (aretana)" Subject: RE: IETF 88 Agenda Items Thread-Topic: IETF 88 Agenda Items Thread-Index: AQHOvu+xvvXhYYVgF0uuaDZky93MeJoDBJsA///2ZyCAADEizYAAvqrg Date: Thu, 24 Oct 2013 12:31:27 +0000 Message-ID: <3977109aac17428485ca5201018fb433@DM2PR05MB528.namprd05.prod.outlook.com> References: , <4142ff97a05948b2ada46a2bc5c0c9c3@DM2PR05MB528.namprd05.prod.outlook.com> <54718288-D8CD-44E1-A640-6A0214BA6D19@cisco.com> In-Reply-To: <54718288-D8CD-44E1-A640-6A0214BA6D19@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 000947967F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 24 Oct 2013 12:32:14 -0000 The working group should discuss what needs to be done to progress this wor= king group document. Chris -----Original Message----- From: Alvaro Retana (aretana) [mailto:aretana@cisco.com]=20 Sent: Wednesday, October 23, 2013 8:05 PM To: Chris Bowers Cc: rtgwg@ietf.org Subject: Re: IETF 88 Agenda Items Chris: Hi! What exactly do you want to get from this slot? Are you looking for an upd= ate from the authors or for some time to continue the list discussion face-= to-face? Thanks! Alvaro. Sent from my iPad > On Oct 23, 2013, at 6:12 PM, "Chris Bowers" wrote: >=20 > I would like to suggest a 10 minute time slot focusing on the base RLFA d= raft. From aretana@cisco.com Thu Oct 24 11:04:39 2013 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 2535121F9E44 for ; Thu, 24 Oct 2013 11:04:39 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pO36JxlVLObM for ; Thu, 24 Oct 2013 11:04:33 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E1FCF11E81E0 for ; Thu, 24 Oct 2013 11:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1336; q=dns/txt; s=iport; t=1382637872; x=1383847472; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=LBi9t8foWd5+8ITOpUyuNF7pa4LSrSWXfIBhgWkiDwM=; b=cqXk0vUm/Z9X7Ys+RknQT9vvBXOD4SSbH4wrjiU1o3kQKL5y8ymWiqpy h7i2Yxdha8ngHZ0IsxGnu9Bw5N4ysAaE/XclscxEZChhMKh5TC24xHHNL e78MgroQht2Gr4Evvz9JY905avVmYYd+NtKjHOEIkUezzR3xzh0ZaV7TF M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAK5gaVKtJXG8/2dsb2JhbABZgweBDL5egR0WdIIlAQEBBDo/DAYBCA4DBAEBAQoUCTkUCQgCBA4FCId/ulePHDEHBoMZgQ0DqhGDJIIq X-IronPort-AV: E=Sophos;i="4.93,563,1378857600"; d="scan'208";a="276063813" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 24 Oct 2013 18:04:31 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9OI4Vop016534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Oct 2013 18:04:31 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.40]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Thu, 24 Oct 2013 13:04:31 -0500 From: "Alvaro Retana (aretana)" To: Chris Bowers Subject: Re: IETF 88 Agenda Items Thread-Topic: IETF 88 Agenda Items Thread-Index: AQHOvu+xvvXhYYVgF0uuaDZky93MeJoDBJsA///2ZyCAADEizYAAvqrggABvDAA= Date: Thu, 24 Oct 2013 18:04:31 +0000 Message-ID: In-Reply-To: <3977109aac17428485ca5201018fb433@DM2PR05MB528.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.7] Content-Type: text/plain; charset="us-ascii" Content-ID: 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, 24 Oct 2013 18:04:39 -0000 On 10/24/13 8:31 AM, "Chris Bowers" wrote: >The working group should discuss what needs to be done to progress this >working group document. I think that the face-to-face meeting is a good place to iron out any issues..specially so that documents can progress. I'll carve out some time in the agenda. So that we can have a structured discussion (vs an open mike), I would like for you (and anyone else interested) to work with the authors on the set of outstanding issues: things that haven't come to a conclusion yet or that any of you think need more discussion. The intent is to have something to guide the conversation. Thanks! Alvaro. > >Chris > >-----Original Message----- >From: Alvaro Retana (aretana) [mailto:aretana@cisco.com] >Sent: Wednesday, October 23, 2013 8:05 PM >To: Chris Bowers >Cc: rtgwg@ietf.org >Subject: Re: IETF 88 Agenda Items > >Chris: > >Hi! > >What exactly do you want to get from this slot? Are you looking for an >update from the authors or for some time to continue the list discussion >face-to-face? > >Thanks! > >Alvaro. > >Sent from my iPad > >> On Oct 23, 2013, at 6:12 PM, "Chris Bowers" wrote: >>=20 >> I would like to suggest a 10 minute time slot focusing on the base RLFA >>draft. > > > From cbowers@juniper.net Fri Oct 25 06:48:25 2013 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 BF0AD11E826B for ; Fri, 25 Oct 2013 06:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rp0eU5hgjI+k for ; Fri, 25 Oct 2013 06:48:17 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 8A33E11E8183 for ; Fri, 25 Oct 2013 06:48:13 -0700 (PDT) Received: from mail32-am1-R.bigfish.com (10.3.201.225) by AM1EHSOBE020.bigfish.com (10.3.207.142) with Microsoft SMTP Server id 14.1.225.22; Fri, 25 Oct 2013 13:48:11 +0000 Received: from mail32-am1 (localhost [127.0.0.1]) by mail32-am1-R.bigfish.com (Postfix) with ESMTP id A189D3E0359; Fri, 25 Oct 2013 13:48:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VPS-30(zzbb2dI98dI9371I103dK542I1432I1418I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL8275bh8275dh1de097hz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2052h20b3h1155h) Received-SPF: pass (mail32-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=cbowers@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(164054003)(51444003)(377454003)(479174003)(51704005)(41574002)(24454002)(13464003)(189002)(199002)(81686001)(53806001)(77096001)(85306002)(69226001)(4396001)(51856001)(76786001)(81542001)(81816001)(33656001)(49866001)(50986001)(46102001)(76796001)(47976001)(56816003)(47736001)(36756003)(82746002)(80976001)(63696002)(83072001)(83716003)(66066001)(80022001)(74706001)(74366001)(65816001)(76482001)(54316002)(56776001)(83322001)(19580395003)(19580405001)(81342001)(79102001)(74662001)(47446002)(74502001)(54356001)(59766001)(77982001)(74876001)(31966008); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB528; H:DM2PR05MB528.namprd05.prod.outlook.com; CLIP:166.205.67.73; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail32-am1 (localhost.localdomain [127.0.0.1]) by mail32-am1 (MessageSwitch) id 1382708888649399_24244; Fri, 25 Oct 2013 13:48:08 +0000 (UTC) Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.239]) by mail32-am1.bigfish.com (Postfix) with ESMTP id 90EB6420075; Fri, 25 Oct 2013 13:48:08 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 25 Oct 2013 13:48:08 +0000 Received: from DM2PR05MB528.namprd05.prod.outlook.com (10.141.99.156) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 25 Oct 2013 13:48:06 +0000 Received: from DM2PR05MB528.namprd05.prod.outlook.com (10.141.99.156) by DM2PR05MB528.namprd05.prod.outlook.com (10.141.99.156) with Microsoft SMTP Server (TLS) id 15.0.775.9; Fri, 25 Oct 2013 13:48:04 +0000 Received: from DM2PR05MB528.namprd05.prod.outlook.com ([169.254.8.76]) by DM2PR05MB528.namprd05.prod.outlook.com ([169.254.8.21]) with mapi id 15.00.0775.005; Fri, 25 Oct 2013 13:48:04 +0000 From: Chris Bowers To: "Alvaro Retana (aretana)" Subject: Re: IETF 88 Agenda Items Thread-Topic: IETF 88 Agenda Items Thread-Index: AQHOvu+xvvXhYYVgF0uuaDZky93MeJoDBJsA///2ZyCAADEizYAAvqrggABvDACAATnYAA== Date: Fri, 25 Oct 2013 13:48:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.205.67.73] x-forefront-prvs: 0010D93EFE Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 25 Oct 2013 13:48:26 -0000 I will do that.=20 Thanks, Chris > On Oct 24, 2013, at 2:05 PM, "Alvaro Retana (aretana)" wrote: >=20 >> On 10/24/13 8:31 AM, "Chris Bowers" wrote: >>=20 >> The working group should discuss what needs to be done to progress this >> working group document. >=20 > I think that the face-to-face meeting is a good place to iron out any > issues..specially so that documents can progress. >=20 > I'll carve out some time in the agenda. So that we can have a structured > discussion (vs an open mike), I would like for you (and anyone else > interested) to work with the authors on the set of outstanding issues: > things that haven't come to a conclusion yet or that any of you think nee= d > more discussion. The intent is to have something to guide the > conversation. >=20 > Thanks! >=20 > Alvaro. >=20 >=20 >=20 >>=20 >> Chris >>=20 >> -----Original Message----- >> From: Alvaro Retana (aretana) [mailto:aretana@cisco.com] >> Sent: Wednesday, October 23, 2013 8:05 PM >> To: Chris Bowers >> Cc: rtgwg@ietf.org >> Subject: Re: IETF 88 Agenda Items >>=20 >> Chris: >>=20 >> Hi! >>=20 >> What exactly do you want to get from this slot? Are you looking for an >> update from the authors or for some time to continue the list discussion >> face-to-face? >>=20 >> Thanks! >>=20 >> Alvaro. >>=20 >> Sent from my iPad >>=20 >>> On Oct 23, 2013, at 6:12 PM, "Chris Bowers" wrote= : >>>=20 >>> I would like to suggest a 10 minute time slot focusing on the base RLFA >>> draft. >=20 >=20 >=20 From stbryant@cisco.com Mon Oct 28 07:33:26 2013 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 9187B11E818B for ; Mon, 28 Oct 2013 07:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.069 X-Spam-Level: X-Spam-Status: No, score=-110.069 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rns6pBA8pqma for ; Mon, 28 Oct 2013 07:33:21 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE9721F9DCA for ; Mon, 28 Oct 2013 07:33:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33862; q=dns/txt; s=iport; t=1382970787; x=1384180387; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; bh=uyz770f9zNPdNjxLd9pJvz5oc+eDWMY/CEh1iA2Md0o=; b=FWklxwhGQtJIjteaQQWzz1t9xVHprd245SXFMiHurwr7A+DlAq8wf1PA RmKsf/iiKIB97K5VAZuX2qgKBx6D8nCzShDIB3dAzLAz1en2U+mWJeJtS JJ0x/8hTFbc/chfLYmaSWXtiRj6Z392f15PSfgOHzfrbJO3CN/Mle9cH4 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAHR0blKQ/khM/2dsb2JhbABPCoJDRDiJRLV0gSUWdIIlAQEBAwEBAQEqQQoGCwsOCgkWAQENCQMCAQIBFTAGAQwGAgEBh30GDbgsjgwGgUqELAOYCpIHgyaBcQ X-IronPort-AV: E=Sophos;i="4.93,586,1378857600"; d="scan'208,217";a="18594375" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 28 Oct 2013 14:33:05 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9SEX0vC020738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Oct 2013 14:33:02 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9SEWxgb003057; Mon, 28 Oct 2013 14:32:59 GMT Message-ID: <526E759B.1090009@cisco.com> Date: Mon, 28 Oct 2013 14:32:59 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Chris Bowers , "rtgwg@ietf.org" Subject: Re: algorithm description for draft-ietf-rtgwg-remote-lfa References: <8987a924cffe4af1b2bc2f94a7950a6e@BL2PR05MB113.namprd05.prod.outlook.com> In-Reply-To: <8987a924cffe4af1b2bc2f94a7950a6e@BL2PR05MB113.namprd05.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------000502010702080901060402" 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: Mon, 28 Oct 2013 14:33:26 -0000 This is a multi-part message in MIME format. --------------000502010702080901060402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Please see notes inline. Here is the current candidate algorithm text. I added lots of comments for my personal checking of the algorithm and my guess is that they will be of use to reader and reviewers further down the line. Once this is correct we will need to add a glossary of terms. 4.3. A Cost Based RLFA Algorithm The preceding text has mostly described the computation of the remote LFA repair point (PQ) in terms of the intersection of two reachability graphs computed using SPFs. This section describes a method of computing the repair point using a cost based algorithm. The pseudo-code provides in this section avoids unnecessary SPF computations, but for the sake of readability, it does not otherwise try to optimize the code. Unconventionally, but for clarity, we provide the main algorithm followed its procedures. In this description D_opt(a,b) is the shortest distance from node a to node b as computed by the SPF. //////////////////////////////////////////////////////////////////// // // We have already computed the forward SPF from self to all nodes // y in network and thus we know D_opt (self, y). This is needed // for normal forwarding. // However for completeness. Compute_and_Store_Forward_SPF(self) // To extend P-space we compute the SPF at each neighbour except the // neighbour that is reached via the link being protected. // We will also need D_opt(fail_intf.remote_node,y) so compute that // at the same time. Compute_Neighbor_SPFs() // Compute the set of nodes {P} reachable other than via the // failed link Compute_Extended_P_Space() // Compute the set of nodes that can reach the node on the far side // of the failed link without traversing the failed link. Compute_Q_Space() // Compute the set of candidate RLFA tunnel endpoints Bryant, et al. Expires May 01, 2014 [Page 8] Internet-Draft Remote LFA FRR October 2013 Intersect_Extended_P_and_Q_Space() // Make sure that we cannot get looping repairs when the // failure is worse than expected. if (guarantee_no_looping_on_worse_than_protected_failure) Apply_Downstream_Constraint() ///////////////////////////////////////////////////////////////////// // // This computes the SPF from root, and stores stores the optimum // distance from root to each node y Compute_and_Store_Forward_SPF(root) Compute_Forward_SPF(root) foreach node y in network store D_opt(root,y) ///////////////////////////////////////////////////////////////////// // // This computes the optimum distance from each neighbour (other than // the neighbour reachable through the failed link) and every other // node in the network Compute_Neighbor_SPFs() foreach interface intf in self Compute_and_Store_Forward_SPF(intf.remote_node) ///////////////////////////////////////////////////////////////////// // // The reverse SPF computes the cost from each remote node to root. // This is acheived by running the normal SPF algorithm, but using the // link cost in the direction from the next hop back towards root // in place of the link cost in the direction away from root towards // the next hop. Compute_and_Store_Reverse_SPF(root) Compute_Reverse_SPF(root) foreach node y in network store D_opt(y,root) Bryant, et al. Expires May 01, 2014 [Page 9] Internet-Draft Remote LFA FRR October 2013 ///////////////////////////////////////////////////////////////////// // // Calculate P space and then extend it by the P-spaces of each // neighbour other than the one reachable via the link being // protected. Note the strictly less than operator is needed to // avoid ECMP issues. Compute_Extended_P_Space() foreach node y in network y.in_extended_P_space = false // Compute P-space // // Editor's note, I think that this if statement may be // redundent since the foreach interface intf in self loop // catches all cases. // // Editor's note D_opt(fail_intf.remote_node,y) requires an // SPF from neighbour fail_intf.remote_node so did this as // part of all neighbours SPF calculation if (D_opt(self, y) < D_opt(self, fail_intf.remote_node) + D_opt(fail_intf.remote_node,y)) y.in_extended_P_space = true // Extend P-space to the P-spaces of all reachable // neighbours foreach interface intf in self if (intf.remote_node != fail_intf.remote_node) if ( D_opt(intf.remote_node, y) < D_opt(intf.remote_node, self) + D_opt(self,fail_intf.remote_node) + D_opt(fail_intf.remote_node,y) ) y.in_extended_P_space = true ///////////////////////////////////////////////////////////////////// // Compute_Q_Space() // Compute the cost from every node the network to the // node normally reachable across the failed link Compute_and_Store_Reverse_SPF(fail_intf.remote_node) // Compute the cost from every node the network to self Compute_and_Store_Reverse_SPF(self) foreach node y in network if ( D_opt(y,fail_intf.remote_node) < D_opt(y,self) + Bryant, et al. Expires May 01, 2014 [Page 10] Internet-Draft Remote LFA FRR October 2013 D_opt(self,fail_intf.remote_node) ) y.in_Q_space = true else y.in_Q_space = false ///////////////////////////////////////////////////////////////////// // // Compute set of nodes in both extended P-space and in Q-space Intersect_Extended_P_and_Q_Space() foreach node y in network if ( y.in_extended_P_space && y.in_Q_space ) y.valid_tunnel_endpoint = true else y.valid_tunnel_endpoint = false ///////////////////////////////////////////////////////////////////// // // A downstream route is one where the next hop is strictly // closer to the destination. By sending the packet to a // PQ node that is downstream, we know that if the PQ node // detects a failure, it will not loop the packet back to self. // This is useful when there are two failures, or a node has // failed rather than a link. Apply_Downstream_Constraint() foreach node y in network if (y.valid_tunnel_endpoint) Compute_and_Store_Forward_SPF(y) if ((D_opt(y,dest) < D_opt(self,dest)) y.valid_tunnel_endpoint = true else y.valid_tunnel_endpoint = false // ///////////////////////////////////////////////////////////////////// Please can someone verify that the algorithm is correct. See from the text below that I thought that the original missed some SPFs On 04/09/2013 22:21, Chris Bowers wrote: > As has been pointed out in other email threads, > the current version of draft-ietf-rtgwg-remote-lfa-02.txt > lacks a formal description of the algorithm being proposed. > Below is a such a formal algorithm description, based on my > reading of the current draft. It would help progress this > draft forward if the authors would correct any errors > in this pseudo-code representation of the algorithm. > The pseudo-code below avoids unnecessary SPF computations, but > for the sake of readability, it does not otherwise try to > optimize the code. > Remote LFA algorithm > Compute_and_Store_Forward_SPF(node root) > Compute_Forward_SPF(root) > foreach node z in network > store D_opt(root,z) > Compute_and_Store_Reverse_SPF(node root) > Compute_Reverse_SPF(root) > foreach node z in network > store D_opt(z,root) > Compute_Neighbor_SPFs() > foreach interface intf in self > if (intf.remote_node != fail_intf.remote_node) > Compute_and_Store_Forward_SPF(intf.remote_node) SB> Later on we need D_opt(fail_intf.remote_node,y) SB> The restriction if (intf.remote_node != fail_intf.remote_node) SB> prevents this calculation.I have therefore removed the SB> restriction in the text. > Compute_Extended_P_Space() > foreach node y in network > y.in_extended_P_space = false SB> This first calculation is P_space and since the first hop is SB> forced, there in no ECMP issue, and so you can go to an equals SB> operator. I think the preference for less than arises from the SB> forwarding code in some implementations that might do the SB> ECMP by mistake. SB> Also why isn't it adequate to compute the union of the P space SB> of the neighbours, since by definition packet must go through a SB> neighbour? SB> SB> In other words can't the following if statement be removed? > if (D_opt(self, y) < > D_opt(self, fail_intf.remote_node) + > D_opt(fail_intf.remote_node,y)) > y.in_extended_P_space = true > foreach interface intf in self > if (intf.remote_node != fail_intf.remote_node) > if ( D_opt(intf.remote_node, y) < > D_opt(intf.remote_node, self) + > D_opt(self,fail_intf.remote_node) + > D_opt(fail_intf.remote_node,y) ) > y.in_extended_P_space = true > Compute_Q_Space() > Compute_and_Store_Reverse_SPF(fail_intf.remote_node) > foreach node y in network > if ( D_opt(y,fail_intf.remote_node) < D_opt(y,self) + SB> D_opt(y,self) needs SB> Compute_and_Store_Reverse_SPF(self) > D_opt(self,fail_intf.remote_node) ) > y.in_Q_space = true > else > y.in_Q_space = false > Intersect_Extended_P_and_Q_Space() > foreach node y in network > if ( y.in_extended_P_space && y.in_Q_space ) > y.valid_tunnel_endpoint = true > else > y.valid_tunnel_endpoint = false > Apply_Downstream_Constraint() > foreach node y in network > if (y.valid_tunnel_endpoint) > Compute_and_Store_Forward_SPF(y) > if ((D_opt(y,dest) < D_opt(self,dest)) > y.valid_tunnel_endpoint = true > else > y.valid_tunnel_endpoint = false > Compute_Neighbor_SPFs() SB> you need the reverse SPF before here as you need the result in SB> the extended p-space calculation > Compute_Extended_P_Space() > Compute_Q_Space() > Intersect_Extended_P_and_Q_Space() > if (guarantee_no_looping_on_worse_than_protected_failure) > Apply_Downstream_Constraint() > ********** > I would also like to propose that the following text to be > inserted after the last paragraph of > section 4.2.1. "Computing Repair Paths". > It should be noted that using the Q-space of E as a proxy for the Q-space > of each destination can result in failing to identify valid remote LFAs. > The extent to which this reduces the effective protection coverage is > topology dependent. > *********** SB> Added > Thanks, > Chris > > > _______________________________________________ > 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 --------------000502010702080901060402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Please see notes inline.

Here is the current candidate algorithm text. I added lots of
comments for my personal checking of the algorithm
and my guess is that they will be of use to reader and
reviewers further down the line.

Once this is correct we will need to add a glossary of terms.


4.3.  A Cost Based RLFA Algorithm

   The preceding text has mostly described the computation of the
   remote LFA repair point (PQ) in terms of the intersection of two
   reachability graphs computed using SPFs.  This section describes a
   method of computing the repair point using a cost based algorithm.
   The pseudo-code provides in this section avoids unnecessary SPF
   computations, but for the sake of readability, it does not otherwise
   try to optimize the code.  Unconventionally, but for clarity, we
   provide the main algorithm followed its procedures.  In this
   description D_opt(a,b) is the shortest distance from node a to node b
   as computed by the SPF.

      ////////////////////////////////////////////////////////////////////
      //
      // We have already computed the forward SPF from self to all nodes
      // y in network and thus we know D_opt (self, y). This is needed
      // for normal forwarding.
      // However for completeness.

      Compute_and_Store_Forward_SPF(self)

      // To extend P-space we compute the SPF at each neighbour except the
      // neighbour that is reached via the link being protected.
      // We will also need D_opt(fail_intf.remote_node,y) so compute that
      // at the same time.

      Compute_Neighbor_SPFs()

      // Compute the set of nodes {P} reachable other than via the
      // failed link

      Compute_Extended_P_Space()

      // Compute the set of nodes that can reach the node on the far side
      // of the failed link without traversing the failed link.

      Compute_Q_Space()

      // Compute the set of candidate RLFA tunnel endpoints




Bryant, et al.            Expires May 01, 2014                  [Page 8]

Internet-Draft               Remote LFA FRR                 October 2013


      Intersect_Extended_P_and_Q_Space()

      // Make sure that we cannot get looping repairs when the
      // failure is worse than expected.

      if (guarantee_no_looping_on_worse_than_protected_failure)
          Apply_Downstream_Constraint()



      /////////////////////////////////////////////////////////////////////
      //
      // This computes the SPF from root, and stores stores the optimum
      // distance from root to each node y

      Compute_and_Store_Forward_SPF(root)
          Compute_Forward_SPF(root)
          foreach node y in network
              store D_opt(root,y)



      /////////////////////////////////////////////////////////////////////
      //
      // This computes the optimum distance from each neighbour (other than
      // the neighbour reachable through the failed link) and every other
      // node in the network

   Compute_Neighbor_SPFs()
       foreach interface intf in self
           Compute_and_Store_Forward_SPF(intf.remote_node)



      /////////////////////////////////////////////////////////////////////
      //
      // The reverse SPF computes the cost from each remote node to root.
      // This is acheived by running the normal SPF algorithm, but using the
      // link cost in the direction from the next hop back towards root
      // in place of the link cost in the direction away from root towards
      // the next hop.

      Compute_and_Store_Reverse_SPF(root)
          Compute_Reverse_SPF(root)
          foreach node y in network
              store D_opt(y,root)





Bryant, et al.            Expires May 01, 2014                  [Page 9]

Internet-Draft               Remote LFA FRR                 October 2013


      /////////////////////////////////////////////////////////////////////
      //
      // Calculate P space and then extend it by the P-spaces of each
      // neighbour other than the one reachable via the link being
      // protected. Note the strictly less than operator is needed to
      // avoid ECMP issues.

      Compute_Extended_P_Space()
          foreach node y in network
              y.in_extended_P_space = false
              // Compute P-space
              //
              // Editor's note, I think that this if statement may be
              // redundent since the foreach interface intf in self loop
              // catches all cases.
              //
              // Editor's note D_opt(fail_intf.remote_node,y) requires an
              // SPF from neighbour fail_intf.remote_node so did this as
              // part of all neighbours SPF calculation
              if (D_opt(self, y) <
                      D_opt(self, fail_intf.remote_node) +
                      D_opt(fail_intf.remote_node,y))
                  y.in_extended_P_space = true
              // Extend P-space to the P-spaces of all reachable
              // neighbours
              foreach interface intf in self
                  if (intf.remote_node != fail_intf.remote_node)
                      if ( D_opt(intf.remote_node, y) <
                           D_opt(intf.remote_node, self) +
                           D_opt(self,fail_intf.remote_node) +
                           D_opt(fail_intf.remote_node,y) )
                       y.in_extended_P_space = true



      /////////////////////////////////////////////////////////////////////
      //

      Compute_Q_Space()
          // Compute the cost from every node the network to the
          // node normally reachable across the failed link
          Compute_and_Store_Reverse_SPF(fail_intf.remote_node)

          // Compute the cost from every node the network to self
          Compute_and_Store_Reverse_SPF(self)

          foreach node y in network
              if ( D_opt(y,fail_intf.remote_node) < D_opt(y,self) +



Bryant, et al.            Expires May 01, 2014                 [Page 10]

Internet-Draft               Remote LFA FRR                 October 2013


                      D_opt(self,fail_intf.remote_node) )
                  y.in_Q_space = true
              else
                  y.in_Q_space = false



      /////////////////////////////////////////////////////////////////////
      //
      // Compute set of nodes in both extended P-space and in Q-space

      Intersect_Extended_P_and_Q_Space()
          foreach node y in network
              if ( y.in_extended_P_space && y.in_Q_space )
                  y.valid_tunnel_endpoint = true
              else
                  y.valid_tunnel_endpoint = false



      /////////////////////////////////////////////////////////////////////
      //
      // A downstream route is one where the next hop is strictly
      // closer to the destination. By sending the packet to a
      // PQ node that is downstream, we know that if the PQ node
      // detects a failure, it will not loop the packet back to self.
      // This is useful when there are two failures, or a node has
      // failed rather than a link.

      Apply_Downstream_Constraint()
          foreach node y in network
              if (y.valid_tunnel_endpoint)
                  Compute_and_Store_Forward_SPF(y)
                  if ((D_opt(y,dest) < D_opt(self,dest))
                      y.valid_tunnel_endpoint = true
                  else
                      y.valid_tunnel_endpoint = false


   //
   /////////////////////////////////////////////////////////////////////
Please can someone verify that the algorithm is correct. See from
the text below that I thought that the original missed some
SPFs





On 04/09/2013 22:21, Chris Bowers wrote:
As has been pointed out in other email threads,
the current version of draft-ietf-rtgwg-remote-lfa-02.txt
lacks a formal description of the algorithm being proposed.
Below is a such a formal algorithm description, based on my
reading of the current draft.  It would help progress this
draft forward if the authors would correct any errors
in this pseudo-code representation of the algorithm.
 
The pseudo-code below avoids unnecessary SPF computations, but
for the sake of readability, it does not otherwise try to
optimize the code.
 
Remote LFA algorithm
 
Compute_and_Store_Forward_SPF(node root)
    Compute_Forward_SPF(root)
    foreach node z in network
        store D_opt(root,z)
       
Compute_and_Store_Reverse_SPF(node root)
    Compute_Reverse_SPF(root)
    foreach node z in network
        store D_opt(z,root)
 
Compute_Neighbor_SPFs()
    foreach interface intf in self
        if (intf.remote_node != fail_intf.remote_node)
            Compute_and_Store_Forward_SPF(intf.remote_node)
SB> Later on we need D_opt(fail_intf.remote_node,y)
SB> The restriction if (intf.remote_node != fail_intf.remote_node)
SB> prevents this calculation. I have therefore removed the
SB> restriction in the text.
 

 
Compute_Extended_P_Space()
    foreach node y in network
        y.in_extended_P_space = false
SB> This first calculation is P_space and since the first hop is
SB> forced, there in no ECMP issue, and so you can go to an equals
SB> operator. I think the preference for less than arises from the
SB> forwarding code in some implementations that might do the
SB> ECMP by mistake.

SB> Also why isn't it adequate to compute the union of the P space
SB> of the neighbours, since by definition packet must go through a
SB> neighbour?
SB>
SB> In other words can't the following if statement be removed?
        if (D_opt(self, y) <
                D_opt(self, fail_intf.remote_node) + D_opt(fail_intf.remote_node,y))
            y.in_extended_P_space = true
        foreach interface intf in self
            if (intf.remote_node != fail_intf.remote_node)
                if ( D_opt(intf.remote_node, y) < D_opt(intf.remote_node, self) +
                        D_opt(self,fail_intf.remote_node) +
                        D_opt(fail_intf.remote_node,y) )
                    y.in_extended_P_space = true               
 
Compute_Q_Space()
    Compute_and_Store_Reverse_SPF(fail_intf.remote_node)
    foreach node y in network
        if ( D_opt(y,fail_intf.remote_node) < D_opt(y,self) +
SB> D_opt(y,self) needs
SB> Compute_and_Store_Reverse_SPF(self)
                D_opt(self,fail_intf.remote_node) )
            y.in_Q_space = true
        else
            y.in_Q_space = false
                       
Intersect_Extended_P_and_Q_Space()
    foreach node y in network
        if ( y.in_extended_P_space && y.in_Q_space )
            y.valid_tunnel_endpoint = true
        else
            y.valid_tunnel_endpoint = false
                                       
Apply_Downstream_Constraint()
    foreach node y in network
        if (y.valid_tunnel_endpoint)
            Compute_and_Store_Forward_SPF(y)
            if ((D_opt(y,dest) < D_opt(self,dest))
                y.valid_tunnel_endpoint = true
           else
                y.valid_tunnel_endpoint = false
                               
Compute_Neighbor_SPFs()
SB> you need the reverse SPF before here as you need the result in
SB> the extended p-space calculation

Compute_Extended_P_Space()
Compute_Q_Space()
Intersect_Extended_P_and_Q_Space()
if (guarantee_no_looping_on_worse_than_protected_failure)
    Apply_Downstream_Constraint()
 
**********     
 
I would also like to propose that the following text to be
inserted after the last paragraph of
section 4.2.1. "Computing Repair Paths".
 
It should be noted that using the Q-space of E as a proxy for the Q-space
of each destination can result in failing to identify valid remote LFAs. 
The extent to which this reduces the effective protection coverage is
topology dependent.
 
***********
 
SB> Added

Thanks,
Chris
 
 
 

_______________________________________________
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
--------------000502010702080901060402-- From stbryant@cisco.com Mon Oct 28 07:48:11 2013 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 CB64F11E818C for ; Mon, 28 Oct 2013 07:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.506 X-Spam-Level: X-Spam-Status: No, score=-110.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvIa4B+LrBm3 for ; Mon, 28 Oct 2013 07:48:07 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id E17CC11E817F for ; Mon, 28 Oct 2013 07:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2006; q=dns/txt; s=iport; t=1382971681; x=1384181281; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=tvKBDI0PMxc+z3aMNtRkU5GHMHsQ/ZcshqxdxCJj7is=; b=hpUED0d22uRcYDMXR56xQtcN3w1I+GvGz708CxA41Fzlf4CwMy99sCgw It62bYtW+HYO/bX7l8j6RQSN/I5RWkvCgsuI4sIhyxYwYp0PW5OElMPBn riohmZztZN1WF6Lti8rdLAA0kJVtP0jqp3yMUgwCxY/KuZ4ZiOK/lGLqM A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAEp4blKQ/khL/2dsb2JhbABZgwc4vziBJRZ0giUBAQEEAQEBJAsBBTYGBBELDgoJFg8JAwIBAgEVMAYBDAYCAQGIAw24LY9chCwDmAqSB4FogT4 X-IronPort-AV: E=Sophos;i="4.93,586,1378857600"; d="scan'208";a="161100871" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 28 Oct 2013 14:47:59 +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 r9SElsql014551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Oct 2013 14:47:56 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9SElrvr003983; Mon, 28 Oct 2013 14:47:53 GMT Message-ID: <526E7919.4070409@cisco.com> Date: Mon, 28 Oct 2013 14:47:53 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Chris Bowers , "rtgwg@ietf.org" Subject: Re: issue with cost-based formulation of extended P-space in draft-ietf-rtgwg-remote-lfa-02 References: <145B98DA3B8D164BA479E1AC5316E6AF1472EDF8@BN1PRD0512MB667.namprd05.prod.outlook.com> In-Reply-To: <145B98DA3B8D164BA479E1AC5316E6AF1472EDF8@BN1PRD0512MB667.namprd05.prod.outlook.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: Mon, 28 Oct 2013 14:48:11 -0000 I think that the new text is correct: In cost terms a router (P) is in extended P-space if the shortest path cost N->P is strictly less than the shortest path cost N->S->E->P. In other words, once the packet it forced to N by S, it is lower cost for it to continue on to P by any path except one that takes it back to S and then across the S->E link. As far as I can see this works for case 1 and case 2 below since the only case where 1 applies is when N == Y, but that comes out in the wash since D_opt(N,Y) == 0 I prefer not to include the D-opt notation at this stage of the text unless we have to. There is a full set of cost based pseudocode in 4.2.3 which defines the D_opt term. - Stewart On 30/07/2013 13:08, Chris Bowers wrote: > It appears that the cost-based formulation for determining the > extended P-space in draft-ietf-rtgwg-remote-lfa-02 is incorrect. In > particular, section 4.2.2 says: > “In cost terms a router is in extended P-space if the shortest path > cost S-N->P is strictly less than the shortest path cost S-E->P.” > Instead, the requirement should be that the shortest path cost N->P is > strictly less than cost N-S-E->P. > I propose the following text for section 4.2.2. > “In terms of cost, a router Y is in the extended P-space of S with > respect to the failure of link S-E, if either of the two following > conditions is true: > (1) D_opt(S,Y) < D_opt(S,E) + D_opt(E,Y) > OR > (2) S has a neighbor N satisfying the inequality: > D_opt(N,Y) < D_opt(N,S) + D_opt(S,E) + D_opt(E,Y)” > This text corrects the error noted above, and it puts both of the > criteria for determining extended P-space in terms of cost in one > place in the text. > Chris > > > _______________________________________________ > 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 Mon Oct 28 10:57:30 2013 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 5989821E80AF for ; Mon, 28 Oct 2013 10:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.507 X-Spam-Level: X-Spam-Status: No, score=-110.507 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssDLNAjhI9cu for ; Mon, 28 Oct 2013 10:57:24 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id CA6CE11E828B for ; Mon, 28 Oct 2013 10:56:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24515; q=dns/txt; s=iport; t=1382983036; x=1384192636; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=OXbHo99uqOA8euT2tUkImAmG4XFP9weHT9GWD1HiXcc=; b=jypAwz/WJtscXFGyC6QV4m5cKmMmW74O//HW68KO4umK5nGiu61rgMC1 Yi+xYgE3ujr1XZk8jX2/Flac19G0ntt1k5vj9nNGdqjBbVYerga6cgO76 7JdPOBcbHskohbu+yo23EzoLgVhfTAakcn/5+OgTm5ABCEVhnusybEe5r Y=; X-IronPort-AV: E=Sophos;i="4.93,587,1378857600"; d="scan'208,217";a="18599317" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 28 Oct 2013 17:56:47 +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 r9SHufHM002720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Oct 2013 17:56:43 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9SHudBg015464; Mon, 28 Oct 2013 17:56:40 GMT Message-ID: <526EA557.6010800@cisco.com> Date: Mon, 28 Oct 2013 17:56:39 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: stephane.litkowski@orange.com, "Alvaro Retana (aretana)" Subject: Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt References: <524C02D3.6050309@cisco.com> <18754_1381136403_52527813_18754_7041_1_EEE55384044474429A926C625D0FCC810966AAC932@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: <18754_1381136403_52527813_18754_7041_1_EEE55384044474429A926C625D0FCC810966AAC932@PUEXCB2F.nanterre.francetelecom.fr> Content-Type: multipart/alternative; boundary="------------080801050600010006060107" Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , rogeriomariano , "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: Mon, 28 Oct 2013 17:57:30 -0000 This is a multi-part message in MIME format. --------------080801050600010006060107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 07/10/2013 09:59, stephane.litkowski@orange.com wrote: > > Hi Stewart, > > Here are some old comments you didn't provide on feedback on : > > "Regarding remote LFA draft, I would hope to see some points addressed > in the draft before going to WGLC. > > - It would be good to add some simulation results about how much TLDP > session are required (TX and TX+RX), this in order to make people > aware on how much rLFA may impact their TLDP session scaling > Done > > - We already raised the point some months ago about possibly "interop" > issues in the following cases : > > * PLR choose a PQ which is not able to accept TLDP session : we > verified it in a lab, and we can clearly fall into such situation in a > live network, leading to protection not available. > I will discuss this in a later thread > > * PQ having multiple IP addresses /32 attached, so which one would > be used to establish TLDP session ? Current implementations are using > some heuristics and it would be good to document this > ... and this > > - Current text states that rLFA is computed only when LFA are not > available and our analysis pointed that this is really not a good idea > as in term of manageability rLFA alternate may be better than LFA > alternate. It would be good that rLFA draft points to potential > manageability issues and refers to the appropriate draft. > I have included a management section which states: The management of LFA and remote LFA is the subject of ongoing work withing the IETF [I-D.ietf-rtgwg-lfa-manageability] to which the reader is refered. In contrast to this text which recoommends that LFAs be preferred over remote LFAs, [I-D.ietf-rtgwg-lfa-manageability] notes that there may be reason to use remote LFAs even if ordinary LFAs are available. This requires further study. Hopefully this addresses this point. Stewart > " > > Thanks > > Stephane > > *Stephane Litkowski* > FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE > > Operational Engineering & Support IPTAC for RAEI network > > Orange Expert Network of Future > tél. +33 2 23 28 49 83 > > mob. +33 6 37 86 97 52 > stephane.litkowski@orange.com > > *De :*rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] *De la > part de* Stewart Bryant > *Envoyé :* mercredi 2 octobre 2013 13:26 > *À :* Alvaro Retana (aretana) > *Cc :* draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rogeriomariano; > rtgwg@ietf.org > *Objet :* Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt > > I will try to get a new version out this week or next. > > I plan to put in the algorithm text, although having discussed > this with Mike, our inclination is to include this as an > appendix since it is not required for interoperability that > you do the computation that way. > > I will look at the issues left unresolved and any comments > posted in response to this email. > > I see no reason to request a slot at IETF88 unless there remain > technical issues that we are unable to resolve on this list. > > - Stewart (as duty editor of the draft) > > > > On 01/10/2013 15:40, Alvaro Retana (aretana) wrote: > > On 10/1/13 10:31 AM, "rogeriomariano" > wrote: > > Rogerio: > > Folks, Does anyone know whether the draft deal will be treated > in the IETF 88? > > We haven't started working on the agenda yet, so it is perhaps too > early to talk about whether this draft will be discussed in > Vancouver or not. > > In the meant time, if you have comments or questions on the draft, > please post them to the list. > > Thanks! > > Alvaro. > > > > > _______________________________________________ > > 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 > > _________________________________________________________________________________________________________________________ > > 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, > 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, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------080801050600010006060107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 07/10/2013 09:59, stephane.litkowski@orange.com wrote:

Hi Stewart,

 

Here are some old comments you didn’t provide on feedback on :

 

“Regarding remote LFA draft, I would hope to see some points addressed in the draft before going to WGLC.

- It would be good to add some simulation results about how much TLDP session are required (TX and TX+RX), this in order to make people aware on how much rLFA may impact their TLDP session scaling

Done

 

- We already raised the point some months ago about possibly "interop" issues in the following cases :

    * PLR choose a PQ which is not able to accept TLDP session : we verified it in a lab, and we can clearly fall into such situation in a live network, leading to protection not available.

 

I will discuss this in a later thread

    * PQ having multiple IP addresses /32 attached, so which one would be used to establish TLDP session ? Current implementations are using some heuristics and it would be good to document this

 

... and this

- Current text states that rLFA is computed only when LFA are not available and our analysis pointed that this is really not a good idea as in term of manageability rLFA alternate may be better than LFA alternate. It would be good that rLFA draft points to potential manageability issues and refers to the appropriate draft.

 

 

I have included a management section which states:

The management of LFA and remote LFA is the subject of ongoing work withing the IETF [I-D.ietf-rtgwg-lfa-manageability] to which the reader is refered. In contrast to this text which recoommends that LFAs be preferred over remote LFAs, [I-D.ietf-rtgwg-lfa-manageability] notes that there may be reason to use remote LFAs even if ordinary LFAs are available. This requires further study.

Hopefully this addresses this point.

Stewart

“

 

Thanks

 

Stephane

 

 

 

Stephane Litkowski
FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE

Operational Engineering & Support IPTAC for RAEI network

Orange Expert Network of Future
tél. +33 2 23 28 49 83

mob. +33 6 37 86 97 52
stephane.litkowski@orange.com

De : rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] De la part de Stewart Bryant
Envoyé : mercredi 2 octobre 2013 13:26
À : Alvaro Retana (aretana)
Cc : draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rogeriomariano; rtgwg@ietf.org
Objet : Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

 

I will try to get a new version out this week or next.

I plan to put in the algorithm text, although having discussed
this with Mike, our inclination is to include this as an
appendix since it is not required for interoperability that
you do the computation that way.

I will look at the issues left unresolved and any comments
posted in response to this email.

I see no reason to request a slot at IETF88 unless there remain
technical issues that we are unable to resolve on this list.

- Stewart (as duty editor of the draft)



On 01/10/2013 15:40, Alvaro Retana (aretana) wrote:

On 10/1/13 10:31 AM, "rogeriomariano" <rsouza.rjo@gmail.com> wrote:

 

Rogerio:

 

Folks, Does anyone know whether the draft deal will be treated in the IETF 88?

 

We haven't started working on the agenda yet, so it is perhaps too early to talk about whether this draft will be discussed in Vancouver or not.

 

In the meant time, if you have comments or questions on the draft, please post them to the list.

 

Thanks!

 

Alvaro.




_______________________________________________
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
 
_________________________________________________________________________________________________________________________

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,
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, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------080801050600010006060107-- From stbryant@cisco.com Mon Oct 28 11:25:11 2013 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 E67A621E8090 for ; Mon, 28 Oct 2013 11:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.509 X-Spam-Level: X-Spam-Status: No, score=-110.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbVwu4cAZIVc for ; Mon, 28 Oct 2013 11:25:06 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id BC35511E8155 for ; Mon, 28 Oct 2013 11:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1036; q=dns/txt; s=iport; t=1382984705; x=1384194305; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=TND+r/ovYDTlUUDZ7ux4ZeaOq7vK1Pie/QyaTgfiMYk=; b=e6wPQO+ZCuD382622uTWrLTF6GJKtj4SJhqBen75zxRVbdh0kj1eia79 g8ckH6Io7ZNSf0DU08XOP7XqxBlaOJolQnkVcN5ngboyQvEtNTGlbOshB /lGwGgWfw7BOTIvgWZStIGAX9NAoWv+uieyfNKNdAa7DNqYvN9ZMH31aq A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAKyqblKQ/khN/2dsb2JhbABZgwe/cIEoFnSCJgEBBDhAARALIRYPCQMCAQIBRQYBDAEHAQGIA7hKj1UHhCwDlCqDYJIHgyY X-IronPort-AV: E=Sophos;i="4.93,587,1378857600"; d="scan'208";a="18599760" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 28 Oct 2013 18:25:04 +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 r9SIOxNh021690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Oct 2013 18:25:01 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9SIOww6016989; Mon, 28 Oct 2013 18:24:58 GMT Message-ID: <526EABF9.3080907@cisco.com> Date: Mon, 28 Oct 2013 18:24:57 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: stephane.litkowski@orange.com, Hannes Gredler Subject: Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt References: <524C02D3.6050309@cisco.com> <18754_1381136403_52527813_18754_7041_1_EEE55384044474429A926C625D0FCC810966AAC932@PUEXCB2F.nanterre.francetelecom.fr> <5252D987.5050201@cisco.com> <28731_1381216021_5253AF15_28731_628_1_EEE55384044474429A926C625D0FCC810968F4D3E6@PUEXCB2F.nanterre.francetelecom.fr> <5253D25A.1020600@cisco.com> <52558D00.2000404@cisco.com> <20212_1381392498_52566072_20212_11110_1_EEE55384044474429A926C625D0FCC810968F4E004@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: <20212_1381392498_52566072_20212_11110_1_EEE55384044474429A926C625D0FCC810968F4E004@PUEXCB2F.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , rogeriomariano , "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: Mon, 28 Oct 2013 18:25:12 -0000 How about the following text: To establish an targeted LDP session with a candidate PQ node the repairing node (S) needs to know what IP address PQ is willing to use for targeted LDP sessions. Ideally this is provided by PQ advertising this address in the IGP in use. Which address is used, how this is advertised in the IGP, and whether this is a special IP address or an IP address also used for some other purpose is out of scope for this document and must be specified in an IGP specific RFC. In the absence of a protocol to learn the prefered IP address for targetted LDP, a tie-breaking mechanism is required. Unless otherwise configured, an LSR should attempt a targeted LDP session with the IP address with the lowest numerical value advertised by the target LSR. To determine the lowest numerical value the address is taken in network byte order and cast to an integer of appropriate size. (in case you are wondering about the appropriate size, it to have common v4 and v6 text) - Stewart From stbryant@cisco.com Mon Oct 28 11:28:05 2013 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 C5F0D21E80A5 for ; Mon, 28 Oct 2013 11:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.509 X-Spam-Level: X-Spam-Status: No, score=-110.509 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5jmyq8oyQyi for ; Mon, 28 Oct 2013 11:28:00 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 15A0C11E8155 for ; Mon, 28 Oct 2013 11:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=50129; q=dns/txt; s=iport; t=1382984874; x=1384194474; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; bh=j4MccJR9yR0F/0zivDNtcp/+90Io9qC37we08vj7Ly0=; b=KjoIA1+HHqzfW+FT3fIdMKSpPsLBsy6b5HytBR40Ck12b3VoQQnuodOR LmtAwWZYyW6L13yhA8T2yHbmAdoA1oAU2HS7FqRNzTF/FtqD0duCIPmHs stq8L9qWG8iDvSex3eqXU2k6vEYrz8QRtsNk0y65Ys2K10TYUmNNMxgsm M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAA2sblKQ/khR/2dsb2JhbABPCoJDRDiJRLV0gSkWdIIlAQEBAwEBAQEqPgMKBgsLEQQBAQEJFgEBBgcJAwIBAgEVHwkIBgEMBgIBAYd9Bg24Qo4MBoEhHQsBBoQmA5NohCKSB4MmgXE X-IronPort-AV: E=Sophos;i="4.93,587,1378857600"; d="scan'208,217";a="161108066" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 28 Oct 2013 18:27:51 +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 r9SIRlCI011114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Oct 2013 18:27:48 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9SIRj1n017177; Mon, 28 Oct 2013 18:27:45 GMT Message-ID: <526EACA1.6030703@cisco.com> Date: Mon, 28 Oct 2013 18:27:45 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: stephane.litkowski@orange.com, Chris Bowers , "rtgwg@ietf.org" Subject: Re: algorithm description for draft-ietf-rtgwg-remote-lfa References: <8987a924cffe4af1b2bc2f94a7950a6e@BL2PR05MB113.namprd05.prod.outlook.com> <29995_1381498201_5257FD58_29995_11275_1_EEE55384044474429A926C625D0FCC8109693082C7@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: <29995_1381498201_5257FD58_29995_11275_1_EEE55384044474429A926C625D0FCC8109693082C7@PUEXCB2F.nanterre.francetelecom.fr> Content-Type: multipart/alternative; boundary="------------090704010107080604000101" 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: Mon, 28 Oct 2013 18:28:06 -0000 This is a multi-part message in MIME format. --------------090704010107080604000101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 11/10/2013 14:29, stephane.litkowski@orange.com wrote: > > Completely agree with Chris. > > Moreover having the algorithm part described clearly inside the main > paragraphs of the document rather than the appendix is completely > inline with what has been done for basic LFA specification (RFC 5286 > Paragraph 3.6 -- Selection procedure). > > As mentioned by Chris, it is important to mention that rLFA alternate > must not be dependant on any direct LFA selection. rLFA must be able > to rely on any LFA (Extended P Space) whatever this LFA is best or not. > See version 3 was soon as I can find a home for it and please propose an exact change Stewart > Stephane > > *De :*rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] *De la > part de* Chris Bowers > *Envoyé :* jeudi 10 octobre 2013 19:00 > *À :* rtgwg@ietf.org > *Objet :* RE: algorithm description for draft-ietf-rtgwg-remote-lfa > > Stewart proposed in another thread making this algorithm text part of > an appendix (see snippet below.) I want to emphasize the importance > of adding more quantitative content to the normative sections of the > text, by illustrating an example of the confusion created by some of > the current text. > > Today I was in a discussion regarding the criteria for evaluating for > use as a tunnel endpoint, a node Y in extended-P space which is > reachable from source S by way of S's neighbor N1. Some confusion > arose during the discussion over whether or not the node Y should be > rejected for consideration if policy had been applied rejecting N1 as > a (local)LFA for reaching Y. We agreed that the evaluation of Y as a > tunnel endpoint for remote LFA should not depend on the policy applied > to the (local)LFA to reach Y. > > However, the text below in section 4.2.2 leads to confusion on this > point. > > "Another way to describe extended P-space is that it is the union of ( > > un-extended ) P-space and the set of destinations for which S has a > > per-prefix LFA protecting the link S-E." > > I think this text should be removed and replaced with precise > quantitative criteria for membership in extended P-space. It is > likely that remote LFA will be deployed together with (local)LFA with > policy determining which type of alternate to use > (draft-litkowski-rtgwg-lfa-manageability). Describing remote LFA in > terms of (local)LFA will create confusion for someone trying to apply > policy. Quantitative criteria avoid this confusion. > > If this text creates such confusion among experts, it is likely to > create even more confusion among end-users of the technology, when > trying to figure out what is really going on in their network. While > one might argue that this behavior is up to the vendor to document, > confusing text in the base rlfa draft will make that task much more > difficult. > > --------- > > A response to this algorithm text showed up in another thread so I am > cutting > > and pasting Stewart Bryant's response from 10/2/13 to this thread to > keep things organized. > > [SB] "I plan to put in the algorithm text, although having discussed > > this with Mike, our inclination is to include this as an > > appendix since it is not required for interoperability that > > you do the computation that way." > > --------- > > Chris > > *From:*rtgwg-bounces@ietf.org > [mailto:rtgwg-bounces@ietf.org] *On Behalf Of *Chris Bowers > *Sent:* Wednesday, September 04, 2013 4:22 PM > *To:* rtgwg@ietf.org > *Subject:* algorithm description for draft-ietf-rtgwg-remote-lfa > > As has been pointed out in other email threads, > > the current version of draft-ietf-rtgwg-remote-lfa-02.txt > > lacks a formal description of the algorithm being proposed. > > Below is a such a formal algorithm description, based on my > > reading of the current draft. It would help progress this > > draft forward if the authors would correct any errors > > in this pseudo-code representation of the algorithm. > > The pseudo-code below avoids unnecessary SPF computations, but > > for the sake of readability, it does not otherwise try to > > optimize the code. > > Remote LFA algorithm > > Compute_and_Store_Forward_SPF(node root) > > Compute_Forward_SPF(root) > > foreach node z in network > > store D_opt(root,z) > > Compute_and_Store_Reverse_SPF(node root) > > Compute_Reverse_SPF(root) > > foreach node z in network > > store D_opt(z,root) > > Compute_Neighbor_SPFs() > > foreach interface intf in self > > if (intf.remote_node != fail_intf.remote_node) > > Compute_and_Store_Forward_SPF(intf.remote_node) > > Compute_Extended_P_Space() > > foreach node y in network > > y.in_extended_P_space = false > > if (D_opt(self, y) < > > D_opt(self, fail_intf.remote_node) + > D_opt(fail_intf.remote_node,y)) > > y.in_extended_P_space = true > > foreach interface intf in self > > if (intf.remote_node != fail_intf.remote_node) > > if ( D_opt(intf.remote_node, y) < > D_opt(intf.remote_node, self) + > > D_opt(self,fail_intf.remote_node) + > > D_opt(fail_intf.remote_node,y) ) > > y.in_extended_P_space = true > > Compute_Q_Space() > > Compute_and_Store_Reverse_SPF(fail_intf.remote_node) > > foreach node y in network > > if ( D_opt(y,fail_intf.remote_node) < D_opt(y,self) + > > D_opt(self,fail_intf.remote_node) ) > > y.in_Q_space = true > > else > > y.in_Q_space = false > > Intersect_Extended_P_and_Q_Space() > > foreach node y in network > > if ( y.in_extended_P_space && y.in_Q_space ) > > y.valid_tunnel_endpoint = true > > else > > y.valid_tunnel_endpoint = false > > Apply_Downstream_Constraint() > > foreach node y in network > > if (y.valid_tunnel_endpoint) > > Compute_and_Store_Forward_SPF(y) > > if ((D_opt(y,dest) < D_opt(self,dest)) > > y.valid_tunnel_endpoint = true > > else > > y.valid_tunnel_endpoint = false > > Compute_Neighbor_SPFs() > > Compute_Extended_P_Space() > > Compute_Q_Space() > > Intersect_Extended_P_and_Q_Space() > > if (guarantee_no_looping_on_worse_than_protected_failure) > > Apply_Downstream_Constraint() > > ********** > > I would also like to propose that the following text to be > > inserted after the last paragraph of > > section 4.2.1. "Computing Repair Paths". > > It should be noted that using the Q-space of E as a proxy for the Q-space > > of each destination can result in failing to identify valid remote LFAs. > > The extent to which this reduces the effective protection coverage is > > topology dependent. > > *********** > > Thanks, > > Chris > > _________________________________________________________________________________________________________________________ > > 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, > 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, 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 -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------090704010107080604000101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/10/2013 14:29, stephane.litkowski@orange.com wrote:

Completely agree with Chris.

 

Moreover having the algorithm part described clearly inside the main paragraphs of the document rather than the appendix is completely inline with what has been done for basic LFA specification (RFC 5286 Paragraph 3.6 – Selection procedure).

 

As mentioned by Chris, it is important to mention that rLFA alternate must not be dependant on any direct LFA selection. rLFA must be able to rely on any LFA (Extended P Space) whatever this LFA is best or not.

 

 

See version 3 was soon as I can find a home for it and please propose an exact change

Stewart

Stephane

 

 

De : rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] De la part de Chris Bowers
Envoyé : jeudi 10 octobre 2013 19:00
À : rtgwg@ietf.org
Objet : RE: algorithm description for draft-ietf-rtgwg-remote-lfa

 

Stewart proposed in another thread making this algorithm text part of an appendix (see snippet below.)  I want to emphasize the importance of adding more quantitative content to the normative sections of the text, by illustrating an example of the confusion created by some of the current text.

 

Today I was in a discussion regarding the criteria for evaluating for use as a tunnel endpoint, a node Y in extended-P space which is reachable from source S by way of S’s neighbor N1.  Some confusion arose during the discussion over whether or not the node Y should be rejected for consideration if policy had been applied rejecting N1 as a (local)LFA for reaching Y.  We agreed that the evaluation of Y as a tunnel endpoint for remote LFA should not depend on the policy applied to the (local)LFA to reach Y.

 

However, the text below in section 4.2.2 leads to confusion on this point. 

 

“Another way to describe extended P-space is that it is the union of (

un-extended ) P-space and the set of destinations for which S has a

per-prefix LFA protecting the link S-E.”

 

I think this text should be removed and replaced with precise quantitative criteria for membership in extended P-space.  It is likely that remote LFA will be deployed together with (local)LFA with policy determining which type of alternate to use (draft-litkowski-rtgwg-lfa-manageability).  Describing remote LFA in terms of (local)LFA will create confusion for someone trying to apply policy. Quantitative criteria avoid this confusion. 

 

If this text creates such confusion among experts, it is likely to create even more confusion among end-users of the technology, when trying to figure out what is really going on in their network.  While one might argue that this behavior is up to the vendor to document, confusing text in the base rlfa draft will make that task much more difficult.

 

---------

A response to this algorithm text showed up in another thread so I am cutting

and pasting Stewart Bryant’s response from 10/2/13 to this thread to keep things organized.

 

[SB] “I plan to put in the algorithm text, although having discussed

this with Mike, our inclination is to include this as an

appendix since it is not required for interoperability that

you do the computation that way.”

---------

 

Chris

 

 

From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Chris Bowers
Sent: Wednesday, September 04, 2013 4:22 PM
To: rtgwg@ietf.org
Subject: algorithm description for draft-ietf-rtgwg-remote-lfa

 

As has been pointed out in other email threads,

the current version of draft-ietf-rtgwg-remote-lfa-02.txt

lacks a formal description of the algorithm being proposed.

Below is a such a formal algorithm description, based on my

reading of the current draft.  It would help progress this

draft forward if the authors would correct any errors

in this pseudo-code representation of the algorithm.

 

The pseudo-code below avoids unnecessary SPF computations, but

for the sake of readability, it does not otherwise try to

optimize the code.

 

Remote LFA algorithm

 

Compute_and_Store_Forward_SPF(node root)

    Compute_Forward_SPF(root)

    foreach node z in network

        store D_opt(root,z)

       

Compute_and_Store_Reverse_SPF(node root)

    Compute_Reverse_SPF(root)

    foreach node z in network

        store D_opt(z,root)

 

Compute_Neighbor_SPFs()

    foreach interface intf in self

        if (intf.remote_node != fail_intf.remote_node)

            Compute_and_Store_Forward_SPF(intf.remote_node)

 

Compute_Extended_P_Space()

    foreach node y in network

        y.in_extended_P_space = false

        if (D_opt(self, y) <

                D_opt(self, fail_intf.remote_node) + D_opt(fail_intf.remote_node,y))

            y.in_extended_P_space = true

        foreach interface intf in self

            if (intf.remote_node != fail_intf.remote_node)

                if ( D_opt(intf.remote_node, y) < D_opt(intf.remote_node, self) +

                        D_opt(self,fail_intf.remote_node) +

                        D_opt(fail_intf.remote_node,y) )

                    y.in_extended_P_space = true               

 

Compute_Q_Space()

    Compute_and_Store_Reverse_SPF(fail_intf.remote_node)

    foreach node y in network

        if ( D_opt(y,fail_intf.remote_node) < D_opt(y,self) +

                D_opt(self,fail_intf.remote_node) )

            y.in_Q_space = true

        else

            y.in_Q_space = false

                       

Intersect_Extended_P_and_Q_Space()

    foreach node y in network

        if ( y.in_extended_P_space && y.in_Q_space )

            y.valid_tunnel_endpoint = true

        else

            y.valid_tunnel_endpoint = false

                                       

Apply_Downstream_Constraint()

    foreach node y in network

        if (y.valid_tunnel_endpoint)

            Compute_and_Store_Forward_SPF(y)

            if ((D_opt(y,dest) < D_opt(self,dest))

                y.valid_tunnel_endpoint = true

           else

                y.valid_tunnel_endpoint = false

                               

Compute_Neighbor_SPFs()

Compute_Extended_P_Space()

Compute_Q_Space()

Intersect_Extended_P_and_Q_Space()

if (guarantee_no_looping_on_worse_than_protected_failure)

    Apply_Downstream_Constraint()

 

**********     

 

I would also like to propose that the following text to be

inserted after the last paragraph of

section 4.2.1. "Computing Repair Paths".

 

It should be noted that using the Q-space of E as a proxy for the Q-space

of each destination can result in failing to identify valid remote LFAs. 

The extent to which this reduces the effective protection coverage is

topology dependent.

 

***********

 

Thanks,

Chris

 

 

_________________________________________________________________________________________________________________________

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,
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, 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



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------090704010107080604000101-- From stbryant@cisco.com Mon Oct 28 12:03:52 2013 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 23F6721E80F0 for ; Mon, 28 Oct 2013 12:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.511 X-Spam-Level: X-Spam-Status: No, score=-110.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0Jjf9KScDos for ; Mon, 28 Oct 2013 12:03:47 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id A267621E8095 for ; Mon, 28 Oct 2013 12:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=204; q=dns/txt; s=iport; t=1382987013; x=1384196613; h=message-id:date:from:reply-to:mime-version:to:subject: content-transfer-encoding; bh=cDcn35OLPm9Xd31DosqKaPA9R6u1HLEZDRhrnfV+tSw=; b=ayWLNBAmEA/3pQ3ebN/5K4MvplX2bC7bOtSUlttX04WBtn2lhC6Y+wLv 8icIq9MLlE+BBx6LwQIlQTCBGg+sDXwB6vAPy6p6wSbjAIGrbG7iK/NWh f6yPIsUnDKSf8dB72vJ9mKueG4pz3rpUJRCp2/V2mRO7FBxDPFk2CN+Hw E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAFAEu0blKQ/khM/2dsb2JhbABZgwc4wGEWbQeCZEA9FhgDAgECAUsNCAEBiAMNlnuHAoxTjgAElAgDmAqSB4Mm X-IronPort-AV: E=Sophos;i="4.93,587,1378857600"; d="scan'208";a="87725380" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 28 Oct 2013 19:03:32 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9SJ3Rjb031857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Oct 2013 19:03:29 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9SJ3Q4B019137; Mon, 28 Oct 2013 19:03:27 GMT Message-ID: <526EB4FE.3020507@cisco.com> Date: Mon, 28 Oct 2013 19:03:26 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "rtgwg@ietf.org" Subject: candidate-draft-ietf-rtgwg-remote-lfa-03.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Mon, 28 Oct 2013 19:03:52 -0000 I have edited draft-ietf-rtgwg-remote-lfa-03.txt, and in view of the cut-off have put a copy here: https://www.dropbox.com/s/kahbqvrsww40qua/candidate-draft-ietf-rtgwg-remote-lfa-03.txt Stewart From stephane.litkowski@orange.com Mon Oct 28 18:45:47 2013 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 2B91821F9FFF for ; Mon, 28 Oct 2013 18:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1xTaGw6SQKd for ; Mon, 28 Oct 2013 18:45:38 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id C643921F9FCF for ; Mon, 28 Oct 2013 18:45:06 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 577D5324803; Tue, 29 Oct 2013 02:45:04 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 38071238048; Tue, 29 Oct 2013 02:45:04 +0100 (CET) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.46]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Tue, 29 Oct 2013 02:45:04 +0100 From: To: "stbryant@cisco.com" , Hannes Gredler Date: Tue, 29 Oct 2013 02:42:24 +0100 Subject: RE: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt Thread-Topic: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt Thread-Index: Ac7UCwZ0asFecVeTQ0ykufgbG4Ij0gAPCA2Q Message-ID: <24873_1383011104_526F1320_24873_16663_1_EEE55384044474429A926C625D0FCC8109902E347A@PUEXCB2F.nanterre.francetelecom.fr> References: <524C02D3.6050309@cisco.com> <18754_1381136403_52527813_18754_7041_1_EEE55384044474429A926C625D0FCC810966AAC932@PUEXCB2F.nanterre.francetelecom.fr> <5252D987.5050201@cisco.com> <28731_1381216021_5253AF15_28731_628_1_EEE55384044474429A926C625D0FCC810968F4D3E6@PUEXCB2F.nanterre.francetelecom.fr> <5253D25A.1020600@cisco.com> <52558D00.2000404@cisco.com> <20212_1381392498_52566072_20212_11110_1_EEE55384044474429A926C625D0FCC810968F4E004@PUEXCB2F.nanterre.francetelecom.fr> <526EABF9.3080907@cisco.com> In-Reply-To: <526EABF9.3080907@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: 2013.10.28.221515 Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , rogeriomariano , "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, 29 Oct 2013 01:45:47 -0000 Hi Stewart, It sounds good to me, except for the proposed tie breaker mechanism. As you= know, today there is no existing mechanism for LDP to advertise the TLDP l= istening IP address in the IGP. So in short/mid term rLFA deployment, no IG= P solution would be available. So the draft must propose a last resort "wor= king" tie breaker. IMHO, using the lowest numerical value would be a very b= ad idea ... because this has no sense (just tie break, but without any insu= rance that the chosen prefix would be good) In order to bring more insurance, at least, I think the the tie breaker mus= t check that the prefix used is an internal one (when possible ...) and is = a /32. I don't think we could make something more precise because otherwis= e we would need to address IGP protocol specifities (TLVs, LSAs ... fields = to check...).=20 Thoughts ? -----Message d'origine----- De=A0: Stewart Bryant [mailto:stbryant@cisco.com]=20 Envoy=E9=A0: lundi 28 octobre 2013 19:25 =C0=A0: LITKOWSKI Stephane DTF/DERX; Hannes Gredler Cc=A0: draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rogeriomariano; rtgwg@ie= tf.org Objet=A0: Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt How about the following text: To establish an targeted LDP session with a candidate PQ node the repairing= node (S) needs to know what IP address PQ is willing to use for targeted L= DP sessions. Ideally this is provided by PQ advertising this address in the= IGP in use. Which address is used, how this is advertised in the IGP, and = whether this is a special IP address or an IP address also used for some ot= her purpose is out of scope for this document and must be specified in an I= GP specific RFC. In the absence of a protocol to learn the prefered IP address for targetted= LDP, a tie-breaking mechanism is required. Unless otherwise configured, a= n LSR should attempt a targeted LDP session with the IP address with the lo= west numerical value advertised by the target LSR. To determine the lowest = numerical value the address is taken in network byte order and cast to an i= nteger of appropriate size. (in case you are wondering about the appropriate size, it to have common v4 and v6 text) - Stewart ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From uma.chunduri@ericsson.com Mon Oct 28 23:00:42 2013 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 DC06911E821C for ; Mon, 28 Oct 2013 23:00:39 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5nNP3AIhfUe for ; Mon, 28 Oct 2013 23:00:30 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 59C7A11E821D for ; Mon, 28 Oct 2013 23:00:30 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-bb-526f4efc64d2 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 77.7A.03458.CFE4F625; Tue, 29 Oct 2013 07:00:29 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Tue, 29 Oct 2013 02:00:28 -0400 From: Uma Chunduri To: "stephane.litkowski@orange.com" , "stbryant@cisco.com" , Hannes Gredler Subject: RE: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt Thread-Topic: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt Thread-Index: AQHOV/3DBJ7iO2EWHEGUhMYQHkFiY5ng+PAAgAACb4CAAVwXgIAHss2AgAB0NICAAP6RgIAAKg4AgAGKv4CAAITuAIAA/A4AgBz2Q4CAAHo5AP//500g Date: Tue, 29 Oct 2013 06:00:27 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F0A4694@eusaamb105.ericsson.se> References: <524C02D3.6050309@cisco.com> <18754_1381136403_52527813_18754_7041_1_EEE55384044474429A926C625D0FCC810966AAC932@PUEXCB2F.nanterre.francetelecom.fr> <5252D987.5050201@cisco.com> <28731_1381216021_5253AF15_28731_628_1_EEE55384044474429A926C625D0FCC810968F4D3E6@PUEXCB2F.nanterre.francetelecom.fr> <5253D25A.1020600@cisco.com> <52558D00.2000404@cisco.com> <20212_1381392498_52566072_20212_11110_1_EEE55384044474429A926C625D0FCC810968F4E004@PUEXCB2F.nanterre.francetelecom.fr> <526EABF9.3080907@cisco.com> <24873_1383011104_526F1320_24873_16663_1_EEE55384044474429A926C625D0FCC8109902E347A@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: <24873_1383011104_526F1320_24873_16663_1_EEE55384044474429A926C625D0FCC8109902E347A@PUEXCB2F.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.53.142.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXRPlO5fv/wgg82f2SyWL7jBaNF/7wmb xYeHZ1gsLrz5zWxx7ukcRouvex+yOrB5TPm9kdVj56y77B5Llvxk8rjedJXdo+XZSTaPL5c/ swWwRXHZpKTmZJalFunbJXBlXDgqUHBbqmLbEo4Gxi7RLkZODgkBE4n/52+yQNhiEhfurWfr YuTiEBI4wigx524/E4SznFHiUOdvVpAqNgE9iY9Tf7KDJEQEpjNKnD56hhHEYRZYzSjxcuM2 NpAqYQFriT0TNzCC2CICNhJHpk5gguhoYpS43DkbbCGLgKrE0gcvwMbyCvhKvDnYyw6xr5FN YtLepWAJToEWRonZNzhAbEagC7+fWsMEYjMLiEvcejKfCeJyAYkle84zQ9iiEi8f/wPq5QCy FSQezamAKNeRWLD7ExuErS2xbOFrZoi9ghInZz5hmcAoNgvJ1FlIWmYhaZmFpGUBI8sqRo7S 4tSy3HQjw02MwMg7JsHmuINxwSfLQ4zSHCxK4rxf3joHCQmkJ5akZqemFqQWxReV5qQWH2Jk 4uCUamDstTukHPBCtTv4z0HeMzu1vtlNE/q29M0OBXbppFlnhNcZmm5Ncl10d6u8f+vtDN6r YixrpXuT5C6cmmrQ/56N51OweqKnpY6Jo/+WktMyi/K3qF8ulXl7klPePm2+6L3dSbFsO+4H bGK6kVfwzTNqu1pX3ZyVqmcnX0xl7S+JubNzUcvPPTOVWIozEg21mIuKEwHSbyiFigIAAA== Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , rogeriomariano , "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, 29 Oct 2013 06:00:42 -0000 IMHO, there is no need for tie-breakers here (or it really *can't* help muc= h). This is a non-issue for OSPF. For the other IGP, if this is the perceived problem: (plz confirm) - PQ node may not accept TLDP session from PLR, if PLR chooses an incorrect= =20 IP represented by PQ node (IGP/ISIS database). Because, today there is no document mandates an IP address which effectivel= y=20 represents the ISIS node. We can't *fully* rely on TLV 134 because this is= =20 not mandated for non TE environments.=20 Instead of inventing a new thing here, the closest and one possible approac= h=20 is to have a document which mandates a reachable prefix (loopback) in TLV 1= 34,=20 **regardless of TE present/supported or not**. This is the key and it fully= =20 solves the issue (it's important to note here - though today it's optional = to=20 have TLV 134 per 5305, some vendors including Ericsson do emit this regardl= ess=20 of TE in the local ISIS LSP). Does it make sense? (Les ?) Advantage of this approach is, lot of vendors need not do any thing for thi= s and=20 for the remaining folk who are *not* doing this; should upgrade to have thi= s TLV=20 (probably upgrade may be necessary with any other always "workable" approac= h too)=20 to represent reachable loopback IP address of the node always. Quick replies in-line [Uma]: --=20 Uma C.=20 -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of s= tephane.litkowski@orange.com Sent: Monday, October 28, 2013 6:42 PM To: stbryant@cisco.com; Hannes Gredler Cc: draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rogeriomariano; rtgwg@ietf.= org Subject: RE: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt Hi Stewart, It sounds good to me, except for the proposed tie breaker mechanism. As you= know, today there is no existing mechanism for LDP to advertise the TLDP l= istening IP address in the IGP. So in short/mid term rLFA deployment, no IG= P solution would be available.=20 [Uma]: True, only if a non-TE ISIS node doesn't advertise TLV 134 today. So the draft must propose a last resort "working" tie breaker.=20 [Uma]: If the above is TRUE, I don't think you can do much by defining=20 a "working" tie breaker here. Also, I don't think there is one=20 possible really in that situation. IMHO, using the lowest numerical value would be a very bad idea ... because= this has no sense (just tie break, but without any insurance that the chos= en prefix would be good). In order to bring more insurance, at least, I thi= nk the the tie breaker must check that the prefix used is an internal one (= when possible ...) and is a /32.=20 [Uma]: /32 is fine but you don't know from the TLV if it is a internal pref= ix or=20 external prefix always=20 (IMO, this could be the blocker for proposing any "working" tie brea= ker). I don't think we could make something more precise because otherwise we wou= ld need to address IGP protocol specifities (TLVs, LSAs ... fields to check= ...).=20 [Uma]: I don't think there is any issue for OSPF in this regard (LSA.. as y= ou mentioned) For ISIS (TLV as you said), yes at times one may quickly lost in TLV= 135s, if one wants=20 to really figure out this /32 (TLV 135) is indeed represents the PQ = node. Thoughts ? From stephane.litkowski@orange.com Mon Oct 28 23:35:56 2013 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 BB1ED11E8116 for ; Mon, 28 Oct 2013 23:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DVo5PLEitPU for ; Mon, 28 Oct 2013 23:35:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 02D9911E81C1 for ; Mon, 28 Oct 2013 23:35:46 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 904333B45EF; Tue, 29 Oct 2013 07:35:31 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 6C96823804B; Tue, 29 Oct 2013 07:35:31 +0100 (CET) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.46]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Tue, 29 Oct 2013 07:35:31 +0100 From: To: Uma Chunduri , "stbryant@cisco.com" , Hannes Gredler Date: Tue, 29 Oct 2013 07:35:28 +0100 Subject: RE: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt Thread-Topic: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt Thread-Index: AQHOV/3DBJ7iO2EWHEGUhMYQHkFiY5ng+PAAgAACb4CAAVwXgIAHss2AgAB0NICAAP6RgIAAKg4AgAGKv4CAAITuAIAA/A4AgBz2Q4CAAHo5AP//500ggAAiidA= Message-ID: <24871_1383028531_526F5733_24871_2717_1_EEE55384044474429A926C625D0FCC8109902E3492@PUEXCB2F.nanterre.francetelecom.fr> References: <524C02D3.6050309@cisco.com> <18754_1381136403_52527813_18754_7041_1_EEE55384044474429A926C625D0FCC810966AAC932@PUEXCB2F.nanterre.francetelecom.fr> <5252D987.5050201@cisco.com> <28731_1381216021_5253AF15_28731_628_1_EEE55384044474429A926C625D0FCC810968F4D3E6@PUEXCB2F.nanterre.francetelecom.fr> <5253D25A.1020600@cisco.com> <52558D00.2000404@cisco.com> <20212_1381392498_52566072_20212_11110_1_EEE55384044474429A926C625D0FCC810968F4E004@PUEXCB2F.nanterre.francetelecom.fr> <526EABF9.3080907@cisco.com> <24873_1383011104_526F1320_24873_16663_1_EEE55384044474429A926C625D0FCC8109902E347A@PUEXCB2F.nanterre.francetelecom.fr> <1B502206DFA0C544B7A60469152008633F0A4694@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008633F0A4694@eusaamb105.ericsson.se> 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: 2013.10.29.30615 Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , rogeriomariano , "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, 29 Oct 2013 06:35:56 -0000 Hi Uma, Inline comments, -----Message d'origine----- De=A0: Uma Chunduri [mailto:uma.chunduri@ericsson.com]=20 Envoy=E9=A0: mardi 29 octobre 2013 07:00 =C0=A0: LITKOWSKI Stephane DTF/DERX; stbryant@cisco.com; Hannes Gredler Cc=A0: draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rogeriomariano; rtgwg@ie= tf.org Objet=A0: RE: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt IMHO, there is no need for tie-breakers here (or it really *can't* help muc= h). This is a non-issue for OSPF. [SLI] OSPF is an old time for me :) so plz correct me if I'm wrong.=20 An OSPF router may advertise as an ISIS router many type of prefixes : - internal - external - Stub (Loopback, or non adj network) - transit (interface) What is good in OSPF compared to ISIS, is that we know what are the prefixe= s belonging to the node compared to what is "external" (type 3 or type 5 ..= .). But whatever, you would need to tiebreak and say, I'm only looking at type = 1 LSA. And in type 1 LSA, I would have multiple infos : - OSPF router ID but it may not match the LDP listening IP. Or we have to = say that LDP listening IP must match the IGP Router ID. - Links : Stub, Transit, Virtual ... and in Stub you may have /x and /32 .= .. so you may need to tiebreak ? Do I miss something ? For the other IGP, if this is the perceived problem: (plz confirm) - PQ nod= e may not accept TLDP session from PLR, if PLR chooses an incorrect IP re= presented by PQ node (IGP/ISIS database). [SLI] Right Because, today there is no document mandates an IP address which effectivel= y represents the ISIS node. We can't *fully* rely on TLV 134 because this i= s not mandated for non TE environments.=20 [SLI] Right, TLV134 is not available everywhere .... Instead of inventing a new thing here, the closest and one possible approac= h is to have a document which mandates a reachable prefix (loopback) in TLV= 134, **regardless of TE present/supported or not**. This is the key and it= fully solves the issue (it's important to note here - though today it's op= tional to have TLV 134 per 5305, some vendors including Ericsson do emit th= is regardless of TE in the local ISIS LSP). Does it make sense? (Les ?) [SLI] I'm ok on the principle, but my concern is that this implies that LDP= listening IP would mandatory need to be configured to match the TLV 134. T= his may cause issue in some networks using multiple loopbacks (one loopback= per protocol or service ...). Is this critical or not ? Note that Juniper also always advertise TLV134 based on what I know. The simpler we can do, the better it would be :) Advantage of this approach is, lot of vendors need not do any thing for thi= s and for the remaining folk who are *not* doing this; should upgrade to ha= ve this TLV (probably upgrade may be necessary with any other always "worka= ble" approach too) to represent reachable loopback IP address of the node a= lways. Quick replies in-line [Uma]: -- Uma C.=20 -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of s= tephane.litkowski@orange.com Sent: Monday, October 28, 2013 6:42 PM To: stbryant@cisco.com; Hannes Gredler Cc: draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rogeriomariano; rtgwg@ietf.= org Subject: RE: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt Hi Stewart, It sounds good to me, except for the proposed tie breaker mechanism. As you= know, today there is no existing mechanism for LDP to advertise the TLDP l= istening IP address in the IGP. So in short/mid term rLFA deployment, no IG= P solution would be available.=20 [Uma]: True, only if a non-TE ISIS node doesn't advertise TLV 134 today. [SLI] : yes and no ... TLV134 may not represent the LDP listening IP addres= s ... IGP and LDP are independent and each may have his own configuration. So the draft must propose a last resort "working" tie breaker.=20 [Uma]: If the above is TRUE, I don't think you can do much by defining=20 a "working" tie breaker here. Also, I don't think there is one=20 possible really in that situation. IMHO, using the lowest numerical value would be a very bad idea ... because= this has no sense (just tie break, but without any insurance that the chos= en prefix would be good). In order to bring more insurance, at least, I thi= nk the the tie breaker must check that the prefix used is an internal one (= when possible ...) and is a /32.=20 [Uma]: /32 is fine but you don't know from the TLV if it is a internal pref= ix or=20 external prefix always=20 (IMO, this could be the blocker for proposing any "working" tie brea= ker). [SLI] Right , with TE TLVs in ISIS we are loosing the "external" identifica= tion that's why I added "when possible ...". But /32 is mandatory. I don't think we could make something more precise because otherwise we wou= ld need to address IGP protocol specifities (TLVs, LSAs ... fields to check= ...).=20 [Uma]: I don't think there is any issue for OSPF in this regard (LSA.. as y= ou mentioned) For ISIS (TLV as you said), yes at times one may quickly lost in TLV= 135s, if one wants=20 to really figure out this /32 (TLV 135) is indeed represents the PQ = node. Thoughts ? ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From dirk.goethals@alcatel-lucent.com Tue Oct 29 06:13:25 2013 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 BECD311E8252 for ; Tue, 29 Oct 2013 06:13:25 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxKgWr+u7F18 for ; Tue, 29 Oct 2013 06:13:19 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id B418811E824F for ; Tue, 29 Oct 2013 06:13:18 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r9TDDGfD011073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 29 Oct 2013 08:13:17 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r9TDDFpe005173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 29 Oct 2013 14:13:15 +0100 Received: from [138.203.22.179] (135.239.27.41) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 29 Oct 2013 14:13:15 +0100 Message-ID: <526FB46A.4060908@alcatel-lucent.com> Date: Tue, 29 Oct 2013 14:13:14 +0100 From: Dirk Goethals User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Subject: candidate-draft-ietf-rtgwg-remote-lfa-03.txt Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.41] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 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, 29 Oct 2013 13:13:25 -0000 Stewart, IMHO, the Q-space expressed in cost in section 4.2.1. should be changed from Expressed in cost terms the set of routers {Q} are those for which the shortest path cost E->Q is strictly less than the shortest path cost E->S->Q. into: Expressed in cost terms the set of routers {Q} are those for which the shortest path cost Q->E is strictly less than the shortest path cost Q->S->E. Dirk From stbryant@cisco.com Tue Oct 29 06:14:31 2013 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 3BC0911E8256 for ; Tue, 29 Oct 2013 06:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.513 X-Spam-Level: X-Spam-Status: No, score=-110.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPdEXG4rNJsF for ; Tue, 29 Oct 2013 06:14:25 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A43D911E824F for ; Tue, 29 Oct 2013 06:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8150; q=dns/txt; s=iport; t=1383052463; x=1384262063; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/5Kw70quqwxC94RPOXWHZBnZpzagSW/b+URLv4rTDlM=; b=QhKUyHdtIwJpohnbnWKdwYokq+NrtWyL8rPRURbQk/FxVZwof7HKMEwh sRx3Tc44e2448bdeiMGHvKayvRDShc0VeEJnMzCncLjTBTV1J0oAVhfOK 30fa6oMgr9vVjFs8P/laYwlCGNptc/0G2uyL0gAG+VUCT4L/ErRMGY6m8 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAKuzb1KQ/khM/2dsb2JhbABZgwc4wAWBJxZ0giUBAQEDATIBBUABBQcECxEEAQEBCRYIBwkDAgECATQJCAYBDAEFAgEBF4dmBg25R41+gScdBQcGhCYDk2hCg2CSCIMmgXE X-IronPort-AV: E=Sophos;i="4.93,593,1378857600"; d="scan'208";a="161156836" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 29 Oct 2013 13:14:22 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9TDEH6Y015146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 13:14:19 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9TDEFNH003612; Tue, 29 Oct 2013 13:14:15 GMT Message-ID: <526FB4A7.4070400@cisco.com> Date: Tue, 29 Oct 2013 13:14:15 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: stephane.litkowski@orange.com, Uma Chunduri , Hannes Gredler Subject: Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt References: <524C02D3.6050309@cisco.com> <18754_1381136403_52527813_18754_7041_1_EEE55384044474429A926C625D0FCC810966AAC932@PUEXCB2F.nanterre.francetelecom.fr> <5252D987.5050201@cisco.com> <28731_1381216021_5253AF15_28731_628_1_EEE55384044474429A926C625D0FCC810968F4D3E6@PUEXCB2F.nanterre.francetelecom.fr> <5253D25A.1020600@cisco.com> <52558D00.2000404@cisco.com> <20212_1381392498_52566072_20212_11110_1_EEE55384044474429A926C625D0FCC810968F4E004@PUEXCB2F.nanterre.francetelecom.fr> <526EABF9.3080907@cisco.com> <24873_1383011104_526F1320_24873_16663_1_EEE55384044474429A926C625D0FCC8109902E347A@PUEXCB2F.nanterre.francetelecom.fr> <1B502206DFA0C544B7A60469152008633F0A4694@eusaamb105.ericsson.se> <24871_1383028531_526F5733_24871_2717_1_EEE55384044474429A926C625D0FCC8109902E3492@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: <24871_1383028531_526F5733_24871_2717_1_EEE55384044474429A926C625D0FCC8109902E3492@PUEXCB2F.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "draft-ietf-rtgwg-remote-lfa@tools.ietf.org" , rogeriomariano , "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: Tue, 29 Oct 2013 13:14:31 -0000 I propose a slight change to the text: In the absence of a protocol to learn the prefered IP address for targetted LDP, a tie-breaking mechanism is required. Unless otherwise configured, an LSR should attempt a targeted LDP session with the *local* IP address with the lowest numerical value advertised by the target LSR. To determine the lowest numerical value the address is taken in network byte order and cast to an integer of appropriate size. This covers three address methods: 1) A documented advertisement protocol, which we all agree is the best way and which we also agree belongs with the protocol group concerned. 2) "Unless otherwise configured" gives the implementer a lot of scope a) Trivially highest instead of lowest b) A locally configured list of OK addresses to look for in the network c) A locally configured list of LSR identifier-address mappings d) Anything else they can think of. (2) Is essentially a local matter 3) local IP address with the lowest numerical This assumes that the implementation is smart enough to figure out which addresses are local and then tells it which one it should pick. It is them up to the operator to makes sure the TLDP is enabled for the lowest local address they assign to the LSR We could remove (3) and require the operator to just configure the useable address set, which is a very simple default mechanism. If anyone thinks we should delete 2 or 3, please say so, or if you think that we need to modify 3, then please propose some text. - Stewart On 29/10/2013 06:35, stephane.litkowski@orange.com wrote: > Hi Uma, > > Inline comments, > > > -----Message d'origine----- > De : Uma Chunduri [mailto:uma.chunduri@ericsson.com] > Envoyé : mardi 29 octobre 2013 07:00 > À : LITKOWSKI Stephane DTF/DERX; stbryant@cisco.com; Hannes Gredler > Cc : draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rogeriomariano; rtgwg@ietf.org > Objet : RE: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt > > IMHO, there is no need for tie-breakers here (or it really *can't* help much). > > This is a non-issue for OSPF. > > [SLI] OSPF is an old time for me :) so plz correct me if I'm wrong. > An OSPF router may advertise as an ISIS router many type of prefixes : > - internal > - external > - Stub (Loopback, or non adj network) > - transit (interface) > > What is good in OSPF compared to ISIS, is that we know what are the prefixes belonging to the node compared to what is "external" (type 3 or type 5 ...). > But whatever, you would need to tiebreak and say, I'm only looking at type 1 LSA. And in type 1 LSA, I would have multiple infos : > - OSPF router ID but it may not match the LDP listening IP. Or we have to say that LDP listening IP must match the IGP Router ID. > - Links : Stub, Transit, Virtual ... and in Stub you may have /x and /32 ... so you may need to tiebreak ? > > Do I miss something ? > > > For the other IGP, if this is the perceived problem: (plz confirm) - PQ node may not accept TLDP session from PLR, if PLR chooses an incorrect IP represented by PQ node (IGP/ISIS database). > > [SLI] Right > > Because, today there is no document mandates an IP address which effectively represents the ISIS node. We can't *fully* rely on TLV 134 because this is not mandated for non TE environments. > > [SLI] Right, TLV134 is not available everywhere .... > > Instead of inventing a new thing here, the closest and one possible approach is to have a document which mandates a reachable prefix (loopback) in TLV 134, **regardless of TE present/supported or not**. This is the key and it fully solves the issue (it's important to note here - though today it's optional to have TLV 134 per 5305, some vendors including Ericsson do emit this regardless of TE in the local ISIS LSP). Does it make sense? (Les ?) > > [SLI] I'm ok on the principle, but my concern is that this implies that LDP listening IP would mandatory need to be configured to match the TLV 134. This may cause issue in some networks using multiple loopbacks (one loopback per protocol or service ...). Is this critical or not ? > Note that Juniper also always advertise TLV134 based on what I know. > The simpler we can do, the better it would be :) > > Advantage of this approach is, lot of vendors need not do any thing for this and for the remaining folk who are *not* doing this; should upgrade to have this TLV (probably upgrade may be necessary with any other always "workable" approach too) to represent reachable loopback IP address of the node always. > > Quick replies in-line [Uma]: > > > -- > Uma C. > > > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com > Sent: Monday, October 28, 2013 6:42 PM > To: stbryant@cisco.com; Hannes Gredler > Cc: draft-ietf-rtgwg-remote-lfa@tools.ietf.org; rogeriomariano; rtgwg@ietf.org > Subject: RE: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt > > Hi Stewart, > > It sounds good to me, except for the proposed tie breaker mechanism. As you know, today there is no existing mechanism for LDP to advertise the TLDP listening IP address in the IGP. So in short/mid term rLFA deployment, no IGP solution would be available. > > [Uma]: True, only if a non-TE ISIS node doesn't advertise TLV 134 today. > > [SLI] : yes and no ... TLV134 may not represent the LDP listening IP address ... IGP and LDP are independent and each may have his own configuration. > > > So the draft must propose a last resort "working" tie breaker. > > [Uma]: If the above is TRUE, I don't think you can do much by defining > a "working" tie breaker here. Also, I don't think there is one > possible really in that situation. > > > IMHO, using the lowest numerical value would be a very bad idea ... because this has no sense (just tie break, but without any insurance that the chosen prefix would be good). In order to bring more insurance, at least, I think the the tie breaker must check that the prefix used is an internal one (when possible ...) and is a /32. > > [Uma]: /32 is fine but you don't know from the TLV if it is a internal prefix or > external prefix always > (IMO, this could be the blocker for proposing any "working" tie breaker). > > [SLI] Right , with TE TLVs in ISIS we are loosing the "external" identification that's why I added "when possible ...". But /32 is mandatory. > > > I don't think we could make something more precise because otherwise we would need to address IGP protocol specifities (TLVs, LSAs ... fields to check...). > > [Uma]: I don't think there is any issue for OSPF in this regard (LSA.. as you mentioned) > For ISIS (TLV as you said), yes at times one may quickly lost in TLV 135s, if one wants > to really figure out this /32 (TLV 135) is indeed represents the PQ node. > > Thoughts ? > > > _________________________________________________________________________________________________________________________ > > 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, > 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, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From cbowers@juniper.net Tue Oct 29 08:39:58 2013 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 361AE11E8302 for ; Tue, 29 Oct 2013 08:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.724 X-Spam-Level: X-Spam-Status: No, score=-3.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgQ+7xnLDE3o for ; Tue, 29 Oct 2013 08:39:29 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 2357B21E817A for ; Tue, 29 Oct 2013 08:39:10 -0700 (PDT) Received: from mail50-ch1-R.bigfish.com (10.43.68.242) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.22; Tue, 29 Oct 2013 15:39:05 +0000 Received: from mail50-ch1 (localhost [127.0.0.1]) by mail50-ch1-R.bigfish.com (Postfix) with ESMTP id 0E54A2C0383; Tue, 29 Oct 2013 15:39:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -37 X-BigFish: VPS-37(z21aIL6cdkz9371I542Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh8275dh1de097h186068hz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1fe8h1ff5h2216h9a9j1155h) Received-SPF: pass (mail50-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=cbowers@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(189002)(199002)(13464003)(5383001)(56776001)(74876001)(76482001)(54316002)(47976001)(4396001)(81342001)(81542001)(49866001)(77982001)(63696002)(69226001)(33646001)(85306002)(80976001)(15975445006)(50986001)(79102001)(19580395003)(80022001)(74366001)(47736001)(65816001)(83322001)(51856001)(66066001)(19580405001)(81816001)(76796001)(76176001)(76786001)(74316001)(56816003)(76576001)(81686001)(74706001)(54356001)(59766001)(46102001)(53806001)(74662001)(74502001)(31966008)(47446002)(83072001)(87266001)(17413003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB290; H:BLUPR05MB292.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail50-ch1 (localhost.localdomain [127.0.0.1]) by mail50-ch1 (MessageSwitch) id 138306114330503_29123; Tue, 29 Oct 2013 15:39:03 +0000 (UTC) Received: from CH1EHSMHS001.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.233]) by mail50-ch1.bigfish.com (Postfix) with ESMTP id 0393A1C0404; Tue, 29 Oct 2013 15:39:03 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 29 Oct 2013 15:38:58 +0000 Received: from BLUPR05MB290.namprd05.prod.outlook.com (10.141.23.24) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Tue, 29 Oct 2013 15:38:58 +0000 Received: from BLUPR05MB292.namprd05.prod.outlook.com (10.141.23.27) by BLUPR05MB290.namprd05.prod.outlook.com (10.141.23.24) with Microsoft SMTP Server (TLS) id 15.0.785.10; Tue, 29 Oct 2013 15:38:57 +0000 Received: from BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) by BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) with mapi id 15.00.0785.001; Tue, 29 Oct 2013 15:38:57 +0000 From: Chris Bowers To: "stbryant@cisco.com" , "rtgwg@ietf.org" Subject: issue #1 in candidate-draft-ietf-rtgwg-remote-lfa-03.txt Thread-Topic: issue #1 in candidate-draft-ietf-rtgwg-remote-lfa-03.txt Thread-Index: Ac7UvIapI+8oihNASsaCdS7uB0EpMw== Date: Tue, 29 Oct 2013 15:38:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 0014E2CF50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 29 Oct 2013 15:39:58 -0000 The text should use "repair tunnel endpoint" instead of "PQ node" when not = specifically referring to a node identified by the cost-based RLFA algorith= m in section 4.3. =20 Section 3.1 describes the conditions that a node should satisfy to function= as a viable repair tunnel endpoint. In general, a node can be a valid rep= air tunnel endpoint (satisfying the conditions of section 3.1) without bein= g a PQ-node (since the Q-space calculation is an approximation). I propose the following changes in the text to address this: Section 1: "Remote LFA - The tail-end of a repair tunnel. This tail-end is a member of both the extended-P space the Q space. It is also termed a "PQ" node." becomes: "Remote LFA - The tail-end of a repair tunnel. A PQ node is always a viabl= e repair tunnel endpoint,=20 but a viable repair tunnel endpoint is not necessarily a PQ node. " Section 3.1: "In this document such a tunnel is termed a repair tunnel. The tail-end of= this tunnel is=20 called a "remote LFA" or a "PQ node". becomes: "In this document such a tunnel is termed a repair tunnel. The tail-end of= this tunnel is=20 called a "repair tunnel endpoint". Section 3.2: "The authors simply note that deployment in an MPLS/ LDP environment is extremely simple and straight-forward as an LDP LSP from S to the PQ node is readily available," becomes: "The authors simply note that deployment in an MPLS/ LDP environment is extremely simple and straight-forward as an LDP LSP from S to the repair tunnel endpoint is readily available," "the decapsulation occurs naturally at the penultimate hop before the PQ node." becomes: "the decapsulation occurs naturally at the penultimate hop before the repair tunnel endpoint." Section 4.2.1: " In Figure 1 the intersection of the E's Q-space with S's P-space defines = the set of viable repair tunnel end-points, known as "PQ nodes". " becomes: " In Figure 1 the intersection of the E's Q-space with S's P-space defines = a set of viable repair tunnel end-points, known as "PQ nodes". " Section 6: "1. Detect when a packet has arrived on some interface I that is also the interface used to reach the first hop on the RLFA path to PQ, and drop the packet. This is useful in the case of a ring topology." becomes: 1. Detect when a packet has arrived on some interface I that is also the interface used to reach the first hop on the RLFA path to the r= epair tunnel endpoint, and drop the packet. This is useful in the case of a ring topology." And: "2. Require that the path from PQ to destination D never passes through E (including in the ECMP case), i.e. only use node protecting paths in which the cost PQ to D is strictly less than the cost PQ to E plus the cost E to D." becomes: "2. Require that the path from the tunnel endpoint to destination D never = passes through E (including in the ECMP case), i.e. only use node protecting paths in which the cost from tunnel endpoint to D is stri= ctly less than the cost from tunnel endpoint to E plus the cost E to D." Section 7 has several references to PQ where a generic reference to repair = tunnel endpoint is more appropriate. Proposed text is shown below. =20 Where this technique is used in an MPLS network using LDP [RFC5036], S will need to push two labels onto the repair packet. First it needs to push the label used by the repair tunnel endpoint to reach the = destination, and then it needs to push its own label for the tunnel endpoint. In the example Section 3.1 = [sic], C plays the role of the tunnel endpoint. S already has the first hop (B) label for node C as a result of the ordinary operation of LDP. To get the label used by C for the destination (D), S needs to establish a targeted LDP session with C. The label stack for normal operation and RLFA operation is shown below in Figure 4. To establish an targeted LDP session with a candidate tunnel endpoint no= de the repairing node (S) needs to know what IP address the tunnel endpoint is = willing to use for targeted LDP sessions. Ideally this is provided by the tunnel endpo= int advertising this address in the IGP in use. Which address is used, how this is advertised in the IGP, and whether this is a special IP address or an IP address also used for some other purpose is out of scope for this document and must be specified in an IGP specific RFC. Note that the existing reference to "the example section 3.1" is not clear. -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of S= tewart Bryant Sent: Monday, October 28, 2013 2:03 PM To: rtgwg@ietf.org Subject: candidate-draft-ietf-rtgwg-remote-lfa-03.txt I have edited draft-ietf-rtgwg-remote-lfa-03.txt, and in view of the cut-of= f have put a copy here: https://www.dropbox.com/s/kahbqvrsww40qua/candidate-draft-ietf-rtgwg-remote= -lfa-03.txt Stewart _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From stephane.litkowski@orange.com Tue Oct 29 08:21:19 2013 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 5CE4611E82CE for ; Tue, 29 Oct 2013 08:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=-0.953, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_SAVELE=2.3, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Os6+lw0KrP20 for ; Tue, 29 Oct 2013 08:21:15 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id DD97211E830D for ; Tue, 29 Oct 2013 08:20:05 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 3ECDE3B468A; Tue, 29 Oct 2013 16:20:05 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 259D74C071; Tue, 29 Oct 2013 16:20:05 +0100 (CET) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.46]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Tue, 29 Oct 2013 16:20:05 +0100 From: To: "stbryant@cisco.com" , "rtgwg@ietf.org" Date: Tue, 29 Oct 2013 16:20:02 +0100 Subject: RE: candidate-draft-ietf-rtgwg-remote-lfa-03.txt Thread-Topic: candidate-draft-ietf-rtgwg-remote-lfa-03.txt Thread-Index: Ac7UEHRSgr6YmoNZQs+GGZpNkNeNiwAqc3YA Message-ID: <25279_1383060005_526FD225_25279_12273_1_EEE55384044474429A926C625D0FCC8109902E372B@PUEXCB2F.nanterre.francetelecom.fr> References: <526EB4FE.3020507@cisco.com> In-Reply-To: <526EB4FE.3020507@cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/mixed; boundary="_002_EEE55384044474429A926C625D0FCC8109902E372BPUEXCB2Fnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.10.29.94515 X-Mailman-Approved-At: Tue, 29 Oct 2013 09:31:11 -0700 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, 29 Oct 2013 15:21:19 -0000 --_002_EEE55384044474429A926C625D0FCC8109902E372BPUEXCB2Fnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Stewart, I attached my review -----Message d'origine----- De=A0: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] De la part de= Stewart Bryant Envoy=E9=A0: lundi 28 octobre 2013 20:03 =C0=A0: rtgwg@ietf.org Objet=A0: candidate-draft-ietf-rtgwg-remote-lfa-03.txt I have edited draft-ietf-rtgwg-remote-lfa-03.txt, and in view of the cut-of= f have put a copy here: https://www.dropbox.com/s/kahbqvrsww40qua/candidate-draft-ietf-rtgwg-remote= -lfa-03.txt Stewart _______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_002_EEE55384044474429A926C625D0FCC8109902E372BPUEXCB2Fnante_ Content-Type: text/plain; name="candidate-draft-ietf-rtgwg-remote-lfa-03-SLI reviewed.txt" Content-Description: candidate-draft-ietf-rtgwg-remote-lfa-03-SLI reviewed.txt Content-Disposition: attachment; filename="candidate-draft-ietf-rtgwg-remote-lfa-03-SLI reviewed.txt"; size=54673; creation-date="Tue, 29 Oct 2013 04:30:11 GMT"; modification-date="Tue, 29 Oct 2013 06:12:56 GMT" Content-Transfer-Encoding: base64 CgoKCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFMuIEJyeWFudApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgQy4gRmlsc2ZpbHMKSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTLiBQcmV2aWRpCkV4cGly ZXM6IE1heSAwMSwgMjAxNCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2lz Y28gU3lzdGVtcwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgTS4gU2hhbmQKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEluZGVwZW5kZW50IENvbnRyaWJ1dG9yCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOLiBT bwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRh dGEgQ29tbXVuaWNhdGlvbnMKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBPY3RvYmVyIDI4LCAyMDEzCgoKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBSZW1vdGUgTEZBIEZSUgogICAgICAgICAgICAgICAgICAgICBjYW5kaWRhdGUtZHJh ZnQtaWV0Zi1ydGd3Zy1yZW1vdGUtbGZhLTAzCgpBYnN0cmFjdAoKICAgVGhpcyBkcmFmdCBkZXNj cmliZXMgYW4gZXh0ZW5zaW9uIHRvIHRoZSBiYXNpYyBJUCBmYXN0IHJlLXJvdXRlCiAgIG1lY2hh bmlzbSBkZXNjcmliZWQgaW4gUkZDNTI4NiB0aGF0IHByb3ZpZGVzIGFkZGl0aW9uYWwgYmFja3Vw CiAgIGNvbm5lY3Rpdml0eSBmb3IgbGluayBmYWlsdXJlcyB3aGVuIG5vbmUgY2FuIGJlIHByb3Zp ZGVkIGJ5IHRoZSBiYXNpYwogICBtZWNoYW5pc21zLgoKUmVxdWlyZW1lbnRzIExhbmd1YWdlCgog ICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwg IlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJN QVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnBy ZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDMjExOSBbUkZDMjExOV0uCgpTdGF0dXMgb2YgVGhpcyBN ZW1vCgogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1h bmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuCgogICBJbnRl cm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVl cmluZwogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFs c28gZGlzdHJpYnV0ZQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBU aGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQogICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUg ZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQg bWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRz IGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJh ZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBh cyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJl IG9uIE1heSAwMSwgMjAxNC4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoYykgMjAx MyBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQogICBkb2N1bWVu dCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCgoKQnJ5YW50LCBldCBhbC4gICAgICAg ICAgICBFeHBpcmVzIE1heSAwMSwgMjAxNCAgICAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBSZW1vdGUgTEZBIEZSUiAgICAgICAgICAgICAgICAg T2N0b2JlciAyMDEzCgoKICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQg dGhlIElFVEYgVHJ1c3QncyBMZWdhbAogICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9j dW1lbnRzCiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVj dCBvbiB0aGUgZGF0ZSBvZgogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNl IHJldmlldyB0aGVzZSBkb2N1bWVudHMKICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlv dXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0CiAgIHRvIHRoaXMgZG9jdW1l bnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0CiAg IGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0 aW9uIDQuZSBvZgogICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVk IHdpdGhvdXQgd2FycmFudHkgYXMKICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBM aWNlbnNlLgoKVGFibGUgb2YgQ29udGVudHMKCiAgIDEuICBUZXJtaW5vbG9neSAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMgogICAyLiAgSW50cm9k dWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg IDMKICAgMy4gIFJlcGFpciBQYXRocyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gICA0CiAgICAgMy4xLiAgVHVubmVscyBhcyBSZXBhaXIgUGF0aHMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQogICAgIDMuMi4gIFR1bm5lbCBSZXF1 aXJlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUKICAgNC4g IENvbnN0cnVjdGlvbiBvZiBSZXBhaXIgUGF0aHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gICA2CiAgICAgNC4xLiAgSWRlbnRpZnlpbmcgUmVxdWlyZWQgVHVubmVsZWQgUmVwYWly IFBhdGhzICAuIC4gLiAuIC4gLiAuICAgNgogICAgIDQuMi4gIERldGVybWluaW5nIFR1bm5lbCBF bmQgUG9pbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDYKICAgICAgIDQuMi4xLiAg Q29tcHV0aW5nIFJlcGFpciBQYXRocyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3 CiAgICAgICA0LjIuMi4gIEV4dGVuZGVkIFAtc3BhY2UgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgOAogICAgICAgNC4yLjMuICBTZWxlY3RpbmcgUmVwYWlyIFBhdGhzICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgKICAgICA0LjMuICBBIENvc3QgQmFzZWQg UkxGQSBBbGdvcml0aG0gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA5CiAgIDUuICBF eGFtcGxlIEFwcGxpY2F0aW9uIG9mIFJlbW90ZSBMRkFzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAxMgogICA2LiAgTm9kZSBGYWlsdXJlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgMTMKICAgNy4gIE9wZXJhdGlvbiBpbiBhbiBMRFAgZW52aXJv bm1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE0CiAgIDguICBBbmFseXNpcyBv ZiBSZWFsIFdvcmxkIFRvcG9sb2dpZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNQog ICAgIDguMS4gIFRvcG9sb2d5IERldGFpbHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgMTUKICAgICA4LjIuICBMRkEgb25seSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE2CiAgICAgOC4zLiAgUkxGQSAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNwogICAgIDguNC4g IENvbXBhcmlzb24gb2YgTEZBIGFuIFJMRkEgcmVzdWx0cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgMTgKICAgOS4gIE1hbmFnZW1lbnQgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDE5CiAgIDEwLiBIaXN0b3JpY2FsIE5vdGUgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxOQogICAxMS4gSUFOQSBDb25zaWRl cmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjAKICAg MTIuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDIwCiAgIDEzLiBBY2tub3dsZWRnbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMAogICAxNC4gSW5mb3JtYXRpdmUgUmVmZXJlbmNl cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjAKICAgQXV0aG9ycycg QWRkcmVzc2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDIyCgoxLiAgVGVybWlub2xvZ3kKCiAgIFRoaXMgZHJhZnQgdXNlcyB0aGUgdGVybXMgZGVmaW5l ZCBpbiBbUkZDNTcxNF0uICBUaGlzIHNlY3Rpb24gZGVmaW5lcwogICBhZGRpdGlvbmFsIHRlcm1z IHVzZWQgaW4gdGhpcyBkcmFmdC4KCiAgIEV4dGVuZGVkIFAtc3BhY2UKCgoKCgpCcnlhbnQsIGV0 IGFsLiAgICAgICAgICAgIEV4cGlyZXMgTWF5IDAxLCAyMDE0ICAgICAgICAgICAgICAgICAgW1Bh Z2UgMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIFJlbW90ZSBMRkEgRlJSICAgICAg ICAgICAgICAgICBPY3RvYmVyIDIwMTMKCgogICAgICAgICAgICAgICAgICBUaGUgdW5pb24gb2Yg dGhlIFAtc3BhY2Ugb2YgdGhlIG5laWdoYm91cnMgb2YgYQogICAgICAgICAgICAgICAgICBzcGVj aWZpYyByb3V0ZXIgd2l0aCByZXNwZWN0IHRvIHRoZSBwcm90ZWN0ZWQgbGluawogICAgICAgICAg ICAgICAgICAoc2VlIFNlY3Rpb24gNC4yLjIpLgoKICAgUC1zcGFjZSAgICAgICAgUC1zcGFjZSBp cyB0aGUgc2V0IG9mIHJvdXRlcnMgcmVhY2hhYmxlIGZyb20gYQogICAgICAgICAgICAgICAgICBz cGVjaWZpYyByb3V0ZXIgd2l0aG91dCBhbnkgcGF0aCAoaW5jbHVkaW5nIGVxdWFsIGNvc3QKICAg ICAgICAgICAgICAgICAgcGF0aCBzcGxpdHMpIHRyYW5zaXRpbmcgdGhlIHByb3RlY3RlZCBsaW5r LgoKICAgICAgICAgICAgICAgICAgRm9yIGV4YW1wbGUsIHRoZSBQLXNwYWNlIG9mIFMsIGlzIHRo ZSBzZXQgb2Ygcm91dGVycwogICAgICAgICAgICAgICAgICB0aGF0IFMgY2FuIHJlYWNoIHdpdGhv dXQgdXNpbmcgdGhlIHByb3RlY3RlZCBsaW5rIFMtRS4KCiAgIFBRIG5vZGUgICAgICAgIEEgbm9k ZSB3aGljaCBpcyBhIG1lbWJlciBvZiBib3RoIHRoZSBleHRlbmRlZCBQLXNwYWNlCiAgICAgICAg ICAgICAgICAgIGFuZCB0aGUgUS1zcGFjZS4KCiAgIFEtc3BhY2UgICAgICAgIFEtc3BhY2UgaXMg dGhlIHNldCBvZiByb3V0ZXJzIGZyb20gd2hpY2ggYSBzcGVjaWZpYwogICAgICAgICAgICAgICAg ICByb3V0ZXIgY2FuIGJlIHJlYWNoZWQgd2l0aG91dCBhbnkgcGF0aCAoaW5jbHVkaW5nCiAgICAg ICAgICAgICAgICAgIGVxdWFsIGNvc3QgcGF0aCBzcGxpdHMpIHRyYW5zaXRpbmcgdGhlIHByb3Rl Y3RlZCBsaW5rLgoKW1NMSV0gU2hvdWxkIHN3YXAgUS1TcGFjZSBhbmQgUFEgbm9kZSBkZWZpbml0 aW9uIHBsYWNlbWVudCwgYXMgUFEgbm9kZSByZWZlcnMgdG8gUS1TcGFjZSBkZWZpbml0aW9uLgoJ CQkJICAKICAgUmVwYWlyIHR1bm5lbCAgQSB0dW5uZWwgZXN0YWJsaXNoZWQgZm9yIHRoZSBwdXJw b3NlIG9mIHByb3ZpZGluZyBhCiAgICAgICAgICAgICAgICAgIHZpcnR1YWwgbmVpZ2hib3Igd2hp Y2ggaXMgYSBMb29wIEZyZWUgQWx0ZXJuYXRlLgoKICAgUmVtb3RlIExGQSAgICAgVGhlIHRhaWwt ZW5kIG9mIGEgcmVwYWlyIHR1bm5lbC4gIFRoaXMgdGFpbC1lbmQgaXMgYQogICAgICAgICAgICAg ICAgICBtZW1iZXIgb2YgYm90aCB0aGUgZXh0ZW5kZWQtUCBzcGFjZSB0aGUgUSBzcGFjZS4gIEl0 CiAgICAgICAgICAgICAgICAgIGlzIGFsc28gdGVybWVkIGEgIlBRIiBub2RlLgoKICAgSW4gdGhp cyBkb2N1bWVudCB3ZSB1c2UgdGhlIG5vdGF0aW9uIFgtWSB0byBtZWFuIHRoZSBwYXRoIGZyb20g WCB0byBZCiAgIG92ZXIgdGhlIGxpbmsgZGlyZWN0bHkgY29ubmVjdGluZyBYIGFuZCBZLCB3aGls c3QgdGhlIG5vdGF0aW9uIFgtPlkKICAgcmVmZXJzIHRvIHRoZSBzaG9ydGVzdCBwYXRoIGZyb20g WCB0byBZIHZpYSBzb21lIHNldCBvZiB1bnNwZWNpZmllZAogICBub2RlcyBpbmNsdWRpbmcgdGhl IG51bGwgc2V0IChpLmUuIGluY2x1ZGluZyBvdmVyIGEgbGluayBkaXJlY3RseQogICBjb25uZWN0 aW5nIFggYW5kIFkpLgoKMi4gIEludHJvZHVjdGlvbgoKICAgUkZDIDU3MTQgW1JGQzU3MTRdIGRl c2NyaWJlcyBhIGZyYW1ld29yayBmb3IgSVAgRmFzdCBSZS1yb3V0ZSBhbmQKICAgcHJvdmlkZXMg YSBzdW1tYXJ5IG9mIHZhcmlvdXMgcHJvcG9zZWQgSVBGUlIgc29sdXRpb25zLiAgQSBiYXNpYwog ICBtZWNoYW5pc20gdXNpbmcgbG9vcC1mcmVlIGFsdGVybmF0ZXMgKExGQXMpIGlzIGRlc2NyaWJl ZCBpbiBbUkZDNTI4Nl0KICAgdGhhdCBwcm92aWRlcyBnb29kIHJlcGFpciBjb3ZlcmFnZSBpbiBt YW55CiAgIHRvcG9sb2dpZXNbSS1ELmZpbHNmaWxzLXJ0Z3dnLWxmYS1hcHBsaWNhYmlsaXR5XSwg ZXNwZWNpYWxseSB0aG9zZQogICB0aGF0IGFyZSBoaWdobHkgbWVzaGVkLiAgSG93ZXZlciwgc29t ZSB0b3BvbG9naWVzLCBub3RhYmx5IHJpbmcgYmFzZWQKICAgdG9wb2xvZ2llcyBhcmUgbm90IHdl bGwgcHJvdGVjdGVkIGJ5IExGQXMgYWxvbmUuICBUaGlzIGlzIGlsbHVzdHJhdGVkCiAgIGluIEZp Z3VyZSAxIGJlbG93LgogICAKICAgW1NMSV0gUmVwbGFjZSBbSS1ELmZpbHNmaWxzLXJ0Z3dnLWxm YS1hcHBsaWNhYmlsaXR5XSBieSBSRkM2NTcxCiAgIAoKICAgICAgICAgICAgIFMtLS1FCiAgICAg ICAgICAgIC8gICAgIFwKICAgICAgICAgICBBICAgICAgIEQKICAgICAgICAgICAgXCAgICAgLwog ICAgICAgICAgICAgQi0tLUMKCgoKCkJyeWFudCwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBN YXkgMDEsIDIwMTQgICAgICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICAgUmVtb3RlIExGQSBGUlIgICAgICAgICAgICAgICAgIE9jdG9iZXIgMjAxMwoK CiAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxOiBBIHNpbXBsZSByaW5nIHRvcG9sb2d5Cgog ICBJZiBhbGwgbGluayBjb3N0cyBhcmUgZXF1YWwsIHRoZSBsaW5rIFMtRSBjYW5ub3QgYmUgZnVs bHkgcHJvdGVjdGVkCiAgIGJ5IExGQXMuICBUaGUgZGVzdGluYXRpb24gQyBpcyBhbiBFQ01QIGZy b20gUywgYW5kIHNvIGNhbiBiZQogICBwcm90ZWN0ZWQgd2hlbiBTLUUgZmFpbHMsIGJ1dCBEIGFu ZCBFIGFyZSBub3QgcHJvdGVjdGFibGUgdXNpbmcgTEZBcwoKICAgVGhpcyBkcmFmdCBkZXNjcmli ZXMgZXh0ZW5zaW9ucyB0byB0aGUgYmFzaWMgKFtTTEldIGFkZCAiYmFzaWMgTEZBIHJlcGFpciAu Li4iKSByZXBhaXIgbWVjaGFuaXNtIGluCiAgIHdoaWNoIHR1bm5lbHMgYXJlIHVzZWQgdG8gcHJv dmlkZSBhZGRpdGlvbmFsIGxvZ2ljYWwgbGlua3Mgd2hpY2ggY2FuCiAgIHRoZW4gYmUgdXNlZCBh cyBsb29wIGZyZWUgYWx0ZXJuYXRlcyB3aGVyZSBub25lIGV4aXN0IGluIHRoZSBvcmlnaW5hbAog ICB0b3BvbG9neS4gIEZvciBleGFtcGxlIGlmIGEgdHVubmVsIGlzIHByb3ZpZGVkIGJldHdlZW4g UyBhbmQgQyBhcwogICBzaG93biBpbiBGaWd1cmUgMiB0aGVuIEMsIG5vdyBiZWluZyBhIGRpcmVj dCBuZWlnaGJvciBvZiBTIHdvdWxkCiAgIGJlY29tZSBhbiBMRkEgZm9yIEQgYW5kIEUuIFRoZSBu b24tZmFpbHVyZSB0cmFmZmljIGRpc3RyaWJ1dGlvbiBpcwogICBub3QgZGlzcnVwdGVkIGJ5IHRo ZSBwcm92aXNpb24gb2Ygc3VjaCBhIHR1bm5lbCBzaW5jZSBpdCBpcyBvbmx5IHVzZWQKICAgZm9y IHJlcGFpciB0cmFmZmljIGFuZCBNVVNUIE5PVCBiZSB1c2VkIGZvciBub3JtYWwgdHJhZmZpYy4K CiAgICAgICAgICBTLS0tRQogICAgICAgICAvIFwgICBcCiAgICAgICAgQSAgIFwgICBECiAgICAg ICAgIFwgICBcIC8KICAgICAgICAgIEItLS1DCgogICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAy OiBUaGUgYWRkaXRpb24gb2YgYSB0dW5uZWwKCiAgIFRoZSB1c2Ugb2YgdGhpcyB0ZWNobmlxdWUg aXMgbm90IHJlc3RyaWN0ZWQgdG8gcmluZyBiYXNlZCB0b3BvbG9naWVzLAogICBidXQgaXMgYSBn ZW5lcmFsIG1lY2hhbmlzbSB3aGljaCBjYW4gYmUgdXNlZCB0byBlbmhhbmNlIHRoZQogICBwcm90 ZWN0aW9uIHByb3ZpZGVkIGJ5IExGQXMuICBBIHN0dWR5IG9mIHRoZSBwcm90ZWN0aW9uIGFjaGll dmVkCiAgIHVzaW5nIHJlbW90ZSBMRkEgaW4gdHlwaWNhbCBzZXJ2aWNlIHByb3ZpZGVyIGNvcmUg bmV0d29ya3MgaXMKICAgcHJvdmlkZWQgaW4gU2VjdGlvbiA4LCBhbmQgYSBzaWRlIGJ5IHNpZGUg Y29tcGFyaXNvbiBiZXR3ZWVuIExGQSBhbmQKICAgcmVtb3RlIExGQSBpcyBwcm92aWRlZCBpbiBT ZWN0aW9uIDguNC4KCiAgIFJlbW90ZSBMRkEgaXMgc3VpdGFibGUgZm9yIGluY3JlbWVudGFsIGRl cGxveW1lbnQgd2l0aGluIGEgbmV0d29yaywKICAgaW5jbHVkaW5nIGEgbmV0d29yayB0aGF0IGlz IGFscmVhZHkgZGVwbG95aW5nIExGQS4gIENvbXB1dGF0aW9uIG9mCiAgIHRoZSByZXBhaXIgcGF0 aCBpcyByZWxhdGl2ZWx5IHNpbXBsZSwgYW5kIHRha2VzIHBsYWNlIGV4Y2x1c2l2ZWx5IG9uCiAg IHRoZSByZXBhaXJpbmcgbm9kZS4gIEluIE1QTFMgbmV0d29ya3MgdGhlIHRhcmdldGVkIExEUCBw cm90b2NvbAogICBuZWVkZWQgdG8gbGVhcm4gdGhlIGxhYmVsIGJpbmRpbmcgYXQgdGhlIHJlcGFp ciB0dW5uZWwgZW5kcG9pbnQgaXMgYQogICB3ZWxsIHVuZGVyc3Rvb2QgYW5kIHdpZGVseSBkZXBs b3llZCB0ZWNobm9sb2d5LgoKICAgVGhpcyB0ZWNobmlxdWUgZGVzY3JpYmVzIGluIHRoaXMgZG9j dW1lbnQgaXMgZGlyZWN0ZWQgYXQgcHJvdmlkaW5nCiAgIHJlcGFpcnMgaW4gdGhlIGNhc2Ugb2Yg bGluayBmYWlsdXJlcy4gIENvbnNpZGVyYXRpb25zIHJlZ2FyZGluZyBub2RlCiAgIGZhaWx1cmVz IGFyZSBkaXNjdXNzZWQgaW4gU2VjdGlvbiA2LgoKMy4gIFJlcGFpciBQYXRocwoKICAgQXMgd2l0 aCBMRkEgRlJSLCB3aGVuIGEgcm91dGVyIGRldGVjdHMgYW4gYWRqYWNlbnQgbGluayBmYWlsdXJl LCBpdAogICB1c2VzIG9uZSBvciBtb3JlIHJlcGFpciBwYXRocyBpbiBwbGFjZSBvZiB0aGUgZmFp bGVkIGxpbmsuICBSZXBhaXIKICAgcGF0aHMgYXJlIHByZS1jb21wdXRlZCBpbiBhbnRpY2lwYXRp b24gb2YgbGF0ZXIgZmFpbHVyZXMgc28gdGhleSBjYW4KICAgYmUgcHJvbXB0bHkgYWN0aXZhdGVk IHdoZW4gYSBmYWlsdXJlIGlzIGRldGVjdGVkLgoKCgoKQnJ5YW50LCBldCBhbC4gICAgICAgICAg ICBFeHBpcmVzIE1heSAwMSwgMjAxNCAgICAgICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgICBSZW1vdGUgTEZBIEZSUiAgICAgICAgICAgICAgICAgT2N0 b2JlciAyMDEzCgoKICAgQSB0dW5uZWxlZCByZXBhaXIgcGF0aCB0dW5uZWxzIHRyYWZmaWMgdG8g c29tZSBzdGFnaW5nIHBvaW50IGluIHRoZQogICBuZXR3b3JrIGZyb20gd2hpY2ggaXQgaXMgYXNz dW1lZCB0aGF0LCBpbiB0aGUgYWJzZW5jZSBvZiBtdWx0aXBsZQogICBmYWlsdXJlcywgaXQgd2ls bCB0cmF2ZWwgdG8gaXRzIGRlc3RpbmF0aW9uIHVzaW5nIG5vcm1hbCBmb3J3YXJkaW5nCiAgIHdp dGhvdXQgbG9vcGluZyBiYWNrLiAgVGhpcyBpcyBlcXVpdmFsZW50IHRvIHByb3ZpZGluZyBhIHZp cnR1YWwKICAgbG9vcC1mcmVlIGFsdGVybmF0ZSB0byBzdXBwbGVtZW50IHRoZSBwaHlzaWNhbCBs b29wLWZyZWUgYWx0ZXJuYXRlcy4KICAgSGVuY2UgdGhlIG5hbWUgIlJlbW90ZSBMRkEgRlJSIi4g IFdoZW4gYSBsaW5rIGNhbm5vdCBiZSBlbnRpcmVseQogICBwcm90ZWN0ZWQgd2l0aCBsb2NhbCBM RkEgbmVpZ2hib3JzLCB0aGUgcHJvdGVjdGluZyByb3V0ZXIgc2Vla3MgdGhlCiAgIGhlbHAgb2Yg YSByZW1vdGUgTEZBIHN0YWdpbmcgcG9pbnQuCiAgIAogICBbU0xJXSBOb3QgYSBnb29kIGlkZWEg dG8gc2VlayByTEZBIG9ubHkgd2hlbiBMRkEgaXMgbm90IGF2YWlsYWJsZSAoc2VlIG1hbmFnZWFi aWxpdHkpCgogICAKMy4xLiAgVHVubmVscyBhcyBSZXBhaXIgUGF0aHMKCiAgIENvbnNpZGVyIGFu IGFyYml0cmFyeSBwcm90ZWN0ZWQgbGluayBTLUUuIEluIExGQSBGUlIsIGlmIGEgcGF0aCB0bwog ICB0aGUgZGVzdGluYXRpb24gZnJvbSBhIG5laWdoYm9yIE4gb2YgUyBkb2VzIG5vdCBjYXVzZSBh IHBhY2tldCB0bwogICBsb29wIGJhY2sgb3ZlciB0aGUgbGluayBTLUUgKGkuZS4gTiBpcyBhIGxv b3AtZnJlZSBhbHRlcm5hdGUpLCB0aGVuIFMKICAgY2FuIHNlbmQgdGhlIHBhY2tldCB0byBOIGFu ZCB0aGUgcGFja2V0IHdpbGwgYmUgZGVsaXZlcmVkIHRvIHRoZQogICBkZXN0aW5hdGlvbiB1c2lu ZyB0aGUgcHJlLWZhaWx1cmUgZm9yd2FyZGluZyBpbmZvcm1hdGlvbi4gIElmIHRoZXJlCiAgIGlz IG5vIHN1Y2ggTEZBIG5laWdoYm9yLCB0aGVuIFMgbWF5IGJlIGFibGUgdG8gY3JlYXRlIGEgdmly dHVhbCBMRkEKICAgYnkgdXNpbmcgYSB0dW5uZWwgdG8gY2FycnkgdGhlIHBhY2tldCB0byBhIHBv aW50IGluIHRoZSBuZXR3b3JrIHdoaWNoCiAgIGlzIG5vdCBhIGRpcmVjdCBuZWlnaGJvciBvZiBT IGZyb20gd2hpY2ggdGhlIHBhY2tldCB3aWxsIGJlIGRlbGl2ZXJlZAogICB0byB0aGUgZGVzdGlu YXRpb24gd2l0aG91dCBsb29waW5nIGJhY2sgdG8gUy4gSW4gdGhpcyBkb2N1bWVudCBzdWNoIGEK ICAgdHVubmVsIGlzIHRlcm1lZCBhIHJlcGFpciB0dW5uZWwuICBUaGUgdGFpbC1lbmQgb2YgdGhp cyB0dW5uZWwgaXMKICAgY2FsbGVkIGEgInJlbW90ZSBMRkEiIG9yIGEgIlBRIG5vZGUiLgoKICAg Tm90ZSB0aGF0IHRoZSByZXBhaXIgdHVubmVsIHRlcm1pbmF0ZXMgYXQgc29tZSBpbnRlcm1lZGlh dGUgcm91dGVyCiAgIGJldHdlZW4gUyBhbmQgRSwgYW5kIG5vdCBFIGl0c2VsZi4gIFRoaXMgaXMg Y2xlYXJseSB0aGUgY2FzZSwgc2luY2UKICAgaWYgaXQgd2VyZSBwb3NzaWJsZSB0byBjb25zdHJ1 Y3QgYSB0dW5uZWwgZnJvbSBTIHRvIEUgdGhlbiBhCiAgIGNvbnZlbnRpb25hbCBMRkEgd291bGQg aGF2ZSBiZWVuIHN1ZmZpY2llbnQgdG8gZWZmZWN0IHRoZSByZXBhaXIuCgozLjIuICBUdW5uZWwg UmVxdWlyZW1lbnRzCgogICBUaGVyZSBhcmUgYSBudW1iZXIgb2YgSVAgaW4gSVAgdHVubmVsIG1l Y2hhbmlzbXMgdGhhdCBtYXkgYmUgdXNlZCB0bwogICBmdWxmaWwgdGhlIHJlcXVpcmVtZW50cyBv ZiB0aGlzIGRlc2lnbiwgc3VjaCBhcyBJUC1pbi1JUCBbUkZDMTg1M10KICAgYW5kIEdSRVtSRkMx NzAxXSAuCgogICBJbiBhbiBNUExTIGVuYWJsZWQgbmV0d29yayB1c2luZyBMRFBbUkZDNTAzNl0s IGEgc2ltcGxlIGxhYmVsCiAgIHN0YWNrW1JGQzMwMzJdIG1heSBiZSB1c2VkIHRvIHByb3ZpZGUg dGhlIHJlcXVpcmVkIHJlcGFpciB0dW5uZWwuICBJbgogICB0aGlzIGNhc2UgdGhlIG91dGVyIGxh YmVsIGlzIFMncyBuZWlnaGJvcidzIGxhYmVsIGZvciB0aGUgcmVwYWlyCiAgIHR1bm5lbCBlbmQg cG9pbnQsIGFuZCB0aGUgaW5uZXIgbGFiZWwgaXMgdGhlIHJlcGFpciB0dW5uZWwgZW5kCiAgIHBv aW50J3MgbGFiZWwgZm9yIHRoZSBwYWNrZXQgZGVzdGluYXRpb24uICBJbiBvcmRlciBmb3IgUyB0 byBvYnRhaW4KICAgdGhlIGNvcnJlY3QgaW5uZXIgbGFiZWwgaXQgaXMgbmVjZXNzYXJ5IHRvIGVz dGFibGlzaCBhIGRpcmVjdGVkIExEUAogICBzZXNzaW9uW1JGQzUwMzZdIHRvIHRoZSB0dW5uZWwg ZW5kIHBvaW50LgoKICAgVGhlIHNlbGVjdGlvbiBvZiB0aGUgc3BlY2lmaWMgdHVubmVsbGluZyBt ZWNoYW5pc20gKGFuZCBhbnkgbmVjZXNzYXJ5CiAgIGVuaGFuY2VtZW50cykgdXNlZCB0byBwcm92 aWRlIGEgcmVwYWlyIHBhdGggaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YKICAgdGhpcyBkb2N1bWVu dC4gIFRoZSBhdXRob3JzIHNpbXBseSBub3RlIHRoYXQgZGVwbG95bWVudCBpbiBhbiBNUExTLwog ICBMRFAgZW52aXJvbm1lbnQgaXMgZXh0cmVtZWx5IHNpbXBsZSBhbmQgc3RyYWlnaHQtZm9yd2Fy ZCBhcyBhbiBMRFAKICAgTFNQIGZyb20gUyB0byB0aGUgUFEgbm9kZSBpcyByZWFkaWx5IGF2YWls YWJsZSwgYW5kIGhlbmNlIGRvZXMgbm90CiAgIHJlcXVpcmUgYW55IG5ldyBwcm90b2NvbCBleHRl bnNpb24gb3IgZGVzaWduIGNoYW5nZS4gIFRoaXMgTFNQIGlzCgoKCkJyeWFudCwgZXQgYWwuICAg ICAgICAgICAgRXhwaXJlcyBNYXkgMDEsIDIwMTQgICAgICAgICAgICAgICAgICBbUGFnZSA1XQoM CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgUmVtb3RlIExGQSBGUlIgICAgICAgICAgICAg ICAgIE9jdG9iZXIgMjAxMwoKCiAgIGF1dG9tYXRpY2FsbHkgZXN0YWJsaXNoZWQgYXMgYSBiYXNp YyBwcm9wZXJ0eSBvZiBMRFAgYmVoYXZpb3IuICBUaGUKICAgcGVyZm9ybWFuY2Ugb2YgdGhlIGVu Y2Fwc3VsYXRpb24gYW5kIGRlY2Fwc3VsYXRpb24gaXMgYWxzbyBleGNlbGxlbnQKICAgYXMgZW5j YXBzdWxhdGlvbiBpcyBqdXN0IGEgcHVzaCBvZiBvbmUgbGFiZWwgKGxpa2UgY29udmVudGlvbmFs IE1QTFMKICAgVEUgRlJSKSBhbmQgdGhlIGRlY2Fwc3VsYXRpb24gb2NjdXJzIG5hdHVyYWxseSBh dCB0aGUgcGVudWx0aW1hdGUgaG9wCiAgIGJlZm9yZSB0aGUgUFEgbm9kZS4KICBbU0xJXSBPayB0 aGUgdHVubmVsIGlzIGFscmVhZHkgYXZhaWxhYmxlLCBidXQgeW91IG5lZWQgc29tZSB0aW1lIHRv IGVzdGFibGlzaCB0aGUgcHJvdGVjdGlvbiAoVExEUCBzZXNzaW9uIGVzdGFibGlzaG1lbnQgKyBs YWJlbCBsZWFybmluZyB0aW1lKS4KCVRoaXMgaXMgaW1wb3J0YW50IHRvIHByZWNpc2UgdGhpcy4K CQogICBXaGVuIGEgZmFpbHVyZSBpcyBkZXRlY3RlZCwgaXQgaXMgbmVjZXNzYXJ5IHRvIGltbWVk aWF0ZWx5IHJlZGlyZWN0CiAgIHRyYWZmaWMgdG8gdGhlIHJlcGFpciBwYXRoLiAgQ29uc2VxdWVu dGx5LCB0aGUgcmVwYWlyIHR1bm5lbCB1c2VkCiAgIG11c3QgYmUgcHJvdmlzaW9uZWQgYmVmb3Jl aGFuZCBpbiBhbnRpY2lwYXRpb24gb2YgdGhlIGZhaWx1cmUuICBTaW5jZQogICB0aGUgbG9jYXRp b24gb2YgdGhlIHJlcGFpciB0dW5uZWxzIGlzIGR5bmFtaWNhbGx5IGRldGVybWluZWQgaXQgaXMK ICAgbmVjZXNzYXJ5IHRvIGVzdGFibGlzaCB0aGUgcmVwYWlyIHR1bm5lbHMgd2l0aG91dCBtYW5h Z2VtZW50IGFjdGlvbi4KICAgW1NMSV0gcy9tYW5hZ2VtZW50IGFjdGlvbi9tYW51YWwgcHJvdmlz aW9ubmluZyBhY3Rpb24vICwgYXMgbWFuYWdlbWVudCBtYXkgYmUgbmVlZGVkIHRvIHR3ZWFrIHRo ZSBiZXN0IHR1bm5lbCB0YWlsZW5kLgogICAKICAgTXVsdGlwbGUgcmVwYWlycyBtYXkgc2hhcmUg YSB0dW5uZWwgZW5kIHBvaW50Cgo0LiAgQ29uc3RydWN0aW9uIG9mIFJlcGFpciBQYXRocwoKNC4x LiAgSWRlbnRpZnlpbmcgUmVxdWlyZWQgVHVubmVsZWQgUmVwYWlyIFBhdGhzCgogICBOb3QgYWxs IGxpbmtzIHdpbGwgcmVxdWlyZSBwcm90ZWN0aW9uIHVzaW5nIGEgdHVubmVsZWQgcmVwYWlyIHBh dGguCiAgIFJlZmVycmluZyB0byBGaWd1cmUgMSwgaWYgRSBjYW4gYWxyZWFkeSBiZSBwcm90ZWN0 ZWQgdmlhIGFuIExGQSwgUy1FCiAgIGRvZXMgbm90IG5lZWQgdG8gYmUgcHJvdGVjdGVkIHVzaW5n IGEgcmVwYWlyIHR1bm5lbCwgc2luY2UgYWxsCiAgIGRlc3RpbmF0aW9ucyBub3JtYWxseSByZWFj aGFibGUgdGhyb3VnaCBFIG11c3QgdGhlcmVmb3JlIGFsc28gYmUKICAgcHJvdGVjdGFibGUgYnkg YW4gTEZBLiAgU3VjaCBhbiBMRkEgaXMgZnJlcXVlbnRseSB0ZXJtZWQgYSAibGluawogICBMRkEi LiAgVHVubmVsZWQgcmVwYWlyIHBhdGhzIGFyZSBvbmx5IHJlcXVpcmVkIGZvciBsaW5rcyB3aGlj aCBkbyBub3QKICAgaGF2ZSBhIGxpbmsgTEZBLgoKICAgSXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQg dXNpbmcgdGhlIFEtc3BhY2Ugb2YgRSBhcyBhIHByb3h5IGZvciB0aGUKICAgUS1zcGFjZSBvZiBl YWNoIGRlc3RpbmF0aW9uIGNhbiByZXN1bHQgaW4gZmFpbGluZyB0byBpZGVudGlmeSB2YWxpZAog ICByZW1vdGUgTEZBcy4gIFRoZSBleHRlbnQgdG8gd2hpY2ggdGhpcyByZWR1Y2VzIHRoZSBlZmZl Y3RpdmUKICAgcHJvdGVjdGlvbiBjb3ZlcmFnZSBpcyB0b3BvbG9neSBkZXBlbmRlbnQuCgo0LjIu ICBEZXRlcm1pbmluZyBUdW5uZWwgRW5kIFBvaW50cwoKICAgVGhlIHJlcGFpciB0dW5uZWwgZW5k cG9pbnQgbmVlZHMgdG8gYmUgYSBub2RlIGluIHRoZSBuZXR3b3JrCiAgIHJlYWNoYWJsZSBmcm9t IFMgd2l0aG91dCB0cmF2ZXJzaW5nIFMtRS4gSW4gYWRkaXRpb24sIHRoZSByZXBhaXIKICAgdHVu bmVsIGVuZCBwb2ludCBuZWVkcyB0byBiZSBhIG5vZGUgZnJvbSB3aGljaCBwYWNrZXRzIHdpbGwg bm9ybWFsbHkKICAgZmxvdyB0b3dhcmRzIHRoZWlyIGRlc3RpbmF0aW9uIHdpdGhvdXQgYmVpbmcg YXR0cmFjdGVkIGJhY2sgdG8gdGhlCiAgIGZhaWxlZCBsaW5rIFMtRS4KCiAgIE5vdGUgdGhhdCBv bmNlIHJlbGVhc2VkIGZyb20gdGhlIHR1bm5lbCwgdGhlIHBhY2tldCB3aWxsIGJlCiAgIGZvcndh cmRlZCwgYXMgbm9ybWFsLCBvbiB0aGUgc2hvcnRlc3QgcGF0aCBmcm9tIHRoZSByZWxlYXNlIHBv aW50IHRvCiAgIGl0cyBkZXN0aW5hdGlvbi4gIFRoaXMgbWF5IHJlc3VsdCBpbiB0aGUgcGFja2V0 IHRyYXZlcnNpbmcgdGhlIHJvdXRlcgogICBFIGF0IHRoZSBmYXIgZW5kIG9mIHRoZSBwcm90ZWN0 ZWQgbGluayBTLUUuLCBidXQgdGhpcyBpcyBvYnZpb3VzbHkKICAgbm90IHJlcXVpcmVkLgoKICAg VGhlIHByb3BlcnRpZXMgdGhhdCBhcmUgcmVxdWlyZWQgb2YgcmVwYWlyIHR1bm5lbCBlbmQgcG9p bnRzIGFyZQogICB0aGVyZWZvcmU6CgoKCgoKQnJ5YW50LCBldCBhbC4gICAgICAgICAgICBFeHBp cmVzIE1heSAwMSwgMjAxNCAgICAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICBSZW1vdGUgTEZBIEZSUiAgICAgICAgICAgICAgICAgT2N0b2JlciAy MDEzCgoKICAgbyAgVGhlIHJlcGFpciB0dW5uZWxlZCBwb2ludCBNVVNUIGJlIHJlYWNoYWJsZSBm cm9tIHRoZSB0dW5uZWwgc291cmNlCiAgICAgIHdpdGhvdXQgdHJhdmVyc2luZyB0aGUgZmFpbGVk IGxpbms7IGFuZAoKICAgbyAgV2hlbiByZWxlYXNlZCwgdHVubmVsZWQgcGFja2V0cyBNVVNUIHBy b2NlZWQgdG93YXJkcyB0aGVpcgogICAgICBkZXN0aW5hdGlvbiB3aXRob3V0IGJlaW5nIGF0dHJh Y3RlZCBiYWNrIG92ZXIgdGhlIGZhaWxlZCBsaW5rLgoKICAgUHJvdmlkZWQgYm90aCB0aGVzZSBy ZXF1aXJlbWVudHMgYXJlIG1ldCwgcGFja2V0cyBmb3J3YXJkZWQgb3ZlciB0aGUKICAgcmVwYWly IHR1bm5lbCB3aWxsIHJlYWNoIHRoZWlyIGRlc3RpbmF0aW9uIGFuZCB3aWxsIG5vdCBsb29wLgoK ICAgSW4gc29tZSB0b3BvbG9naWVzIGl0IHdpbGwgbm90IGJlIHBvc3NpYmxlIHRvIGZpbmQgYSBy ZXBhaXIgdHVubmVsCiAgIGVuZHBvaW50IHRoYXQgZXhoaWJpdHMgYm90aCB0aGUgcmVxdWlyZWQg cHJvcGVydGllcy4gIEZvciBleGFtcGxlIGlmCiAgIHRoZSByaW5nIHRvcG9sb2d5IGlsbHVzdHJh dGVkIGluIEZpZ3VyZSAxIGhhZCBhIGNvc3Qgb2YgNCBmb3IgdGhlCiAgIGxpbmsgQi1DLCB3aGls ZSB0aGUgcmVtYWluaW5nIGxpbmtzIHdlcmUgY29zdCAxLCB0aGVuIGl0IHdvdWxkIG5vdCBiZQog ICBwb3NzaWJsZSB0byBlc3RhYmxpc2ggYSB0dW5uZWwgZnJvbSBTIHRvIEMgKHdpdGhvdXQgcmVz b3J0aW5nIHRvIHNvbWUKICAgZm9ybSBvZiBzb3VyY2Ugcm91dGluZykuCgo0LjIuMS4gIENvbXB1 dGluZyBSZXBhaXIgUGF0aHMKCiAgIFRoZSBzZXQgb2Ygcm91dGVycyB3aGljaCBjYW4gYmUgcmVh Y2hlZCBmcm9tIFMgd2l0aG91dCB0cmF2ZXJzaW5nIFMtRQogICBpcyB0ZXJtZWQgdGhlIFAtc3Bh Y2Ugb2YgUyB3aXRoIHJlc3BlY3QgdG8gdGhlIGxpbmsgUy1FLiBUaGUgUC1zcGFjZQogICBjYW4g YmUgb2J0YWluZWQgYnkgY29tcHV0aW5nIGEgc2hvcnRlc3QgcGF0aCB0cmVlIChTUFQpIHJvb3Rl ZCBhdCBTCiAgIGFuZCBleGNpc2luZyB0aGUgc3ViLXRyZWUgcmVhY2hlZCB2aWEgdGhlIGxpbmsg Uy1FIChpbmNsdWRpbmcgdGhvc2UKICAgd2hpY2ggYXJlIG1lbWJlcnMgb2YgYW4gRUNNUCkuICBJ biB0aGUgY2FzZSBvZiBGaWd1cmUgMSB0aGUgUC1zcGFjZQogICBjb21wcmlzZXMgbm9kZXMgQSBh bmQgQiBvbmx5LiAgRXhwcmVzc2VkIGluIGNvc3QgdGVybXMgdGhlIHNldCBvZgogICByb3V0ZXJz IHtQfSBhcmUgdGhvc2UgZm9yIHdoaWNoIHRoZSBzaG9ydGVzdCBwYXRoIGNvc3QgUy0+UCBpcwog ICBzdHJpY3RseSBsZXNzIHRoYW4gdGhlIHNob3J0ZXN0IHBhdGggY29zdCBTLT5FLT5QLgoKICAg VGhlIHNldCBvZiByb3V0ZXJzIGZyb20gd2hpY2ggdGhlIG5vZGUgRSBjYW4gYmUgcmVhY2hlZCwg Ynkgbm9ybWFsCiAgIGZvcndhcmRpbmcsIHdpdGhvdXQgdHJhdmVyc2luZyB0aGUgbGluayBTLUUg aXMgdGVybWVkIHRoZSBRLXNwYWNlIG9mCiAgIEUgd2l0aCByZXNwZWN0IHRvIHRoZSBsaW5rIFMt RS4gVGhlIFEtc3BhY2UgY2FuIGJlIG9idGFpbmVkIGJ5CiAgIGNvbXB1dGluZyBhIHJldmVyc2Ug c2hvcnRlc3QgcGF0aCB0cmVlIChyU1BUKSByb290ZWQgYXQgRSwgd2l0aCB0aGUKICAgc3ViLXRy ZWUgd2hpY2ggdHJhdmVyc2VzIHRoZSBmYWlsZWQgbGluayBleGNpc2VkIChpbmNsdWRpbmcgdGhv c2UKICAgd2hpY2ggYXJlIG1lbWJlcnMgb2YgYW4gRUNNUCkuICBUaGUgclNQVCB1c2VzIHRoZSBj b3N0IHRvd2FyZHMgdGhlCiAgIHJvb3QgcmF0aGVyIHRoYW4gZnJvbSBpdCBhbmQgeWllbGRzIHRo ZSBiZXN0IHBhdGhzIHRvd2FyZHMgdGhlIHJvb3QKICAgZnJvbSBvdGhlciBub2RlcyBpbiB0aGUg bmV0d29yay4gIEluIHRoZSBjYXNlIG9mIEZpZ3VyZSAxIHRoZSBRLXNwYWNlCiAgIGNvbXByaXNl cyBub2RlcyBDIGFuZCBEIG9ubHkuICBFeHByZXNzZWQgaW4gY29zdCB0ZXJtcyB0aGUgc2V0IG9m CiAgIHJvdXRlcnMge1F9IGFyZSB0aG9zZSBmb3Igd2hpY2ggdGhlIHNob3J0ZXN0IHBhdGggY29z dCBFLT5RIGlzCiAgIHN0cmljdGx5IGxlc3MgdGhhbiB0aGUgc2hvcnRlc3QgcGF0aCBjb3N0IEUt PlMtPlEuIAogICAKICAgW1NMSV0gV291bGQgaXQgYmUgUS0+RSBsZXNzIHRoYW4gUS0+Uy0+RQog ICAKICAgSW4gRmlndXJlIDEgdGhlCiAgIGludGVyc2VjdGlvbiBvZiB0aGUgRSdzIFEtc3BhY2Ug d2l0aCBTJ3MgUC1zcGFjZSBkZWZpbmVzIHRoZSBzZXQgb2YKICAgdmlhYmxlIHJlcGFpciB0dW5u ZWwgZW5kLXBvaW50cywga25vd24gYXMgIlBRIG5vZGVzIi4gIEFzIGNhbiBiZQogICBzZWVuLCBm b3IgdGhlIGNhc2Ugb2YgRmlndXJlIDEgdGhlcmUgaXMgbm8gY29tbW9uIG5vZGUgYW5kIGhlbmNl IG5vCiAgIHZpYWJsZSByZXBhaXIgdHVubmVsIGVuZC1wb2ludC4KCiAgIE5vdGUgdGhhdCB0aGUg US1zcGFjZSBjYWxjdWxhdGlvbiBjb3VsZCBiZSBjb25kdWN0ZWQgZm9yIGVhY2gKICAgaW5kaXZp ZHVhbCBkZXN0aW5hdGlvbiBhbmQgYSBwZXItZGVzdGluYXRpb24gcmVwYWlyIHR1bm5lbCBlbmQg cG9pbnQKICAgZGV0ZXJtaW5lZC4gIEhvd2V2ZXIgdGhpcyB3b3VsZCwgaW4gdGhlIHdvcnN0IGNh c2UsIHJlcXVpcmUgYW4gU1BGCiAgIGNvbXB1dGF0aW9uIHBlciBkZXN0aW5hdGlvbiB3aGljaCBp cyBub3QgY3VycmVudGx5IGNvbnNpZGVyZWQgdG8gYmUKICAgc2NhbGFibGUuICBXZSB0aGVyZWZv cmUgdXNlIHRoZSBRLXNwYWNlIG9mIEUgYXMgYSBwcm94eSBmb3IgdGhlCgoKCkJyeWFudCwgZXQg YWwuICAgICAgICAgICAgRXhwaXJlcyBNYXkgMDEsIDIwMTQgICAgICAgICAgICAgICAgICBbUGFn ZSA3XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgUmVtb3RlIExGQSBGUlIgICAgICAg ICAgICAgICAgIE9jdG9iZXIgMjAxMwoKCiAgIFEtc3BhY2Ugb2YgZWFjaCBkZXN0aW5hdGlvbi4g IFRoaXMgYXBwcm94aW1hdGlvbiBpcyBvYnZpb3VzbHkgY29ycmVjdAogICBzaW5jZSB0aGUgcmVw YWlyIGlzIG9ubHkgdXNlZCBmb3IgdGhlIHNldCBvZiBkZXN0aW5hdGlvbnMgd2hpY2ggd2VyZSwK ICAgcHJpb3IgdG8gdGhlIGZhaWx1cmUsIHJvdXRlZCB0aHJvdWdoIG5vZGUgRS4gVGhpcyBpcyBh bmFsb2dvdXMgdG8gdGhlCiAgIHVzZSBvZiBsaW5rLUxGQXMgcmF0aGVyIHRoYW4gcGVyLXByZWZp eCBMRkFzLgoKNC4yLjIuICBFeHRlbmRlZCBQLXNwYWNlCgogICBUaGUgZGVzY3JpcHRpb24gaW4g U2VjdGlvbiA0LjIuMSBjYWxjdWxhdGVkIHJvdXRlciBTJ3MgUC1zcGFjZSByb290ZWQKICAgYXQg UyBpdHNlbGYuICBIb3dldmVyLCBzaW5jZSByb3V0ZXIgUyB3aWxsIG9ubHkgdXNlIGEgcmVwYWly IHBhdGgKICAgd2hlbiBpdCBoYXMgZGV0ZWN0ZWQgdGhlIGZhaWx1cmUgb2YgdGhlIGxpbmsgUy1F LCB0aGUgaW5pdGlhbCBob3Agb2YKICAgdGhlIHJlcGFpciBwYXRoIG5lZWQgbm90IGJlIHN1Ympl Y3QgdG8gUydzIG5vcm1hbCBmb3J3YXJkaW5nIGRlY2lzaW9uCiAgIHByb2Nlc3MuICBUaHVzIHdl IGludHJvZHVjZSB0aGUgY29uY2VwdCBvZiBleHRlbmRlZCBQLXNwYWNlLiAgUm91dGVyCiAgIFMn cyBleHRlbmRlZCBQLXNwYWNlIGlzIHRoZSB1bmlvbiBvZiB0aGUgUC1zcGFjZXMgb2YgZWFjaCBv ZiBTJ3MKICAgbmVpZ2hib3VycyAoTikuICBUaGlzIG1heSBiZSBjYWxjdWxhdGVkIGJ5IGNvbXB1 dGluZyBhbiBTUFQgYXQgZWFjaAogICBvZiBTJ3MgbmVpZ2hib3JzIChleGNsdWRpbmcgRSkgYW5k IGV4Y2lzaW5nIHRoZSBzdWJ0cmVlIHJlYWNoZWQgdmlhCiAgIHRoZSBwYXRoIE4tPlMtPkUuIFRo ZSB1c2Ugb2YgZXh0ZW5kZWQgUC1zcGFjZSBtYXkgYWxsb3cgcm91dGVyIFMgdG8KICAgcmVhY2gg cG90ZW50aWFsIHJlcGFpciB0dW5uZWwgZW5kIHBvaW50cyB0aGF0IHdlcmUgb3RoZXJ3aXNlCiAg IHVucmVhY2hhYmxlLiAgSW4gY29zdCB0ZXJtcyBhIHJvdXRlciAoUCkgaXMgaW4gZXh0ZW5kZWQg UC1zcGFjZSBpZgogICB0aGUgc2hvcnRlc3QgcGF0aCBjb3N0IE4tPlAgaXMgc3RyaWN0bHkgbGVz cyB0aGFuIHRoZSBzaG9ydGVzdCBwYXRoCiAgIGNvc3QgTi0+Uy0+RS0+UC4gSW4gb3RoZXIgd29y ZHMsIG9uY2UgdGhlIHBhY2tldCBpdCBmb3JjZWQgdG8gTiBieSBTLAogICBpdCBpcyBsb3dlciBj b3N0IGZvciBpdCB0byBjb250aW51ZSBvbiB0byBQIGJ5IGFueSBwYXRoIGV4Y2VwdCBvbmUKICAg dGhhdCB0YWtlcyBpdCBiYWNrIHRvIFMgYW5kIHRoZW4gYWNyb3NzIHRoZSBTLT5FIGxpbmsuCgog ICBBbm90aGVyIHdheSB0byBkZXNjcmliZSBleHRlbmRlZCBQLXNwYWNlIGlzIHRoYXQgaXQgaXMg dGhlIHVuaW9uIG9mICgKICAgdW4tZXh0ZW5kZWQgKSBQLXNwYWNlIGFuZCB0aGUgc2V0IG9mIGRl c3RpbmF0aW9ucyBmb3Igd2hpY2ggUyBoYXMgYQogICBwZXItcHJlZml4IExGQSBwcm90ZWN0aW5n IHRoZSBsaW5rIFMtRS4gaS5lLiB0aGUgcmVwYWlyIHR1bm5lbCBlbmQKICAgcG9pbnQgY2FuIGJl IHJlYWNoZWQgZWl0aGVyIGRpcmVjdGx5IG9yIHVzaW5nIGEgcGVyLXByZWZpeCBMRkEuCgogICAJ W1NMSV0gTGFjayBvZiBwcmVjaXNpb24gYWJvdXQgaW5kZXBlbmRhbmN5IG9mIHJMRkEgYW5kIExG QSBhbHRlcm5hdGUgY2hvaWNlIGlzIHJMRkEgaXMgdXNpbmcgZXh0ZW5kZWQgUCBzcGFjZSBub2Rl LgoJSSB3b3VsZCBwcm9wb3NlIDoKCQoJIkV2ZW4gaWYgZXh0ZW5kZWQgUC1zcGFjZSB3b3VsZCBi ZSBjb21wb3NlZCBvbiBub2RlcyByZWFjaGFibGUgdGhyb3VnaCBhIHBlci1wcmVmaXggTEZBLCB0 aGlzIGRvZXMgbm90IGNvbmNsdWRlIHRoYXQgdGhlIHJMRkEgd291bGQgaW5oZXJpdCB0aGUgYmVz dCBMRkEgdG8gcmVhY2ggdGhlIFBROiAKCXJMRkEgYW4gTEZBIE1VU1QgYmUgY29tcGxldGVseSBp bmRlcGVuZGFudC4gSW4gb3RoZXIgd29yZHMsIGlmIFMgaGFzIE4xIGFuZCBOMiBhcyBMRkFzIHRv IHByb3RlY3Rpb24gYSBkZXN0aW5hdGlvbiBQLCBhbmQgUyB3YW50cyB0byB1c2UgUCBhcyBQUSB0 byBwcm90ZWN0IGEgZGVzdGluYXRpb24gRC4gCglTIG11c3QgYmUgYWJsZSB0byBwcm9ncmFtIE4x IGFzIExGQSB0byByZWFjaCBQIGFuZCBQIHRocm91Z2ggTjIgdG8gcmVhY2ggRCBmb3IgbWFuYWdl YWJpbGl0eSByZWFzb25zIChyZWZlciB0byBTZWN0aW9uIDkpLiIKICAgCiAgIFNpbmNlIGluIHRo ZSBjYXNlIG9mIEZpZ3VyZSAxIG5vZGUgQSBpcyBhIHBlci1wcmVmaXggTEZBIGZvciB0aGUKICAg ZGVzdGluYXRpb24gbm9kZSBDLCB0aGUgc2V0IG9mIGV4dGVuZGVkIFAtc3BhY2Ugbm9kZXMgY29t cHJpc2VzIG5vZGVzCiAgIEEsIEIgYW5kIEMuIFNpbmNlIG5vZGUgQyBpcyBhbHNvIGluIEUncyBR LXNwYWNlLCB0aGVyZSBpcyBub3cgYSBub2RlCiAgIGNvbW1vbiB0byBib3RoIGV4dGVuZGVkIFAt c3BhY2UgYW5kIFEtc3BhY2Ugd2hpY2ggY2FuIGJlIHVzZWQgYXMgYQogICByZXBhaXIgdHVubmVs IGVuZC1wb2ludCB0byBwcm90ZWN0IHRoZSBsaW5rIFMtRS4KCgoJCjQuMi4zLiAgU2VsZWN0aW5n IFJlcGFpciBQYXRocwoKICAgVGhlIG1lY2hhbmlzbXMgZGVzY3JpYmVkIGFib3ZlIHdpbGwgaWRl bnRpZnkgYWxsIHRoZSBwb3NzaWJsZSByZXBhaXIKICAgdHVubmVsIGVuZCBwb2ludHMgdGhhdCBj YW4gYmUgdXNlZCB0byBwcm90ZWN0IGEgcGFydGljdWxhciBsaW5rLiAgSW4KICAgYSB3ZWxsLWNv bm5lY3RlZCBuZXR3b3JrIHRoZXJlIGFyZSBsaWtlbHkgdG8gYmUgbXVsdGlwbGUgcG9zc2libGUK ICAgcmVsZWFzZSBwb2ludHMgZm9yIGVhY2ggcHJvdGVjdGVkIGxpbmsuICBBbGwgd2lsbCBkZWxp dmVyIHRoZSBwYWNrZXRzCiAgIGNvcnJlY3RseSBzbywgYXJndWFibHksIGl0IGRvZXMgbm90IG1h dHRlciB3aGljaCBpcyBjaG9zZW4uICBIb3dldmVyLAogICBvbmUgcmVwYWlyIHR1bm5lbCBlbmQg cG9pbnQgbWF5IGJlIHByZWZlcnJlZCBvdmVyIHRoZSBvdGhlcnMgb24gdGhlCiAgIGJhc2lzIG9m IHBhdGggY29zdCBvciBzb21lIG90aGVyIHNlbGVjdGlvbiBjcml0ZXJpYS4KCiAgIFRoZXJlIGlz IG5vIHRlY2huaWNhbCByZXF1aXJlbWVudCBmb3IgdGhlIHNlbGVjdGlvbiBjcml0ZXJpYSB0byBi ZQogICBjb25zaXN0ZW50IGFjcm9zcyBhbGwgcm91dGVycywgYnV0IHN1Y2ggY29uc2lzdGVuY3kg bWF5IGJlIGRlc2lyYWJsZQogICBmcm9tIGFuIG9wZXJhdGlvbmFsIHBvaW50IG9mIHZpZXcuICBJ biBnZW5lcmFsIHRoZXJlIGFyZSBhZHZhbnRhZ2VzCiAgIGluIGNob29zaW5nIHRoZSByZXBhaXIg dHVubmVsIGVuZCBwb2ludCBjbG9zZXN0IChzaG9ydGVzdCBtZXRyaWMpIHRvCgoKCkJyeWFudCwg ZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBNYXkgMDEsIDIwMTQgICAgICAgICAgICAgICAgICBb UGFnZSA4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgUmVtb3RlIExGQSBGUlIgICAg ICAgICAgICAgICAgIE9jdG9iZXIgMjAxMwoKCiAgIFMuIENob29zaW5nIHRoZSBjbG9zZXN0IG1h eGltaXNlcyB0aGUgb3Bwb3J0dW5pdHkgZm9yIHRoZSB0cmFmZmljIHRvCiAgIGJlIGxvYWQgYmFs YW5jZWQgb25jZSBpdCBoYXMgYmVlbiByZWxlYXNlZCBmcm9tIHRoZSB0dW5uZWwuICBGb3IKICAg Y29uc2lzdGVuY3kgaW4gYmVoYXZpb3IgaXMgUkVDT01NRU5ERUQgdGhhdCBtZW1iZXIgb2YgdGhl IHNldCBvZgogICByb3V0ZXJzIHtQfSB3aXRoIHRoZSBsb3dlc3QgY29zdCBTLT5QIGJlIHRoZSBk ZWZhdWx0IGNob2ljZSBmb3IgUC4gSW4KICAgdGhlIGV2ZW50IG9mIGEgdGllIHRoZSByb3V0ZXIg d2l0aCB0aGUgbG93ZXN0IG5vZGUgaWRlbnRpZmllciBTSE9VTEQKICAgYmUgc2VsZWN0ZWQuCiAg IAogICBbU0xJXSBOZWVkIHRvIHJlcGxhY2UgUCBieSBQUSA6ICJGb3IKICAgY29uc2lzdGVuY3kg aW4gYmVoYXZpb3IgaXMgUkVDT01NRU5ERUQgdGhhdCBtZW1iZXIgb2YgdGhlIHNldCBvZgogICBy b3V0ZXJzIHtQUX0gd2l0aCB0aGUgbG93ZXN0IGNvc3QgUy0+UFEgYmUgdGhlIGRlZmF1bHQgY2hv aWNlIGZvciBQUS4iCiAgIAoKNC4zLiAgQSBDb3N0IEJhc2VkIFJMRkEgQWxnb3JpdGhtCgogICBU aGUgcHJlY2VkaW5nIHRleHQgaGFzIG1vc3RseSBkZXNjcmliZWQgdGhlIGNvbXB1dGF0aW9uIG9m IHRoZSByZW1vdGUKICAgTEZBIHJlcGFpciBwb2ludCAoUFEpIGluIHRlcm1zIG9mIHRoZSBpbnRl cnNlY3Rpb24gb2YgdHdvCiAgIHJlYWNoYWJpbGl0eSBncmFwaHMgY29tcHV0ZWQgdXNpbmcgU1BG cy4gIFRoaXMgc2VjdGlvbiBkZXNjcmliZXMgYQogICBtZXRob2Qgb2YgY29tcHV0aW5nIHRoZSBy ZXBhaXIgcG9pbnQgdXNpbmcgYSBjb3N0IGJhc2VkIGFsZ29yaXRobS4KICAgCiAgIFtTTEldICJy ZXBhaXIgcG9pbnQiIGlzIGNvbmZ1c2luZyBhcyBhIHJlcGFpciBwb2ludCBpcyBhIFBMUiBhbmQg aGVyZSB3ZSB0YWxrIGFib3V0IFBRLgogICBDb3VsZCB3ZSB1c2UgIlJlbW90ZSBMRkEiIGluc3Rl YWQgPwogICAKICAgVGhlIHBzZXVkby1jb2RlIHByb3ZpZGVzIGluIHRoaXMgc2VjdGlvbiBhdm9p ZHMgdW5uZWNlc3NhcnkgU1BGCiAgIGNvbXB1dGF0aW9ucywgYnV0IGZvciB0aGUgc2FrZSBvZiBy ZWFkYWJpbGl0eSwgaXQgZG9lcyBub3Qgb3RoZXJ3aXNlCiAgIHRyeSB0byBvcHRpbWl6ZSB0aGUg Y29kZS4gIFVuY29udmVudGlvbmFsbHksIGJ1dCBmb3IgY2xhcml0eSwgd2UKICAgcHJvdmlkZSB0 aGUgbWFpbiBhbGdvcml0aG0gZm9sbG93ZWQgaXRzIHByb2NlZHVyZXMuICBJbiB0aGlzCiAgIGRl c2NyaXB0aW9uIERfb3B0KGEsYikgaXMgdGhlIHNob3J0ZXN0IGRpc3RhbmNlIGZyb20gbm9kZSBh IHRvIG5vZGUgYgogICBhcyBjb21wdXRlZCBieSB0aGUgU1BGLgoKCVtTTEldIENoYW5naW5nIHRo ZSBwc2V1ZG9jb2RlIGFuZCBjcmVhdGUgYSByZW1vdGUgTEZBIGZ1bmN0aW9uIGFzIHN0ZXAgb2Yg ckxGQSBjb21wdXRhdGlvbiBhcmUgaGVyZSBtaXhlZCB3aXRoIHN1YmZ1bmN0aW9ucy4KCVByb3Bv c2FsIGhlcmUgOgoKCS8vIFJlbW90ZSBMRkEgY29tcHV0YXRpb24gZnVuY3Rpb24KCQoJbWFpbiB7 CgkgIC8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLwogICAgICAvLwogICAgICAvLyBXZSBoYXZlIGFscmVhZHkgY29tcHV0ZWQg dGhlIGZvcndhcmQgU1BGIGZyb20gc2VsZiB0byBhbGwgbm9kZXMKICAgICAgLy8geSBpbiBuZXR3 b3JrIGFuZCB0aHVzIHdlIGtub3cgRF9vcHQgKHNlbGYsIHkpLiBUaGlzIGlzIG5lZWRlZAogICAg ICAvLyBmb3Igbm9ybWFsIGZvcndhcmRpbmcuCiAgICAgIC8vIEhvd2V2ZXIgZm9yIGNvbXBsZXRl bmVzcy4KCiAgICAgIENvbXB1dGVfYW5kX1N0b3JlX0ZvcndhcmRfU1BGKHNlbGYpCgoJICAvLyBO ZWVkIHRvIGNvbXB1dGUgclNQRihzZWxmKSB0byBjb21wdXRlIGNvc3QgYmFzZWQgUSBTcGFjZSAo ZG9uZSBvbmx5IG9uZSB0aW1lKQoJICBDb21wdXRlX2FuZF9TdG9yZV9SZXZlcnNlX1NQRihzZWxm KQoJCQogICAgICAvLyBUbyBleHRlbmQgUC1zcGFjZSB3ZSBjb21wdXRlIHRoZSBTUEYgYXQgZWFj aCBuZWlnaGJvdXIgZXhjZXB0CiAgICAgIC8vIHRoZSBuZWlnaGJvdXIgdGhhdCBpcyByZWFjaGVk IHZpYSB0aGUgbGluayBiZWluZyBwcm90ZWN0ZWQuCiAgICAgIC8vIFdlIHdpbGwgYWxzbyBuZWVk IERfb3B0KGZhaWxfaW50Zi5yZW1vdGVfbm9kZSx5KSBzbyBjb21wdXRlCiAgICAgIC8vIHRoYXQg YXQgdGhlIHNhbWUgdGltZS4KCiAgICAgIGZvcmVhY2ggaW50ZXJmYWNlIGludGYgaW4gc2VsZgog ICAgICAgICAgICAgIENvbXB1dGVfYW5kX1N0b3JlX0ZvcndhcmRfU1BGKGludGYucmVtb3RlX25v ZGUpCgkJW1NMSV0gSSByZW1vdmVkIHRoZSBDb21wdXRlX05laWdoYm9yX1NQRnMgYXMgLCBJTUhP LCBpdCBjb21wbGV4aWZpZXMgdGhlIHJlYWRhYmlsaXR5IC4uLgoJCQoJICAvLyBDb21wdXRlIHJM RkEgZm9yIGVhY2ggaW50ZXJmYWNlCgkgIGZvcmVhY2ggaW50ZXJmYWNlIGZhaWxfaW50ZiBpbiBz ZWxmCgkJQ29tcHV0ZV9STEZBKGZhaWxfaW50ZikKCX0KCQoJQ29tcHV0ZV9STEZBKGZhaWxfaW50 ZikgewoJCiAgICAgIC8vIENvbXB1dGUgdGhlIHNldCBvZiBub2RlcyB7UH0gcmVhY2hhYmxlIG90 aGVyIHRoYW4gdmlhIHRoZQogICAgICAvLyBmYWlsZWQgbGluawoKICAgICAgQ29tcHV0ZV9FeHRl bmRlZF9QX1NwYWNlKGZhaWxfaW50ZikKCVtTTEldIEFkZGluZyAiZmFpbF9pbnRmIiBhcyBwYXJh bWV0ZXIKCQogICAgICAvLyBDb21wdXRlIHRoZSBzZXQgb2Ygbm9kZXMgdGhhdCBjYW4gcmVhY2gg dGhlIG5vZGUgb24gdGhlIGZhcgogICAgICAvLyBzaWRlIG9mIHRoZSBmYWlsZWQgbGluayB3aXRo b3V0IHRyYXZlcnNpbmcgdGhlIGZhaWxlZCBsaW5rLgoKICAgICAgQ29tcHV0ZV9RX1NwYWNlKGZh aWxfaW50ZikKCVtTTEldIEFkZGluZyAiZmFpbF9pbnRmIiBhcyBwYXJhbWV0ZXIKCiAgICAgIC8v IENvbXB1dGUgdGhlIHNldCBvZiBjYW5kaWRhdGUgUkxGQSB0dW5uZWwgZW5kcG9pbnRzCgoKCgpC cnlhbnQsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgTWF5IDAxLCAyMDE0ICAgICAgICAgICAg ICAgICAgW1BhZ2UgOV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIFJlbW90ZSBMRkEg RlJSICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMTMKCgogICAgICBJbnRlcnNlY3RfRXh0ZW5k ZWRfUF9hbmRfUV9TcGFjZSgpCgogICAgICAvLyBNYWtlIHN1cmUgdGhhdCB3ZSBjYW5ub3QgZ2V0 IGxvb3BpbmcgcmVwYWlycyB3aGVuIHRoZQogICAgICAvLyBmYWlsdXJlIGlzIHdvcnNlIHRoYW4g ZXhwZWN0ZWQuCgogICAgICBpZiAoZ3VhcmFudGVlX25vX2xvb3Bpbmdfb25fd29yc2VfdGhhbl9w cm90ZWN0ZWRfZmFpbHVyZSkKICAgICAgICAgIEFwcGx5X0Rvd25zdHJlYW1fQ29uc3RyYWludCgp Cn0KCgoJLy8gU3ViIGZ1bmN0aW9ucwoJCiAgICAgIC8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vCiAgICAgIC8vCiAgICAgIC8v IFRoaXMgY29tcHV0ZXMgdGhlIFNQRiBmcm9tIHJvb3QsIGFuZCBzdG9yZXMgdGhlIG9wdGltdW0K ICAgICAgLy8gZGlzdGFuY2UgZnJvbSByb290IHRvIGVhY2ggbm9kZSB5CgogICAgICBDb21wdXRl X2FuZF9TdG9yZV9Gb3J3YXJkX1NQRihyb290KQogICAgICAgICAgQ29tcHV0ZV9Gb3J3YXJkX1NQ Rihyb290KQogICAgICAgICAgZm9yZWFjaCBub2RlIHkgaW4gbmV0d29yawogICAgICAgICAgICAg IHN0b3JlIERfb3B0KHJvb3QseSkKCglbU0xJXSBJIHdvdWxkIGFkZCBhIGNvbW1lbnQgdG8gdGhl IGZ1bmN0aW9uIDoKCQogICAgICBDb21wdXRlX2FuZF9TdG9yZV9Gb3J3YXJkX1NQRihyb290KQog ICAgICAgICAgQ29tcHV0ZV9Gb3J3YXJkX1NQRihyb290KQkJLy8gQSBTUEYgbWF5IGFscmVhZHkg YmVlbiBpbiBjYWNoZSBhbmQgc28gbWF5IGJlIG5vIG5lZWQgdG8gcmVjb21wdXRlIGl0CiAgICAg ICAgICBmb3JlYWNoIG5vZGUgeSBpbiBuZXR3b3JrCiAgICAgICAgICAgICAgc3RvcmUgRF9vcHQo cm9vdCx5KQoKCiAgICAgIC8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vCiAgICAgIC8vCiAgICAgIC8vIFRoZSByZXZlcnNlIFNQ RiBjb21wdXRlcyB0aGUgY29zdCBmcm9tIGVhY2ggcmVtb3RlIG5vZGUgdG8KICAgICAgLy8gcm9v dC4gVGhpcyBpcyBhY2hpZXZlZCBieSBydW5uaW5nIHRoZSBub3JtYWwgU1BGIGFsZ29yaXRobSwK ICAgICAgLy8gYnV0IHVzaW5nIHRoZSBsaW5rIGNvc3QgaW4gdGhlIGRpcmVjdGlvbiBmcm9tIHRo ZSBuZXh0IGhvcAogICAgICAvLyBiYWNrIHRvd2FyZHMgcm9vdCBpbiBwbGFjZSBvZiB0aGUgbGlu ayBjb3N0IGluIHRoZSBkaXJlY3Rpb24KICAgICAgLy8gYXdheSBmcm9tIHJvb3QgdG93YXJkcyB0 aGUgbmV4dCBob3AuCgogICAgICBDb21wdXRlX2FuZF9TdG9yZV9SZXZlcnNlX1NQRihyb290KQog ICAgICAgICAgQ29tcHV0ZV9SZXZlcnNlX1NQRihyb290KQogICAgICAgICAgZm9yZWFjaCBub2Rl IHkgaW4gbmV0d29yawogICAgICAgICAgICAgIHN0b3JlIERfb3B0KHkscm9vdCkKCgoKCgpCcnlh bnQsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgTWF5IDAxLCAyMDE0ICAgICAgICAgICAgICAg ICBbUGFnZSAxMF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIFJlbW90ZSBMRkEgRlJS ICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMTMKCgogICAgICAvLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLwogICAgICAvLwog ICAgICAvLyBDYWxjdWxhdGUgUCBzcGFjZSBhbmQgdGhlbiBleHRlbmQgaXQgYnkgdGhlIFAtc3Bh Y2VzIG9mIGVhY2gKICAgICAgLy8gbmVpZ2hib3VyIG90aGVyIHRoYW4gdGhlIG9uZSByZWFjaGFi bGUgdmlhIHRoZSBsaW5rIGJlaW5nCiAgICAgIC8vIHByb3RlY3RlZC4gTm90ZSB0aGUgc3RyaWN0 bHkgbGVzcyB0aGFuIG9wZXJhdG9yIGlzIG5lZWRlZCB0bwogICAgICAvLyBhdm9pZCBFQ01QIGlz c3Vlcy4KCiAgICAgIENvbXB1dGVfRXh0ZW5kZWRfUF9TcGFjZSgpCiAgICAgICAgICBmb3JlYWNo IG5vZGUgeSBpbiBuZXR3b3JrCiAgICAgICAgICAgICAgeS5pbl9leHRlbmRlZF9QX3NwYWNlID0g ZmFsc2UKICAgICAgICAgICAgICAvLyBDb21wdXRlIFAtc3BhY2UKICAgICAgICAgICAgICAvLwog ICAgICAgICAgICAgIC8vIEVkaXRvcidzIG5vdGUsIEkgdGhpbmsgdGhhdCB0aGlzIGlmIHN0YXRl bWVudCBtYXkgYmUKICAgICAgICAgICAgICAvLyByZWR1bmRhbnQgc2luY2UgdGhlIGZvcmVhY2gg aW50ZXJmYWNlIGludGYgaW4gc2VsZgogICAgICAgICAgICAgIC8vIGxvb3AgY2F0Y2hlcyBhbGwg Y2FzZXMuCgkJCSAgCgkJCSAgW1NMSV0gWWVzLCBJTUhPLCB0aGlzIGlzIHJlZHVuZGFudC4KICAg ICAgICAgICAgICAKCQkJICAvLwogICAgICAgICAgICAgIC8vIEVkaXRvcidzIG5vdGUgRF9vcHQo ZmFpbF9pbnRmLnJlbW90ZV9ub2RlLHkpIHJlcXVpcmVzCiAgICAgICAgICAgICAgLy8gYW4gU1BG IGZyb20gbmVpZ2hib3VyIGZhaWxfaW50Zi5yZW1vdGVfbm9kZSBzbyBkaWQKICAgICAgICAgICAg ICAvLyB0aGlzIGFzIHBhcnQgb2YgYWxsIG5laWdoYm91cnMgU1BGIGNhbGN1bGF0aW9uCiAgICAg ICAgICAgICAgaWYgKERfb3B0KHNlbGYsIHkpIDwKICAgICAgICAgICAgICAgICAgICAgIERfb3B0 KHNlbGYsIGZhaWxfaW50Zi5yZW1vdGVfbm9kZSkgKwogICAgICAgICAgICAgICAgICAgICAgRF9v cHQoZmFpbF9pbnRmLnJlbW90ZV9ub2RlLHkpKQogICAgICAgICAgICAgICAgICB5LmluX2V4dGVu ZGVkX1Bfc3BhY2UgPSB0cnVlCiAgICAgICAgICAgICAgLy8gRXh0ZW5kIFAtc3BhY2UgdG8gdGhl IFAtc3BhY2VzIG9mIGFsbCByZWFjaGFibGUKICAgICAgICAgICAgICAvLyBuZWlnaGJvdXJzCiAg ICAgICAgICAgICAgZm9yZWFjaCBpbnRlcmZhY2UgaW50ZiBpbiBzZWxmCiAgICAgICAgICAgICAg ICAgIGlmIChpbnRmLnJlbW90ZV9ub2RlICE9IGZhaWxfaW50Zi5yZW1vdGVfbm9kZSkKICAgICAg ICAgICAgICAgICAgICAgIGlmICggRF9vcHQoaW50Zi5yZW1vdGVfbm9kZSwgeSkgPAogICAgICAg ICAgICAgICAgICAgICAgICAgICBEX29wdChpbnRmLnJlbW90ZV9ub2RlLCBzZWxmKSArCiAgICAg ICAgICAgICAgICAgICAgICAgICAgIERfb3B0KHNlbGYsZmFpbF9pbnRmLnJlbW90ZV9ub2RlKSAr CiAgICAgICAgICAgICAgICAgICAgICAgICAgIERfb3B0KGZhaWxfaW50Zi5yZW1vdGVfbm9kZSx5 KSApCiAgICAgICAgICAgICAgICAgICAgICAgeS5pbl9leHRlbmRlZF9QX3NwYWNlID0gdHJ1ZQoK CgogICAgICAvLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLwogICAgICAvLwoKICAgICAgQ29tcHV0ZV9RX1NwYWNlKGZhaWxfaW50 ZikKICAgICAgICAgIC8vIENvbXB1dGUgdGhlIGNvc3QgZnJvbSBldmVyeSBub2RlIHRoZSBuZXR3 b3JrIHRvIHRoZQogICAgICAgICAgLy8gbm9kZSBub3JtYWxseSByZWFjaGFibGUgYWNyb3NzIHRo ZSBmYWlsZWQgbGluawogICAgICAgICAgQ29tcHV0ZV9hbmRfU3RvcmVfUmV2ZXJzZV9TUEYoZmFp bF9pbnRmLnJlbW90ZV9ub2RlKQoKICAgICAgICAgIC8vIENvbXB1dGUgdGhlIGNvc3QgZnJvbSBl dmVyeSBub2RlIHRoZSBuZXR3b3JrIHRvIHNlbGYKICAgICAgICAgICBbU0xJXSBOZWVkIHRvIGJl IHJlbW92ZWQgSSBwdXR0ZWQgaXQgaW4gbWFpbiBjb2RlIChvcHRpbWl6ZSBudW1iZXIgb2YgU1BG KQoKICAgICAgICAgIGZvcmVhY2ggbm9kZSB5IGluIG5ldHdvcmsKICAgICAgICAgICAgICBpZiAo IERfb3B0KHksZmFpbF9pbnRmLnJlbW90ZV9ub2RlKSA8IERfb3B0KHksc2VsZikgKwoKCgpCcnlh bnQsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgTWF5IDAxLCAyMDE0ICAgICAgICAgICAgICAg ICBbUGFnZSAxMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIFJlbW90ZSBMRkEgRlJS ICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMTMKCgogICAgICAgICAgICAgICAgICAgICAgRF9v cHQoc2VsZixmYWlsX2ludGYucmVtb3RlX25vZGUpICkKICAgICAgICAgICAgICAgICAgeS5pbl9R X3NwYWNlID0gdHJ1ZQogICAgICAgICAgICAgIGVsc2UKICAgICAgICAgICAgICAgICAgeS5pbl9R X3NwYWNlID0gZmFsc2UKCgoKICAgICAgLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8KICAgICAgLy8KICAgICAgLy8gQ29tcHV0 ZSBzZXQgb2Ygbm9kZXMgaW4gYm90aCBleHRlbmRlZCBQLXNwYWNlIGFuZCBpbiBRLXNwYWNlCgog ICAgICBJbnRlcnNlY3RfRXh0ZW5kZWRfUF9hbmRfUV9TcGFjZSgpCiAgICAgICAgICBmb3JlYWNo IG5vZGUgeSBpbiBuZXR3b3JrCiAgICAgICAgICAgICAgaWYgKCB5LmluX2V4dGVuZGVkX1Bfc3Bh Y2UgJiYgeS5pbl9RX3NwYWNlICkKICAgICAgICAgICAgICAgICAgeS52YWxpZF90dW5uZWxfZW5k cG9pbnQgPSB0cnVlCiAgICAgICAgICAgICAgZWxzZQogICAgICAgICAgICAgICAgICB5LnZhbGlk X3R1bm5lbF9lbmRwb2ludCA9IGZhbHNlCgoKCiAgICAgIC8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vCiAgICAgIC8vCiAgICAg IC8vIEEgZG93bnN0cmVhbSByb3V0ZSBpcyBvbmUgd2hlcmUgdGhlIG5leHQgaG9wIGlzIHN0cmlj dGx5CiAgICAgIC8vIGNsb3NlciB0byB0aGUgZGVzdGluYXRpb24uIEJ5IHNlbmRpbmcgdGhlIHBh Y2tldCB0byBhCiAgICAgIC8vIFBRIG5vZGUgdGhhdCBpcyBkb3duc3RyZWFtLCB3ZSBrbm93IHRo YXQgaWYgdGhlIFBRIG5vZGUKICAgICAgLy8gZGV0ZWN0cyBhIGZhaWx1cmUsIGl0IHdpbGwgbm90 IGxvb3AgdGhlIHBhY2tldCBiYWNrIHRvIHNlbGYuCiAgICAgIC8vIFRoaXMgaXMgdXNlZnVsIHdo ZW4gdGhlcmUgYXJlIHR3byBmYWlsdXJlcywgb3IgYSBub2RlIGhhcwogICAgICAvLyBmYWlsZWQg cmF0aGVyIHRoYW4gYSBsaW5rLgoKICAgICAgQXBwbHlfRG93bnN0cmVhbV9Db25zdHJhaW50KCkK ICAgICAgICAgIGZvcmVhY2ggbm9kZSB5IGluIG5ldHdvcmsKICAgICAgICAgICAgICBpZiAoeS52 YWxpZF90dW5uZWxfZW5kcG9pbnQpCiAgICAgICAgICAgICAgICAgIENvbXB1dGVfYW5kX1N0b3Jl X0ZvcndhcmRfU1BGKHkpCiAgICAgICAgICAgICAgICAgIGlmICgoRF9vcHQoeSxkZXN0KSA8IERf b3B0KHNlbGYsZGVzdCkpCiAgICAgICAgICAgICAgICAgICAgICB5LnZhbGlkX3R1bm5lbF9lbmRw b2ludCA9IHRydWUKICAgICAgICAgICAgICAgICAgZWxzZQogICAgICAgICAgICAgICAgICAgICAg eS52YWxpZF90dW5uZWxfZW5kcG9pbnQgPSBmYWxzZQoJW1NMSV0gQmFzZWQgb24gbXkgc2ltdWxh dGlvbnMsIENvbXB1dGVfYW5kX1N0b3JlX0ZvcndhcmRfU1BGKHkpIHdvdWxkIG5vdCBiZSBwb3Nz aWJsZSBhcyBudW1iZXIgb2YgeS52YWxpZF90dW5uZWxfZW5kcG9pbnQgPT0gdHJ1ZSBpcyB2ZXJ5 IGhpZ2ggIQoJU28gZG93bnN0cmVhbW5lc3MgY291bGQgbm90IGJlIGVzdGFibGlzaGVkIHNvIGVh c2lseSAuLi4gZXZlbiBpZiBpdCdzIHRoZW9yaWNhbCB3b3JraW5nLgoJCgogICAvLwogICAvLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLwoKCgoKNS4gIEV4YW1wbGUgQXBwbGljYXRpb24gb2YgUmVtb3RlIExGQXMKCgoKCgpCcnlh bnQsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgTWF5IDAxLCAyMDE0ICAgICAgICAgICAgICAg ICBbUGFnZSAxMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIFJlbW90ZSBMRkEgRlJS ICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMTMKCgogICBBbiBleGFtcGxlIG9mIGEgY29tbW9u bHkgZGVwbG95ZWQgdG9wb2xvZ3kgd2hpY2ggaXMgbm90IGZ1bGx5CiAgIHByb3RlY3RlZCBieSBM RkFzIGFsb25lIGlzIHNob3duIGluIEZpZ3VyZSAzLiAgUEUxIGFuZCBQRTIgYXJlCiAgIGNvbm5l Y3RlZCBpbiB0aGUgc2FtZSBzaXRlLiAgUDEgYW5kIFAyIG1heSBiZSBnZW9ncmFwaGljYWxseQog ICBzZXBhcmF0ZWQgKGludGVyLXNpdGUpLiAgSW4gb3JkZXIgdG8gZ3VhcmFudGVlIHRoZSBsb3dl c3QgbGF0ZW5jeQogICBwYXRoIGZyb20vdG8gYWxsIG90aGVyIHJlbW90ZSBQRXMsIG5vcm1hbGx5 IHRoZSBzaG9ydGVzdCBwYXRoIGZvbGxvd3MKICAgdGhlIGdlb2dyYXBoaWNhbCBkaXN0YW5jZSBv ZiB0aGUgc2l0ZSBsb2NhdGlvbnMuICBUaGVyZWZvcmUsIHRvCiAgIGVuc3VyZSB0aGlzLCBhIGxv d2VyIElHUCBtZXRyaWMgKDUpIGlzIGFzc2lnbmVkIGJldHdlZW4gUEUxIGFuZCBQRTIuCiAgIEEg aGlnaCBtZXRyaWMgKDEwMDApIGlzIHNldCBvbiB0aGUgUC1QRSBsaW5rcyB0byBwcmV2ZW50IHRo ZSBQRXMKICAgYmVpbmcgdXNlZCBmb3IgdHJhbnNpdCB0cmFmZmljLiAgVGhlIFBFcyBhcmUgbm90 IGluZGl2aWR1YWxseSBkdWFsLQogICBob21lZCBpbiBvcmRlciB0byByZWR1Y2UgY29zdHMuCgog ICBUaGlzIGlzIGEgY29tbW9uIHRvcG9sb2d5IGluIFNQIG5ldHdvcmtzLgoKICAgV2hlbiBhIGZh aWx1cmUgb2NjdXJzIG9uIHRoZSBsaW5rIGJldHdlZW4gUEUxIGFuZCBQMiwgUEUxIGRvZXMgbm90 CiAgIGhhdmUgYW4gTEZBIGZvciB0cmFmZmljIHJlYWNoYWJsZSB2aWEgUDEuICBTaW1pbGFybHks IGJ5IHN5bW1ldHJ5LCBpZgogICB0aGUgbGluayBiZXR3ZWVuIFBFMiBhbmQgUDEgZmFpbHMsIFBF MiBkb2VzIG5vdCBoYXZlIGFuIExGQSBmb3IKICAgdHJhZmZpYyByZWFjaGFibGUgdmlhIFAyLgoK ICAgSW5jcmVhc2luZyB0aGUgbWV0cmljIGJldHdlZW4gUEUxIGFuZCBQRTIgdG8gYWxsb3cgdGhl IExGQSB3b3VsZAogICBpbXBhY3QgdGhlIG5vcm1hbCB0cmFmZmljIHBlcmZvcm1hbmNlIGJ5IHBv dGVudGlhbGx5IGluY3JlYXNpbmcgdGhlCiAgIGxhdGVuY3kuCgogICAgICAgICAgfCAgICAxMDAg ICAgfAogICAgICAgICAtUDItLS0tLS0tLS1QMS0KICAgICAgICAgICBcICAgICAgICAgLwogICAg ICAgMTAwMCBcICAgICAgIC8gMTAwMAogICAgICAgICAgICBQRTEtLS1QRTIKICAgICAgICAgICAg ICAgIDUKCiAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDM6IEV4YW1wbGUgU1AgdG9wb2xv Z3kKCiAgIENsZWFybHksIGZ1bGwgcHJvdGVjdGlvbiBjYW4gYmUgcHJvdmlkZWQsIHVzaW5nIHRo ZSB0ZWNobmlxdWVzCiAgIGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0LCBieSBQRTEgY2hvb3Npbmcg UDIgYXMgYSBQUSBub2RlLCBhbmQgUEUyCiAgIGNob29zaW5nIFAxIGFzIGEgUFEgbm9kZS4KICAg CiAgIFtTTEldIFdvdWxkIGl0IGJlICJQRTEgY2hvb3NpbmcgUDEiIGFuZCAiUEUyIGNob29zaW5n IFAyIiA/Cgo2LiAgTm9kZSBGYWlsdXJlcwoKICAgV2hlbiB0aGUgZmFpbHVyZSBpcyBhIG5vZGUg ZmFpbHVyZSByYXRoZXIgdGhhbiBhIGxpbmsgZmFpbHVyZSB0aGVyZQogICBpcyBhIGRhbmdlciB0 aGF0IHRoZSBSTEZBIHJlcGFpciB3aWxsIGxvb3AuICBUaGlzIGlzIGRpc2N1c3NlZCBpbgogICBk ZXRhaWwgaW4gW0ktRC5icnlhbnQtaXBmcnItdHVubmVsc10uICBJbiBzdW1tYXJ5IHByb2JsZW0g aXMgdGhhdCB0d28KICAgb2YgbW9yZSBvZiBFJ3MgbmVpZ2hib3JzIGVhY2ggd2l0aCBFIGFzIHRo ZSBuZXh0IGhvcCB0byBzb21lCiAgIGRlc3RpbmF0aW9uIEQgbWF5IGF0dGVtcHQgdG8gcmVwYWly IGEgcGFja2V0IGFkZHJlc3NlZCB0byBkZXN0aW5hdGlvbgogICBEIHZpYSB0aGUgb3RoZXIgbmVp Z2hib3IgYW5kIHRoZW4gRSwgdGh1cyBjYXVzaW5nIGEgbG9vcCB0byBmb3JtLiAgQXMKICAgd2ls bCBiZSBub3RlZCBmcm9tIFtJLUQuYnJ5YW50LWlwZnJyLXR1bm5lbHNdLCB0aGlzIGNhbiByYXBp ZGx5CiAgIGJlY29tZSBhIGNvbXBsZXggcHJvYmxlbSB0byBhZGRyZXNzLgoKCgoKCgpCcnlhbnQs IGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgTWF5IDAxLCAyMDE0ICAgICAgICAgICAgICAgICBb UGFnZSAxM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIFJlbW90ZSBMRkEgRlJSICAg ICAgICAgICAgICAgICBPY3RvYmVyIDIwMTMKCgogICBUaGVyZSBhcmUgYSBudW1iZXIgb2Ygd2F5 cyB0byBtaW5pbWl6ZSB0aGUgcHJvYmFiaWxpdHkgb2YgYSBsb29wCiAgIGZvcm1pbmcgd2hlbiBh IG5vZGUgZmFpbHVyZSBvY2N1cnMgYW5kIHRoZXJlIGV4aXN0cyB0aGUgcG9zc2liaWxpdHkKICAg dGhhdCB0d28gb2YgRSdzIG5laWdoYm9ycyBtYXkgZm9ybSBhIG11dHVhbCByZXBhaXIuCgogICAx LiAgRGV0ZWN0IHdoZW4gYSBwYWNrZXQgaGFzIGFycml2ZWQgb24gc29tZSBpbnRlcmZhY2UgSSB0 aGF0IGlzIGFsc28KICAgICAgIHRoZSBpbnRlcmZhY2UgdXNlZCB0byByZWFjaCB0aGUgZmlyc3Qg aG9wIG9uIHRoZSBSTEZBIHBhdGggdG8gUFEsCiAgICAgICBhbmQgZHJvcCB0aGUgcGFja2V0LiAg VGhpcyBpcyB1c2VmdWwgaW4gdGhlIGNhc2Ugb2YgYSByaW5nCiAgICAgICB0b3BvbG9neS4KW1NM SV0gVGhpcyBoYXMgc2V2ZXJhbCBkcmF3YmFja3MsIGVzcGVjaWFsbHkgdGhpcyBtYXkgY2F1c2Ug c29tZSAibGVnYWwgcGFja2V0IiBkcm9wcyAuLi4KIAoJICAgCiAgIDIuICBSZXF1aXJlIHRoYXQg dGhlIHBhdGggZnJvbSBQUSB0byBkZXN0aW5hdGlvbiBEIG5ldmVyIHBhc3NlcwogICAgICAgdGhy b3VnaCBFIChpbmNsdWRpbmcgaW4gdGhlIEVDTVAgY2FzZSksIGkuZS4gb25seSB1c2Ugbm9kZQog ICAgICAgcHJvdGVjdGluZyBwYXRocyBpbiB3aGljaCB0aGUgY29zdCBQUSB0byBEIGlzIHN0cmlj dGx5IGxlc3MgdGhhbgogICAgICAgdGhlIGNvc3QgUFEgdG8gRSBwbHVzIHRoZSBjb3N0IEUgdG8g RC4KCiAgIDMuICBSZXF1aXJlIHRoYXQgd2hlcmUgdGhlIHBhY2tldCBtYXkgcGFzcyB0aHJvdWdo IGFub3RoZXIgbmVpZ2hib3IKICAgICAgIG9mIEUsIHRoYXQgbm9kZSBpcyBkb3duIHN0cmVhbSAo aS5lLiBzdHJpY3RseSBjbG9zZXIgdG8gRCB0aGFuCiAgICAgICB0aGUgcmVwYWlyaW5nIG5vZGUp LiAgVGhpcyBtZWFucyB0aGF0IHNvbWUgbmVpZ2hib3Igb2YgRSAoWCkgY2FuCiAgICAgICByZXBh aXIgdmlhIHNvbWUgb3RoZXIgbmVpZ2hib3Igb2YgRSAoWSksIGJ1dCBZIGNhbm5vdCByZXBhaXIg dmlhCiAgICAgICBYLgoKICAgQ2FzZSAxIGFjY2VwdHMgdGhhdCBsb29wcyBtYXkgZm9ybSBhbmQg c3VwcHJlc3NlcyB0aGVtIGJ5IGRyb3BwaW5nCiAgIHBhY2tldHMuICBEcm9wcGluZyBwYWNrZXRz IG1heSBiZSBjb25zaWRlcmVkIGxlc3MgZGV0cmltZW50YWwgdGhhbgogICBsb29waW5nIHBhY2tl dHMuICBDYXNlcyAyIGFuZCAzIGFib3ZlIHByZXZlbnQgdGhlIGZvcm1hdGlvbiBvZiBhCiAgIGxv b3AsIGJ1dCBhdCB0aGUgZXhwZW5zZSBvZiBhIHJlZHVjZWQgcmVwYWlyIGNvdmVyYWdlIGFuZCBh dCB0aGUgY29zdAogICBvZiBhZGRpdGlvbmFsIGNvbXBsZXhpdHkgaW4gdGhlIGFsZ29yaXRobSB0 byBjb21wdXRlIHRoZSByZXBhaXIgcGF0aC4KCiAgIFRoZSBwcm9iYWJpbGl0eSBvZiBhIG5vZGUg ZmFpbHVyZSBhbmQgdGhlIGNvbnNlcXVlbmNlcyBvZiBub2RlCiAgIGZhaWx1cmUgaW4gYW55IHBh cnRpY3VsYXIgdG9wb2xvZ3kgd2lsbCBkZXBlbmQgb24gdGhlIG5vZGUgZGVzaWduLAogICB0aGUg cGFydGljdWxhciB0b3BvbG9neSBpbiB1c2UsIGFuZCBub2RlIGZhaWx1cmUgc3RyYXRlZ3kgKGlu Y2x1ZGluZwogICB0aGUgbnVsbCBzdHJhdGVneSkuICBJdCBpcyByZWNvbW1lbmRlZCB0aGF0IGEg bmV0d29yayBvcGVyYXRvcgogICBwZXJmb3JtIGFuIGFuYWx5c2lzIG9mIHRoZSBjb25zZXF1ZW5j ZXMgYW5kIHByb2JhYmlsaXR5IG9mIG5vZGUKICAgZmFpbHVyZSBpbiB0aGVpciBuZXR3b3JrLCBh bmQgZGV0ZXJtaW5lIHdoZXRoZXIgdGhlIGluY2lkZW5jZSBhbmQKICAgY29uc2VxdWVuY2Ugb2Yg b2NjdXJyZW5jZSBhcmUgYWNjZXB0YWJsZS4KCiAgIFRoaXMgdG9waWMgaXMgZnVydGhlciBkaXNj dXNzZWQgaW4KICAgW0ktRC5wc2Fya2FyLXJ0Z3dnLXJsZmEtbm9kZS1wcm90ZWN0aW9uXS4KCjcu ICBPcGVyYXRpb24gaW4gYW4gTERQIGVudmlyb25tZW50CgogICBXaGVyZSB0aGlzIHRlY2huaXF1 ZSBpcyB1c2VkIGluIGFuIE1QTFMgbmV0d29yayB1c2luZyBMRFAgW1JGQzUwMzZdLAogICBTIHdp bGwgbmVlZCB0byBwdXNoIHR3byBsYWJlbHMgb250byB0aGUgcmVwYWlyIHBhY2tldC4gIEZpcnN0 IGl0CiAgIG5lZWRzIHRvIHB1c2ggUFEncyBsYWJlbCB0byB0aGUgZGVzdGluYXRpb24sIGFuZCB0 aGVuIGl0IG5lZWRzIHRvCiAgIHB1c2ggaXRzIG93biBsYWJlbCBmb3IgUFEuICAKICAgCiAgIFtT TEldIElmIFMgaXMgdHJhbnNpdCBub2RlLCBpdCBzd2FwcyBpbmNvbWluZyBsYWJlbCB0byBQUSdz IGxhYmVsIHRvIHRoZSBkZXN0IGFuZCB0aGVuIHB1c2guCiAgIFNvIHRvIHNpbXBsaWZ5LCBJIHdv dWxkIHNheSA6ICJTIG5lZWQgdG8gcHVzaCBhbiBhZGRpdGlvbmFsIGxhYmVsIG9udG8gdGhlIHJl cGFpciBwYWNrZXQiLgogICAKICAgSW4gdGhlIGV4YW1wbGUgU2VjdGlvbiAzLjEgUyBhbHJlYWR5 IGhhcwogICBbU0xJXSBUaGUgZXhhbXBsZSBpcyBpbiBTZWN0aW9uIDIKICAgCiAgIHRoZSBmaXJz dCBob3AgKEIpIGxhYmVsIGZvciB0aGUgUFEgbm9kZSAoQykgYXMgYSByZXN1bHQgb2YgdGhlCiAg IFtTTEldIFdvdWxkIGl0IGJlICJ0aGUgZmlyc3QgaG9wIChBKSIgPwogICAKICAgb3JkaW5hcnkg b3BlcmF0aW9uIG9mIExEUC4gIFRvIGdldCB0aGUgUFEgbm9kZSAoQykgbGFiZWwgZm9yIHRoZQog ICBkZXN0aW5hdGlvbiAoRCksIFMgbmVlZHMgdG8gZXN0YWJsaXNoIGEgdGFyZ2V0ZWQgTERQIHNl c3Npb24gd2l0aCBDLgogICBUaGUgbGFiZWwgc3RhY2sgZm9yIG5vcm1hbCBvcGVyYXRpb24gYW5k IFJMRkEgb3BlcmF0aW9uIGlzIHNob3duCiAgIGJlbG93IGluIEZpZ3VyZSA0LgoKCgpCcnlhbnQs IGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgTWF5IDAxLCAyMDE0ICAgICAgICAgICAgICAgICBb UGFnZSAxNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIFJlbW90ZSBMRkEgRlJSICAg ICAgICAgICAgICAgICBPY3RvYmVyIDIwMTMKCgogICArLS0tLS0tLS0tLS0tLS0tLS0rICAgICAr LS0tLS0tLS0tLS0tLS0tLS0rICAgICArLS0tLS0tLS0tLS0tLS0tLS0rCiAgIHwgICAgZGF0YWxp bmsgICAgIHwgICAgIHwgICAgZGF0YWxpbmsgICAgIHwgICAgIHwgICAgZGF0YWxpbmsgICAgIHwK ICAgKy0tLS0tLS0tLS0tLS0tLS0tKyAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKyAgICAgKy0tLS0t LS0tLS0tLS0tLS0tKwogICB8IFMncyBsYWJlbCBmb3IgRCB8ICAgICB8IEUncyBsYWJlbCBmb3Ig RCB8ICAgICB8IEMncyBsYWJlbCBmb3IgRCB8CiAgICstLS0tLS0tLS0tLS0tLS0tLSsgICAgICst LS0tLS0tLS0tLS0tLS0tLSsgICAgICstLS0tLS0tLS0tLS0tLS0tLSsKICAgfCAgICBQYXlsb2Fk ICAgICAgfCAgICAgfCAgICBQYXlsb2FkICAgICAgfCAgICAgfCBCJ3MgbGFiZWwgZm9yIEMgfAog ICArLS0tLS0tLS0tLS0tLS0tLS0rICAgICArLS0tLS0tLS0tLS0tLS0tLS0rICAgICArLS0tLS0t LS0tLS0tLS0tLS0rCiAgICAgICAgICAgWCAgICAgICAgICAgICAgICAgICAgICAgWSAgICAgICAg ICAgICAgIHwgICAgUGF5bG9hZCAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBaCgogICBYID0gTm9y bWFsIGxhYmVsIHN0YWNrIHBhY2tldCBhcnJpdmluZyBhdCBTCiAgIFkgPSBOb3JtYWwgbGFiZWwg c3RhY2sgcGFja2V0IGxlYXZpbmcgUwogICBaID0gUkxGQSBsYWJlbCBzdGFjayB0byBEIHZpYSBD IGFzIFBRIG5vZGUKCglbU0xJXSBJbiBaLCB3b3VsZCBpdCBiZSAiQSdzIGxhYmVsIGZvciBDIiwg YXMgQSBpcyB0aGUgbmV4dGhvcCB0byByZWFjaCBDIGZyb20gUy4KCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEZpZ3VyZSA0CgogICBUbyBlc3RhYmxpc2ggYW4gdGFyZ2V0ZWQgTERQ IHNlc3Npb24gd2l0aCBhIGNhbmRpZGF0ZSBQUSBub2RlIHRoZQogICByZXBhaXJpbmcgbm9kZSAo UykgbmVlZHMgdG8ga25vdyB3aGF0IElQIGFkZHJlc3MgUFEgaXMgd2lsbGluZyB0byB1c2UKICAg Zm9yIHRhcmdldGVkIExEUCBzZXNzaW9ucy4gIElkZWFsbHkgdGhpcyBpcyBwcm92aWRlZCBieSBQ UQogICBhZHZlcnRpc2luZyB0aGlzIGFkZHJlc3MgaW4gdGhlIElHUCBpbiB1c2UuICBXaGljaCBh ZGRyZXNzIGlzIHVzZWQsCiAgIGhvdyB0aGlzIGlzIGFkdmVydGlzZWQgaW4gdGhlIElHUCwgYW5k IHdoZXRoZXIgdGhpcyBpcyBhIHNwZWNpYWwgSVAKICAgYWRkcmVzcyBvciBhbiBJUCBhZGRyZXNz IGFsc28gdXNlZCBmb3Igc29tZSBvdGhlciBwdXJwb3NlIGlzIG91dCBvZgogICBzY29wZSBmb3Ig dGhpcyBkb2N1bWVudCBhbmQgbXVzdCBiZSBzcGVjaWZpZWQgaW4gYW4gSUdQIHNwZWNpZmljIFJG Qy4KCiAgIEluIHRoZSBhYnNlbmNlIG9mIGEgcHJvdG9jb2wgdG8gbGVhcm4gdGhlIHByZWZlcnJl ZCBJUCBhZGRyZXNzIGZvcgogICB0YXJnZXRlZCBMRFAsIGEgdGllLWJyZWFraW5nIG1lY2hhbmlz bSBpcyByZXF1aXJlZC4gIFVubGVzcyBvdGhlcndpc2UKICAgY29uZmlndXJlZCwgYW4gTFNSIHNo b3VsZCBhdHRlbXB0IGEgdGFyZ2V0ZWQgTERQIHNlc3Npb24gd2l0aCB0aGUgSVAKICAgYWRkcmVz cyB3aXRoIHRoZSBsb3dlc3QgbnVtZXJpY2FsIHZhbHVlIGFkdmVydGlzZWQgYnkgdGhlIHRhcmdl dCBMU1IuCiAgIFRvIGRldGVybWluZSB0aGUgbG93ZXN0IG51bWVyaWNhbCB2YWx1ZSB0aGUgYWRk cmVzcyBpcyB0YWtlbiBpbgogICBuZXR3b3JrIGJ5dGUgb3JkZXIgYW5kIGNhc3QgdG8gYW4gaW50 ZWdlciBvZiBhcHByb3ByaWF0ZSBzaXplLgogICAKICAgW1NMSV0gSSB3b3VsZCBzdWdnZXN0IDoK ICAgVW5sZXNzIG90aGVyd2lzZQogICBjb25maWd1cmVkLCBhbiBMU1Igc2hvdWxkIGF0dGVtcHQg YSB0YXJnZXRlZCBMRFAgc2Vzc2lvbiBieSBzZWxlY3RpbmcgdGhlIGxvd2VzdCBpbnRlcm5hbCAv MzIgcHJlZml4IGFkdmVydGlzZWQgYnkgdGhlIHRhcmdldCBMU1IuCiAgIAogICBbU0xJXSBJIHdv dWxkIGFkZCBhbHNvIDoKICAgIklmIHRoZSBUTERQIHNlc3Npb24gY291bGQgbm90IGJlIGVzdGFi bGlzaGVkLCBubyBwcm90ZWN0aW9uIHdvdWxkIGJlIGF2YWlsYWJsZSB1bnRpbCB0aGUgZXN0YWJs aXNobWVudCBzdWNjZWVkcyBhbmQgYSBsYWJlbCBmb3IgdGhlIGRlc3RpbmF0aW9uIGhhcyBiZWVu IGxlYXJuZWQgZnJvbSB0aGUgUFEuIAogICBBbiBpbXBsZW1lbnRhdGlvbiBtYXkgYWR2aXNlIHRo ZSBvcGVyYXRvciBhYm91dCB0aGUgcHJvdGVjdGlvbiBzZXR1cCBpc3N1ZSB1c2luZyBhbnkgd2Vs bCBrbm93biBtZWNoYW5pc20gc3VjaCBhcyBzeXNsb2cgb3IgU05NUCBmb3IgZXhhbXBsZS4iCiAg IAoKCjguICBBbmFseXNpcyBvZiBSZWFsIFdvcmxkIFRvcG9sb2dpZXMKCiAgIFRoaXMgc2VjdGlv biBnaXZlcyB0aGUgcmVzdWx0cyBvZiBhbmFseXNpbmcgYSBudW1iZXIgb2YgcmVhbCB3b3JsZAog ICBzZXJ2aWNlIHByb3ZpZGVyIHRvcG9sb2dpZXMgY29sbGVjdGVkIGJldHdlZW4gT2N0b2JlciAy MDEyIGFuZCB0aGUKICAgZGF0ZSBvZiB0aGlzIGRyYWZ0LgoKOC4xLiAgVG9wb2xvZ3kgRGV0YWls cwoKICAgVGhlIGZpZ3VyZSBiZWxvdyBjaGFyYWN0ZXJpc2VzIGVhY2ggdG9wb2xvZ3kgKHRvcG8p IHN0dWRpZWQgaW4gdGVybXMKICAgb2YgOgoKICAgbyAgVGhlIG51bWJlciBvZiBub2RlcyAoIyBu b2RlcykgZXhjbHVkaW5nIHBzZXVkb25vZGVzLgoKCgoKCkJyeWFudCwgZXQgYWwuICAgICAgICAg ICAgRXhwaXJlcyBNYXkgMDEsIDIwMTQgICAgICAgICAgICAgICAgIFtQYWdlIDE1XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgUmVtb3RlIExGQSBGUlIgICAgICAgICAgICAgICAgIE9j dG9iZXIgMjAxMwoKCiAgIG8gIFRoZSBudW1iZXIgb2YgYmlkaXJlY3Rpb25hbCBsaW5rcyAoICMg bGlua3MpIGluY2x1ZGluZyBwYXJhbGxlbAogICAgICBsaW5rcyBhbmQgbGlua3MgdG8gYW5kIGZy b20gcHNldWRvbm9kZXMuCgogICBvICBUaGUgbnVtYmVyIG9mIG5vZGUgcGFpcnMgdGhhdCBhcmUg Y29ubmVjdGVkIGJ5IG9uZSBvciBtb3JlIGxpbmtzCiAgICAgICgjIHBhaXJzKS4KCiAgIG8gIFRo ZSBudW1iZXIgb2Ygbm9kZSBwYWlycyB0aGF0IGFyZSBjb25uZWN0ZWQgYnkgbW9yZSB0aGFuIG9u ZSAoaS5lLgogICAgICBwYXJhbGxlbCkgbGluayAoICMgcGFyYSkuCgogICBvICBUaGUgbnVtYmVy IG9mIGxpbmtzIChleGNsdWRpbmcgcHNldWRvbm9kZSBsaW5rcywgd2hpY2ggYXJlIGJ5CiAgICAg IGRlZmluaXRpb24gYXN5bW1ldHJpYykgdGhhdCBoYXZlIGFzeW1tZXRyaWMgbWV0cmljcyAoI2Fz eW0pLgoKICAgKy0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLSst LS0tLS0tLSsKICAgfCB0b3BvIHwgIyBub2RlcyB8ICMgbGlua3MgfCAjIHBhaXJzIHwgIyBwYXJh IHwgIyBhc3ltIHwKICAgKy0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0t LS0tLSstLS0tLS0tLSsKICAgfCAgICAxIHwgICAgIDMxNSB8ICAgICA1NzAgfCAgICAgNTYwIHwg ICAgIDEwIHwgICAgICAzIHwKICAgfCAgICAyIHwgICAgIDE1OCB8ICAgICAzNzMgfCAgICAgMzEy IHwgICAgIDMzIHwgICAgICAwIHwKICAgfCAgICAzIHwgICAgIDY1NSB8ICAgIDE3NjggfCAgICAx MzE0IHwgICAgMjc1IHwgICAxMTk1IHwKICAgfCAgICA0IHwgICAgMTI4MSB8ICAgIDIzMjYgfCAg ICAyMjQ4IHwgICAgIDcwIHwgICAgIDEwIHwKICAgfCAgICA1IHwgICAgIDM2NCB8ICAgICA4MTEg fCAgICAgNjU5IHwgICAgIDgwIHwgICAgIDg2IHwKICAgfCAgICA2IHwgICAgIDExNCB8ICAgICAz MTggfCAgICAgMTk3IHwgICAgMTAxIHwgICAgICA0IHwKICAgfCAgICA3IHwgICAgICA1NSB8ICAg ICAyMzcgfCAgICAgMTU5IHwgICAgIDY3IHwgICAgICAyIHwKICAgfCAgICA4IHwgICAgIDc3OSB8 ICAgIDE4NDggfCAgICAxNDQxIHwgICAgMTk5IHwgICAgNDM3IHwKICAgfCAgICA5IHwgICAgIDI2 MyB8ICAgICA0ODIgfCAgICAgNDEzIHwgICAgIDQxIHwgICAgIDEyIHwKICAgfCAgIDEwIHwgICAg ICA4NiB8ICAgICAzNzUgfCAgICAgMTQ1IHwgICAgIDY0IHwgICAgIDIyIHwKICAgfCAgIDExIHwg ICAgIDE2MiB8ICAgIDEwODMgfCAgICAgMzUxIHwgICAgMjAxIHwgICAgIDQ5IHwKICAgfCAgIDEy IHwgICAgIDM4MCB8ICAgIDExNzQgfCAgICAgNzYzIHwgICAgMjMxIHwgICAgICAwIHwKICAgfCAg IDEzIHwgICAgMTA1MSB8ICAgIDIwODcgfCAgICAyMDM3IHwgICAgIDQ4IHwgICAgIDY0IHwKICAg fCAgIDE0IHwgICAgICA5MiB8ICAgICAyOTEgfCAgICAgMjA0IHwgICAgIDY0IHwgICAgICAyIHwK ICAgKy0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLSstLS0tLS0t LSsKCgo4LjIuICBMRkEgb25seQoKICAgVGhlIGZpZ3VyZSBiZWxvdyBzaG93cyB0aGUgcGVyY2Vu dGFnZSBvZiBwcm90ZWN0ZWQgZGVzdGluYXRpb25zICglCiAgIHByb3QpIGFuZCBwZXJjZW50YWdl IG9mIGd1YXJhbnRlZWQgbm9kZSBwcm90ZWN0ZWQgZGVzdGluYXRpb25zICggJQogICBndGQgTikg Zm9yIHRoZSBzZXQgb2YgdG9wb2xvZ2llcyBjaGFyYWN0ZXJpemVkIGluIFNlY3Rpb24gOC4xCiAg IGFjaGlldmVkIHVzaW5nIG9ubHkgTEZBIHJlcGFpcnMuCgogICArLS0tLS0tKy0tLS0tLS0tKy0t LS0tLS0tLSsKICAgfCB0b3BvIHwgJSBwcm90IHwgJSBndGQgTiB8CiAgICstLS0tLS0rLS0tLS0t LS0rLS0tLS0tLS0tKwogICB8ICAgIDEgfCA3OC41ICAgfCAzNi45ICAgIHwKICAgfCAgICAyIHwg OTcuMyAgIHwgNTIuNCAgICB8CiAgIHwgICAgMyB8IDk5LjMgICB8IDU4ICAgICAgfAogICB8ICAg IDQgfCA4My4xICAgfCA2My4xICAgIHwKICAgfCAgICA1IHwgOTkgICAgIHwgNTkuMSAgICB8CiAg IHwgICAgNiB8IDg2LjQgICB8IDIxLjQgICAgfAoKCgpCcnlhbnQsIGV0IGFsLiAgICAgICAgICAg IEV4cGlyZXMgTWF5IDAxLCAyMDE0ICAgICAgICAgICAgICAgICBbUGFnZSAxNl0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgIFJlbW90ZSBMRkEgRlJSICAgICAgICAgICAgICAgICBPY3Rv YmVyIDIwMTMKCgogICB8ICAgIDcgfCA5My45ICAgfCAzNS40ICAgIHwKICAgfCAgICA4IHwgOTUu MyAgIHwgNDguMSAgICB8CiAgIHwgICAgOSB8IDgyLjIgICB8IDQ5LjUgICAgfAogICB8ICAgMTAg fCA5OC41ICAgfCAxNC45ICAgIHwKICAgfCAgIDExIHwgOTkuNiAgIHwgMjQuOCAgICB8CiAgIHwg ICAxMiB8IDk5LjUgICB8IDYyLjQgICAgfAogICB8ICAgMTMgfCA5Mi40ICAgfCA1MS42ICAgIHwK ICAgfCAgIDE0IHwgOTkuMyAgIHwgNDguNiAgICB8CiAgICstLS0tLS0rLS0tLS0tLS0rLS0tLS0t LS0tKwoKCjguMy4gIFJMRkEKCiAgIFRoZSBmaWd1cmUgYmVsb3cgc2hvd3MgdGhlIHBlcmNlbnRh Z2Ugb2YgcHJvdGVjdGVkIGRlc3RpbmF0aW9ucyAoJQogICBwcm90KSBhbmQgJSBndWFyYW50ZWVk IG5vZGUgcHJvdGVjdGVkIGRlc3RpbmF0aW9ucyAoICUgZ3RkIE4pIGZvcgogICBSTEZBIHByb3Rl Y3Rpb24gaW4gdGhlIHRvcG9sb2dpZXMgc3R1ZGllcy4gIAogICAKICAgW1NMSV0gSG93IGNvdWxk IHlvdSBkZXRlcm1pbmUgZ3VhcmFudGVlZCBub2RlIHByb3RlY3Rpb24gd2l0aCB5b3VyIHNwZWMg Zm9yIHJMRkEgPwogICAKICAgSW4gYWRkaXRpb24sIGl0IHNob3cgdGhlCiAgIHBlcmNlbnRhZ2Ug b2YgZGVzdGluYXRpb25zIHVzaW5nIGFuIFJMRkEgcmVwYWlyICglIFBRKSB0b2dldGhlciB3aXRo CiAgIHRoZSB0b3RhbCBudW1iZXIgb2YgdW5pZGlyZWN0aW9uYWwgUkxGQSB0YXJnZXRlZCBMRFAg c2Vzc2lvbgogICBlc3RhYmxpc2hlZCAoIyBQUSksIHRoZSBudW1iZXIgb2YgUFEgc2Vzc2lvbnMg d2hpY2ggd291bGQgYmUgcmVxdWlyZWQKICAgZm9yIGNvbXBsZXRlIHByb3RlY3Rpb24sIGJ1dCB3 aGljaCBjb3VsZCBub3QgYmUgZXN0YWJsaXNoZWQgKG5vIFBRKS4KICAgSXQgYWxzbyBzaG93cyB0 aGUgNTAgKHA1MCksIDkwIChwOTApIGFuZCAxMDAgKHAxMDApIHBlcmNlbnRpbGVzIGZvcgogICB0 aGUgbnVtYmVyIG9mIGluZGl2aWR1YWwgTERQIHNlc3Npb25zIHRlcm1pbmF0aW5nIGF0IGFuIGlu ZGl2aWR1YWwKICAgbm9kZSAod2hldGhlciB1c2VkIGZvciBUWCwgUlggb3IgYm90aCkuCgogICBG b3IgZXhhbXBsZSwgaWYgdGhlcmUgd2VyZSBMRFAgc2Vzc2lvbnMgcmVxdWlyZWQgQS0+QiwgQS0+ QywgQy0+QSwKICAgQy0+RCwgdGhlc2Ugd291bGQgYmUgY291bnRlZCBhcyAyLCAxLCAyLCAxIGF0 IG5vZGVzIEEsQixDIGFuZCBECiAgIHJlc3BlY3RpdmVseSBiZWNhdXNlOi0KCiAgICAgIEEgaGFz IHR3byBzZXNzaW9ucyAodG8gbm9kZXMgQiBhbmQgQykKCiAgICAgIEIgaGFzIG9uZSBzZXNzaW9u ICh0byBub2RlIEEpCgogICAgICBDIGhhcyB0d28gc2Vzc2lvbnMgKHRvIG5vZGVzIEEgYW5kIEQp CgogICAgICBEIGhhcyBvbmUgc2Vzc2lvbiAodG8gbm9kZSBEKQoKICAgSW4gdGhpcyBzdHVkeSwg UkxGQSBpcyBvbmx5IHVzZWQgd2hlbiBuZWNlc3NhcnkuIGkuZS4gd2hlbiB0aGVyZSBpcwogICBh dCBsZWFzdCBvbmUgZGVzdGluYXRpb24gd2hpY2ggaXMgbm90IHJlcGFyYWJsZSBieSBhIHBlciBk ZXN0aW5hdGlvbgogICBMRkEsIGFuZCBhIHNpbmdsZSBQUSB0dW5uZWwgaXMgdXNlZCAoaWYgYXZh aWxhYmxlKSB0byByZXBhaXIgdHJhZmZpYwogICB0byBhbGwgc3VjaCBkZXN0aW5hdGlvbnMuICBU aGUgUkxGQSBQUSBwb2ludHMgYXJlIGNvbXB1dGVkIHVzaW5nCiAgIGV4dGVuZGVkIFAgc3BhY2Ug YW5kIGNob29zaW5nIHRoZSBQUSBub2RlIHdoaWNoIGhhcyB0aGUgbG93ZXN0IG1ldHJpYwogICBj b3N0IGZyb20gdGhlIHJlcGFpcmluZyBub2RlLgoKCiAgICAgKy0tLS0tLSstLS0tLS0tLSstLS0t LS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLS0rLS0tLS0rLS0tLS0rLS0tLS0tKwogICAgIHwgdG9w byB8ICUgcHJvdCB8JSBndGQgTiB8ICUgUFEgfCAjIFBRIHwgbm8gUFEgfCBwNTAgfCBwOTAgfCBw MTAwIHwKICAgICArLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0t LSstLS0tLSstLS0tLSstLS0tLS0rCiAgICAgfCAgICAxIHwgOTkuNyAgIHwgNTMuMyAgIHwgMjEu MiB8ICAyOTUgfCAgICAgMyB8ICAgMSB8ICAgNSB8ICAgMTQgfAoKCgpCcnlhbnQsIGV0IGFsLiAg ICAgICAgICAgIEV4cGlyZXMgTWF5IDAxLCAyMDE0ICAgICAgICAgICAgICAgICBbUGFnZSAxN10K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIFJlbW90ZSBMRkEgRlJSICAgICAgICAgICAg ICAgICBPY3RvYmVyIDIwMTMKCgogICAgIHwgICAgMiB8IDk3LjUgICB8IDUyLjQgICB8IDAuMiAg fCAgICA3IHwgICAgNDAgfCAgIDAgfCAgIDAgfCAgICAyIHwKICAgICB8ICAgIDMgfCA5OS45OTkg fCA1OC40ICAgfCAwLjcgIHwgICA2MyB8ICAgICA1IHwgICAwIHwgICAxIHwgICAgNSB8CiAgICAg fCAgICA0IHwgOTkgICAgIHwgNzQuOCAgIHwgMTYgICB8IDE0MjQgfCAgICA1NCB8ICAgMSB8ICAg MyB8ICAgMjMgfAogICAgIHwgICAgNSB8IDk5LjUgICB8IDU5LjUgICB8IDAuNSAgfCAgMTUxIHwg ICAgIDcgfCAgIDAgfCAgIDIgfCAgICA3IHwKICAgICB8ICAgIDYgfCAxMDAgICAgfCAzNC45ICAg fCAxMy42IHwgICA2MyB8ICAgICAwIHwgICAxIHwgICAyIHwgICAgNiB8CiAgICAgfCAgICA3IHwg OTkuOTk5IHwgNDAuNiAgIHwgNi4xICB8ICAgMTYgfCAgICAgMiB8ICAgMCB8ICAgMiB8ICAgIDQg fAogICAgIHwgICAgOCB8IDk5LjUgICB8IDUwLjIgICB8IDQuMyAgfCAgMzUwIHwgICAgMzkgfCAg IDAgfCAgIDIgfCAgIDE1IHwKICAgICB8ICAgIDkgfCA5OS41ICAgfCA1NSAgICAgfCAxNy4zIHwg IDQyOCB8ICAgICA1IHwgICAxIHwgICAyIHwgICA2NyB8CiAgICAgfCAgIDEwIHwgOTkuNiAgIHwg MTQuMSAgIHwgMSAgICB8ICAgNDkgfCAgICAgNyB8ICAgMSB8ICAgMiB8ICAgIDUgfAogICAgIHwg ICAxMSB8IDk5LjkgICB8IDI0LjkgICB8IDAuMyAgfCAgIDg1IHwgICAgIDEgfCAgIDAgfCAgIDIg fCAgICA4IHwKICAgICB8ICAgMTIgfCA5OS45OTkgfCA2Mi44ICAgfCAwLjUgIHwgIDUxMiB8ICAg ICA0IHwgICAwIHwgICAwIHwgICAgMyB8CiAgICAgfCAgIDEzIHwgOTcuNSAgIHwgNTQuNiAgIHwg NS4xICB8IDExODggfCAgICA5NSB8ICAgMCB8ICAgMiB8ICAgMjcgfAogICAgIHwgICAxNCB8IDEw MCAgICB8IDQ4LjYgICB8IDAuNyAgfCAgIDc5IHwgICAgIDAgfCAgIDAgfCAgIDIgfCAgICA0IHwK ICAgICArLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tLSstLS0t LSstLS0tLSstLS0tLS0rCgoKCSBbU0xpXSBXb3VsZCBiZSBnb29kIHRvIGhhdmUgdGhlIGF2Zywg YW5kIG1heCBudW1iZXIgb2YgUFFzIG5vZGUgYXZhaWxhYmxlIGZvciBhIHNwZWNpZmljIGludGVy ZmFjZSBvciBnbG9iYWxseSBmb3IgYSBub2RlLgoKCiAgIEFub3RoZXIgc3R1ZHlbSVNPQ09SRTIw MTBdIGNvbmZpcm1zIHRoZSBzaWduaWZpY2FudCBjb3ZlcmFnZSBpbmNyZWFzZQogICBwcm92aWRl ZCBieSBSZW1vdGUgTEZBcy4KCjguNC4gIENvbXBhcmlzb24gb2YgTEZBIGFuIFJMRkEgcmVzdWx0 cwoKICAgVGhlIHRhYmxlIGJlbG93IHByb3ZpZGVzIGEgc2lkZSBieSBzaWRlIGNvbXBhcmlzb24g dGhlIExGQSBhbmQgdGhlCiAgIHJlbW90ZSBMRkEgcmVzdWx0cy4gIFRoaXMgc2hvd3MgYSBzaWdu aWZpY2FudCBpbXByb3ZlbWVudCBpbiB0aGUKICAgcGVyY2VudGFnZSBvZiBwcm90ZWN0ZWQgZGVz dGluYXRpb25zIGFuZCBub3JtYWxseSBhIG1vZGVzdAogICBpbXByb3ZlbWVudCBpbiB0aGUgcGVy Y2VudGFnZSBvZiBndWFyYW50ZWVkIG5vZGUgcHJvdGVjdGVkCiAgIGRlc3RpbmF0aW9ucy4KCgog ICAgICArLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0rCiAgICAg IHwgdG9wbyB8ICBMRkEgICB8IFJMRkEgICB8ICBMRkEgICAgfCAgUkxGQSAgIHwKICAgICAgfCAg ICAgIHwgJSBwcm90IHwgJXByb3QgIHwgJSBndGQgTiB8ICUgZ3RkIE4gfAogICAgICArLS0tLS0t Ky0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0rCiAgICAgIHwgICAgMSB8IDc4 LjUgICB8IDk5LjcgICB8IDM2LjkgICAgfCA1My4zICAgIHwKICAgICAgfCAgICAyIHwgOTcuMyAg IHwgOTcuNSAgIHwgNTIuNCAgICB8IDUyLjQgICAgfAogICAgICB8ICAgIDMgfCA5OS4zICAgfCA5 OS45OTkgfCA1OCAgICAgIHwgNTguNCAgICB8CiAgICAgIHwgICAgNCB8IDgzLjEgICB8IDk5ICAg ICB8IDYzLjEgICAgfCA3NC44ICAgIHwKICAgICAgfCAgICA1IHwgOTkgICAgIHwgOTkuNSAgIHwg NTkuMSAgICB8IDU5LjUgICAgfAogICAgICB8ICAgIDYgfCA4Ni40ICAgfDEwMCAgICAgfCAyMS40 ICAgIHwgMzQuOSAgICB8CiAgICAgIHwgICAgNyB8IDkzLjkgICB8IDk5Ljk5OSB8IDM1LjQgICAg fCA0MC42ICAgIHwKICAgICAgfCAgICA4IHwgOTUuMyAgIHwgOTkuNSAgIHwgNDguMSAgICB8IDUw LjIgICAgfAogICAgICB8ICAgIDkgfCA4Mi4yICAgfCA5OS41ICAgfCA0OS41ICAgIHwgNTUgICAg ICB8CiAgICAgIHwgICAxMCB8IDk4LjUgICB8IDk5LjYgICB8IDE0LjkgICAgfCAxNC4xICAgIHwK ICAgICAgfCAgIDExIHwgOTkuNiAgIHwgOTkuOSAgIHwgMjQuOCAgICB8IDI0LjkgICAgfAogICAg ICB8ICAgMTIgfCA5OS41ICAgfCA5OS45OTkgfCA2Mi40ICAgIHwgNjIuOCAgICB8CiAgICAgIHwg ICAxMyB8IDkyLjQgICB8IDk3LjUgICB8IDUxLjYgICAgfCA1NC42ICAgIHwKICAgICAgfCAgIDE0 IHwgOTkuMyAgIHwxMDAgICAgIHwgNDguNiAgICB8IDQ4LjYgICAgfAoKCgpCcnlhbnQsIGV0IGFs LiAgICAgICAgICAgIEV4cGlyZXMgTWF5IDAxLCAyMDE0ICAgICAgICAgICAgICAgICBbUGFnZSAx OF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIFJlbW90ZSBMRkEgRlJSICAgICAgICAg ICAgICAgICBPY3RvYmVyIDIwMTMKCgogICAgICArLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tKy0t LS0tLS0tLSstLS0tLS0tLS0rCgoKCiAgIEFzIHNob3duIGluIHRoZSB0YWJsZSwgcmVtb3RlIExG QSBwcm92aWRlcyBjbG9zZSB0byAxMDAlIHByZWZpeAogICBwcm90ZWN0aW9uIGFnYWluc3QgbGlu ayBmYWlsdXJlIGluIDExIG9mIHRoZSAxNCB0b3BvbG9naWVzIHN0dWRpZWQsCiAgIGFuZCBwcm92 aWRlcyBhIHNpZ25pZmljYW50IGltcHJvdmVtZW50IGluIHR3byBvZiB0aGUgcmVtYWluaW5nIHRo cmVlCiAgIGNhc2VzLiAgSW4gYW4gTVBMUyBuZXR3b3JrLCB0aGlzIGlzIGFjaGlldmVkIHdpdGhv dXQgYW55IHNhbGVhYmlsaXR5CiAgIGltcGFjdCwgYXMgdGhlIHR1bm5lbHMgdG8gdGhlIFBRIG5v ZGVzIGFyZSBhbHdheXMgcHJlc2VudCBhcyBhCiAgIHByb3BlcnR5IG9mIGFuIExEUC1iYXNlZCBk ZXBsb3ltZW50LiAgSW4gdGhlIHZlcnkgZmV3IGNhc2VzIHdoZXJlIFAKICAgYW5kIFEgc3BhY2Vz IGhhdmUgYW4gZW1wdHkgaW50ZXJzZWN0aW9uLCBvbmUgY291bGQgc2VsZWN0IHRoZSBjbG9zZXN0 CiAgIG5vZGUgaW4gdGhlIFEgc3BhY2UgYW5kIHNpZ25hbCBhbiBleHBsaWNpdGx5LXJvdXRlZCBS U1ZQIFRFIExTUCB0bwogICB0aGF0IFEgbm9kZS4gIEEgZGlyZWN0ZWQgTERQIHNlc3Npb24gaXMg dGhlbiBlc3RhYmxpc2hlZCB3aXRoIHRoZQogICBzZWxlY3RlZCBRIG5vZGUgYW5kIHRoZSByZXN0 IG9mIHRoZSBzb2x1dGlvbiBpcyBpZGVudGljYWwgdG8gdGhhdAogICBkZXNjcmliZWQgZWxzZXdo ZXJlIGluIHRoaXMgZG9jdW1lbnQuICBBbHRlcm5hdGl2ZWx5IHRoZSBzZWdtZW50CiAgIHJvdXRp bmcgdGVjaG5vbG9neSBiZWluZyBkZWZpbmVkIGluIHRoZSBJRVRGIG1heSBiZSB1c2VkIHRvIGNh cnJ5IHRoZQogICB0cmFmZmljIGJldHdlZW4gbm9uLWNvbGxvY2F0ZWQgUCBhbmQgUSBub2Rlcwog ICBbSS1ELmZpbHNmaWxzLXJ0Z3dnLXNlZ21lbnQtcm91dGluZy11c2UtY2FzZXNdLAogICBbSS1E LmZpbHNmaWxzLXJ0Z3dnLXNlZ21lbnQtcm91dGluZ10sCiAgIFtJLUQuZ3JlZGxlci1ydGd3Zy1p Z3AtbGFiZWwtYWR2ZXJ0aXNlbWVudF0uCgo5LiAgTWFuYWdlbWVudCBDb25zaWRlcmF0aW9ucwoK ICAgVGhlIG1hbmFnZW1lbnQgb2YgTEZBIGFuZCByZW1vdGUgTEZBIGlzIHRoZSBzdWJqZWN0IG9m IG9uZ29pbmcgd29yawogICB3aXRoaW5nIHRoZSBJRVRGW0ktRC5pZXRmLXJ0Z3dnLWxmYS1tYW5h Z2VhYmlsaXR5XSB0byB3aGljaCB0aGUKICAgcmVhZGVyIGlzIHJlZmVycmVkLiAgSW4gY29udHJh c3QgdG8gdGhpcyB0ZXh0IHdoaWNoIHJlY29tbWVuZHMgdGhhdAogICBMRkFzIGJlIHByZWZlcnJl ZCBvdmVyIHJlbW90ZSBMRkFzLAogICBbSS1ELmlldGYtcnRnd2ctbGZhLW1hbmFnZWFiaWxpdHld IG5vdGVzIHRoYXQgdGhlcmUgbWF5IGJlIHJlYXNvbiB0bwogICB1c2UgcmVtb3RlIExGQXMgZXZl biBpZiBvcmRpbmFyeSBMRkFzIGFyZSBhdmFpbGFibGUuICBUaGlzIHJlcXVpcmVzCiAgIGZ1cnRo ZXIgc3R1ZHkuCiAgIAogICBbU0xJXSBJIHdvdWxkIHJlbW92ZSAiVGhpcyByZXF1aXJlcyBmdXJ0 aGVyIHN0dWR5LiIsIGFzIHRoZSBwcm9ibGVtIGlzIGEgdHJ1ZSBvbmUsIGFscmVhZHkgcHJvdmVk LCBhbmQgdGhlcmUgaXMgYWxyZWFkeSBzb21lIGltcGxlbWVudGF0aW9ucy4KICAgV2hhdCB3b3Vs ZCBiZSB0aGUgaW1wYWN0IG9mIGFsd2F5cyBydW5uaW5nIHJMRkEgPyBJIGRvbid0IHJlYWxseSBz ZWUgYSByZWFzb24gdG8gbm90IGRvIGl0IGJ5IGRlZmF1bHQuIAogICBDb21wdXRhdGlvbiBpcyBu b3QgYSBiaWcgZGVhbCBhbmQgcGVvcGxlIHdobyBkb24ndCB3YW50IHJlbW90ZSBMRkEgY2FuIGNo b29zZSB0byBub3QgYWN0aXZhdGUgaXQgb24gYSBzcGVjaWZpYyBpbnRlcmZhY2Ugb3Igbm9kZS4K ICAgSSBkb24ndCB3YW50IHRvIHNlZSBhICJub24gZ29vZCBiZWhhdmlvciIgbWVudGlvbm5lZCBp biB0aGUgZHJhZnQsIGp1c3QgYmVjYXVzZSBvbmUgY29kZSBpcyBhbHJlYWR5IHJ1bm5pbmcgYXMg eW91IHNwZWNpZmllZCAuLi4gaXQgbWF5IG5vdCBiZSB0aGUgZ29vZCBhcHByb2FjaC4KCiAgIEkg d291bGQgcHJvcG9zZSB0byBjaGFuZ2UgeW91ciBiZWhhdmlvciBhbmQgc2F5IGFsd2F5cyBjb21w dXRlIHJMRkEsIGFuZCB0aGVuIHRpZSBicmVhayBiZXR3ZWVuIGFsbCBhbHRlcm5hdGVzLgogICAK ICAgCgoxMC4gIEhpc3RvcmljYWwgTm90ZQoKICAgVGhlIGJhc2ljIGNvbmNlcHRzIGJlaGluZCBS ZW1vdGUgTEZBIHdlcmUgaW52ZW50ZWQgaW4gMjAwMiBhbmQgd2VyZQogICBsYXRlciBpbmNsdWRl ZCBpbiBbSS1ELmJyeWFudC1pcGZyci10dW5uZWxzXSwgc3VibWl0dGVkIGluIDIwMDQuCgogICBb SS1ELmJyeWFudC1pcGZyci10dW5uZWxzXSwgdGFyZ2V0ZWQgYSAxMDAlIHByb3RlY3Rpb24gY292 ZXJhZ2UgYW5kCiAgIGhlbmNlIGluY2x1ZGVkIGFkZGl0aW9uYWwgbWVjaGFuaXNtcyBvbiB0b3Ag b2YgdGhlIFJlbW90ZSBMRkEKICAgY29uY2VwdC4gIFRoZSBhZGRpdGlvbiBvZiB0aGVzZSBtZWNo YW5pc21zIG1hZGUgdGhlIHByb3Bvc2FsIHZlcnkKICAgY29tcGxleCBhbmQgY29tcHV0YXRpb25h bGx5IGludGVuc2l2ZSBhbmQgaXQgd2FzIHRoZXJlZm9yZSBub3QKICAgcHVyc3VlZCBhcyBhIHdv cmtpbmcgZ3JvdXAgaXRlbS4KCiAgIEFzIGV4cGxhaW5lZCBpbiBbSS1ELmZpbHNmaWxzLXJ0Z3dn LWxmYS1hcHBsaWNhYmlsaXR5XSwgdGhlIHB1cnBvc2UKICAgb2YgdGhlIExGQSBGUlIgdGVjaG5v bG9neSBpcyBub3QgdG8gcHJvdmlkZSBjb3ZlcmFnZSBhdCBhbnkgY29zdC4gIEEKICAgc29sdXRp b24gZm9yIHRoaXMgYWxyZWFkeSBleGlzdHMgd2l0aCBNUExTIFRFIEZSUi4gIE1QTFMgVEUgRlJS IGlzIGEKICAgbWF0dXJlIHRlY2hub2xvZ3kgd2hpY2ggaXMgYWJsZSB0byBwcm92aWRlIHByb3Rl Y3Rpb24gaW4gYW55IHRvcG9sb2d5CiAgIHRoYW5rcyB0byB0aGUgZXhwbGljaXQgcm91dGluZyBj YXBhYmlsaXR5IG9mIE1QTFMgVEUuCgoKCgpCcnlhbnQsIGV0IGFsLiAgICAgICAgICAgIEV4cGly ZXMgTWF5IDAxLCAyMDE0ICAgICAgICAgICAgICAgICBbUGFnZSAxOV0KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgIFJlbW90ZSBMRkEgRlJSICAgICAgICAgICAgICAgICBPY3RvYmVyIDIw MTMKCgogICBUaGUgcHVycG9zZSBvZiBMRkEgRlJSIHRlY2hub2xvZ3kgaXMgdG8gcHJvdmlkZSBm b3IgYSBzaW1wbGUgRlJSCiAgIHNvbHV0aW9uIHdoZW4gc3VjaCBhIHNvbHV0aW9uIGlzIHBvc3Np YmxlLiAgVGhlIGZpcnN0IHN0ZXAgYWxvbmcgdGhpcwogICBzaW1wbGljaXR5IGFwcHJvYWNoIHdh cyAibG9jYWwiIExGQSBbUkZDNTI4Nl0uICBXZSBwcm9wb3NlICJSZW1vdGUKICAgTEZBIiBhcyBh IG5hdHVyYWwgc2Vjb25kIHN0ZXAuICBUaGUgZm9sbG93aW5nIHNlY3Rpb24gbW90aXZhdGVzIGl0 cwogICBiZW5lZml0cyBpbiB0ZXJtcyBvZiBzaW1wbGljaXR5LCBpbmNyZW1lbnRhbCBkZXBsb3lt ZW50IGFuZAogICBzaWduaWZpY2FudCBjb3ZlcmFnZSBpbmNyZWFzZS4KCjExLiAgSUFOQSBDb25z aWRlcmF0aW9ucwoKICAgVGhlcmUgYXJlIG5vIElBTkEgY29uc2lkZXJhdGlvbnMgdGhhdCBhcmlz ZSBmcm9tIHRoaXMgYXJjaGl0ZWN0dXJhbAogICBkZXNjcmlwdGlvbiBvZiBJUEZSUi4gIFRoZSBS RkMgRWRpdG9yIG1heSByZW1vdmUgdGhpcyBzZWN0aW9uIG9uCiAgIHB1YmxpY2F0aW9uLgoKMTIu ICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAgVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z IG9mIFJGQyA1Mjg2IGFsc28gYXBwbHkuCgogICBUbyBwcmV2ZW50IHRoZWlyIHVzZSBhcyBhbiBh dHRhY2sgdmVjdG9yIHRoZSByZXBhaXIgdHVubmVsIGVuZHBvaW50cwogICBTSE9VTEQgYmUgYXNz aWduZWQgZnJvbSBhIHNldCBvZiBhZGRyZXNzZXMgdGhhdCBhcmUgbm90IHJlYWNoYWJsZQogICBm cm9tIG91dHNpZGUgdGhlIHJvdXRpbmcgZG9tYWluLgoKMTMuICBBY2tub3dsZWRnbWVudHMKCiAg IFRoZSBhdXRob3JzIGFja25vd2xlZGdlIHRoZSB0ZWNobmljYWwgY29udHJpYnV0aW9ucyBtYWRl IHRvIHRoaXMgd29yawogICBieSBTdGVmYW5vIFByZXZpZGkuICBUaGUgYXV0aG9ycyB3aXNoIHRv IHRoYW5rIExldmVudGUgQ3Npa29yIGFuZAogICBDaHJpcyBCb3dlcnMgZm9yIHRoZXJlIGNvbnRy aWJ1dGlvbiB0byB0aGUgY29zdCBiYXNlZCBhbGdvcml0aG0gdGV4dC4KCjE0LiAgSW5mb3JtYXRp dmUgUmVmZXJlbmNlcwoKICAgW0ktRC5icnlhbnQtaXBmcnItdHVubmVsc10KICAgICAgICAgICAg ICBCcnlhbnQsIFMuLCBGaWxzZmlscywgQy4sIFByZXZpZGksIFMuLCBhbmQgTS4gU2hhbmQsICJJ UAogICAgICAgICAgICAgIEZhc3QgUmVyb3V0ZSB1c2luZyB0dW5uZWxzIiwgZHJhZnQtYnJ5YW50 LWlwZnJyLXR1bm5lbHMtMDMKICAgICAgICAgICAgICAod29yayBpbiBwcm9ncmVzcyksIE5vdmVt YmVyIDIwMDcuCgogICBbSS1ELmZpbHNmaWxzLXJ0Z3dnLWxmYS1hcHBsaWNhYmlsaXR5XQogICAg ICAgICAgICAgIEZpbHNmaWxzLCBDLiwgRnJhbmNvaXMsIFAuLCBTaGFuZCwgTS4sIERlY3JhZW5l LCBCLiwKICAgICAgICAgICAgICBVdHRhcm8sIEouLCBMZXltYW5uLCBOLiwgYW5kIE0uIEhvcm5l ZmZlciwgIkxGQQogICAgICAgICAgICAgIGFwcGxpY2FiaWxpdHkgaW4gU1AgbmV0d29ya3MiLCBk cmFmdC1maWxzZmlscy1ydGd3Zy1sZmEtCiAgICAgICAgICAgICAgYXBwbGljYWJpbGl0eS0wMCAo d29yayBpbiBwcm9ncmVzcyksIE1hcmNoIDIwMTAuCgogICBbSS1ELmZpbHNmaWxzLXJ0Z3dnLXNl Z21lbnQtcm91dGluZy11c2UtY2FzZXNdCiAgICAgICAgICAgICAgRmlsc2ZpbHMsIEMuLCBGcmFu Y29pcywgUC4sIFByZXZpZGksIFMuLCBEZWNyYWVuZSwgQi4sCiAgICAgICAgICAgICAgTGl0a293 c2tpLCBTLiwgSG9ybmVmZmVyLCBNLiwgTWlsb2pldmljLCBJLiwgU2hha2lyLCBSLiwKICAgICAg ICAgICAgICBZdHRpLCBTLiwgSGVuZGVyaWNreCwgVy4sIFRhbnRzdXJhLCBKLiwgS2luaSwgUy4s IGFuZCBFLgogICAgICAgICAgICAgIENyYWJiZSwgIlNlZ21lbnQgUm91dGluZyBVc2UgQ2FzZXMi LCBkcmFmdC1maWxzZmlscy1ydGd3Zy0KICAgICAgICAgICAgICBzZWdtZW50LXJvdXRpbmctdXNl LWNhc2VzLTAyICh3b3JrIGluIHByb2dyZXNzKSwgT2N0b2JlcgogICAgICAgICAgICAgIDIwMTMu CgoKCgpCcnlhbnQsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgTWF5IDAxLCAyMDE0ICAgICAg ICAgICAgICAgICBbUGFnZSAyMF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIFJlbW90 ZSBMRkEgRlJSICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMTMKCgogICBbSS1ELmZpbHNmaWxz LXJ0Z3dnLXNlZ21lbnQtcm91dGluZ10KICAgICAgICAgICAgICBGaWxzZmlscywgQy4sIFByZXZp ZGksIFMuLCBCYXNoYW5keSwgQS4sIERlY3JhZW5lLCBCLiwKICAgICAgICAgICAgICBMaXRrb3dz a2ksIFMuLCBIb3JuZWZmZXIsIE0uLCBNaWxvamV2aWMsIEkuLCBTaGFraXIsIFIuLAogICAgICAg ICAgICAgIFl0dGksIFMuLCBIZW5kZXJpY2t4LCBXLiwgVGFudHN1cmEsIEouLCBhbmQgRS4gQ3Jh YmJlLAogICAgICAgICAgICAgICJTZWdtZW50IFJvdXRpbmcgQXJjaGl0ZWN0dXJlIiwgZHJhZnQt Zmlsc2ZpbHMtcnRnd2ctCiAgICAgICAgICAgICAgc2VnbWVudC1yb3V0aW5nLTAxICh3b3JrIGlu IHByb2dyZXNzKSwgT2N0b2JlciAyMDEzLgoKICAgW0ktRC5ncmVkbGVyLXJ0Z3dnLWlncC1sYWJl bC1hZHZlcnRpc2VtZW50XQogICAgICAgICAgICAgIEdyZWRsZXIsIEguLCBBbWFudGUsIFMuLCBT Y2hvbGwsIFQuLCBhbmQgTC4gSmFsaWwsCiAgICAgICAgICAgICAgIkFkdmVydGlzaW5nIE1QTFMg bGFiZWxzIGluIElHUHMiLCBkcmFmdC1ncmVkbGVyLXJ0Z3dnLQogICAgICAgICAgICAgIGlncC1s YWJlbC1hZHZlcnRpc2VtZW50LTA1ICh3b3JrIGluIHByb2dyZXNzKSwgTWF5IDIwMTMuCgogICBb SS1ELmlldGYtcnRnd2ctbGZhLW1hbmFnZWFiaWxpdHldCiAgICAgICAgICAgICAgTGl0a293c2tp LCBTLiwgRGVjcmFlbmUsIEIuLCBGaWxzZmlscywgQy4sIGFuZCBLLiBSYXphLAogICAgICAgICAg ICAgICJPcGVyYXRpb25hbCBtYW5hZ2VtZW50IG9mIExvb3AgRnJlZSBBbHRlcm5hdGVzIiwgZHJh ZnQtCiAgICAgICAgICAgICAgaWV0Zi1ydGd3Zy1sZmEtbWFuYWdlYWJpbGl0eS0wMCAod29yayBp biBwcm9ncmVzcyksIE1heQogICAgICAgICAgICAgIDIwMTMuCgogICBbSS1ELnBzYXJrYXItcnRn d2ctcmxmYS1ub2RlLXByb3RlY3Rpb25dCiAgICAgICAgICAgICAgcHNhcmthckBqdW5pcGVyLm5l dCwgcC4sIEdyZWRsZXIsIEguLCBIZWdkZSwgUy4sIGFuZCBILgogICAgICAgICAgICAgIFJhZ2h1 dmVlciwgIk5vZGUgUHJvdGVjdGluZyBSLUxGQSBhbmQgTWFuYWdlYWJpbGl0eSIsCiAgICAgICAg ICAgICAgZHJhZnQtcHNhcmthci1ydGd3Zy1ybGZhLW5vZGUtcHJvdGVjdGlvbi0wMSAod29yayBp bgogICAgICAgICAgICAgIHByb2dyZXNzKSwgSnVseSAyMDEzLgoKICAgW0lTT0NPUkUyMDEwXQog ICAgICAgICAgICAgIFNvLCBOLiwgTGluLCBULiwgYW5kIEMuIENoZW4sICJMRkEgKExvb3AgRnJl ZSBBbHRlcm5hdGVzKQogICAgICAgICAgICAgIENhc2UgU3R1ZGllcyBpbiBWZXJpem9uJ3MgTERQ IE5ldHdvcmsiLCAyMDEwLgoKICAgW1JGQzE3MDFdICBIYW5rcywgUy4sIExpLCBULiwgRmFyaW5h Y2NpLCBELiwgYW5kIFAuIFRyYWluYSwgIkdlbmVyaWMKICAgICAgICAgICAgICBSb3V0aW5nIEVu Y2Fwc3VsYXRpb24gKEdSRSkiLCBSRkMgMTcwMSwgT2N0b2JlciAxOTk0LgoKICAgW1JGQzE4NTNd ICBTaW1wc29uLCBXLiwgIklQIGluIElQIFR1bm5lbGluZyIsIFJGQyAxODUzLCBPY3RvYmVyIDE5 OTUuCgogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZD cyB0byBJbmRpY2F0ZQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwg UkZDIDIxMTksIE1hcmNoIDE5OTcuCgogICBbUkZDMzAzMl0gIFJvc2VuLCBFLiwgVGFwcGFuLCBE LiwgRmVkb3Jrb3csIEcuLCBSZWtodGVyLCBZLiwKICAgICAgICAgICAgICBGYXJpbmFjY2ksIEQu LCBMaSwgVC4sIGFuZCBBLiBDb250YSwgIk1QTFMgTGFiZWwgU3RhY2sKICAgICAgICAgICAgICBF bmNvZGluZyIsIFJGQyAzMDMyLCBKYW51YXJ5IDIwMDEuCgogICBbUkZDNTAzNl0gIEFuZGVyc3Nv biwgTC4sIE1pbmVpLCBJLiwgYW5kIEIuIFRob21hcywgIkxEUAogICAgICAgICAgICAgIFNwZWNp ZmljYXRpb24iLCBSRkMgNTAzNiwgT2N0b2JlciAyMDA3LgoKICAgW1JGQzUyODZdICBBdGxhcywg QS4gYW5kIEEuIFppbmluLCAiQmFzaWMgU3BlY2lmaWNhdGlvbiBmb3IgSVAgRmFzdAogICAgICAg ICAgICAgIFJlcm91dGU6IExvb3AtRnJlZSBBbHRlcm5hdGVzIiwgUkZDIDUyODYsIFNlcHRlbWJl ciAyMDA4LgoKICAgW1JGQzU3MTRdICBTaGFuZCwgTS4gYW5kIFMuIEJyeWFudCwgIklQIEZhc3Qg UmVyb3V0ZSBGcmFtZXdvcmsiLCBSRkMKICAgICAgICAgICAgICA1NzE0LCBKYW51YXJ5IDIwMTAu CgoKCkJyeWFudCwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBNYXkgMDEsIDIwMTQgICAgICAg ICAgICAgICAgIFtQYWdlIDIxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgUmVtb3Rl IExGQSBGUlIgICAgICAgICAgICAgICAgIE9jdG9iZXIgMjAxMwoKCkF1dGhvcnMnIEFkZHJlc3Nl cwoKICAgU3Rld2FydCBCcnlhbnQKICAgQ2lzY28gU3lzdGVtcwogICAyNTAsIExvbmd3YXRlciwg R3JlZW4gUGFyaywKICAgUmVhZGluZyAgUkcyIDZHQiwgVUsKICAgVUsKCiAgIEVtYWlsOiBzdGJy eWFudEBjaXNjby5jb20KCgogICBDbGFyZW5jZSBGaWxzZmlscwogICBDaXNjbyBTeXN0ZW1zCiAg IERlIEtsZWV0bGFhbiA2YQogICAxODMxIERpZWdlbQogICBCZWxnaXVtCgogICBFbWFpbDogY2Zp bHNmaWxAY2lzY28uY29tCgoKICAgU3RlZmFubyBQcmV2aWRpCiAgIENpc2NvIFN5c3RlbXMKCiAg IEVtYWlsOiBzcHJldmlkaUBjaXNjby5jb20KCgogICBNaWtlIFNoYW5kCiAgIEluZGVwZW5kZW50 IENvbnRyaWJ1dG9yCgogICBFbWFpbDogaW1jLnNoYW5kQGdtYWlsLmNvbQoKCiAgIE5pbmcgU28K ICAgVGF0YSBDb21tdW5pY2F0aW9ucwogICBNb2JpbGUgQnJvYWRiYW5kIFNlcnZpY2VzCgogICBF bWFpbDogTmluZy5Tb0B0YXRhY29tbXVuaWNhdGlvbnMuY29tCgoKCgoKCgoKCgoKCgoKQnJ5YW50 LCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIE1heSAwMSwgMjAxNCAgICAgICAgICAgICAgICAg W1BhZ2UgMjJdCg== --_002_EEE55384044474429A926C625D0FCC8109902E372BPUEXCB2Fnante_-- From aretana@cisco.com Tue Oct 29 09:50:33 2013 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 68C8E11E8251 for ; Tue, 29 Oct 2013 09:50:17 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nItVfojQlkaK for ; Tue, 29 Oct 2013 09:50:11 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 09B2121E80BE for ; Tue, 29 Oct 2013 09:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2076; q=dns/txt; s=iport; t=1383065313; x=1384274913; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=1BcCV0eYEbdETPpQ4Zd5mqt4AufWr/veoy4x4dDxfag=; b=HjAdVGi7tX3tANTmNDjBtyfovJ8OY88E5oXvYT9MspYput+n4odaJiKK JGRF4wwOn0IWiSPZssXGASgEqVAVme0NqS9VqS6MIFCH7fLu7OBWSyDEh FGWbOVyAA3AEk2t79BPj+3nz078L9UsIbKMkZLUF4rs6O48D8slB7S+G0 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4GABrmb1KtJV2b/2dsb2JhbABZgkNEOFS/NYEqFm0HgicBBIELAQgEAR0dORQRAgQTCId/DZgvoWkEjxYtC4MfgQ0DqhKDJoIq X-IronPort-AV: E=Sophos;i="4.93,594,1378857600"; d="scan'208,217";a="277877299" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 29 Oct 2013 16:48:20 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9TGmK2c030043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 29 Oct 2013 16:48:20 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.40]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Tue, 29 Oct 2013 11:48:20 -0500 From: "Alvaro Retana (aretana)" To: "rtgwg@ietf.org" Subject: Re: IETF 88 Agenda Items Thread-Topic: IETF 88 Agenda Items Thread-Index: AQHOvu+xvvXhYYVgF0uuaDZky93MeJoDBJsAgAkbnQA= Date: Tue, 29 Oct 2013 16:48:19 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.255.166] Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94E396F480Axmbalnx15ciscoc_" 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, 29 Oct 2013 16:50:35 -0000 --_000_BBD66FD99311804F80324E8139B3C94E396F480Axmbalnx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 10/23/13 5:43 PM, "Alvaro Retana (aretana)" > wrote: I just published the draft agenda here: https://datatracker.ietf.org/meeti= ng/88/agenda/rtgwg/ Just updated the agenda to the final one. Alvaro. --_000_BBD66FD99311804F80324E8139B3C94E396F480Axmbalnx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <0DD6D9E05D36824FAB5862EAD6F058BB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 10/23/13 5:43 PM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

I just published the draft agenda here:  https://datatracker.ietf.org/meeting/88= /agenda/rtgwg/

Just updated the agenda to the final one.

Alvaro.
--_000_BBD66FD99311804F80324E8139B3C94E396F480Axmbalnx15ciscoc_-- From cbowers@juniper.net Tue Oct 29 11:21:04 2013 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 6CF2B21E809D for ; Tue, 29 Oct 2013 11:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.182 X-Spam-Level: X-Spam-Status: No, score=-5.182 tagged_above=-999 required=5 tests=[AWL=1.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yNOFQz7mqyb for ; Tue, 29 Oct 2013 11:20:57 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 72EEA11E8185 for ; Tue, 29 Oct 2013 11:20:57 -0700 (PDT) Received: from mail1-co9-R.bigfish.com (10.236.132.235) by CO9EHSOBE024.bigfish.com (10.236.130.87) with Microsoft SMTP Server id 14.1.225.22; Tue, 29 Oct 2013 18:20:56 +0000 Received: from mail1-co9 (localhost [127.0.0.1]) by mail1-co9-R.bigfish.com (Postfix) with ESMTP id C7BF73602A9; Tue, 29 Oct 2013 18:20:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz9371Ic85fh1418I199bIzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2fh2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h9a9j1155h) Received-SPF: pass (mail1-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=cbowers@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(51444003)(65554003)(377454003)(74706001)(31966008)(80976001)(66066001)(81816001)(81342001)(15202345003)(76482001)(56776001)(69226001)(54316002)(15975445006)(74316001)(74876001)(46102001)(51856001)(74366001)(87266001)(79102001)(33646001)(85306002)(80022001)(4396001)(16236675002)(74662001)(74502001)(47446002)(65816001)(81686001)(47976001)(50986001)(49866001)(47736001)(53806001)(54356001)(63696002)(19580405001)(83322001)(83072001)(59766001)(77982001)(76176001)(76576001)(81542001)(56816003)(19580395003)(76786001)(76796001)(19300405004)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB290; H:BLUPR05MB292.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail1-co9 (localhost.localdomain [127.0.0.1]) by mail1-co9 (MessageSwitch) id 1383070854714693_7038; Tue, 29 Oct 2013 18:20:54 +0000 (UTC) Received: from CO9EHSMHS021.bigfish.com (unknown [10.236.132.249]) by mail1-co9.bigfish.com (Postfix) with ESMTP id A8DBC340068; Tue, 29 Oct 2013 18:20:54 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS021.bigfish.com (10.236.130.31) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 29 Oct 2013 18:20:50 +0000 Received: from BLUPR05MB290.namprd05.prod.outlook.com (10.141.23.24) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.371.2; Tue, 29 Oct 2013 18:20:46 +0000 Received: from BLUPR05MB292.namprd05.prod.outlook.com (10.141.23.27) by BLUPR05MB290.namprd05.prod.outlook.com (10.141.23.24) with Microsoft SMTP Server (TLS) id 15.0.785.10; Tue, 29 Oct 2013 18:20:45 +0000 Received: from BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) by BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) with mapi id 15.00.0785.001; Tue, 29 Oct 2013 18:20:45 +0000 From: Chris Bowers To: "stbryant@cisco.com" , "rtgwg@ietf.org" Subject: issue#2 in candidate-draft-ietf-rtgwg-remote-lfa-03.txt Thread-Topic: issue#2 in candidate-draft-ietf-rtgwg-remote-lfa-03.txt Thread-Index: Ac7UvymD5GcQE3G7Q92ZB9+fbjoXFQ== Date: Tue, 29 Oct 2013 18:20:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 0014E2CF50 Content-Type: multipart/alternative; boundary="_000_af308a17d3f24a65a61cb1b476fa4782BLUPR05MB292namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 29 Oct 2013 18:21:04 -0000 --_000_af308a17d3f24a65a61cb1b476fa4782BLUPR05MB292namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The text in section 4.2.1 and 4.2.2 describing the (unextended) P-space cal= culation should be removed. I agree with the Editor's note below in the comments for the Compute_Extend= ed_P_Space() function in the algorithm pseudocode that the "if statement ma= y be redundant since the foreach interface intf in self loop catches all ca= ses." That is, calculating (unextended) P-space is not needed. The original algorithm text was written to mirror the existing description = in section 4.2.2. " Another way to describe extended P-space is that it is the union of ( un-extended ) P-space and the set of destinations for which S has a per-prefix LFA protecting the link S-E. i.e. the repair tunnel end point can be reached either directly or using a per-prefix LFA." If we are in agreement that the (unextended) P-space is not needed, then se= ctions 4.2.1 and 4.2.2 should be rewritten to eliminate or lessen the impor= tance of (unextended) P-space since it doesn't serve a useful purpose in th= e text (except to motivate why it makes sense to use extended P-space.) In particular, section 4.2.1 contains the following definition of a PQ-node= : "In Figure 1 the intersection of the E's Q-space with S's P-space defines the set of viable repair tunnel end-points, known as "PQ nodes"= . " This definition contradicts the definition of the PQ node in section 1. "PQ node- A node which is a member of both the extended P-space and the Q-space." I am happy to provide new text for sections 4.2.1 and 4.2.2 if we are in ba= sic agreement on this. Chris From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Monday, October 28, 2013 9:33 AM To: Chris Bowers; rtgwg@ietf.org Subject: Re: algorithm description for draft-ietf-rtgwg-remote-lfa Please see notes inline. Here is the current candidate algorithm text. I added lots of comments for my personal checking of the algorithm and my guess is that they will be of use to reader and reviewers further down the line. Once this is correct we will need to add a glossary of terms. 4.3. A Cost Based RLFA Algorithm The preceding text has mostly described the computation of the remote LFA repair point (PQ) in terms of the intersection of two reachability graphs computed using SPFs. This section describes a method of computing the repair point using a cost based algorithm. The pseudo-code provides in this section avoids unnecessary SPF computations, but for the sake of readability, it does not otherwise try to optimize the code. Unconventionally, but for clarity, we provide the main algorithm followed its procedures. In this description D_opt(a,b) is the shortest distance from node a to node b as computed by the SPF. //////////////////////////////////////////////////////////////////// // // We have already computed the forward SPF from self to all nodes // y in network and thus we know D_opt (self, y). This is needed // for normal forwarding. // However for completeness. Compute_and_Store_Forward_SPF(self) // To extend P-space we compute the SPF at each neighbour except the // neighbour that is reached via the link being protected. // We will also need D_opt(fail_intf.remote_node,y) so compute that // at the same time. Compute_Neighbor_SPFs() // Compute the set of nodes {P} reachable other than via the // failed link Compute_Extended_P_Space() // Compute the set of nodes that can reach the node on the far side // of the failed link without traversing the failed link. Compute_Q_Space() // Compute the set of candidate RLFA tunnel endpoints Bryant, et al. Expires May 01, 2014 [Page 8] Internet-Draft Remote LFA FRR October 2013 Intersect_Extended_P_and_Q_Space() // Make sure that we cannot get looping repairs when the // failure is worse than expected. if (guarantee_no_looping_on_worse_than_protected_failure) Apply_Downstream_Constraint() ///////////////////////////////////////////////////////////////////// // // This computes the SPF from root, and stores stores the optimum // distance from root to each node y Compute_and_Store_Forward_SPF(root) Compute_Forward_SPF(root) foreach node y in network store D_opt(root,y) ///////////////////////////////////////////////////////////////////// // // This computes the optimum distance from each neighbour (other than // the neighbour reachable through the failed link) and every other // node in the network Compute_Neighbor_SPFs() foreach interface intf in self Compute_and_Store_Forward_SPF(intf.remote_node) ///////////////////////////////////////////////////////////////////// // // The reverse SPF computes the cost from each remote node to root. // This is acheived by running the normal SPF algorithm, but using th= e // link cost in the direction from the next hop back towards root // in place of the link cost in the direction away from root towards // the next hop. Compute_and_Store_Reverse_SPF(root) Compute_Reverse_SPF(root) foreach node y in network store D_opt(y,root) Bryant, et al. Expires May 01, 2014 [Page 9] Internet-Draft Remote LFA FRR October 2013 ///////////////////////////////////////////////////////////////////// // // Calculate P space and then extend it by the P-spaces of each // neighbour other than the one reachable via the link being // protected. Note the strictly less than operator is needed to // avoid ECMP issues. Compute_Extended_P_Space() foreach node y in network y.in_extended_P_space =3D false // Compute P-space // // Editor's note, I think that this if statement may be // redundent since the foreach interface intf in self loop // catches all cases. // // Editor's note D_opt(fail_intf.remote_node,y) requires an // SPF from neighbour fail_intf.remote_node so did this as // part of all neighbours SPF calculation if (D_opt(self, y) < D_opt(self, fail_intf.remote_node) + D_opt(fail_intf.remote_node,y)) y.in_extended_P_space =3D true // Extend P-space to the P-spaces of all reachable // neighbours foreach interface intf in self if (intf.remote_node !=3D fail_intf.remote_node) if ( D_opt(intf.remote_node, y) < D_opt(intf.remote_node, self) + D_opt(self,fail_intf.remote_node) + D_opt(fail_intf.remote_node,y) ) y.in_extended_P_space =3D true ///////////////////////////////////////////////////////////////////// // Compute_Q_Space() // Compute the cost from every node the network to the // node normally reachable across the failed link Compute_and_Store_Reverse_SPF(fail_intf.remote_node) // Compute the cost from every node the network to self Compute_and_Store_Reverse_SPF(self) foreach node y in network if ( D_opt(y,fail_intf.remote_node) < D_opt(y,self) + Bryant, et al. Expires May 01, 2014 [Page 10] Internet-Draft Remote LFA FRR October 2013 D_opt(self,fail_intf.remote_node) ) y.in_Q_space =3D true else y.in_Q_space =3D false ///////////////////////////////////////////////////////////////////// // // Compute set of nodes in both extended P-space and in Q-space Intersect_Extended_P_and_Q_Space() foreach node y in network if ( y.in_extended_P_space && y.in_Q_space ) y.valid_tunnel_endpoint =3D true else y.valid_tunnel_endpoint =3D false ///////////////////////////////////////////////////////////////////// // // A downstream route is one where the next hop is strictly // closer to the destination. By sending the packet to a // PQ node that is downstream, we know that if the PQ node // detects a failure, it will not loop the packet back to self. // This is useful when there are two failures, or a node has // failed rather than a link. Apply_Downstream_Constraint() foreach node y in network if (y.valid_tunnel_endpoint) Compute_and_Store_Forward_SPF(y) if ((D_opt(y,dest) < D_opt(self,dest)) y.valid_tunnel_endpoint =3D true else y.valid_tunnel_endpoint =3D false // ///////////////////////////////////////////////////////////////////// Please can someone verify that the algorithm is correct. See from the text below that I thought that the original missed some SPFs --------- Rest of thread removed to keep below 50kB. --_000_af308a17d3f24a65a61cb1b476fa4782BLUPR05MB292namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
The text in section 4.2.1 and 4.2.2 describing the (unextended) P-spac=
e calculation should be removed.  
 
I agree with the Editor’s note below in the comments for the Com=
pute_Extended_P_Space() function in the algorithm pseudocode that the ̶=
0;if statement may be redundant since the foreach interface intf in self lo=
op catches all cases.”  That is, calculating (unextended) P-spac=
e is not needed.
 
The original algorithm text was written to mirror the existing descrip=
tion in section 4.2.2.
“  Another way to describe extended P-space is that it is t=
he union of (
   un-extended ) P-space and the set of destinations for whi=
ch S has a
   per-prefix LFA protecting the link S-E. i.e. the repair t=
unnel end
   point can be reached either directly or using a per-prefi=
x LFA.”
 
If we are in agreement that the (unextended) P-space is not needed, th=
en sections 4.2.1 and 4.2.2 should be rewritten to eliminate or lessen the =
importance of (unextended) P-space since it doesn’t serve a useful pu=
rpose in the text (except to motivate why it makes sense to use extended P-=
space.)
 
In particular, section 4.2.1 contains the following definition of a PQ=
-node:
 
   “In Figure 1 the intersection of the E's Q-space wi=
th S's P-space 
    defines the set of viable repair tunnel end-po=
ints, known as "PQ nodes". “
 
This definition contradicts the definition of the PQ node in section 1=
.  
 
“PQ node- A node which is a member of both the extended P-space<=
o:p>
         and the Q-space.̶=
1;
 
I am happy to provide new text for sections 4.2.1 and 4.2.2 if we are =
in basic agreement on this.
 
Chris
 

 <= /p>

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Monday, October 28, 2013 9:33 AM
To: Chris Bowers; rtgwg@ietf.org
Subject: Re: algorithm description for draft-ietf-rtgwg-remote-lfa

 

Please see notes inli= ne.

Here is the current candidate algorithm text. I added lots of
comments for my personal checking of the algorithm
and my guess is that they will be of use to reader and
reviewers further down the line.

Once this is correct we will need to add a glossary of terms. 

4.3.  A Cost Based RLFA Algorithm
 
   The preceding text has mostly described the computation o=
f the
   remote LFA repair point (PQ) in terms of the intersection=
 of two
   reachability graphs computed using SPFs.  This secti=
on describes a
   method of computing the repair point using a cost based a=
lgorithm.
   The pseudo-code provides in this section avoids unnecessa=
ry SPF
   computations, but for the sake of readability, it does no=
t otherwise
   try to optimize the code.  Unconventionally, but for=
 clarity, we
   provide the main algorithm followed its procedures. =
 In this
   description D_opt(a,b) is the shortest distance from node=
 a to node b
   as computed by the SPF.
      ///////////////////////////////////////=
/////////////////////////////
      //
      // We have already computed the forward=
 SPF from self to all nodes
      // y in network and thus we know D_opt =
(self, y). This is needed
      // for normal forwarding.

      // However for completeness.=



 


      Compute_and_Store_Forward_SPF(self)


 


      // To extend P-space we compute the SPF=
 at each neighbour except the


      // neighbour that is reached via the li=
nk being protected.


      // We will also need D_opt(fail_intf.re=
mote_node,y) so compute that


      // at the same time.


 


      Compute_Neighbor_SPFs()

 


      // Compute the set of nodes {P} reachab=
le other than via the


      // failed link


 


      Compute_Extended_P_Space()

 


      // Compute the set of nodes that can re=
ach the node on the far side


      // of the failed link without traversin=
g the failed link.


 


      Compute_Q_Space()


 


      // Compute the set of candidate RLFA tu=
nnel endpoints


 


 


 


 


Bryant, et al.         &n=
bsp;  Expires May 01, 2014       &n=
bsp;          [Page 8]


 


Internet-Draft         &n=
bsp;     Remote LFA FRR     &n=
bsp;           October 20=
13


 


 


      Intersect_Extended_P_and_Q_Space()=



 


      // Make sure that we cannot get looping=
 repairs when the


      // failure is worse than expected.=



 


      if (guarantee_no_looping_on_worse_than_=
protected_failure)


          Apply_Downstrea=
m_Constraint()


 


 


 


      ///////////////////////////////////////=
//////////////////////////////


      //


      // This computes the SPF from root, and=
 stores stores the optimum


      // distance from root to each node y


 


      Compute_and_Store_Forward_SPF(root)


          Compute_Forward=
_SPF(root)


          foreach node y =
in network


           &nbs=
p;  store D_opt(root,y)


 


 


 


      ///////////////////////////////////////=
//////////////////////////////


      //


      // This computes the optimum distance f=
rom each neighbour (other than


      // the neighbour reachable through the =
failed link) and every other


      // node in the network


 


   Compute_Neighbor_SPFs()


       foreach interface intf in self


           Compute_a=
nd_Store_Forward_SPF(intf.remote_node)


 


 


 


      ///////////////////////////////////////=
//////////////////////////////


      //


      // The reverse SPF computes the cost fr=
om each remote node to root.


      // This is acheived by running the norm=
al SPF algorithm, but using the


      // link cost in the direction from the =
next hop back towards root


      // in place of the link cost in the dir=
ection away from root towards


      // the next hop.


 


      Compute_and_Store_Reverse_SPF(root)


          Compute_Reverse=
_SPF(root)


          foreach node y =
in network


           &nbs=
p;  store D_opt(y,root)


 


 


 


 


 


Bryant, et al.         &n=
bsp;  Expires May 01, 2014       &n=
bsp;          [Page 9]


 


Internet-Draft         &n=
bsp;     Remote LFA FRR     &n=
bsp;           October 20=
13


 


 


      ///////////////////////////////////////=
//////////////////////////////


      //


      // Calculate P space and then extend it=
 by the P-spaces of each


      // neighbour other than the one reachab=
le via the link being


      // protected. Note the strictly less th=
an operator is needed to


      // avoid ECMP issues.


 


      Compute_Extended_P_Space()

          foreach node y =
in network


           &nbs=
p;  y.in_extended_P_space =3D false


           &nbs=
p;  // Compute P-space


           &nbs=
p;  //


           &nbs=
p;  // Editor's note, I think that this if statement may be=



           &nbs=
p;  // redundent since the foreach interface intf in self loop


            &nb=
sp; // catches all cases.


           &nbs=
p;  //


           &nbs=
p;  // Editor's note D_opt(fail_intf.remote_node,y) requires an


           &nbs=
p;  // SPF from neighbour fail_intf.remote_node so did this as


           &nbs=
p;  // part of all neighbours SPF calculation


            &nb=
sp; if (D_opt(self, y) <


           &nbs=
p;          D_opt(self, fail_i=
ntf.remote_node) +


           &nbs=
p;          D_opt(fail_intf.re=
mote_node,y))


           &nbs=
p;      y.in_extended_P_space =3D true<=
/pre>

           &nbs=
p;  // Extend P-space to the P-spaces of all reachable

           &nbs=
p;  // neighbours


           &nbs=
p;  foreach interface intf in self


           &nbs=
p;      if (intf.remote_node !=3D fail_intf.remote=
_node)


           &nbs=
p;          if ( D_opt(intf.re=
mote_node, y) <


           &nbs=
p;            &=
nbsp;  D_opt(intf.remote_node, self) +


            &nb=
sp;            =
  D_opt(self,fail_intf.remote_node) +


           &nbs=
p;            &=
nbsp;  D_opt(fail_intf.remote_node,y) )


           &nbs=
p;           y.in_extende=
d_P_space =3D true


 


 


 


      ///////////////////////////////////////=
//////////////////////////////


      //


 


      Compute_Q_Space()


          // Compute the =
cost from every node the network to the


          // node normall=
y reachable across the failed link


          Compute_and_Sto=
re_Reverse_SPF(fail_intf.remote_node)


 


          // Compute the =
cost from every node the network to self


          Compute_and_Sto=
re_Reverse_SPF(self)


 


          foreach node y =
in network


           &nbs=
p;  if ( D_opt(y,fail_intf.remote_node) < D_opt(y,self) +<=
/o:p>


 


 


 


Bryant, et al.         &n=
bsp;  Expires May 01, 2014       &n=
bsp;         [Page 10]

 


Internet-Draft         &n=
bsp;     Remote LFA FRR     &n=
bsp;           October 20=
13


 


 


           &nbs=
p;          D_opt(self,fail_in=
tf.remote_node) )


           &nbs=
p;      y.in_Q_space =3D true


           &nbs=
p;  else


           &nbs=
p;      y.in_Q_space =3D false


 


 


 


      ///////////////////////////////////////=
//////////////////////////////


      //


      // Compute set of nodes in both extende=
d P-space and in Q-space


 


      Intersect_Extended_P_and_Q_Space()=



          foreach node y =
in network


           &nbs=
p;  if ( y.in_extended_P_space && y.in_Q_space )

           &nbs=
p;      y.valid_tunnel_endpoint =3D true


           &nbs=
p;  else


           &nbs=
p;      y.valid_tunnel_endpoint =3D false


 


 


 


      ///////////////////////////////////////=
//////////////////////////////


      //


      // A downstream route is one where the =
next hop is strictly


      // closer to the destination. By sendin=
g the packet to a


      // PQ node that is downstream, we know =
that if the PQ node


      // detects a failure, it will not loop =
the packet back to self.


      // This is useful when there are two fa=
ilures, or a node has


      // failed rather than a link.


 


      Apply_Downstream_Constraint()


          foreach node y =
in network


           &nbs=
p;  if (y.valid_tunnel_endpoint)


           &nbs=
p;      Compute_and_Store_Forward_SPF(y)


           &nbs=
p;      if ((D_opt(y,dest) < D_opt(self,dest))<=
o:p>


           &nbs=
p;          y.valid_tunnel_end=
point =3D true


           &nbs=
p;      else


           &nbs=
p;          y.valid_tunnel_end=
point =3D false


 


 


   //


   /////////////////////////////////////////////////////////=
////////////


 


 


 


Please can someone verify that the algorithm is corr=
ect. See from

the text below that I thought that the original missed some

SPFs



---------


Rest of thread removed to keep below 50kB.















 
--_000_af308a17d3f24a65a61cb1b476fa4782BLUPR05MB292namprd05pro_-- From gregimirsky@gmail.com Tue Oct 29 12:56:57 2013 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 8761811E82A6 for ; Tue, 29 Oct 2013 12:56:57 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-PjkPRbqryd for ; Tue, 29 Oct 2013 12:56:56 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id A0E2B11E8293 for ; Tue, 29 Oct 2013 12:56:22 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id ib11so257356vcb.8 for ; Tue, 29 Oct 2013 12:56:22 -0700 (PDT) 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=4L/DG8XmVCZPQpigw8b5bJJKKuMmqRbFTRhGyBGJ+Oc=; b=cH42S4IfIDWuCajaG2Jbb1t2OAmQGzbmBnch0UGt26P7uw8gjE158eluPK5XAeVsPo DC/1MVyh6jKXlXpnY63T315D3ps+lZToAa58ZyYuv1TA/0AgveONElFIDnv54ypt7gqQ XVZP8o0Cf1b8W07acqagD3IgUDxdB5+dZ/9SnYjcXfFrlpBdOOvEDfK2AaSDkaOWACSI uotqRNHgR5TuWT6oR8L9vsz4Jfv4sutLEutQWrmo/gVUQRo5IzdnDXN5Yq88jXsNboLA m//QfmAJikMUin7BMljGUcx+ACr7bVndICc0bbNVkFebZzWGq1pm2QB8OSBjg6DR+SQ6 1BOg== MIME-Version: 1.0 X-Received: by 10.220.169.203 with SMTP id a11mr622289vcz.26.1383076582102; Tue, 29 Oct 2013 12:56:22 -0700 (PDT) Received: by 10.220.159.143 with HTTP; Tue, 29 Oct 2013 12:56:22 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Oct 2013 12:56:22 -0700 Message-ID: Subject: Re: IETF 88 Agenda Items From: Greg Mirsky To: "Alvaro Retana (aretana)" Content-Type: multipart/alternative; boundary=047d7b6721c45f9e3704e9e69c97 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, 29 Oct 2013 19:56:57 -0000 --047d7b6721c45f9e3704e9e69c97 Content-Type: text/plain; charset=ISO-8859-1 Hi, this question may be more addressed to Fred Would the following fit as well or even better into SPRING WG: Requirements and Use Cases for Source/Destination Routing http://tools.ietf.org/html/draft-baker-rtgwg-src-dst-routing-use-cases Fred Baker Unfortunately agenda for SPRING not yet available. Regards, Greg On Tue, Oct 29, 2013 at 9:48 AM, Alvaro Retana (aretana) wrote: > On 10/23/13 5:43 PM, "Alvaro Retana (aretana)" wrote: > > I just published the draft agenda here: > https://datatracker.ietf.org/meeting/88/agenda/rtgwg/ > > > Just updated the agenda to the final one. > > Alvaro. > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > > --047d7b6721c45f9e3704e9e69c97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
this question may be more addressed to F= red Would the following fit as well or even better into SPRING WG:
=
Requirements and Use Cases for Source/Destination Routing
  http://tools.ietf.org/html/draft-baker-rtgwg-src-dst-routing-use-=
cases
  Fred Baker    

Unfortunately agenda for SPRING not yet =
available.

Regards,
Greg



On Tue, Oct = 29, 2013 at 9:48 AM, Alvaro Retana (aretana) <aretana@cisco.com> wrote:
On 10/23/13 5:43 PM, "Alvaro Retana (aretana)" <aretana@cisco.com> w= rote:

I just published the draft agenda here: =A0https://datatracker.ietf= .org/meeting/88/agenda/rtgwg/

Just updated the agenda to the final one.
=

Alvaro.

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


--047d7b6721c45f9e3704e9e69c97-- From stbryant@cisco.com Thu Oct 31 07:11:51 2013 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 1C9AC21E808F for ; Thu, 31 Oct 2013 07:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.292 X-Spam-Level: X-Spam-Status: No, score=-110.292 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sjqaL8FCqAm for ; Thu, 31 Oct 2013 07:11:46 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id A332F11E80FA for ; Thu, 31 Oct 2013 07:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5091; q=dns/txt; s=iport; t=1383228705; x=1384438305; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=Rk0I0y7tdsatb+a3J0AlSVQZVWLEuzFkJdFSmJoNa40=; b=YJO2EWBpuvwDJATgLeoggNzDxVAih+iJyPA30Poo5CzslsLYTEkS1Y2e G6BBq5EfsLYOgfAeDA+J3nyxjASloZ0BsgF5zPLDNNPuH+rNhMiEKFyBZ +7aLTBbFkIS6j/FZQ8FHm1eR2t/j9Bb4MQyGwwKCZwl+Ld7VovJNWD/Dv g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQ4AKNjclKQ/khR/2dsb2JhbABZgwc4g2eJHrM3gSQWdIIlAQEBBAEBASAPAQU2ChEJAhgCAgUWBAQDAgIJAwIBAgEVHwYLEwYCAQEFh34NjgWbXpJbgSmOLYJrgUMDmAuBL5BagWiBPg X-IronPort-AV: E=Sophos;i="4.93,609,1378857600"; d="scan'208";a="87806455" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 31 Oct 2013 14:11:37 +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 r9VEBV96020476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 31 Oct 2013 14:11:33 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9VEBVNx017029; Thu, 31 Oct 2013 14:11:31 GMT Message-ID: <52726513.8040705@cisco.com> Date: Thu, 31 Oct 2013 14:11:31 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: rtgwg@ietf.org Subject: Re: =?UTF-8?B?562U5aSNOiDnrZTlpI06IFNvbGljaXRpbmcgV0cgZmVlZGJhY2s=?= =?UTF-8?B?IGFuZCBjb21tZW50cyBvbiBkcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWM=?= =?UTF-8?B?LWFkanVzdG1lbnQtMDA=?= References: <94A203EA12AECE4BA92D42DBFFE0AE470309F337@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47030A2579@eusaamb101.ericsson.se> <5266434B.4050309@gmail.com> In-Reply-To: <5266434B.4050309@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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, 31 Oct 2013 14:11:51 -0000 Please note Cisco declared IPR on RFC 5715 section 6.1 - Stewart On 22/10/2013 10:20, Mike Shand wrote: > So you have described the difference with OFIB (RFC 6976), but how > does your proposal differ from "incremental cost advertisement" as > described in RFC 5715 section 6.1? > > Mike > > > > On 22/10/2013 04:39, Yangang wrote: >> OK, I got it. >> >> Actually, we pay attention to two point: >> >> 1. Which method will be more nicety? In RFC6976, all devices in >> network need calculate the schedule time, base on the different >> hardware and environment, we worry about its effect. In our draft, >> only failure point adjust the cost, the other device just response >> the cost change. I think the effect of this kind of difference will >> be less. >> >> 2. Due to no new extension, maybe the distribution will be more >> smoothly. >> >> -----邮件原件----- >> å‘件人: Acee Lindem [mailto:acee.lindem@ericsson.com] >> å‘é€æ—¶é—´: 2013å¹´10月22æ—¥ 9:42 >> 收件人: Yangang >> 抄é€: rtgwg@ietf.org; Zhangxudong (zhangxudong, VRP) >> 主题: Re: ç­”å¤: Soliciting WG feedback and comments on >> draft-zxd-rtgwg-ordered-metric-adjustment-00 >> >> I'm aware of the basic premise of the two drafts and was not asking >> for you to restate the obvious. Specifically, what are the benefits >> and determents of your draft when compared to RFC 6976? >> Acee >> >> On Oct 21, 2013, at 9:30 PM, Yangang wrote: >> >>> Our draft is similar with section 6.1 in RFC5715, the cost of >>> changed link will be adjusted and advertised, maybe more than one >>> time, this sequence will base on some pre-calculations. But in RFC >>> 6976, each device should calculate the distance with the failue >>> link, base on this distance, each device decide when the FIB will be >>> updated. >>> >>> -----邮件原件----- >>> å‘件人: Acee Lindem [mailto:acee.lindem@ericsson.com] >>> å‘é€æ—¶é—´: 2013å¹´10月21æ—¥ 10:07 >>> 收件人: Yangang >>> 抄é€: rtgwg@ietf.org; Zhangxudong (zhangxudong, VRP) >>> 主题: Re: Soliciting WG feedback and comments on >>> draft-zxd-rtgwg-ordered-metric-adjustment-00 >>> >>> Can you contrast this with RFC 6976? You include RFC 6976 in the >>> Normative References but it is never referenced (this will show up >>> if you run idnits). >>> Acee >>> On Oct 20, 2013, at 9:49 PM, Yangang wrote: >>> >>>> Hi: >>>> >>>> We had submitted the a new draft: >>>> http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustment-00, >>>> we want to discuss the micro-loop problem through another method. >>>> Your feedback and comments on the rtgwg mailing list are appreciated. >>>> >>>> Thanks, >>>> Rahul.Yan >>>> >>>> -----邮件原件----- >>>> å‘件人: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>> å‘é€æ—¶é—´: 2013å¹´10月18æ—¥ 15:47 >>>> 收件人: Zhangxudong (zhangxudong, VRP); Yangang >>>> 主题: New Version Notification for >>>> draft-zxd-rtgwg-ordered-metric-adjustment-00.txt >>>> >>>> >>>> A new version of I-D, draft-zxd-rtgwg-ordered-metric-adjustment-00.txt >>>> has been successfully submitted by Xudong Zhang and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-zxd-rtgwg-ordered-metric-adjustment >>>> Revision: 00 >>>> Title: Algorithm for Ordered Metric Adjustment >>>> Creation date: 2013-10-18 >>>> Group: Individual Submission >>>> Number of pages: 10 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-zxd-rtgwg-ordered-metric-adjustment-00.txt >>>> Status: >>>> http://datatracker.ietf.org/doc/draft-zxd-rtgwg-ordered-metric-adjustment >>>> Htmlized: >>>> http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustment-00 >>>> >>>> >>>> >>>> Abstract: >>>> Upon link down event or link up event, each device in network >>>> individually schedules route calculation. Because of different >>>> hardware capabilities and internal/external environments, the >>>> time to >>>> update forwarding entries on these devices are disordered which can >>>> cause a transient forwarding loop. This document introduces a >>>> method >>>> to prevent forwarding loop by adjusting link metric gradually for >>>> several times. >>>> >>>> >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> The IETF Secretariat >>>> >>>> _______________________________________________ >>>> rtgwg mailing list >>>> rtgwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtgwg >> _______________________________________________ >> 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 -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From pierre.francois@imdea.org Thu Oct 31 08:49:56 2013 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 1EC2F11E8199 for ; Thu, 31 Oct 2013 08:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-GQuhem+Yks for ; Thu, 31 Oct 2013 08:49:51 -0700 (PDT) Received: from estafeta21.imdea.org (maquina46.madrimasd.org [193.145.15.46]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC9111E8226 for ; Thu, 31 Oct 2013 08:49:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by estafeta21.imdea.org (imdea mail daemon) with ESMTP id A04441CC4AE; Thu, 31 Oct 2013 16:48:39 +0100 (CET) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta21.imdea.org ([127.0.0.1]) by localhost (estafeta21.imdea.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAqm-NCvHNsi; Thu, 31 Oct 2013 16:48:39 +0100 (CET) Received: from [10.61.199.70] (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: pierre.francois) by estafeta21.imdea.org (imdea mail daemon) with ESMTPSA id 8DBAF1CC4AC; Thu, 31 Oct 2013 16:48:31 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_D1B07B88-6AC1-404A-B147-2DF3D44F53B7" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00 From: Pierre Francois In-Reply-To: <16236_1382529710_5267BAAE_16236_1925_1_EEE55384044474429A926C625D0FCC81098FE657D2@PUEXCB2F.nanterre.francetelecom.fr> Date: Thu, 31 Oct 2013 16:49:24 +0100 Message-Id: <241747C2-51B7-4252-AEAE-5B65F0691A2C@imdea.org> References: <16236_1382529710_5267BAAE_16236_1925_1_EEE55384044474429A926C625D0FCC81098FE657D2@PUEXCB2F.nanterre.francetelecom.fr> To: stephane.litkowski@orange.com X-Mailer: Apple Mail (2.1510) Cc: "rtgwg@ietf.org" , "Zhangxudong \(zhangxudong, VRP\)" , Yangang 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, 31 Oct 2013 15:49:56 -0000 --Apple-Mail=_D1B07B88-6AC1-404A-B147-2DF3D44F53B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Stephane,=20 Much progress on the topic has been made since that much preliminary = Infocom paper.=20 So here come more up-to-date reference points to compare: Graceful Convergence in Link-State IP Networks F. Clad, P. M=C3=A9rindol, J.-J. Pansiot, P. Francois and O. Bonaventure=20= In IEEE/ACM Transactions on Networking, 2013 documents the most optimised algorithm known so far for the link = shutdown case, with extensive simulation results and performance = analysis.=20 Graceful Router Updates for Link-State Protocols F. Clad, P. M=C3=A9rindol, S. Vissicchio, J.-J. Pansiot and P. Francois In proceedings of IEEE ICNP 2013, G=C3=B6ttingen, Germany, October 2013 provides an algorithm to do the same in the node shutdown case, smarter = than doing one link after the other.=20 Cheers, Pierre. On Oct 23, 2013, at 2:01 PM, stephane.litkowski@orange.com wrote: > Hi, >=20 > I would need more time to review your algo part. But anyway, could you = explain the difference with some old public approach like the paper from = Pierre, Mike and Olivier : = http://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.67.8263&rep=3Dr= ep1&type=3Dpdf >=20 > Moreover I would be interested to see in your draft some simulation = proving the metric list is quite low ... > I can remember in the paper I'm referencing that the challenge was to = compress the KMS list in order to prevent a very very long list which = would not be applicable in a live network. >=20 > Thanks >=20 > Stephane >=20 >=20 >=20 > -----Message d'origine----- > De : rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] De la part = de Yangang > Envoy=C3=A9 : lundi 21 octobre 2013 03:49 > =C3=80 : rtgwg@ietf.org > Cc : Zhangxudong (zhangxudong, VRP); Yangang > Objet : Soliciting WG feedback and comments on = draft-zxd-rtgwg-ordered-metric-adjustment-00 >=20 > Hi: >=20 > We had submitted the a new draft: = http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustment-00, = we want to discuss the micro-loop problem through another method. Your = feedback and comments on the rtgwg mailing list are appreciated.=20 >=20 > Thanks, > Rahul.Yan >=20 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B410=E6=9C=8818=E6=97=A5= 15:47 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Zhangxudong (zhangxudong, VRP); Yangang > =E4=B8=BB=E9=A2=98: New Version Notification for = draft-zxd-rtgwg-ordered-metric-adjustment-00.txt >=20 >=20 > A new version of I-D, draft-zxd-rtgwg-ordered-metric-adjustment-00.txt > has been successfully submitted by Xudong Zhang and posted to the > IETF repository. >=20 > Filename: draft-zxd-rtgwg-ordered-metric-adjustment > Revision: 00 > Title: Algorithm for Ordered Metric Adjustment > Creation date: 2013-10-18 > Group: Individual Submission > Number of pages: 10 > URL: = http://www.ietf.org/internet-drafts/draft-zxd-rtgwg-ordered-metric-adjustm= ent-00.txt > Status: = http://datatracker.ietf.org/doc/draft-zxd-rtgwg-ordered-metric-adjustment > Htmlized: = http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustment-00 >=20 >=20 > Abstract: > Upon link down event or link up event, each device in network > individually schedules route calculation. Because of different > hardware capabilities and internal/external environments, the time = to > update forwarding entries on these devices are disordered which can > cause a transient forwarding loop. This document introduces a = method > to prevent forwarding loop by adjusting link metric gradually for > several times. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > 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, > 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, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg --Apple-Mail=_D1B07B88-6AC1-404A-B147-2DF3D44F53B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Graceful = Convergence in Link-State IP Networks
F. Clad, P. M=C3=A9rindol, J.-J. Pansiot, P. Francois = and O. Bonaventure 
In IEEE/ACM Transactions on Networking, = 2013

documents the most optimised algorithm = known so far for the link shutdown case, with extensive simulation = results and performance analysis. 


Graceful Router Updates for = Link-State Protocols
In = proceedings of IEEE ICNP 2013, G=C3=B6ttingen, Germany, October = 2013

provides an algorithm to do the same in = the node shutdown case, smarter than doing one link after the = other. 

Cheers,

Pie= rre.





On Oct 23, 2013, at 2:01 PM, stephane.litkowski@orange.co= m wrote:

Hi,

I would need more time to review your algo = part. But anyway, could you explain the difference with some old public = approach like the paper from Pierre, Mike and Olivier :  http://citeseerx.ist.psu.edu/viewdoc/downl= oad?doi=3D10.1.1.67.8263&rep=3Drep1&type=3Dpdf

Moreover= I would be interested to see in your draft some simulation proving the = metric list is quite low ...
I can remember in the paper I'm = referencing that the challenge was to compress the KMS list in order to = prevent a very very long list which would not be applicable in a live = network.

Thanks

Stephane



-----Message = d'origine-----
De : rtgwg-bounces@ietf.org = [mailto:rtgwg-bounces@ietf.org] = De la part de Yangang
Envoy=C3=A9 : lundi 21 octobre 2013 = 03:49
=C3=80 : rtgwg@ietf.org
Cc : = Zhangxudong (zhangxudong, VRP); Yangang
Objet : Soliciting WG = feedback and comments on = draft-zxd-rtgwg-ordered-metric-adjustment-00

Hi:

We had = submitted the a new draft: http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustmen= t-00, we want to discuss the micro-loop problem through another = method. Your feedback and comments on the rtgwg mailing list are = appreciated. =

Thanks,
Rahul.Yan

-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB= =B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org] =
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B410=E6=9C=8818=E6=97= =A5 15:47
=E6=94=B6=E4=BB=B6=E4=BA=BA: Zhangxudong (zhangxudong, = VRP); Yangang
=E4=B8=BB=E9=A2=98: New Version Notification for = draft-zxd-rtgwg-ordered-metric-adjustment-00.txt


A new = version of I-D, draft-zxd-rtgwg-ordered-metric-adjustment-00.txt
has = been successfully submitted by Xudong Zhang and posted to the
IETF = repository.

Filename: = draft-zxd-rtgwg-ordered-metric-adjustment
Revision: = 00
Title: = = Algorithm for Ordered Metric Adjustment
Creation date: = 2013-10-18
Group: Individual Submission
Number = of pages: 10
URL: =             http://www.ietf.org/internet-drafts/draft-zxd-rtgwg-or= dered-metric-adjustment-00.txt
Status: =          http://datatracker.ietf.org/doc/draft-zxd-rtgwg-ordered-metric-ad= justment
Htmlized:        http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustmen= t-00


Abstract:
  Upon link down event or = link up event, each device in network
  individually = schedules route calculation.  Because of different
=   hardware capabilities and internal/external environments, = the time to
  update forwarding entries on these devices = are disordered which can
  cause a transient forwarding = loop.  This document introduces a method
  to prevent = forwarding loop by adjusting link metric gradually for
=   several times.





Please note that it = may take a couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

The IETF = Secretariat

_______________________________________________
rtgw= g 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,
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, 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
<= /blockquote>

= --Apple-Mail=_D1B07B88-6AC1-404A-B147-2DF3D44F53B7-- From akatlas@gmail.com Thu Oct 31 08:54:11 2013 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 6DD7721F9D3E for ; Thu, 31 Oct 2013 08:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMJoai+bgKkk for ; Thu, 31 Oct 2013 08:54:10 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 101F821F9DBD for ; Thu, 31 Oct 2013 08:54:09 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id aq17so5454915iec.10 for ; Thu, 31 Oct 2013 08:54:09 -0700 (PDT) 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=qmPYd6AcjsAEr1YAHcEPPN7U85agLHbkxNKGkkomLps=; b=Qg1d+6zW/++jxx10uPARROR9If1h3U1wcsLh69SkZq0YqiTwa3b8v7SY6YlgechLTx baoeo6x7uiZG7nIhOTmsuHtpkUfgyBIjTjuxOJFk0AJIwSclTHI1LedRsw/6+QqrjvTK ybfpvoXEnLwhxgmszMZfpZF0cnl/v12px+AgV5QogP7wx3aEZDWqx5LI5K24uuGGR7gk bSHvnAQg45rXMvo0D3IdKmDyOQacrT5EZ6FbVSZZj7m3irRGy3sd4kFc/X6TnOYRPmqF bdyCnuZjqXshOXylI2A18pOPkXcr6UcLWP0f141RJKoLP7urR96O6Etaw+6LTHq8u6XE n2Dg== MIME-Version: 1.0 X-Received: by 10.50.128.137 with SMTP id no9mr103674igb.36.1383234849590; Thu, 31 Oct 2013 08:54:09 -0700 (PDT) Received: by 10.64.78.72 with HTTP; Thu, 31 Oct 2013 08:54:09 -0700 (PDT) In-Reply-To: <241747C2-51B7-4252-AEAE-5B65F0691A2C@imdea.org> References: <16236_1382529710_5267BAAE_16236_1925_1_EEE55384044474429A926C625D0FCC81098FE657D2@PUEXCB2F.nanterre.francetelecom.fr> <241747C2-51B7-4252-AEAE-5B65F0691A2C@imdea.org> Date: Thu, 31 Oct 2013 11:54:09 -0400 Message-ID: Subject: Re: Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00 From: Alia Atlas To: Pierre Francois Content-Type: multipart/alternative; boundary=047d7b10cf0dda1eb104ea0b75d3 Cc: Yangang , "Zhangxudong \(zhangxudong, VRP\)" , "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, 31 Oct 2013 15:54:11 -0000 --047d7b10cf0dda1eb104ea0b75d3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pierre, Thanks for the updates. Can you summarize? Have the number of changes become few enough in general to be practical? Alia On Thu, Oct 31, 2013 at 11:49 AM, Pierre Francois wrote: > Stephane, > > Much progress on the topic has been made since that much preliminary > Infocom paper. > So here come more up-to-date reference points to compare: > > Graceful Convergence in Link-State IP Networks > F. Clad, P. M=C3=A9rindol, J.-J. Pansiot, P. Francois and O. Bonaventure > In IEEE/ACM Transactions on Networking, 2013 > > documents the most optimised algorithm known so far for the link shutdown > case, with extensive simulation results and performance analysis. > > > Graceful Router Updates for Link-State Protocols > F. Clad, P. M=C3=A9rindol, S. Vissicchio, J.-J. Pansiot and P. Francois > In proceedings of IEEE ICNP 2013, G=C3=B6ttingen, Germany, October 2013 > > provides an algorithm to do the same in the node shutdown case, smarter > than doing one link after the other. > > Cheers, > > Pierre. > > > > > > On Oct 23, 2013, at 2:01 PM, stephane.litkowski@orange.com wrote: > > Hi, > > I would need more time to review your algo part. But anyway, could you > explain the difference with some old public approach like the paper from > Pierre, Mike and Olivier : > http://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.67.8263&rep=3D= rep1&type=3Dpdf > > Moreover I would be interested to see in your draft some simulation > proving the metric list is quite low ... > I can remember in the paper I'm referencing that the challenge was to > compress the KMS list in order to prevent a very very long list which wou= ld > not be applicable in a live network. > > Thanks > > Stephane > > > > -----Message d'origine----- > De : rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] De la part de > Yangang > Envoy=C3=A9 : lundi 21 octobre 2013 03:49 > =C3=80 : rtgwg@ietf.org > Cc : Zhangxudong (zhangxudong, VRP); Yangang > Objet : Soliciting WG feedback and comments on > draft-zxd-rtgwg-ordered-metric-adjustment-00 > > Hi: > > We had submitted the a new draft: > http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustment-00, > we want to discuss the micro-loop problem through another method. Your > feedback and comments on the rtgwg mailing list are appreciated. > > Thanks, > Rahul.Yan > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org [mailto:internet-dr= afts@ietf.org] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B410=E6=9C=8818=E6=97=A5= 15:47 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Zhangxudong (zhangxudong, VRP); Yangang > =E4=B8=BB=E9=A2=98: New Version Notification for > draft-zxd-rtgwg-ordered-metric-adjustment-00.txt > > > A new version of I-D, draft-zxd-rtgwg-ordered-metric-adjustment-00.txt > has been successfully submitted by Xudong Zhang and posted to the > IETF repository. > > Filename: draft-zxd-rtgwg-ordered-metric-adjustment > Revision: 00 > Title: Algorithm for Ordered Metric Adjustment > Creation date: 2013-10-18 > Group: Individual Submission > Number of pages: 10 > URL: > http://www.ietf.org/internet-drafts/draft-zxd-rtgwg-ordered-metric-adjust= ment-00.txt > Status: > http://datatracker.ietf.org/doc/draft-zxd-rtgwg-ordered-metric-adjustment > Htmlized: > http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustment-00 > > > Abstract: > Upon link down event or link up event, each device in network > individually schedules route calculation. Because of different > hardware capabilities and internal/external environments, the time to > update forwarding entries on these devices are disordered which can > cause a transient forwarding loop. This document introduces a method > to prevent forwarding loop by adjusting link metric gradually for > several times. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.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, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > 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, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. > > _______________________________________________ > 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 > > --047d7b10cf0dda1eb104ea0b75d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Pierre,

Thanks for the updates. =C2=A0 = Can you summarize? =C2=A0Have the number of changes become few enough in ge= neral to be practical?

Alia


On Thu, Oct 31, 2013 at 11:49 AM, Pierre= Francois <pierre.francois@imdea.org> wrote:
Stephane,=C2=A0

Much= progress on the topic has been made since that much preliminary Infocom pa= per.=C2=A0
So here come more up-to-date reference points to compa= re:

Graceful Convergence in Link-St= ate IP Networks
F. Clad, P. M= =C3=A9rindol, J.-J. Pansiot, P. Francois and O. Bonaventure=C2=A0
In IEEE/ACM Transactions on Networ= king, 2013

documents the most optimised algorithm = known so far for the link shutdown case, with extensive simulation results = and performance analysis.=C2=A0


Graceful Router Updates for Link-State Protocols
F. Clad, P. M=C3=A9rindol, S. Vissicchio, J.-J. Pansiot and P. Francois
In proceedings of IEEE ICNP 2013= , G=C3=B6ttingen, Germany, October 2013

provides a= n algorithm to do the same in the node shutdown case, smarter than doing on= e link after the other.=C2=A0

Cheers,

Pierre.




<= /div>

On Oct 23, 2013, at 2:01 PM, stephane.litkowski@orange.com<= /a> wrote:

Hi,

I would need more time to review y= our algo part. But anyway, could you explain the difference with some old p= ublic approach like the paper from Pierre, Mike and Olivier : =C2=A0http://citeseerx.ist.psu.edu/v= iewdoc/download?doi=3D10.1.1.67.8263&rep=3Drep1&type=3Dpdf

Moreover I would be interested to see in your draft some simulation pro= ving the metric list is quite low ...
I can remember in the paper I'= m referencing that the challenge was to compress the KMS list in order to p= revent a very very long list which would not be applicable in a live networ= k.

Thanks

Stephane



-----Message d'origine-----De=C2=A0: rtg= wg-bounces@ietf.org [mailto:rtgwg-bounces@ie= tf.org] De la part de Yangang
Envoy=C3=A9=C2=A0: lundi 21 octobre 2013 03:49
=C3=80=C2=A0: rtgwg@ietf.org
Cc=C2=A0: Zh= angxudong (zhangxudong, VRP); Yangang
Objet=C2=A0: Soliciting WG feedbac= k and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00

Hi:

We had submitted the a new draft: http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustment-00, we want to discuss the micro-loop problem through another method. Your f= eedback and comments on the rtgwg mailing list are appreciated.

Thanks,
Rahul.Yan

-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6--= ---
=E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org= ]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B410=E6=9C=8818=E6=97=A5 1= 5:47
=E6=94=B6=E4=BB=B6=E4=BA=BA: Zhangxudong (zhangxudong, VRP); Yangan= g
=E4=B8=BB=E9=A2=98: New Version Notification for draft-zxd-rtgwg-order= ed-metric-adjustment-00.txt


A new version of I-D, draft-zxd-rtgw= g-ordered-metric-adjustment-00.txt
has been successfully submitted by Xudong Zhang and posted to the
IETF r= epository.

Filename: dr= aft-zxd-rtgwg-ordered-metric-adjustment
Revision: 00
Title: Algorithm for Ordered Metric Adjustment
Creation d= ate: 2013-10-18
Group: Individual Submission
Number of pages: 10
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0http://w= ww.ietf.org/internet-drafts/draft-zxd-rtgwg-ordered-metric-adjustment-00.tx= t
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http://datatracker.ietf.org/doc/draft-zxd-rtgwg-ordered-met= ric-adjustment
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= a href=3D"http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustm= ent-00" target=3D"_blank">http://tools.ietf.org/html/draft-zxd-rtgwg-ordere= d-metric-adjustment-00


Abstract:
=C2=A0=C2=A0Upon link down event or link up event, ea= ch device in network
=C2=A0=C2=A0individually schedules route calculati= on. =C2=A0Because of different
=C2=A0=C2=A0hardware capabilities and in= ternal/external environments, the time to
=C2=A0=C2=A0update forwarding entries on these devices are disordered whic= h can
=C2=A0=C2=A0cause a transient forwarding loop. =C2=A0This documen= t introduces a method
=C2=A0=C2=A0to prevent forwarding loop by adjusti= ng link metric gradually for
=C2=A0=C2=A0several times.





Please note that it may = take a couple of minutes from the time of submission
until the htmlized = version and diff are available at tools.ietf.org.

The IETF Secretariat

___________________________________________= ____
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg=

_______________________________________________________________________= __________________________________________________

Ce message et ses= pieces jointes peuvent contenir des informations confidentielles ou privil= egiees 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 de= truire ainsi que les pieces jointes. Les messages electroniques etant susce= ptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confid= ential or privileged information that may be protected by law;
they shou= ld 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, Orange is= not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
rtgwg = mailing list
rtgwg@i= etf.org
https://www.ietf.org/mailman/listinfo/rtgwg


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


--047d7b10cf0dda1eb104ea0b75d3-- From pierre.francois@imdea.org Thu Oct 31 09:04:35 2013 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 A5AD721F9DCB for ; Thu, 31 Oct 2013 09:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFi+i4iH6Irb for ; Thu, 31 Oct 2013 09:04:31 -0700 (PDT) Received: from estafeta21.imdea.org (maquina46.madrimasd.org [193.145.15.46]) by ietfa.amsl.com (Postfix) with ESMTP id 913B111E8233 for ; Thu, 31 Oct 2013 09:04:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by estafeta21.imdea.org (imdea mail daemon) with ESMTP id B2CC11CC5D9; Thu, 31 Oct 2013 17:03:32 +0100 (CET) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta21.imdea.org ([127.0.0.1]) by localhost (estafeta21.imdea.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w51-1Flb-8Aq; Thu, 31 Oct 2013 17:03:32 +0100 (CET) Received: from [10.61.199.70] (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: pierre.francois) by estafeta21.imdea.org (imdea mail daemon) with ESMTPSA id D80981CC5D7; Thu, 31 Oct 2013 17:03:30 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_8F687B5E-52CC-47FB-A6A7-DA426F1D96BF" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00 From: Pierre Francois In-Reply-To: Date: Thu, 31 Oct 2013 17:04:23 +0100 Message-Id: <0D953FB7-A7CC-4224-9C83-5A8424AAB52B@imdea.org> References: <16236_1382529710_5267BAAE_16236_1925_1_EEE55384044474429A926C625D0FCC81098FE657D2@PUEXCB2F.nanterre.francetelecom.fr> <241747C2-51B7-4252-AEAE-5B65F0691A2C@imdea.org> To: Alia Atlas X-Mailer: Apple Mail (2.1510) Cc: Yangang , "Zhangxudong \(zhangxudong, VRP\)" , "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, 31 Oct 2013 16:04:35 -0000 --Apple-Mail=_8F687B5E-52CC-47FB-A6A7-DA426F1D96BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Alia,=20 Some corner cases here and there, but yes, Francois' code (Francois = Clad, not me) computes these sequences in a ridiculously low amount of = time, and the sequences tend to be very short even in large topologies.=20= I still think this should be investigated for maintenance cases and = metric updates stemming out of a TE exercise.=20 I do not think this is a practical approach to apply after a FRR = application.=20 Cheers, Pierre. On Oct 31, 2013, at 4:54 PM, Alia Atlas wrote: > Pierre, >=20 > Thanks for the updates. Can you summarize? Have the number of = changes become few enough in general to be practical? >=20 > Alia >=20 >=20 > On Thu, Oct 31, 2013 at 11:49 AM, Pierre Francois = wrote: > Stephane,=20 >=20 > Much progress on the topic has been made since that much preliminary = Infocom paper.=20 > So here come more up-to-date reference points to compare: >=20 > Graceful Convergence in Link-State IP Networks > F. Clad, P. M=C3=A9rindol, J.-J. Pansiot, P. Francois and O. = Bonaventure=20 > In IEEE/ACM Transactions on Networking, 2013 >=20 > documents the most optimised algorithm known so far for the link = shutdown case, with extensive simulation results and performance = analysis.=20 >=20 >=20 > Graceful Router Updates for Link-State Protocols > F. Clad, P. M=C3=A9rindol, S. Vissicchio, J.-J. Pansiot and P. = Francois > In proceedings of IEEE ICNP 2013, G=C3=B6ttingen, Germany, October = 2013 >=20 > provides an algorithm to do the same in the node shutdown case, = smarter than doing one link after the other.=20 >=20 > Cheers, >=20 > Pierre. >=20 >=20 >=20 >=20 >=20 > On Oct 23, 2013, at 2:01 PM, stephane.litkowski@orange.com wrote: >=20 >> Hi, >>=20 >> I would need more time to review your algo part. But anyway, could = you explain the difference with some old public approach like the paper = from Pierre, Mike and Olivier : = http://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.67.8263&rep=3Dr= ep1&type=3Dpdf >>=20 >> Moreover I would be interested to see in your draft some simulation = proving the metric list is quite low ... >> I can remember in the paper I'm referencing that the challenge was to = compress the KMS list in order to prevent a very very long list which = would not be applicable in a live network. >>=20 >> Thanks >>=20 >> Stephane >>=20 >>=20 >>=20 >> -----Message d'origine----- >> De : rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] De la = part de Yangang >> Envoy=C3=A9 : lundi 21 octobre 2013 03:49 >> =C3=80 : rtgwg@ietf.org >> Cc : Zhangxudong (zhangxudong, VRP); Yangang >> Objet : Soliciting WG feedback and comments on = draft-zxd-rtgwg-ordered-metric-adjustment-00 >>=20 >> Hi: >>=20 >> We had submitted the a new draft: = http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustment-00, = we want to discuss the micro-loop problem through another method. Your = feedback and comments on the rtgwg mailing list are appreciated.=20 >>=20 >> Thanks, >> Rahul.Yan >>=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B410=E6=9C=8818=E6=97=A5= 15:47 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Zhangxudong (zhangxudong, VRP); Yangang >> =E4=B8=BB=E9=A2=98: New Version Notification for = draft-zxd-rtgwg-ordered-metric-adjustment-00.txt >>=20 >>=20 >> A new version of I-D, = draft-zxd-rtgwg-ordered-metric-adjustment-00.txt >> has been successfully submitted by Xudong Zhang and posted to the >> IETF repository. >>=20 >> Filename: draft-zxd-rtgwg-ordered-metric-adjustment >> Revision: 00 >> Title: Algorithm for Ordered Metric Adjustment >> Creation date: 2013-10-18 >> Group: Individual Submission >> Number of pages: 10 >> URL: = http://www.ietf.org/internet-drafts/draft-zxd-rtgwg-ordered-metric-adjustm= ent-00.txt >> Status: = http://datatracker.ietf.org/doc/draft-zxd-rtgwg-ordered-metric-adjustment >> Htmlized: = http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustment-00 >>=20 >>=20 >> Abstract: >> Upon link down event or link up event, each device in network >> individually schedules route calculation. Because of different >> hardware capabilities and internal/external environments, the time = to >> update forwarding entries on these devices are disordered which can >> cause a transient forwarding loop. This document introduces a = method >> to prevent forwarding loop by adjusting link metric gradually for >> several times. >>=20 >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >> _______________________________________________ >> 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, >> 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, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg >=20 >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg >=20 >=20 --Apple-Mail=_8F687B5E-52CC-47FB-A6A7-DA426F1D96BF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 akatlas@gmail.com> = wrote:

Pierre,

Thanks for the = updates.   Can you summarize?  Have the number of changes = become few enough in general to be = practical?

Alia


On Thu, Oct 31, 2013 at 11:49 AM, = Pierre Francois <pierre.francois@imdea.org> = wrote:
Stephane, 

Much = progress on the topic has been made since that much preliminary Infocom = paper. 
So here come more up-to-date reference points to = compare:

Graceful Convergence in Link-State = IP Networks
F. Clad, P. = M=C3=A9rindol, J.-J. Pansiot, P. Francois and O. Bonaventure 
In IEEE/ACM Transactions on = Networking, 2013

documents the most optimised = algorithm known so far for the link shutdown case, with extensive = simulation results and performance analysis. 


Graceful Router Updates for = Link-State Protocols
F. Clad, P. M=C3=A9rindol, S. Vissicchio, J.-J. Pansiot and P. = Francois
In proceedings of = IEEE ICNP 2013, G=C3=B6ttingen, Germany, October = 2013

provides an algorithm to do the same in = the node shutdown case, smarter than doing one link after the = other. 
=

Cheers,

Pierre.




<= div>
On Oct 23, 2013, at 2:01 PM, stephane.litkowski@orange.com wrote:

Hi,

I would need more time to = review your algo part. But anyway, could you explain the difference with = some old public approach like the paper from Pierre, Mike and Olivier : =  http://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1= .1.67.8263&rep=3Drep1&type=3Dpdf

Moreover I would be interested to see in your draft some simulation = proving the metric list is quite low ...
I can remember in the paper = I'm referencing that the challenge was to compress the KMS list in order = to prevent a very very long list which would not be applicable in a live = network.

Thanks

Stephane



-----Message = d'origine-----
De : rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] = De la part de Yangang
Envoy=C3=A9 : lundi 21 octobre 2013 03:49
=C3=80 : rtgwg@ietf.org
Cc : Zhangxudong = (zhangxudong, VRP); Yangang
Objet : Soliciting WG feedback and = comments on draft-zxd-rtgwg-ordered-metric-adjustment-00

Hi:

We had submitted the a new draft: http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metri= c-adjustment-00, we want to discuss the micro-loop problem through = another method. Your feedback and comments on the rtgwg mailing list are = appreciated.

Thanks,
Rahul.Yan

-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-= ----
=E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B410=E6=9C=8818=E6=97=A5 = 15:47
=E6=94=B6=E4=BB=B6=E4=BA=BA: Zhangxudong (zhangxudong, VRP); = Yangang
=E4=B8=BB=E9=A2=98: New Version Notification for = draft-zxd-rtgwg-ordered-metric-adjustment-00.txt


A new = version of I-D, draft-zxd-rtgwg-ordered-metric-adjustment-00.txt
has been successfully submitted by Xudong Zhang and posted to = the
IETF repository.

Filename: = draft-zxd-rtgwg-ordered-metric-adjustment
Revision: 00
Title: Algorithm for Ordered Metric = Adjustment
Creation date: = 2013-10-18
Group: = Individual = Submission
Number of pages: 10
URL: =             http://www.ietf.org/internet-drafts/draft-zxd-rtgwg-orde= red-metric-adjustment-00.txt
Status:          http://datatracker.ietf.org/doc/draft-zxd-rtgwg-ordered-= metric-adjustment
Htmlized: =        http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metri= c-adjustment-00


Abstract:
  Upon link down event or link up event, = each device in network
  individually schedules route = calculation.  Because of different
  hardware = capabilities and internal/external environments, the time to
  update forwarding entries on these devices are disordered = which can
  cause a transient forwarding loop.  This = document introduces a method
  to prevent forwarding loop = by adjusting link metric gradually for
  several times.





Please note that it = may take a couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

The IETF = Secretariat

_______________________________________________
rtgw= g 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,
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, = 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
=


_______________________= ________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg



From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Be= half Of Chris Bowers
Sent: Wednesday, September 04, 2013 4:22= PM
To: rtgwg@ietf.org
<= b>Subject: algorithm description for draft-ietf-rtgwg-remote-lfa

= --Apple-Mail=_8F687B5E-52CC-47FB-A6A7-DA426F1D96BF-- From stephane.litkowski@orange.com Thu Oct 31 09:29:17 2013 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 9E74E21F9F80 for ; Thu, 31 Oct 2013 09:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKotfEYe1xK5 for ; Thu, 31 Oct 2013 09:29:13 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 153EB21F9F85 for ; Thu, 31 Oct 2013 09:29:12 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id A7030C0682; Thu, 31 Oct 2013 17:29:10 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 8EEFA384072; Thu, 31 Oct 2013 17:29:10 +0100 (CET) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.46]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 31 Oct 2013 17:29:10 +0100 From: To: Pierre Francois , Alia Atlas Date: Thu, 31 Oct 2013 17:29:07 +0100 Subject: RE: Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00 Thread-Topic: Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00 Thread-Index: Ac7WUuAwOPctbXsWSeax0xrwWsXJcgAA0ciw Message-ID: <17617_1383236950_52728556_17617_2779_1_EEE55384044474429A926C625D0FCC8109902E3E05@PUEXCB2F.nanterre.francetelecom.fr> References: <16236_1382529710_5267BAAE_16236_1925_1_EEE55384044474429A926C625D0FCC81098FE657D2@PUEXCB2F.nanterre.francetelecom.fr> <241747C2-51B7-4252-AEAE-5B65F0691A2C@imdea.org> <0D953FB7-A7CC-4224-9C83-5A8424AAB52B@imdea.org> In-Reply-To: <0D953FB7-A7CC-4224-9C83-5A8424AAB52B@imdea.org> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_EEE55384044474429A926C625D0FCC8109902E3E05PUEXCB2Fnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.10.31.151815 Cc: Yangang , "Zhangxudong \(zhangxudong, VRP\)" , "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, 31 Oct 2013 16:29:17 -0000 --_000_EEE55384044474429A926C625D0FCC8109902E3E05PUEXCB2Fnante_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PkkgZG8gbm90IHRoaW5rIHRoaXMgaXMgYSBwcmFjdGljYWwgYXBwcm9hY2ggdG8gYXBwbHkgYWZ0 ZXIgYSBGUlIgYXBwbGljYXRpb24uDQoNCisxLCBpbiB0ZXJtIG9mIG9wZXJhdGlvbnMsIEkgd291 bGQgc2F5IHRoYXQgaW5jcmVtZW50YWwgbWV0cmljIHdvdWxkIGJlIGFwcGxpY2FibGUgb25seSBm b3IgbWFpbnRlbmFuY2UgYW5kIG1heSBub3QgZm9yIG91dGFnZXMNCg0KDQpEZSA6IFBpZXJyZSBG cmFuY29pcyBbbWFpbHRvOnBpZXJyZS5mcmFuY29pc0BpbWRlYS5vcmddDQpFbnZvecOpIDogamV1 ZGkgMzEgb2N0b2JyZSAyMDEzIDE3OjA0DQrDgCA6IEFsaWEgQXRsYXMNCkNjIDogTElUS09XU0tJ IFN0ZXBoYW5lIERURi9ERVJYOyBydGd3Z0BpZXRmLm9yZzsgWmhhbmd4dWRvbmcgKHpoYW5neHVk b25nLCBWUlApOyBZYW5nYW5nDQpPYmpldCA6IFJlOiBTb2xpY2l0aW5nIFdHIGZlZWRiYWNrIGFu ZCBjb21tZW50cyBvbiBkcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0w MA0KDQpBbGlhLA0KDQpTb21lIGNvcm5lciBjYXNlcyBoZXJlIGFuZCB0aGVyZSwgYnV0IHllcywg RnJhbmNvaXMnIGNvZGUgKEZyYW5jb2lzIENsYWQsIG5vdCBtZSkgY29tcHV0ZXMgdGhlc2Ugc2Vx dWVuY2VzIGluIGEgcmlkaWN1bG91c2x5IGxvdyBhbW91bnQgb2YgdGltZSwgYW5kIHRoZSBzZXF1 ZW5jZXMgdGVuZCB0byBiZSB2ZXJ5IHNob3J0IGV2ZW4gaW4gbGFyZ2UgdG9wb2xvZ2llcy4NCg0K SSBzdGlsbCB0aGluayB0aGlzIHNob3VsZCBiZSBpbnZlc3RpZ2F0ZWQgZm9yIG1haW50ZW5hbmNl IGNhc2VzIGFuZCBtZXRyaWMgdXBkYXRlcyBzdGVtbWluZyBvdXQgb2YgYSBURSBleGVyY2lzZS4N Cg0KSSBkbyBub3QgdGhpbmsgdGhpcyBpcyBhIHByYWN0aWNhbCBhcHByb2FjaCB0byBhcHBseSBh ZnRlciBhIEZSUiBhcHBsaWNhdGlvbi4NCg0KQ2hlZXJzLA0KDQpQaWVycmUuDQoNCk9uIE9jdCAz MSwgMjAxMywgYXQgNDo1NCBQTSwgQWxpYSBBdGxhcyA8YWthdGxhc0BnbWFpbC5jb208bWFpbHRv OmFrYXRsYXNAZ21haWwuY29tPj4gd3JvdGU6DQoNCg0KUGllcnJlLA0KDQpUaGFua3MgZm9yIHRo ZSB1cGRhdGVzLiAgIENhbiB5b3Ugc3VtbWFyaXplPyAgSGF2ZSB0aGUgbnVtYmVyIG9mIGNoYW5n ZXMgYmVjb21lIGZldyBlbm91Z2ggaW4gZ2VuZXJhbCB0byBiZSBwcmFjdGljYWw/DQoNCkFsaWEN Cg0KT24gVGh1LCBPY3QgMzEsIDIwMTMgYXQgMTE6NDkgQU0sIFBpZXJyZSBGcmFuY29pcyA8cGll cnJlLmZyYW5jb2lzQGltZGVhLm9yZzxtYWlsdG86cGllcnJlLmZyYW5jb2lzQGltZGVhLm9yZz4+ IHdyb3RlOg0KU3RlcGhhbmUsDQoNCk11Y2ggcHJvZ3Jlc3Mgb24gdGhlIHRvcGljIGhhcyBiZWVu IG1hZGUgc2luY2UgdGhhdCBtdWNoIHByZWxpbWluYXJ5IEluZm9jb20gcGFwZXIuDQpTbyBoZXJl IGNvbWUgbW9yZSB1cC10by1kYXRlIHJlZmVyZW5jZSBwb2ludHMgdG8gY29tcGFyZToNCg0KR3Jh Y2VmdWwgQ29udmVyZ2VuY2UgaW4gTGluay1TdGF0ZSBJUCBOZXR3b3Jrcw0KRi4gQ2xhZCwgUC4g TcOpcmluZG9sLCBKLi1KLiBQYW5zaW90LCBQLiBGcmFuY29pcyBhbmQgTy4gQm9uYXZlbnR1cmUN CkluIElFRUUvQUNNIFRyYW5zYWN0aW9ucyBvbiBOZXR3b3JraW5nLCAyMDEzDQoNCmRvY3VtZW50 cyB0aGUgbW9zdCBvcHRpbWlzZWQgYWxnb3JpdGhtIGtub3duIHNvIGZhciBmb3IgdGhlIGxpbmsg c2h1dGRvd24gY2FzZSwgd2l0aCBleHRlbnNpdmUgc2ltdWxhdGlvbiByZXN1bHRzIGFuZCBwZXJm b3JtYW5jZSBhbmFseXNpcy4NCg0KDQpHcmFjZWZ1bCBSb3V0ZXIgVXBkYXRlcyBmb3IgTGluay1T dGF0ZSBQcm90b2NvbHMNCkYuIENsYWQsIFAuIE3DqXJpbmRvbCwgUy4gVmlzc2ljY2hpbywgSi4t Si4gUGFuc2lvdCBhbmQgUC4gRnJhbmNvaXMNCkluIHByb2NlZWRpbmdzIG9mIElFRUUgSUNOUCAy MDEzLCBHw7Z0dGluZ2VuLCBHZXJtYW55LCBPY3RvYmVyIDIwMTMNCg0KcHJvdmlkZXMgYW4gYWxn b3JpdGhtIHRvIGRvIHRoZSBzYW1lIGluIHRoZSBub2RlIHNodXRkb3duIGNhc2UsIHNtYXJ0ZXIg dGhhbiBkb2luZyBvbmUgbGluayBhZnRlciB0aGUgb3RoZXIuDQoNCkNoZWVycywNCg0KUGllcnJl Lg0KDQoNCg0KDQoNCk9uIE9jdCAyMywgMjAxMywgYXQgMjowMSBQTSwgc3RlcGhhbmUubGl0a293 c2tpQG9yYW5nZS5jb208bWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPiB3cm90 ZToNCg0KDQpIaSwNCg0KSSB3b3VsZCBuZWVkIG1vcmUgdGltZSB0byByZXZpZXcgeW91ciBhbGdv IHBhcnQuIEJ1dCBhbnl3YXksIGNvdWxkIHlvdSBleHBsYWluIHRoZSBkaWZmZXJlbmNlIHdpdGgg c29tZSBvbGQgcHVibGljIGFwcHJvYWNoIGxpa2UgdGhlIHBhcGVyIGZyb20gUGllcnJlLCBNaWtl IGFuZCBPbGl2aWVyIDogIGh0dHA6Ly9jaXRlc2VlcnguaXN0LnBzdS5lZHUvdmlld2RvYy9kb3du bG9hZD9kb2k9MTAuMS4xLjY3LjgyNjMmcmVwPXJlcDEmdHlwZT1wZGYNCg0KTW9yZW92ZXIgSSB3 b3VsZCBiZSBpbnRlcmVzdGVkIHRvIHNlZSBpbiB5b3VyIGRyYWZ0IHNvbWUgc2ltdWxhdGlvbiBw cm92aW5nIHRoZSBtZXRyaWMgbGlzdCBpcyBxdWl0ZSBsb3cgLi4uDQpJIGNhbiByZW1lbWJlciBp biB0aGUgcGFwZXIgSSdtIHJlZmVyZW5jaW5nIHRoYXQgdGhlIGNoYWxsZW5nZSB3YXMgdG8gY29t cHJlc3MgdGhlIEtNUyBsaXN0IGluIG9yZGVyIHRvIHByZXZlbnQgYSB2ZXJ5IHZlcnkgbG9uZyBs aXN0IHdoaWNoIHdvdWxkIG5vdCBiZSBhcHBsaWNhYmxlIGluIGEgbGl2ZSBuZXR3b3JrLg0KDQpU aGFua3MNCg0KU3RlcGhhbmUNCg0KDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGUg OiBydGd3Zy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpydGd3Zy1ib3VuY2VzQGlldGYub3JnPiBb bWFpbHRvOnJ0Z3dnLTxtYWlsdG86cnRnd2ctPmJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmJvdW5j ZXNAaWV0Zi5vcmc+XSBEZSBsYSBwYXJ0IGRlIFlhbmdhbmcNCkVudm95w6kgOiBsdW5kaSAyMSBv Y3RvYnJlIDIwMTMgMDM6NDkNCsOAIDogcnRnd2dAaWV0Zi5vcmc8bWFpbHRvOnJ0Z3dnQGlldGYu b3JnPg0KQ2MgOiBaaGFuZ3h1ZG9uZyAoemhhbmd4dWRvbmcsIFZSUCk7IFlhbmdhbmcNCk9iamV0 IDogU29saWNpdGluZyBXRyBmZWVkYmFjayBhbmQgY29tbWVudHMgb24gZHJhZnQtenhkLXJ0Z3dn LW9yZGVyZWQtbWV0cmljLWFkanVzdG1lbnQtMDANCg0KSGk6DQoNCldlIGhhZCBzdWJtaXR0ZWQg dGhlIGEgbmV3IGRyYWZ0OiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16eGQtcnRn d2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0wMCwgd2Ugd2FudCB0byBkaXNjdXNzIHRoZSBt aWNyby1sb29wIHByb2JsZW0gdGhyb3VnaCBhbm90aGVyIG1ldGhvZC4gWW91ciBmZWVkYmFjayBh bmQgY29tbWVudHMgb24gdGhlIHJ0Z3dnIG1haWxpbmcgbGlzdCBhcmUgYXBwcmVjaWF0ZWQuDQoN ClRoYW5rcywNClJhaHVsLllhbg0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6 IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn PiBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPl0NCuWPkemAgeaXtumXtDogMjAxM+W5tDEw5pyIMTjml6UgMTU6NDcNCuaUtuS7 tuS6ujogWmhhbmd4dWRvbmcgKHpoYW5neHVkb25nLCBWUlApOyBZYW5nYW5nDQrkuLvpopg6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtenhkLXJ0Z3dnLW9yZGVyZWQtbWV0cmlj LWFkanVzdG1lbnQtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXp4ZC1y dGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50LTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBYdWRvbmcgWmhhbmcgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVw b3NpdG9yeS4NCg0KRmlsZW5hbWU6IGRyYWZ0LXp4ZC1ydGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1 c3RtZW50DQpSZXZpc2lvbjogMDANClRpdGxlOiBBbGdvcml0aG0gZm9yIE9yZGVyZWQgTWV0cmlj IEFkanVzdG1lbnQNCkNyZWF0aW9uIGRhdGU6IDIwMTMtMTAtMTgNCkdyb3VwOiBJbmRpdmlkdWFs IFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTANClVSTDogICAgICAgICAgICAgaHR0cDov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtenhkLXJ0Z3dnLW9yZGVyZWQtbWV0 cmljLWFkanVzdG1lbnQtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtenhkLXJ0Z3dnLW9yZGVyZWQtbWV0cmljLWFkanVzdG1lbnQN Ckh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtenhkLXJ0 Z3dnLW9yZGVyZWQtbWV0cmljLWFkanVzdG1lbnQtMDANCg0KDQpBYnN0cmFjdDoNCiAgVXBvbiBs aW5rIGRvd24gZXZlbnQgb3IgbGluayB1cCBldmVudCwgZWFjaCBkZXZpY2UgaW4gbmV0d29yaw0K ICBpbmRpdmlkdWFsbHkgc2NoZWR1bGVzIHJvdXRlIGNhbGN1bGF0aW9uLiAgQmVjYXVzZSBvZiBk aWZmZXJlbnQNCiAgaGFyZHdhcmUgY2FwYWJpbGl0aWVzIGFuZCBpbnRlcm5hbC9leHRlcm5hbCBl bnZpcm9ubWVudHMsIHRoZSB0aW1lIHRvDQogIHVwZGF0ZSBmb3J3YXJkaW5nIGVudHJpZXMgb24g dGhlc2UgZGV2aWNlcyBhcmUgZGlzb3JkZXJlZCB3aGljaCBjYW4NCiAgY2F1c2UgYSB0cmFuc2ll bnQgZm9yd2FyZGluZyBsb29wLiAgVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIGEgbWV0aG9kDQog IHRvIHByZXZlbnQgZm9yd2FyZGluZyBsb29wIGJ5IGFkanVzdGluZyBsaW5rIG1ldHJpYyBncmFk dWFsbHkgZm9yDQogIHNldmVyYWwgdGltZXMuDQoNCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lv bg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0 b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvPi4NCg0KVGhlIElFVEYgU2VjcmV0 YXJpYXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CnJ0Z3dnIG1haWxpbmcgbGlzdA0KcnRnd2dAaWV0Zi5vcmc8bWFpbHRvOnJ0Z3dnQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGd3Zw0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVz IGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZl bnQgZG9uYw0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRv cmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxs ZXogbGUgc2lnbmFsZXINCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBs ZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2Nl cHRpYmxlcyBkJ2FsdGVyYXRpb24sDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0 ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2ku DQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhv dXQgYXV0aG9yaXNhdGlvbi4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzLg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90 IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3Ig ZmFsc2lmaWVkLg0KVGhhbmsgeW91Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KcnRnd2cgbWFpbGluZyBsaXN0DQpydGd3Z0BpZXRmLm9yZzxtYWls dG86cnRnd2dAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3J0Z3dnDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnJ0Z3dnIG1haWxpbmcgbGlzdA0KcnRnd2dAaWV0Zi5vcmc8bWFpbHRvOnJ0Z3dnQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGd3Zw0KDQoNCgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmly IGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBk b2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBh dXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1 aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVl IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxp dGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNp LgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxh dzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0 IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlh YmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz aWZpZWQuClRoYW5rIHlvdS4KCg== --_000_EEE55384044474429A926C625D0FCC8109902E3E05PUEXCB2Fnante_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7 DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlBNaW5nTGlVOw0KCXBhbm9zZS0xOjIgMiA1IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpQTWluZ0xpVTsNCglwYW5vc2UtMToyIDIgNSAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFBNaW5nTGlVIjsNCglwYW5vc2UtMToyIDIgNSAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg MyA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm Ijt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxp Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJU ZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlRleHRlIGRlIGJ1bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUZSIGxp bms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+Jmd0O0kgZG8gbm90IHRoaW5rIHRoaXMgaXMgYSBwcmFj dGljYWwgYXBwcm9hY2ggdG8gYXBwbHkgYWZ0ZXIgYSBGUlIgYXBwbGljYXRpb24uJm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+KzEsIGluIHRlcm0gb2Ygb3Bl cmF0aW9ucywgSSB3b3VsZCBzYXkgdGhhdCBpbmNyZW1lbnRhbCBtZXRyaWMgd291bGQgYmUgYXBw bGljYWJsZSBvbmx5IGZvciBtYWludGVuYW5jZSBhbmQgbWF5IG5vdCBmb3Igb3V0YWdlczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+ PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IFBpZXJyZSBGcmFuY29pcyBb bWFpbHRvOnBpZXJyZS5mcmFuY29pc0BpbWRlYS5vcmddIDxicj48Yj5FbnZvecOpJm5ic3A7Ojwv Yj4gamV1ZGkgMzEgb2N0b2JyZSAyMDEzIDE3OjA0PGJyPjxiPsOAJm5ic3A7OjwvYj4gQWxpYSBB dGxhczxicj48Yj5DYyZuYnNwOzo8L2I+IExJVEtPV1NLSSBTdGVwaGFuZSBEVEYvREVSWDsgcnRn d2dAaWV0Zi5vcmc7IFpoYW5neHVkb25nICh6aGFuZ3h1ZG9uZywgVlJQKTsgWWFuZ2FuZzxicj48 Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBTb2xpY2l0aW5nIFdHIGZlZWRiYWNrIGFuZCBjb21tZW50 cyBvbiBkcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0wMDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPkFsaWEsJm5ic3A7PG86cD48L286cD48L3A+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+U29tZSBjb3JuZXIgY2FzZXMgaGVyZSBhbmQgdGhlcmUsIGJ1dCB5ZXMs IEZyYW5jb2lzJyBjb2RlIChGcmFuY29pcyBDbGFkLCBub3QgbWUpIGNvbXB1dGVzIHRoZXNlIHNl cXVlbmNlcyBpbiBhIHJpZGljdWxvdXNseSBsb3cgYW1vdW50IG9mIHRpbWUsIGFuZCB0aGUgc2Vx dWVuY2VzJm5ic3A7dGVuZCB0byBiZSB2ZXJ5IHNob3J0IGV2ZW4gaW4gbGFyZ2UgdG9wb2xvZ2ll cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JIHN0aWxsIHRo aW5rIHRoaXMgc2hvdWxkIGJlIGludmVzdGlnYXRlZCBmb3IgbWFpbnRlbmFuY2UgY2FzZXMgYW5k IG1ldHJpYyB1cGRhdGVzIHN0ZW1taW5nIG91dCBvZiBhIFRFIGV4ZXJjaXNlLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkkgZG8gbm90IHRoaW5rIHRoaXMgaXMg YSBwcmFjdGljYWwgYXBwcm9hY2ggdG8gYXBwbHkgYWZ0ZXIgYSBGUlIgYXBwbGljYXRpb24uJm5i c3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Q2hlZXJzLDxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlBpZXJyZS48bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPk9uIE9jdCAzMSwgMjAxMywgYXQgNDo1NCBQTSwgQWxpYSBBdGxh cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFrYXRsYXNAZ21haWwuY29tIj5ha2F0bGFzQGdtYWlsLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 YnI+PGJyPjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlBpZXJyZSw8bzpw PjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UaGFua3MgZm9yIHRoZSB1cGRhdGVzLiAmbmJz cDsgQ2FuIHlvdSBzdW1tYXJpemU/ICZuYnNwO0hhdmUgdGhlIG51bWJlciBvZiBjaGFuZ2VzIGJl Y29tZSBmZXcgZW5vdWdoIGluIGdlbmVyYWwgdG8gYmUgcHJhY3RpY2FsPzxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkFsaWE8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9uIFRodSwgT2N0IDMxLCAy MDEzIGF0IDExOjQ5IEFNLCBQaWVycmUgRnJhbmNvaXMgJmx0OzxhIGhyZWY9Im1haWx0bzpwaWVy cmUuZnJhbmNvaXNAaW1kZWEub3JnIiB0YXJnZXQ9Il9ibGFuayI+cGllcnJlLmZyYW5jb2lzQGlt ZGVhLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPlN0ZXBoYW5lLCZuYnNwOzxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk11Y2gg cHJvZ3Jlc3Mgb24gdGhlIHRvcGljIGhhcyBiZWVuIG1hZGUgc2luY2UgdGhhdCBtdWNoIHByZWxp bWluYXJ5IEluZm9jb20gcGFwZXIuJm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+U28gaGVyZSBjb21lIG1vcmUgdXAtdG8tZGF0ZSByZWZlcmVuY2UgcG9p bnRzIHRvIGNvbXBhcmU6PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSd0ZXh0LWFsaWduOmp1c3RpZnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWFsaWduOmp1c3RpZnknPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6OS4wcHQnPkdyYWNlZnVsIENvbnZlcmdlbmNlIGluIExpbmstU3RhdGUgSVAgTmV0d29y a3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J3RleHQtYWxpZ246anVzdGlmeSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdCc+Ri4g Q2xhZCwgUC4gTcOpcmluZG9sLCBKLi1KLiBQYW5zaW90LCBQLiBGcmFuY29pcyBhbmQgTy4gQm9u YXZlbnR1cmUmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J3RleHQtYWxpZ246anVzdGlmeSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZTo5LjBwdCc+SW4gSUVFRS9BQ00gVHJhbnNhY3Rpb25zIG9uIE5ldHdvcmtpbmcsIDIwMTM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3Rl eHQtYWxpZ246anVzdGlmeSc+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtYWxpZ246anVzdGlmeSc+ZG9jdW1lbnRzIHRoZSBtb3N0 IG9wdGltaXNlZCBhbGdvcml0aG0ga25vd24gc28gZmFyIGZvciB0aGUgbGluayBzaHV0ZG93biBj YXNlLCB3aXRoIGV4dGVuc2l2ZSBzaW11bGF0aW9uIHJlc3VsdHMgYW5kIHBlcmZvcm1hbmNlIGFu YWx5c2lzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0ndGV4dC1hbGlnbjpqdXN0aWZ5Jz48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J3RleHQtYWxpZ246anVzdGlmeSc+PG86cD4mbmJzcDs8L286cD48L3A+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtYWxpZ246anVzdGlmeSc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZTo5LjBwdCc+R3JhY2VmdWwgUm91dGVyIFVwZGF0ZXMgZm9yIExpbmstU3Rh dGUgUHJvdG9jb2xzPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSd0ZXh0LWFsaWduOmp1c3RpZnknPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 OS4wcHQnPkYuIENsYWQsIFAuIE3DqXJpbmRvbCwgUy4gVmlzc2ljY2hpbywgSi4tSi4gUGFuc2lv dCBhbmQgUC4gRnJhbmNvaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtYWxpZ246anVzdGlmeSc+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZTo5LjBwdCc+SW4gcHJvY2VlZGluZ3Mgb2YgSUVFRSBJQ05QIDIwMTMsIEfDtnR0aW5nZW4s IEdlcm1hbnksIE9jdG9iZXIgMjAxMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1hbGlnbjpqdXN0aWZ5Jz48bzpwPiZuYnNwOzwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1hbGlnbjpq dXN0aWZ5Jz5wcm92aWRlcyBhbiBhbGdvcml0aG0gdG8gZG8gdGhlIHNhbWUgaW4gdGhlIG5vZGUg c2h1dGRvd24gY2FzZSwgc21hcnRlciB0aGFuIGRvaW5nIG9uZSBsaW5rIGFmdGVyIHRoZSBvdGhl ci4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0ndGV4dC1hbGlnbjpqdXN0aWZ5Jz48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1hbGlnbjpqdXN0aWZ5Jz5DaGVlcnMsPG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtYWxpZ246 anVzdGlmeSc+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J3RleHQtYWxpZ246anVzdGlmeSc+UGllcnJlLjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPk9uIE9jdCAyMywgMjAxMywgYXQgMjowMSBQTSwgPGEgaHJlZj0ibWFpbHRvOnN0ZXBoYW5l LmxpdGtvd3NraUBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+c3RlcGhhbmUubGl0a293c2tp QG9yYW5nZS5jb208L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48YnI+PGJyPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5IaSw8YnI+PGJy Pkkgd291bGQgbmVlZCBtb3JlIHRpbWUgdG8gcmV2aWV3IHlvdXIgYWxnbyBwYXJ0LiBCdXQgYW55 d2F5LCBjb3VsZCB5b3UgZXhwbGFpbiB0aGUgZGlmZmVyZW5jZSB3aXRoIHNvbWUgb2xkIHB1Ymxp YyBhcHByb2FjaCBsaWtlIHRoZSBwYXBlciBmcm9tIFBpZXJyZSwgTWlrZSBhbmQgT2xpdmllciA6 ICZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9jaXRlc2VlcnguaXN0LnBzdS5lZHUvdmlld2RvYy9kb3du bG9hZD9kb2k9MTAuMS4xLjY3LjgyNjMmYW1wO3JlcD1yZXAxJmFtcDt0eXBlPXBkZiIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHA6Ly9jaXRlc2VlcnguaXN0LnBzdS5lZHUvdmlld2RvYy9kb3dubG9hZD9k b2k9MTAuMS4xLjY3LjgyNjMmYW1wO3JlcD1yZXAxJmFtcDt0eXBlPXBkZjwvYT48YnI+PGJyPk1v cmVvdmVyIEkgd291bGQgYmUgaW50ZXJlc3RlZCB0byBzZWUgaW4geW91ciBkcmFmdCBzb21lIHNp bXVsYXRpb24gcHJvdmluZyB0aGUgbWV0cmljIGxpc3QgaXMgcXVpdGUgbG93IC4uLjxicj5JIGNh biByZW1lbWJlciBpbiB0aGUgcGFwZXIgSSdtIHJlZmVyZW5jaW5nIHRoYXQgdGhlIGNoYWxsZW5n ZSB3YXMgdG8gY29tcHJlc3MgdGhlIEtNUyBsaXN0IGluIG9yZGVyIHRvIHByZXZlbnQgYSB2ZXJ5 IHZlcnkgbG9uZyBsaXN0IHdoaWNoIHdvdWxkIG5vdCBiZSBhcHBsaWNhYmxlIGluIGEgbGl2ZSBu ZXR3b3JrLjxicj48YnI+VGhhbmtzPGJyPjxicj5TdGVwaGFuZTxicj48YnI+PGJyPjxicj4tLS0t LU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08YnI+RGUmbmJzcDs6IDxhIGhyZWY9Im1haWx0bzpydGd3 Zy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRnd2ctYm91bmNlc0BpZXRmLm9y ZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86cnRnd2ctIiB0YXJnZXQ9Il9ibGFuayI+cnRn d2ctPC9hPjxhIGhyZWY9Im1haWx0bzpib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ Ym91bmNlc0BpZXRmLm9yZzwvYT5dIERlIGxhIHBhcnQgZGUgWWFuZ2FuZzxicj5FbnZvecOpJm5i c3A7OiBsdW5kaSAyMSBvY3RvYnJlIDIwMTMgMDM6NDk8YnI+w4AmbmJzcDs6IDxhIGhyZWY9Im1h aWx0bzpydGd3Z0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Z3dnQGlldGYub3JnPC9hPjxi cj5DYyZuYnNwOzogWmhhbmd4dWRvbmcgKHpoYW5neHVkb25nLCBWUlApOyBZYW5nYW5nPGJyPk9i amV0Jm5ic3A7OiBTb2xpY2l0aW5nIFdHIGZlZWRiYWNrIGFuZCBjb21tZW50cyBvbiBkcmFmdC16 eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0wMDxicj48YnI+SGk6PGJyPjxicj5X ZSBoYWQgc3VibWl0dGVkIHRoZSBhIG5ldyBkcmFmdDogPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtenhkLXJ0Z3dnLW9yZGVyZWQtbWV0cmljLWFkanVzdG1lbnQtMDAi IHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16eGQtcnRn d2ctb3JkZXJlZC1tZXRyaWMtYWRqdXN0bWVudC0wMDwvYT4sIHdlIHdhbnQgdG8gZGlzY3VzcyB0 aGUgbWljcm8tbG9vcCBwcm9ibGVtIHRocm91Z2ggYW5vdGhlciBtZXRob2QuIFlvdXIgZmVlZGJh Y2sgYW5kIGNvbW1lbnRzIG9uIHRoZSBydGd3ZyBtYWlsaW5nIGxpc3QgYXJlIGFwcHJlY2lhdGVk LiA8YnI+PGJyPlRoYW5rcyw8YnI+UmFodWwuWWFuPGJyPjxicj4tLS0tLTxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiUE1pbmdMaVUiLCJzZXJpZiInPumCruS7tuWOn+S7tjwvc3Bhbj4tLS0tLTxi cj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlBNaW5nTGlVIiwic2VyaWYiJz7lj5Hku7bkuro8 L3NwYW4+OiA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc8L2E+XSA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJQTWluZ0xp VSIsInNlcmlmIic+5Y+R6YCB5pe26Ze0PC9zcGFuPjogMjAxMzxzcGFuIHN0eWxlPSdmb250LWZh bWlseToiTVMgTWluY2hvIic+5bm0PC9zcGFuPjEwPHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJN UyBNaW5jaG8iJz7mnIg8L3NwYW4+MTg8c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Ik1TIE1pbmNo byInPuaXpTwvc3Bhbj4gMTU6NDc8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJNUyBNaW5j aG8iJz7mlLbku7bkuro8L3NwYW4+OiBaaGFuZ3h1ZG9uZyAoemhhbmd4dWRvbmcsIFZSUCk7IFlh bmdhbmc8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iJz7kuLs8L3NwYW4+ PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJQTWluZ0xpVSIsInNlcmlmIic+6aKYPC9zcGFuPjog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRy aWMtYWRqdXN0bWVudC0wMC50eHQ8YnI+PGJyPjxicj5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtenhkLXJ0Z3dnLW9yZGVyZWQtbWV0cmljLWFkanVzdG1lbnQtMDAudHh0PGJyPmhhcyBiZWVu IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWHVkb25nIFpoYW5nIGFuZCBwb3N0ZWQgdG8gdGhl PGJyPklFVEYgcmVwb3NpdG9yeS48YnI+PGJyPkZpbGVuYW1lOiBkcmFmdC16eGQtcnRnd2ctb3Jk ZXJlZC1tZXRyaWMtYWRqdXN0bWVudDxicj5SZXZpc2lvbjogMDA8YnI+VGl0bGU6IEFsZ29yaXRo bSBmb3IgT3JkZXJlZCBNZXRyaWMgQWRqdXN0bWVudDxicj5DcmVhdGlvbiBkYXRlOiAyMDEzLTEw LTE4PGJyPkdyb3VwOiBJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+TnVtYmVyIG9mIHBhZ2VzOiAx MDxicj5VUkw6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LXp4ZC1ydGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50LTAw LnR4dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LXp4ZC1ydGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50LTAwLnR4dDwvYT48YnI+ U3RhdHVzOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXp4ZC1y dGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16eGQtcnRnd2ctb3JkZXJlZC1tZXRyaWMtYWRq dXN0bWVudDwvYT48YnI+SHRtbGl6ZWQ6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXp4ZC1y dGd3Zy1vcmRlcmVkLW1ldHJpYy1hZGp1c3RtZW50LTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtenhkLXJ0Z3dnLW9yZGVyZWQtbWV0cmljLWFkanVz dG1lbnQtMDA8L2E+PGJyPjxicj48YnI+QWJzdHJhY3Q6PGJyPiZuYnNwOyZuYnNwO1Vwb24gbGlu ayBkb3duIGV2ZW50IG9yIGxpbmsgdXAgZXZlbnQsIGVhY2ggZGV2aWNlIGluIG5ldHdvcms8YnI+ Jm5ic3A7Jm5ic3A7aW5kaXZpZHVhbGx5IHNjaGVkdWxlcyByb3V0ZSBjYWxjdWxhdGlvbi4gJm5i c3A7QmVjYXVzZSBvZiBkaWZmZXJlbnQ8YnI+Jm5ic3A7Jm5ic3A7aGFyZHdhcmUgY2FwYWJpbGl0 aWVzIGFuZCBpbnRlcm5hbC9leHRlcm5hbCBlbnZpcm9ubWVudHMsIHRoZSB0aW1lIHRvPGJyPiZu YnNwOyZuYnNwO3VwZGF0ZSBmb3J3YXJkaW5nIGVudHJpZXMgb24gdGhlc2UgZGV2aWNlcyBhcmUg ZGlzb3JkZXJlZCB3aGljaCBjYW48YnI+Jm5ic3A7Jm5ic3A7Y2F1c2UgYSB0cmFuc2llbnQgZm9y d2FyZGluZyBsb29wLiAmbmJzcDtUaGlzIGRvY3VtZW50IGludHJvZHVjZXMgYSBtZXRob2Q8YnI+ Jm5ic3A7Jm5ic3A7dG8gcHJldmVudCBmb3J3YXJkaW5nIGxvb3AgYnkgYWRqdXN0aW5nIGxpbmsg bWV0cmljIGdyYWR1YWxseSBmb3I8YnI+Jm5ic3A7Jm5ic3A7c2V2ZXJhbCB0aW1lcy48YnI+PGJy Pjxicj48YnI+PGJyPjxicj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPnVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPnRvb2xzLmlldGYub3JnPC9hPi48YnI+PGJyPlRo ZSBJRVRGIFNlY3JldGFyaWF0PGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj5ydGd3ZyBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRv OnJ0Z3dnQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRnd2dAaWV0Zi5vcmc8L2E+PGJyPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnd2ciIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Z3dnPC9h Pjxicj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj48YnI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPGJyPnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0 ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz YWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPGJyPmEgbCdleHBlZGl0ZXVyIGV0 IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBl bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPGJyPk9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48YnI+PGJyPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PGJyPnRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxicj5JZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48YnI+QXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxicj5UaGFuayB5 b3UuPGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj5ydGd3ZyBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOnJ0Z3dnQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+cnRnd2dAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnd2ciIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Z3dnPC9hPjxvOnA+PC9vOnA+PC9w PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2Rp dj48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIu MHB0Jz48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+cnRnd2cgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpydGd3Z0BpZXRmLm9yZyI+ cnRnd2dAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRnd2ciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3J0Z3dnPC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PC9kaXY+PFBSRT5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNz YWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlv bnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFz IGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFs ZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0 ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2Fn ZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQg bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u CklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpB cyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdl cyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlv dS4KPC9QUkU+PC9ib2R5PjwvaHRtbD4= --_000_EEE55384044474429A926C625D0FCC8109902E3E05PUEXCB2Fnante_-- From aretana@cisco.com Thu Oct 31 13:55:47 2013 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 77EFA21F9E76 for ; Thu, 31 Oct 2013 13:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.585 X-Spam-Level: X-Spam-Status: No, score=-10.585 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eKqmezWPv96 for ; Thu, 31 Oct 2013 13:55:37 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD3F11E81B9 for ; Thu, 31 Oct 2013 13:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1121; q=dns/txt; s=iport; t=1383252936; x=1384462536; h=from:to:subject:date:message-id:mime-version; bh=rwFLPi273li70j+kFtTcjXrRy0etUcj3fZxEoDxxpuY=; b=bmtzRJlsTdQLeNuAaoM1eFUyI2dn5kbt8L6v/zW5Fj7o/7TeI0zvFojz jyHlCZQKW0299IMoZERZyvX6St1E6nr8t/SK12snOVEPGUyg1aAvUwq1a 2ZfA5XD2UjPKjrHJkqkEloOxFxKAJIBK2PEgaOhYR2wvbbUqqAv/m0yBS k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgGAD3DclKtJV2b/2dsb2JhbABZgkNEgQy/bYEoFm0HgicBBIELAQsBHlYnBBuHf5sUoWSPHoNYgQ4DqhODJoIq X-IronPort-AV: E=Sophos;i="4.93,611,1378857600"; d="scan'208,217";a="279177241" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 31 Oct 2013 20:55:35 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9VKtZVp002071 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 31 Oct 2013 20:55:35 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.171]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 31 Oct 2013 15:55:35 -0500 From: "Alvaro Retana (aretana)" To: "rtgwg@ietf.org" Subject: Note Taker and Jabber Scribe Thread-Topic: Note Taker and Jabber Scribe Thread-Index: AQHO1nuLByDPyZOpokussYaL8P61ow== Date: Thu, 31 Oct 2013 20:55:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.244.219] Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94E3972B4B5xmbalnx15ciscoc_" 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: Thu, 31 Oct 2013 20:55:47 -0000 --_000_BBD66FD99311804F80324E8139B3C94E3972B4B5xmbalnx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! We need volunteers to take notes and be the Jabber scribe for next week's m= eeting. Thanks! Alvaro. --_000_BBD66FD99311804F80324E8139B3C94E3972B4B5xmbalnx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <0B11F742F5B7654AB7F05A16C8FCAD50@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi!

We need volunteers to take notes and be the Jabber scribe for next wee= k's meeting.

Thanks!

Alvaro.

--_000_BBD66FD99311804F80324E8139B3C94E3972B4B5xmbalnx15ciscoc_-- From aretana@cisco.com Thu Oct 31 19:55:56 2013 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 986A711E82B3 for ; Thu, 31 Oct 2013 19:55:49 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOieprUFUqKQ for ; Thu, 31 Oct 2013 19:55:33 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9D821F9E43 for ; Thu, 31 Oct 2013 19:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3647; q=dns/txt; s=iport; t=1383274525; x=1384484125; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=quAdUPL3wNvfqAhYvVSsRVB5ktxwvXyH4NGEfRCi++g=; b=LcSrPGk7TmtqimR3rq2y9g1wK0jySmHni2tWvEhnOoQwtkEhuUMOub7I OgvyxmZuBrU2Qh073OTqaoIQsW8a0RMdFvR3cGEdK8DyHHcf0WylUQimO c3HV2Izhcl8g3f+V16T0KrbjbtMIFCfxeIiIcJ13h4v6TVYfpFgAa7w0y A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYHAHEXc1KtJXG9/2dsb2JhbABZgkNEOFS/XoEjFm0HgicBBIELAQgEHh05FBECBBMIh38NmxShVgSPHi0LgyCBDgOqE4Mmgio X-IronPort-AV: E=Sophos;i="4.93,613,1378857600"; d="scan'208,217";a="279308717" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 01 Nov 2013 02:55:25 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA12tOw0008755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 1 Nov 2013 02:55:24 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.171]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Thu, 31 Oct 2013 21:55:24 -0500 From: "Alvaro Retana (aretana)" To: "rtgwg@ietf.org" Subject: Re: IETF 88 Agenda Items Thread-Topic: IETF 88 Agenda Items Thread-Index: AQHOvu+xvvXhYYVgF0uuaDZky93MeJoDBJsAgAkbnQCAA85IAA== Date: Fri, 1 Nov 2013 02:55:24 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.245.185] Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94E3972F58Cxmbalnx15ciscoc_" 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: Fri, 01 Nov 2013 02:55:56 -0000 --_000_BBD66FD99311804F80324E8139B3C94E3972F58Cxmbalnx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a reminder that rtgwg will meet on Monday in Vancouver. To the presenters: Please send your slides to the chairs before the meetin= g so we can use one computer to project everything. By "before the meeting= " we mean the latest by Sunday. We may reshuffle the agenda if the slides = have not been received. Thanks! Alvaro. On 10/29/13 12:48 PM, "Alvaro Retana (aretana)" > wrote: On 10/23/13 5:43 PM, "Alvaro Retana (aretana)" > wrote: I just published the draft agenda here: https://datatracker.ietf.org/meeti= ng/88/agenda/rtgwg/ Just updated the agenda to the final one. Alvaro. --_000_BBD66FD99311804F80324E8139B3C94E3972F58Cxmbalnx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <18727F0352CB854FA5CEB83896931709@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Just a reminder that rtgwg will meet on Monday in Vancouver.

To the presenters:  Please send your slides to the chairs before the meeting so we can use one computer to project everyt= hing.  By "before the meeting" we mean the latest by Sunday.=  We may reshuffle the agenda if the slides have not been received.

Thanks!

Alvaro.

On 10/29/13 12:48 PM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

On 10/23/13 5:43 PM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

I just published the draft agenda here:  https://datatracker.ietf.org/meeting/88= /agenda/rtgwg/

Just updated the agenda to the final one.

Alvaro.
 --_000_BBD66FD99311804F80324E8139B3C94E3972F58Cxmbalnx15ciscoc_--