From bashandy@cisco.com Thu Nov 1 11:21:08 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529B321F8FF6 for ; Thu, 1 Nov 2012 11:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.283 X-Spam-Level: X-Spam-Status: No, score=-10.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7hbAZ8wO+JV for ; Thu, 1 Nov 2012 11:21:06 -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 38FE221F8F85 for ; Thu, 1 Nov 2012 11:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7832; q=dns/txt; s=iport; t=1351794066; x=1353003666; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=eeSqTWDF61Ax970QoPfIIgFd8YYqFNBrviWpU3o5FAk=; b=bEexOuyd6ZMD1E8E3SWjxvY2AzXhlHRij77rivZAfxF1XE+BIPqXc7uq lOZ42Ni8uzRoO7TQgCIdT1lXFR8Oix+tZ61n4TUGzWZE602oTHOQdGU/5 z2UE8mLI/qsjWmdqIq6DU0cC0+p//8H/QQRn08rN6/lTY92qL+ihmwq2X U=; X-Files: signature.asc : 248 X-IronPort-AV: E=Sophos;i="4.80,695,1344211200"; d="asc'?scan'208,217";a="137634897" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 01 Nov 2012 18:21:06 +0000 Received: from [10.82.210.28] (rtp-vpn4-540.cisco.com [10.82.210.28]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA1IL3MF014079; Thu, 1 Nov 2012 18:21:04 GMT Message-ID: <5092BD8B.3070605@cisco.com> Date: Thu, 01 Nov 2012 20:20:59 +0200 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "rtgwg@ietf.org" Subject: Fwd: New Version Notification for draft-rtgwg-bgp-pic-00.txt References: <20121001140839.25089.92354.idtracker@ietfa.amsl.com> In-Reply-To: <20121001140839.25089.92354.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.5 X-Forwarded-Message-Id: <20121001140839.25089.92354.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig523FBD60525868C33F92F3B5" Cc: "Pradosh Mohapatra \(pmohapat\)" 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, 01 Nov 2012 18:21:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig523FBD60525868C33F92F3B5 Content-Type: multipart/alternative; boundary="------------040800000208070806050408" This is a multi-part message in MIME format. --------------040800000208070806050408 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, This draft provides an overview of BGP prefix independent convergence and how it is possible to achieve sub-second and, for certain local failures, sub-50msec convergence using hierarchical and shared FIB chain design The basic idea relies on constructing the forwarding chains such that the BGP pathlists are shared among the maximum possible number of BGP prefixes. At the same time, BGP pathlists act as dependents on IGP prefixes in a hierarchy that allows modifying IGP without impacting BGP. The draft will be presented in the RTGWG meeting next week All comments and suggestions are most welcomed Thanks Ahmed -------- Original Message -------- Subject: New Version Notification for draft-rtgwg-bgp-pic-00.txt Date: Mon, 1 Oct 2012 07:08:39 -0700 From: To: CC: , A new version of I-D, draft-rtgwg-bgp-pic-00.txt has been successfully submitted by Ahmed Bashandy and posted to the IETF repository. Filename: draft-rtgwg-bgp-pic Revision: 00 Title: Abstract Creation date: 2012-09-28 WG ID: Individual Submission Number of pages: 19 URL: http://www.ietf.org/internet-drafts/draft-rtgwg-bgp-pic-= 00.txt Status: http://datatracker.ietf.org/doc/draft-rtgwg-bgp-pic Htmlized: http://tools.ietf.org/html/draft-rtgwg-bgp-pic-00 Abstract: In the network comprising thousands of iBGP peers exchanging millions of routes, many routes are reachable via more than one path. Given the large scaling targets, it is desirable to restore traffic after failure in a time period that does not depend on the number of BGP prefixes. In this document we proposed a technique by which traffic can be re-routed to ECMP or pre-calculated backup paths in a timeframe that does not depend on the number of BGP prefixes. The objective is achieved through organizing the forwarding chains in a hierarchical manner and sharing forwarding elements among the maximum possible number of routes. The proposed technique achieves prefix independent convergence while ensuring incremental deployment, complete transparency and automation, and zero management and provisioning effort = =20 The IETF Secretariat --------------040800000208070806050408 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

This draft provides an overview of BGP prefix independent convergence and how it is possible to achieve sub-second and, for certain local failures, sub-50msec convergence using hierarchical and shared FIB chain design

The basic idea relies on constructing the forwarding chains such that the BGP pathlists are shared among the maximum possible number of BGP prefixes. At the same time, BGP pathlists act as dependents on IGP prefixes in a hierarchy that allows modifying IGP without impacting BGP.

The draft will be presented in the RTGWG meeting next week

All comments and suggestions are most welcomed

Thanks

Ahmed

-------- Original Message --------
Sub= ject: New Version Notification for draft-rtgwg-bgp-pic-00.txt
Dat= e: Mon, 1 Oct 2012 07:08:39 -0700
Fro= m: <internet-drafts@ietf.org>
To:= <bashandy@cisco.com>
CC:= <pmohapat@cisco.com>, <cfilsfil@cisco.com><= /td> 


A new version of I-D, draft-rtgwg-bgp-pic-00.txt
has been successfully submitted by Ahmed Bashandy and posted to the
IETF repository.

Filename:	 draft-rtgwg-bgp-pic
Revision:	 00
Title:		 Abstract
Creation date:	 2012-09-28
WG ID:		 Individual Submission
Number of pages: 19
URL:             http://www.ietf.org/in=
ternet-drafts/draft-rtgwg-bgp-pic-00.txt
Status:          http://datatracker.ietf.org/doc/d=
raft-rtgwg-bgp-pic
Htmlized:        http://tools.ietf.org/html/draft-rt=
gwg-bgp-pic-00


Abstract:
In the network comprising thousands of iBGP peers exchanging millions
of routes, many routes are reachable via more than one path. Given
the large scaling targets, it is desirable to restore traffic after
failure in a time period that does not depend on the number of BGP
prefixes. In this document we proposed a technique by which traffic
can be re-routed to ECMP or pre-calculated backup paths in a
timeframe that does not depend on the number of BGP prefixes. The
objective is achieved through organizing the forwarding chains in a
hierarchical manner and sharing forwarding elements among the maximum
possible number of routes. The proposed technique achieves prefix
independent convergence while ensuring incremental deployment,
complete transparency and automation, and zero management and
provisioning effort

                                                                         =
        =20


The IETF Secretariat



--------------040800000208070806050408-- --------------enig523FBD60525868C33F92F3B5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iD8DBQFQkr2P+G19kFA5zIYRAhLfAJ9XptMfMGFh7YmRNkBXsCXQkabLTwCePzbF tEN8sddDWfdNgDMoqWWpwlE= =wAsu -----END PGP SIGNATURE----- --------------enig523FBD60525868C33F92F3B5-- From aretana@cisco.com Fri Nov 2 08:31:46 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B80521F8BA1 for ; Fri, 2 Nov 2012 08:31:46 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYF3ejNRyCkW for ; Fri, 2 Nov 2012 08:31:45 -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 537B721F8B9F for ; Fri, 2 Nov 2012 08:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4333; q=dns/txt; s=iport; t=1351870305; x=1353079905; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=QJkf0RcNDP5G9I39dm8WyOv7kk+YvHtUdMwcUkDd23s=; b=DqtR8mdJrH8eHfb3MjSS0RgvtQd2obgi845ERH5vFi3TIO6WFc3V34Fm b2Xk66/l0JgALrE4bi4EAFgpmj+Wq9zGexnN6EPywfIIumM4mXYeCNru5 qJMx+Mrdqk+MoDRRAeeiMrvZf4aI/DDdPXRoU2zutCJ6oDKv0sP+jCU+A w=; X-Files: ATT00001.txt : 130 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4GAJrmk1CtJXG8/2dsb2JhbABDAYJJhGm8BIEIgiABBAEBAQ8BWx0BDB4PAgwJJQsUEQIEEwgBBRSHaAuaQoEsoBOPKQGCMWEDjnmBIYItkguBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,699,1344211200"; d="txt'?scan'208,217";a="138237225" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 02 Nov 2012 15:31:44 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA2FVi0U010355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 2 Nov 2012 15:31:44 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.50]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 10:31:44 -0500 From: "Alvaro Retana (aretana)" To: "rtgwg@ietf.org" Subject: Reminder to Presenters (rtgwg Agenda + Slides) Thread-Topic: Reminder to Presenters (rtgwg Agenda + Slides) Thread-Index: AQHNuQ8pgyeIqDm2HEqdljNt0oFeSQ== Date: Fri, 2 Nov 2012 15:31:44 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.245.198] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--38.955800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/mixed; boundary="_004_BBD66FD99311804F80324E8139B3C94EAA3747xmbalnx15ciscocom_" 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, 02 Nov 2012 15:31:46 -0000 --_004_BBD66FD99311804F80324E8139B3C94EAA3747xmbalnx15ciscocom_ Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94EAA3747xmbalnx15ciscocom_" --_000_BBD66FD99311804F80324E8139B3C94EAA3747xmbalnx15ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://www.ietf.org/proceedings/85/agenda/agenda-85-rtgwg I have still not received any final slides for Monday! Please see below. Thanks! Alvaro. On 10/24/12 12:48 PM, "Alvaro Retana (aretana)" > wrote: Note to presenters: The time on the agenda includes presentation and discu= ssion, so please plan accordingly. You MUST send your slides to the chairs= before the day of the meeting (local Atlanta time). Given that the WG mee= ting is scheduled for Monday (Nov/5 at 1pm in Salon E), we SHOULD receive a= ll presentations by the end of the day on Friday Nov/2 (pick your favorite = timezone). The chairs MAY change the order of the presentations based on s= lide availability. --_000_BBD66FD99311804F80324E8139B3C94EAA3747xmbalnx15ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

I have still not received any final slides for Monday!  Please se= e below.

Thanks!

Alvaro.

On 10/24/12 12:48 PM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

Note to presenters:  The time on the agenda includes presentation and disc= ussion, so please plan accordingly.  You MUST send your slides to the = chairs before the day = of the meeting (local Atlanta time).  Given that the WG meeting is scheduled for Monday (Nov/5 at 1pm in Salon E), we SHOULD recei= ve all presentations by the end of the day on Friday Nov/2 (pick your favor= ite timezone).  The chairs MAY change the order of the presentations b= ased on slide availability.
 --_000_BBD66FD99311804F80324E8139B3C94EAA3747xmbalnx15ciscocom_-- --_004_BBD66FD99311804F80324E8139B3C94EAA3747xmbalnx15ciscocom_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=130; creation-date="Fri, 02 Nov 2012 15:31:44 GMT"; modification-date="Fri, 02 Nov 2012 15:31:44 GMT" Content-ID: <7A9217D2CC081A43827CA28971170408@cisco.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Z3dnIG1h aWxpbmcgbGlzdA0KcnRnd2dAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcnRnd2cNCg== --_004_BBD66FD99311804F80324E8139B3C94EAA3747xmbalnx15ciscocom_-- From akatlas@gmail.com Fri Nov 2 09:46:10 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6073D21F8CC3 for ; Fri, 2 Nov 2012 09:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.598 X-Spam-Level: X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9O5NTyoVtcqp for ; Fri, 2 Nov 2012 09:46:09 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2E421F8AB1 for ; Fri, 2 Nov 2012 09:46:09 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so6021826iec.31 for ; Fri, 02 Nov 2012 09:46:09 -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=dzoxqkhBAhjqXwMl+wFE49bVjmBgdMW3ADsgpQ+wmo0=; b=EKfZGsbDvsGkP0OrMEFOAAcsI7rZiFCSZPGxYMSZ8iM0FI0WqSdbfNmUci8S4CFFZg Y1vd/9l2ur/vfgY/06PKUbZ3O55OpiFgN1m11Ea7FhwkSDY7wBXN+xPtCFXU9rod9Flo GXBcucR2kfajpbhgrp4+8pytF74LH5JxyD9BIIgNjqP6vzOl2wFFZGUT7gxYw+zAfq8+ gcX75WwMoA+Q0kIlH/mLR4SUsykS02r81AaQ+dNSJzE5Cc2paMxYC7/0Em9G2KW3zlaV v1Pri74caTwBoPjBtZiB5Pm7q70miYiB1Sfhv7pfysNG+Y0zFFsMtGrQpkF6Pp//HLzW Lgaw== MIME-Version: 1.0 Received: by 10.50.187.194 with SMTP id fu2mr2314911igc.63.1351874767345; Fri, 02 Nov 2012 09:46:07 -0700 (PDT) Received: by 10.50.45.39 with HTTP; Fri, 2 Nov 2012 09:46:07 -0700 (PDT) Date: Fri, 2 Nov 2012 12:46:07 -0400 Message-ID: Subject: Remote Participation for rtgwg: WebEx session information From: Alia Atlas To: "rtgwg@ietf.org" Content-Type: multipart/alternative; boundary=14dae9340de349d7e104cd85dfb3 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, 02 Nov 2012 16:46:10 -0000 --14dae9340de349d7e104cd85dfb3 Content-Type: text/plain; charset=ISO-8859-1 ---------- Forwarded message ---------- From: Cindy Morgan Date: Fri, Nov 2, 2012 at 12:42 PM Subject: Meeting invitation: rtgwg To: akatlas@gmail.com Hello , Cindy Morgan invites you to attend this online meeting. Topic: rtgwg Date: Monday, November 5, 2012 Time: 1:00 pm, Eastern Standard Time (New York, GMT-05:00) Meeting Number: 641 593 753 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?ED=163901742&UID=1286525702&PW=NMDZkMmQ5NWUx&RT=MiMxMQ%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?ED=163901742&UID=1286525702&PW=NMDZkMmQ5NWUx&ORT=MiMxMQ%3D%3D ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: cmorgan@amsl.com 1-510-492-4085 To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ietf.webex.com/ietf/j.php?ED=163901742&UID=1286525702&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAp8D7qSvz27mmhPQehH6EmFKPK1TBJ4W-cRp3cgz6RPh&RT=MiMxMQ%3D%3D The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. --14dae9340de349d7e104cd85dfb3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

---------- Forwarded message ----------<= br>From: Cindy Morgan &= lt;messenger@webex.com>
Date: Fri, Nov 2, 2012 at 12:42 PM
Subject: Meeting invitation: rtgwgTo: akatlas@gmail.com


=
Hello ,
Cindy Morgan invites you to attend this online meeting.

Top= ic: rtgwg
Date: Monday, November 5, 2012
Time: 1:00 pm, Eastern S= tandard Time (New York, GMT-05:00)
Meeting Number: 641 593 753
Meeting Password: 1234


------------------------------------= -------------------
To join the online meeting (Now from mobile device= s!)
-------------------------------------------------------
1. Go= to h= ttps://ietf.webex.com/ietf/j.php?ED=3D163901742&UID=3D1286525702&PW= =3DNMDZkMmQ5NWUx&RT=3DMiMxMQ%3D%3D
2. If requested, enter your name and email address.
3. If a password = is required, enter the meeting password: 1234
4. Click "Join"= ;.

To view in other time zones or languages, please click the lin= k:
htt= ps://ietf.webex.com/ietf/j.php?ED=3D163901742&UID=3D1286525702&PW= =3DNMDZkMmQ5NWUx&ORT=3DMiMxMQ%3D%3D


-------------------------------------------------------
For= assistance
------------------------------------------------------- 1. Go to ht= tps://ietf.webex.com/ietf/mc
2. On the left navigation bar, click "Support".

You ca= n contact me at:
cmorgan@amsl.com
1-510-492-4085

To add this meeting to your calendar program (for example Microsoft O= utlook), click this link:
https://ietf.webex.com/ietf/j.php?ED=3D1= 63901742&UID=3D1286525702&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1= &SHA2=3DAAAAAp8D7qSvz27mmhPQehH6EmFKPK1TBJ4W-cRp3cgz6RPh&RT=3DMiMxM= Q%3D%3D

The playback of UCF (Universal Communications Format) rich media file= s requires appropriate players. To view this type of rich media files in th= e meeting, please check whether you have the players installed on your comp= uter by going to https://ietf.webex.com/ietf/systemdiagnosis.php.
Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial=

http://ww= w.webex.com



IMPORTANT NOTICE: This WebEx service includes a feature tha= t allows audio and any documents and other materials exchanged or viewed du= ring the session to be recorded. By joining this session, you automatically= consent to such recordings. If you do not consent to the recording, discus= s your concerns with the meeting host prior to the start of the recording o= r do not join the session. Please note that any such recordings may be subj= ect to discovery in the event of litigation.

--14dae9340de349d7e104cd85dfb3-- From aretana@cisco.com Sat Nov 3 04:41:09 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BF721F9C55 for ; Sat, 3 Nov 2012 04:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.598 X-Spam-Level: X-Spam-Status: No, score=-12.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrFG3+f20+Un for ; Sat, 3 Nov 2012 04:41:08 -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 9ECF621F9C4D for ; Sat, 3 Nov 2012 04:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8228; q=dns/txt; s=iport; t=1351942853; x=1353152453; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=M05jthNdmhOkEtazGFPD9X8LfvCOba+E+bC8husKMZU=; b=JGZMenviWWBIpPyMq+gPYMf1RD+M4S1/le1Jxrft11w9fAMMUlKRjxar ++h4xVcC8i/4Ruc9m+HBPeJomMuAEXLY57IM+flAP4op78raw+fkWVUrh kPSsImQHIgvgwHkMEOEElJpe/U2Nd/na5ChURxE8L0hXumIcDh4RJIwh0 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJYBlVCtJXG//2dsb2JhbAAqFwOCScBqgQiCHgEBAQQSARwmNgEIDgMDAQILDgwDKBEUCQgCBAESCAEZh1YDDwstmk2RM4RNDYlUixlogxIHgkJhA5QmjQiDJoFrgm+BZBce X-IronPort-AV: E=Sophos;i="4.80,705,1344211200"; d="scan'208,217";a="138433551" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 03 Nov 2012 11:40:53 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA3BeqMJ032467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Nov 2012 11:40:52 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.50]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 06:40:52 -0500 From: "Alvaro Retana (aretana)" To: Alia Atlas , "rtgwg@ietf.org" Subject: Re: Remote Participation for rtgwg: WebEx session information Thread-Topic: Remote Participation for rtgwg: WebEx session information Thread-Index: AQHNuRmWPggxj0CfoUS8VDKll6fyrZfYDraA Date: Sat, 3 Nov 2012 11:40:52 +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.211.149] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001 x-tm-as-result: No--58.149600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94EAA4EDCxmbalnx15ciscocom_" 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: Sat, 03 Nov 2012 11:41:09 -0000 --_000_BBD66FD99311804F80324E8139B3C94EAA4EDCxmbalnx15ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The Audio Streaming information is here: http://www.ietf.org/meeting/85/re= mote-participation.html Alvaro. On 11/2/12 2:46 PM, "Alia Atlas" > wrote: ---------- Forwarded message ---------- From: Cindy Morgan > Date: Fri, Nov 2, 2012 at 12:42 PM Subject: Meeting invitation: rtgwg To: akatlas@gmail.com Hello , Cindy Morgan invites you to attend this online meeting. Topic: rtgwg Date: Monday, November 5, 2012 Time: 1:00 pm, Eastern Standard Time (New York, GMT-05:00) Meeting Number: 641 593 753 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?ED=3D163901742&UID=3D1286525702&= PW=3DNMDZkMmQ5NWUx&RT=3DMiMxMQ%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?ED=3D163901742&UID=3D1286525702&PW=3DNMDZ= kMmQ5NWUx&ORT=3DMiMxMQ%3D%3D ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: cmorgan@amsl.com 1-510-492-4085 To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link: https://ietf.webex.com/ietf/j.php?ED=3D163901742&UID=3D1286525702&ICS=3DMI&= LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAp8D7qSvz27mmhPQehH6EmFKPK1TBJ4W-cRp3cgz6RP= h&RT=3DMiMxMQ%3D%3D The playback of UCF (Universal Communications Format) rich media files requ= ires appropriate players. To view this type of rich media files in the meet= ing, please check whether you have the players installed on your computer b= y going to https://ietf.webex.com/ietf/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. --_000_BBD66FD99311804F80324E8139B3C94EAA4EDCxmbalnx15ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
The Audio Streaming information is here:  http://www.ietf.org/meeting/8= 5/remote-participation.html

Alvaro.

On 11/2/12 2:46 PM, "Alia Atlas" <akatlas@gmail.com> wrote:



---------- Forwarded message ----------
From: Cindy Morgan <= messenger@webex.com> Date: Fri, Nov 2, 2012 at 12:42 PM
Subject: Meeting invitation: rtgwg
To: akatlas@gmail.com



Hello ,

Cindy Morgan invites you to attend this online meeting.

Topic: rtgwg
Date: Monday, November 5, 2012
Time: 1:00 pm, Eastern Standard Time (New York, GMT-05:00)
Meeting Number: 641 593 753
Meeting Password: 1234


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://ietf.webex.com/ietf/j.php?ED=3D163901742&UID=3D1286525702&P= W=3DNMDZkMmQ5NWUx&RT=3DMiMxMQ%3D%3D
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: 1234
4. Click "Join".

To view in other time zones or languages, please click the link:
http= s://ietf.webex.com/ietf/j.php?ED=3D163901742&UID=3D1286525702&PW=3D= NMDZkMmQ5NWUx&ORT=3DMiMxMQ%3D%3D


-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https= ://ietf.webex.com/ietf/mc
2. On the left navigation bar, click "Support".

You can contact me at:
cmorgan@amsl.com =
1-510-492-4085

To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link:
https://ietf.webex.com/ietf/j.php?ED=3D163901742&UID=3D1286525702&am= p;ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAp8D7qSvz27mmhPQ= ehH6EmFKPK1TBJ4W-cRp3cgz6RPh&RT=3DMiMxMQ%3D%3D

The playback of UCF (Universal Communications Format) rich media files requ= ires appropriate players. To view this type of rich media files in the meet= ing, please check whether you have the players installed on your computer b= y going to https://ietf.webex.com/ietf/systemdiagnosis.php.

Sign up for a free trial of WebEx
http://= www.webex.com/go/mcemfreetrial

http://www.webex.com=



IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the= start of the recording or do not join the session. Please note that any su= ch recordings may be subject to discovery in the event of litigation.

--_000_BBD66FD99311804F80324E8139B3C94EAA4EDCxmbalnx15ciscocom_-- From aretana@cisco.com Sun Nov 4 17:45:55 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749F321F8817 for ; Sun, 4 Nov 2012 17:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJliLkH53YmH for ; Sun, 4 Nov 2012 17:45:54 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 7C90721F8618 for ; Sun, 4 Nov 2012 17:45:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1094; q=dns/txt; s=iport; t=1352079954; x=1353289554; h=from:to:subject:date:message-id:mime-version; bh=Q1LRM1D9iS6kfNOZRj2E3omYD2edmqSfoHGtlCTPE0Y=; b=hudIdeNBF4HbBz3OGoVagZlF0y4Sliw8BBl077DR4nFbHI3DCffJg0z5 h/vpLTpi2TzHUwBzsUwiQxmD093UGUhExhlFu2zyFDcADNxGlmPMclevb xRvudq+Z9j5N8aoSq13AlvGlpiN3yT3M8taI6jCYdoBncDGkKkQseAK7d w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABYal1CtJXHB/2dsb2JhbABEgknAbYEIgiABBBIBeAELAQIcVicEGxqHaJhCgSufCJFcYQOkVIFrgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,712,1344211200"; d="scan'208,217";a="138677242" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 05 Nov 2012 01:45:50 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA51joFP008888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 5 Nov 2012 01:45:50 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.50]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Sun, 4 Nov 2012 19:45:49 -0600 From: "Alvaro Retana (aretana)" To: "rtgwg@ietf.org" Subject: Scribes for rtgwg Thread-Topic: Scribes for rtgwg Thread-Index: AQHNuvdH9/JSVnQZ2Eud0XvZD8AIwg== Date: Mon, 5 Nov 2012 01:45:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.248.146] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19338.004 x-tm-as-result: No--23.014100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94EAA7B79xmbalnx15ciscocom_" 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: Mon, 05 Nov 2012 01:45:55 -0000 --_000_BBD66FD99311804F80324E8139B3C94EAA7B79xmbalnx15ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! We need both a Jabber scribe and someone to take meeting notes. Volunteers? Thanks! Alvaro. --_000_BBD66FD99311804F80324E8139B3C94EAA7B79xmbalnx15ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi!

We need both a Jabber scribe and someone to take meeting notes.

Volunteers?

Thanks!

Alvaro.
--_000_BBD66FD99311804F80324E8139B3C94EAA7B79xmbalnx15ciscocom_-- From lizhong.jin@zte.com.cn Thu Nov 8 03:33:50 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8225621F8A44 for ; Thu, 8 Nov 2012 03:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z45qdCWawRjB for ; Thu, 8 Nov 2012 03:33:49 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 08C0B21F86AB for ; Thu, 8 Nov 2012 03:33:49 -0800 (PST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 0FCE0127D152; Thu, 8 Nov 2012 19:34:58 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qA8BXbNQ044964; Thu, 8 Nov 2012 19:33:37 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: ice@cisco.com Subject: Re: draft-wijnands-rtgwg-mcast-frr-tn-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Thu, 8 Nov 2012 19:32:48 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-11-08 19:33:32, Serialize complete at 2012-11-08 19:33:32 Content-Type: multipart/alternative; boundary="=_alternative 003F813C48257AB0_=" X-MAIL: mse01.zte.com.cn qA8BXbNQ044964 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, 08 Nov 2012 11:33:50 -0000 This is a multipart message in MIME format. --=_alternative 003F813C48257AB0_= Content-Type: text/plain; charset="US-ASCII" Hi Ice, I have one concern with the DTNP mechanism. When a node receives a DTNP from its primary UMH and the node has a secondary UMH for which no DTNP had been received beforehand, it unblocks its secondary UMH. But later it received DTNP from a secondary UMH, then the node again has to block its secondary UMH, right? It would be common that the node will receive DTNP from primary UMH earlier than secondary UMH, then there would be a flip flop in a transient time. Have you considered this issue before? Thanks Lizhong > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 23 Oct 2012 22:03:05 +0200 > From: IJsbrand Wijnands > To: rtgwg@ietf.org > Subject: draft-wijnands-rtgwg-mcast-frr-tn-00.txt > Message-ID: > Content-Type: text/plain; charset=us-ascii > > Hi Folks, > > I like to encourage the WG to read through this draft so that we can > have productive discussion at the IETF. > > In short, this draft proposes two enhancements to Multicast Only > Fast ReRoute (draft-ietf-rtgwg-mofrr-00). > > 1. A router on the tree that detects a failure on its upstream (RPF) > interface injects a Downstream Tree Notification (DTN) down the tree > to notify (potential) downstream MoFRR routers. When a downstream > MoFRR router has received such notification, it will switch to the > backup path. The notification is sent as data down the tree and > forwarded as 'normal' data by non-MoFRR routers. In order to allow > Fast Convergence to happen, originating and processing of the TN > message must happen in the data-plane, similar to how BFD packets > are processed in the data-plane. The big different with BFD is that > TN packets are not periodic, but only triggered when a failure happens. > > 2. With normal MoFRR, packets are received over two diverse paths to > the MoFRR router. While in many cases this is not considered to be a > problem, there are situations where the additional bandwidth may be > worth saving. For this cases we are proposing to join the backup > path in 'standby' mode, such that forwarding state is programmed, > but no data is actually forwarded. When a failure has happened on > the tree (detected by Downstream TN or directly connected link > failure) an Upstream Tree Notification (UTN) is originated up the > tree to reset the non-forwarding state. This notification is also > originated and processed in the data-plane. Note, this is optional > functionality. The main advantage of this draft comes from option 1. > > Thx, > > Andras, Jeff and Ice. > > > > > Begin forwarded message: > > > From: internet-drafts@ietf.org > > Subject: I-D Action: draft-wijnands-rtgwg-mcast-frr-tn-00.txt > > Date: 15 Oct 2012 21:22:11 GMT+02:00 > > To: i-d-announce@ietf.org > > Reply-To: internet-drafts@ietf.org > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Tree Notification to Improve Multicast Fast Reroute > > Author(s) : IJsbrand Wijnands > > Andras Csaszar > > Jeff Tantsura > > Filename : draft-wijnands-rtgwg-mcast-frr-tn-00.txt > > Pages : 18 > > Date : 2012-10-15 > > > > Abstract: > > This draft proposes using dataplane triggered notifications in order > > to support multicast fast reroute methods in various ways. Sending > > such notifications down the tree can be used to trigger fail-over in > > nodes not adjacent to the failure. Sending such dataplane > > notification up the tree can help to activate pre-built standby > > backup tree segments. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-wijnands-rtgwg-mcast-frr-tn > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-wijnands-rtgwg-mcast-frr-tn-00 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > --=_alternative 003F813C48257AB0_= Content-Type: text/html; charset="US-ASCII"
Hi Ice,
I have one concern with the DTNP mechanism. When a node receives a DTNP from its primary UMH and the node has a secondary UMH for which no DTNP had been received beforehand, it unblocks its secondary UMH. But later it received DTNP from a secondary UMH, then the node again has to block its secondary UMH, right?
It would be common that the node will receive DTNP from primary UMH earlier than secondary UMH, then there would be a flip flop in a transient time. Have you considered this issue before?

Thanks
Lizhong

>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 23 Oct 2012 22:03:05 +0200
> From: IJsbrand Wijnands <ice@cisco.com>
> To: rtgwg@ietf.org
> Subject: draft-wijnands-rtgwg-mcast-frr-tn-00.txt
> Message-ID: <B8A2779A-971F-4404-89E9-E7AF3D981999@cisco.com>
> Content-Type: text/plain; charset=us-ascii
>
> Hi Folks,
>
> I like to encourage the WG to read through this draft so that we can
> have productive discussion at the IETF.
>
> In short, this draft proposes two enhancements to Multicast Only
> Fast ReRoute (draft-ietf-rtgwg-mofrr-00).
>
> 1. A router on the tree that detects a failure on its upstream (RPF)
> interface injects a Downstream Tree Notification (DTN) down the tree
> to notify (potential) downstream MoFRR routers. When a downstream
> MoFRR router has received such notification, it will switch to the
> backup path. The notification is sent as data down the tree and
> forwarded as 'normal' data by non-MoFRR routers. In order to allow
> Fast Convergence to happen, originating and processing of the TN
> message must happen in the data-plane, similar to how BFD packets
> are processed in the data-plane. The big different with BFD is that
> TN packets are not periodic, but only triggered when a failure happens.
>
> 2. With normal MoFRR, packets are received over two diverse paths to
> the MoFRR router. While in many cases this is not considered to be a
> problem, there are situations where the additional bandwidth may be
> worth saving. For this cases we are proposing to join the backup
> path in 'standby' mode, such that forwarding state is programmed,
> but no data is actually forwarded. When a failure has happened on
> the tree (detected by Downstream TN or directly connected link
> failure) an Upstream Tree Notification (UTN) is originated up the
> tree to reset the non-forwarding state. This notification is also
> originated and processed in the data-plane. Note, this is optional
> functionality. The main advantage of this draft comes from option 1.
>
> Thx,
>
> Andras, Jeff and Ice.
>
>
>
>
> Begin forwarded message:
>
> > From: internet-drafts@ietf.org
> > Subject: I-D Action: draft-wijnands-rtgwg-mcast-frr-tn-00.txt
> > Date: 15 Oct 2012 21:22:11 GMT+02:00
> > To: i-d-announce@ietf.org
> > Reply-To: internet-drafts@ietf.org
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >
> >
> >    Title           : Tree Notification to Improve Multicast Fast Reroute
> >    Author(s)       : IJsbrand Wijnands
> >                          Andras Csaszar
> >                          Jeff Tantsura
> >    Filename        : draft-wijnands-rtgwg-mcast-frr-tn-00.txt
> >    Pages           : 18
> >    Date            : 2012-10-15
> >
> > Abstract:
> >   This draft proposes using dataplane triggered notifications in order
> >   to support multicast fast reroute methods in various ways.  Sending
> >   such notifications down the tree can be used to trigger fail-over in
> >   nodes not adjacent to the failure.  Sending such dataplane
> >   notification up the tree can help to activate pre-built standby
> >   backup tree segments.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-wijnands-rtgwg-mcast-frr-tn
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-wijnands-rtgwg-mcast-frr-tn-00
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > I-D-Announce@ietf.org
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
>
>
> --=_alternative 003F813C48257AB0_=-- From ice@cisco.com Thu Nov 8 08:01:10 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5BF21F8A5E for ; Thu, 8 Nov 2012 08:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EN-mgv34P9sl for ; Thu, 8 Nov 2012 08:01:09 -0800 (PST) Received: from av-tac-sj.cisco.com (av-tac-sj.cisco.com [171.68.227.119]) by ietfa.amsl.com (Postfix) with ESMTP id E3D4821F8B0C for ; Thu, 8 Nov 2012 08:01:09 -0800 (PST) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA8G11Qq025870; Thu, 8 Nov 2012 08:01:01 -0800 (PST) Received: from [10.21.167.211] ([10.21.167.211]) by fire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA8G0vFe020057; Thu, 8 Nov 2012 08:01:01 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: draft-wijnands-rtgwg-mcast-frr-tn-00.txt From: IJsbrand Wijnands In-Reply-To: Date: Thu, 8 Nov 2012 11:00:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3F74EF58-23BF-4CE9-88AF-95AFEE9864D7@cisco.com> References: To: Lizhong Jin 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: Thu, 08 Nov 2012 16:01:10 -0000 Hi Lizhong, > I have one concern with the DTNP mechanism. When a node receives a = DTNP from its primary UMH and the node has a secondary UMH for which no = DTNP had been received beforehand, it unblocks its secondary UMH. But = later it received DTNP from a secondary UMH, then the node again has to = block its secondary UMH, right?=20 > It would be common that the node will receive DTNP from primary UMH = earlier than secondary UMH, then there would be a flip flop in a = transient time. Have you considered this issue before?=20 Yes, this is a situation where the MoFRR router can't repair the = failure, because the upstream path was shared by the primary and backup = path. The MoFRR router may switch to the secondary UMH unnecessary (for = a short time), but it will not flip-flop. The MoFRR router keeps track = of getting a DTNP on both primary and secondary (section 3.2). If this = happens, the DTNP will be forwarded downstream to allow an other = downstream MoFRR router to repair the failure. If there is no other = MoFRR router, it means MoFRR did not provide full coverage to remedy the = failure.=20 Thx, Ice. >=20 > Thanks=20 > Lizhong >=20 >=20 > >=20 > > = ---------------------------------------------------------------------- > >=20 > > Message: 1 > > Date: Tue, 23 Oct 2012 22:03:05 +0200 > > From: IJsbrand Wijnands > > To: rtgwg@ietf.org > > Subject: draft-wijnands-rtgwg-mcast-frr-tn-00.txt > > Message-ID: > > Content-Type: text/plain; charset=3Dus-ascii > >=20 > > Hi Folks, > >=20 > > I like to encourage the WG to read through this draft so that we can > > have productive discussion at the IETF. > >=20 > > In short, this draft proposes two enhancements to Multicast Only=20 > > Fast ReRoute (draft-ietf-rtgwg-mofrr-00). > >=20 > > 1. A router on the tree that detects a failure on its upstream (RPF) > > interface injects a Downstream Tree Notification (DTN) down the tree > > to notify (potential) downstream MoFRR routers. When a downstream=20 > > MoFRR router has received such notification, it will switch to the=20= > > backup path. The notification is sent as data down the tree and=20 > > forwarded as 'normal' data by non-MoFRR routers. In order to allow=20= > > Fast Convergence to happen, originating and processing of the TN=20 > > message must happen in the data-plane, similar to how BFD packets=20 > > are processed in the data-plane. The big different with BFD is that=20= > > TN packets are not periodic, but only triggered when a failure = happens. > >=20 > > 2. With normal MoFRR, packets are received over two diverse paths to > > the MoFRR router. While in many cases this is not considered to be a > > problem, there are situations where the additional bandwidth may be=20= > > worth saving. For this cases we are proposing to join the backup=20 > > path in 'standby' mode, such that forwarding state is programmed,=20 > > but no data is actually forwarded. When a failure has happened on=20 > > the tree (detected by Downstream TN or directly connected link=20 > > failure) an Upstream Tree Notification (UTN) is originated up the=20 > > tree to reset the non-forwarding state. This notification is also=20 > > originated and processed in the data-plane. Note, this is optional=20= > > functionality. The main advantage of this draft comes from option 1. > >=20 > > Thx, > >=20 > > Andras, Jeff and Ice. > >=20 > >=20 > >=20 > >=20 > > Begin forwarded message: > >=20 > > > From: internet-drafts@ietf.org > > > Subject: I-D Action: draft-wijnands-rtgwg-mcast-frr-tn-00.txt > > > Date: 15 Oct 2012 21:22:11 GMT+02:00 > > > To: i-d-announce@ietf.org > > > Reply-To: internet-drafts@ietf.org > > >=20 > > >=20 > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > >=20 > > >=20 > > > Title : Tree Notification to Improve Multicast Fast = Reroute > > > Author(s) : IJsbrand Wijnands > > > Andras Csaszar > > > Jeff Tantsura > > > Filename : draft-wijnands-rtgwg-mcast-frr-tn-00.txt > > > Pages : 18 > > > Date : 2012-10-15 > > >=20 > > > Abstract: > > > This draft proposes using dataplane triggered notifications in = order > > > to support multicast fast reroute methods in various ways. = Sending > > > such notifications down the tree can be used to trigger = fail-over in > > > nodes not adjacent to the failure. Sending such dataplane > > > notification up the tree can help to activate pre-built standby > > > backup tree segments. > > >=20 > > >=20 > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-wijnands-rtgwg-mcast-frr-tn > > >=20 > > > There's also a htmlized version available at: > > > http://tools.ietf.org/html/draft-wijnands-rtgwg-mcast-frr-tn-00 > > >=20 > > >=20 > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > >=20 > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > Internet-Draft directories: http://www.ietf.org/shadow.html > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >=20 > >=20 > >=20 > > From lizhong.jin@zte.com.cn Mon Nov 12 04:29:58 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF79A21F8485 for ; Mon, 12 Nov 2012 04:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.656 X-Spam-Level: X-Spam-Status: No, score=-101.656 tagged_above=-999 required=5 tests=[AWL=0.942, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebwOKCb5FajL for ; Mon, 12 Nov 2012 04:29:57 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id E18A621F8570 for ; Mon, 12 Nov 2012 04:29:56 -0800 (PST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 895CD12B0C94; Mon, 12 Nov 2012 20:31:12 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qACCTlrI015036; Mon, 12 Nov 2012 20:29:47 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: <3F74EF58-23BF-4CE9-88AF-95AFEE9864D7@cisco.com> To: IJsbrand Wijnands Subject: Re: draft-wijnands-rtgwg-mcast-frr-tn-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Mon, 12 Nov 2012 20:29:45 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-11-12 20:29:36, Serialize complete at 2012-11-12 20:29:36 Content-Type: multipart/alternative; boundary="=_alternative 0044A69D48257AB4_=" X-MAIL: mse01.zte.com.cn qACCTlrI015036 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, 12 Nov 2012 12:29:58 -0000 This is a multipart message in MIME format. --=_alternative 0044A69D48257AB4_= Content-Type: text/plain; charset="US-ASCII" Hi Ice, Thank you for the reply. Yes, it is not flip-flop, but unnecessary switch. Overall, I think this is a useful draft. Thanks Lizhong IJsbrand Wijnands wrote 2012/11/09 00:00:58: > Hi Lizhong, > > > I have one concern with the DTNP mechanism. When a node receives a > DTNP from its primary UMH and the node has a secondary UMH for which > no DTNP had been received beforehand, it unblocks its secondary UMH. > But later it received DTNP from a secondary UMH, then the node again > has to block its secondary UMH, right? > > It would be common that the node will receive DTNP from primary > UMH earlier than secondary UMH, then there would be a flip flop in a > transient time. Have you considered this issue before? > > Yes, this is a situation where the MoFRR router can't repair the > failure, because the upstream path was shared by the primary and > backup path. The MoFRR router may switch to the secondary UMH > unnecessary (for a short time), but it will not flip-flop. The MoFRR > router keeps track of getting a DTNP on both primary and secondary > (section 3.2). If this happens, the DTNP will be forwarded > downstream to allow an other downstream MoFRR router to repair the > failure. If there is no other MoFRR router, it means MoFRR did not > provide full coverage to remedy the failure. > > Thx, > > Ice. > > > > > Thanks > > Lizhong > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > Message: 1 > > > Date: Tue, 23 Oct 2012 22:03:05 +0200 > > > From: IJsbrand Wijnands > > > To: rtgwg@ietf.org > > > Subject: draft-wijnands-rtgwg-mcast-frr-tn-00.txt > > > Message-ID: > > > Content-Type: text/plain; charset=us-ascii > > > > > > Hi Folks, > > > > > > I like to encourage the WG to read through this draft so that we can > > > have productive discussion at the IETF. > > > > > > In short, this draft proposes two enhancements to Multicast Only > > > Fast ReRoute (draft-ietf-rtgwg-mofrr-00). > > > > > > 1. A router on the tree that detects a failure on its upstream (RPF) > > > interface injects a Downstream Tree Notification (DTN) down the tree > > > to notify (potential) downstream MoFRR routers. When a downstream > > > MoFRR router has received such notification, it will switch to the > > > backup path. The notification is sent as data down the tree and > > > forwarded as 'normal' data by non-MoFRR routers. In order to allow > > > Fast Convergence to happen, originating and processing of the TN > > > message must happen in the data-plane, similar to how BFD packets > > > are processed in the data-plane. The big different with BFD is that > > > TN packets are not periodic, but only triggered when a failure happens. > > > > > > 2. With normal MoFRR, packets are received over two diverse paths to > > > the MoFRR router. While in many cases this is not considered to be a > > > problem, there are situations where the additional bandwidth may be > > > worth saving. For this cases we are proposing to join the backup > > > path in 'standby' mode, such that forwarding state is programmed, > > > but no data is actually forwarded. When a failure has happened on > > > the tree (detected by Downstream TN or directly connected link > > > failure) an Upstream Tree Notification (UTN) is originated up the > > > tree to reset the non-forwarding state. This notification is also > > > originated and processed in the data-plane. Note, this is optional > > > functionality. The main advantage of this draft comes from option 1. > > > > > > Thx, > > > > > > Andras, Jeff and Ice. > > > > > > > > > > > > > > > Begin forwarded message: > > > > > > > From: internet-drafts@ietf.org > > > > Subject: I-D Action: draft-wijnands-rtgwg-mcast-frr-tn-00.txt > > > > Date: 15 Oct 2012 21:22:11 GMT+02:00 > > > > To: i-d-announce@ietf.org > > > > Reply-To: internet-drafts@ietf.org > > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > > > > > > > > > Title : Tree Notification to Improve Multicast Fast Reroute > > > > Author(s) : IJsbrand Wijnands > > > > Andras Csaszar > > > > Jeff Tantsura > > > > Filename : draft-wijnands-rtgwg-mcast-frr-tn-00.txt > > > > Pages : 18 > > > > Date : 2012-10-15 > > > > > > > > Abstract: > > > > This draft proposes using dataplane triggered notifications in order > > > > to support multicast fast reroute methods in various ways. Sending > > > > such notifications down the tree can be used to trigger fail-over in > > > > nodes not adjacent to the failure. Sending such dataplane > > > > notification up the tree can help to activate pre-built standby > > > > backup tree segments. > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > https://datatracker.ietf.org/doc/draft-wijnands-rtgwg-mcast-frr-tn > > > > > > > > There's also a htmlized version available at: > > > > http://tools.ietf.org/html/draft-wijnands-rtgwg-mcast-frr-tn-00 > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > _______________________________________________ > > > > I-D-Announce mailing list > > > > I-D-Announce@ietf.org > > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > Internet-Draft directories: http://www.ietf.org/shadow.html > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > > > --=_alternative 0044A69D48257AB4_= Content-Type: text/html; charset="US-ASCII"
Hi Ice,
Thank you for the reply. Yes, it is not flip-flop, but unnecessary switch. Overall, I think this is a useful draft.

Thanks
Lizhong

 

IJsbrand Wijnands <ice@cisco.com> wrote 2012/11/09 00:00:58:

> Hi Lizhong,
>
> > I have one concern with the DTNP mechanism. When a node receives a
> DTNP from its primary UMH and the node has a secondary UMH for which
> no DTNP had been received beforehand, it unblocks its secondary UMH.
> But later it received DTNP from a secondary UMH, then the node again
> has to block its secondary UMH, right?
> > It would be common that the node will receive DTNP from primary
> UMH earlier than secondary UMH, then there would be a flip flop in a
> transient time. Have you considered this issue before?
>
> Yes, this is a situation where the MoFRR router can't repair the
> failure, because the upstream path was shared by the primary and
> backup path. The MoFRR router may switch to the secondary UMH
> unnecessary (for a short time), but it will not flip-flop. The MoFRR
> router keeps track of getting a DTNP on both primary and secondary
> (section 3.2).  If this happens, the DTNP will be forwarded
> downstream to allow an other downstream MoFRR router to repair the
> failure. If there is no other MoFRR router, it means MoFRR did not
> provide full coverage to remedy the failure.
>
> Thx,
>
> Ice.
>
> >
> > Thanks
> > Lizhong
> >
> >
> > >
> > > ----------------------------------------------------------------------
> > >
> > > Message: 1
> > > Date: Tue, 23 Oct 2012 22:03:05 +0200
> > > From: IJsbrand Wijnands <ice@cisco.com>
> > > To: rtgwg@ietf.org
> > > Subject: draft-wijnands-rtgwg-mcast-frr-tn-00.txt
> > > Message-ID: <B8A2779A-971F-4404-89E9-E7AF3D981999@cisco.com>
> > > Content-Type: text/plain; charset=us-ascii
> > >
> > > Hi Folks,
> > >
> > > I like to encourage the WG to read through this draft so that we can
> > > have productive discussion at the IETF.
> > >
> > > In short, this draft proposes two enhancements to Multicast Only
> > > Fast ReRoute (draft-ietf-rtgwg-mofrr-00).
> > >
> > > 1. A router on the tree that detects a failure on its upstream (RPF)
> > > interface injects a Downstream Tree Notification (DTN) down the tree
> > > to notify (potential) downstream MoFRR routers. When a downstream
> > > MoFRR router has received such notification, it will switch to the
> > > backup path. The notification is sent as data down the tree and
> > > forwarded as 'normal' data by non-MoFRR routers. In order to allow
> > > Fast Convergence to happen, originating and processing of the TN
> > > message must happen in the data-plane, similar to how BFD packets
> > > are processed in the data-plane. The big different with BFD is that
> > > TN packets are not periodic, but only triggered when a failure happens.
> > >
> > > 2. With normal MoFRR, packets are received over two diverse paths to
> > > the MoFRR router. While in many cases this is not considered to be a
> > > problem, there are situations where the additional bandwidth may be
> > > worth saving. For this cases we are proposing to join the backup
> > > path in 'standby' mode, such that forwarding state is programmed,
> > > but no data is actually forwarded. When a failure has happened on
> > > the tree (detected by Downstream TN or directly connected link
> > > failure) an Upstream Tree Notification (UTN) is originated up the
> > > tree to reset the non-forwarding state. This notification is also
> > > originated and processed in the data-plane. Note, this is optional
> > > functionality. The main advantage of this draft comes from option 1.
> > >
> > > Thx,
> > >
> > > Andras, Jeff and Ice.
> > >
> > >
> > >
> > >
> > > Begin forwarded message:
> > >
> > > > From: internet-drafts@ietf.org
> > > > Subject: I-D Action: draft-wijnands-rtgwg-mcast-frr-tn-00.txt
> > > > Date: 15 Oct 2012 21:22:11 GMT+02:00
> > > > To: i-d-announce@ietf.org
> > > > Reply-To: internet-drafts@ietf.org
> > > >
> > > >
> > > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > directories.
> > > >
> > > >
> > > >    Title           : Tree Notification to Improve Multicast Fast Reroute
> > > >    Author(s)       : IJsbrand Wijnands
> > > >                          Andras Csaszar
> > > >                          Jeff Tantsura
> > > >    Filename        : draft-wijnands-rtgwg-mcast-frr-tn-00.txt
> > > >    Pages           : 18
> > > >    Date            : 2012-10-15
> > > >
> > > > Abstract:
> > > >   This draft proposes using dataplane triggered notifications in order
> > > >   to support multicast fast reroute methods in various ways.  Sending
> > > >   such notifications down the tree can be used to trigger fail-over in
> > > >   nodes not adjacent to the failure.  Sending such dataplane
> > > >   notification up the tree can help to activate pre-built standby
> > > >   backup tree segments.
> > > >
> > > >
> > > > The IETF datatracker status page for this draft is:
> > > > https://datatracker.ietf.org/doc/draft-wijnands-rtgwg-mcast-frr-tn
> > > >
> > > > There's also a htmlized version available at:
> > > > http://tools.ietf.org/html/draft-wijnands-rtgwg-mcast-frr-tn-00
> > > >
> > > >
> > > > Internet-Drafts are also available by anonymous FTP at:
> > > > ftp://ftp.ietf.org/internet-drafts/
> > > >
> > > > _______________________________________________
> > > > I-D-Announce mailing list
> > > > I-D-Announce@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/i-d-announce
> > > > Internet-Draft directories: http://www.ietf.org/shadow.html
> > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > >
> > >
> > >
> > >
>
--=_alternative 0044A69D48257AB4_=-- From stephane.litkowski@orange.com Tue Nov 13 00:08:58 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4DB21F88DF; Tue, 13 Nov 2012 00:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmTFUWBxTxKA; Tue, 13 Nov 2012 00:08:58 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7829821F88DC; Tue, 13 Nov 2012 00:08:57 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 1F4753B4472; Tue, 13 Nov 2012 09:08:56 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 0526A238070; Tue, 13 Nov 2012 09:08:56 +0100 (CET) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.54]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Tue, 13 Nov 2012 09:08:55 +0100 From: To: "mpls@ietf.org" , "rtgwg@ietf.org" Date: Tue, 13 Nov 2012 09:08:54 +0100 Subject: TR: I-D Action: draft-litkowski-rtgwg-lfa-rsvpte-cooperation-00.txt Thread-Topic: I-D Action: draft-litkowski-rtgwg-lfa-rsvpte-cooperation-00.txt Thread-Index: Ac3BcsBJvj5Ic4hjTYauSayNHfFdqwAAsxGQ Message-ID: <18235_1352794136_50A20018_18235_520_1_EEE55384044474429A926C625D0FCC81045D1CEB30@PUEXCB2F.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 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, 13 Nov 2012 08:08:59 -0000 Hi Folks, We currently have some deployment scenarios where LFA and RSVP-TE are confi= gured at the same time, and basically we would like to propose some guideli= nes on how LFA should behave in such scenarios.=20 We would be pleased to received your feedback. Thanks, Stephane -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de internet-drafts@ietf.org Envoy=E9 : mardi 13 novembre 2012 08:44 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-litkowski-rtgwg-lfa-rsvpte-cooperation-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Interactions between LFA and RSVP-TE Author(s) : Stephane Litkowski Bruno Decraene Clarence Fils Fils Kamran Raza Filename : draft-litkowski-rtgwg-lfa-rsvpte-cooperation-00.txt Pages : 12 Date : 2012-11-12 Abstract: RSVP-TE FRR is a well known and deployed technology for fast reroute, and there are some use cases where LFA and RSVP-TE may interact. This document clarifies the behavior of LFA when RSVP-TE tunnels are used simultaneously. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-litkowski-rtgwg-lfa-rsvpte-cooperati= on There's also a htmlized version available at: http://tools.ietf.org/html/draft-litkowski-rtgwg-lfa-rsvpte-cooperation-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From adrian@olddog.co.uk Tue Nov 27 07:21:01 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81A021F8574 for ; Tue, 27 Nov 2012 07:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvFEDPQdWRHV for ; Tue, 27 Nov 2012 07:21:00 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 199A021F84F6 for ; Tue, 27 Nov 2012 07:20:59 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id qARFKwuL012551; Tue, 27 Nov 2012 15:20:58 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id qARFKvvp012545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Nov 2012 15:20:58 GMT From: "Adrian Farrel" To: References: <0b7c01cda01e$e07fb020$a17f1060$@olddog.co.uk> In-Reply-To: <0b7c01cda01e$e07fb020$a17f1060$@olddog.co.uk> Subject: RE: AD review of draft-ietf-rtgwg-ordered-fib Date: Tue, 27 Nov 2012 15:20:57 -0000 Message-ID: <033c01cdccb2$cd479d40$67d6d7c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEgnNNDO/5OFriVIcgokQFicDvUYJlYK84A Content-Language: en-gb Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 15:21:01 -0000 Authors and shepherd, Are there any plans to move this document forward? Thanks, Adrian > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of > Adrian Farrel > Sent: 01 October 2012 22:51 > To: draft-ietf-rtgwg-ordered-fib.all@tools.ietf.org > Cc: rtgwg@ietf.org > Subject: AD review of draft-ietf-rtgwg-ordered-fib > > Hi, > > I've done my usual AD review of your draft prior to issuing IETF last > call and passing the I-D for IESG evaluation. The main purpose of the > review is to catch issues that might come up in later reviews and to > ensure that the document is ready for publication as and RFC. > > I have a number of concerns that I believe will necessitate a new > revision of the document, so I will put it into "Revised I-D Needed" > state in the data tracker and wait to hear from you. > > As always, all my comments are up for discussion and negotiation. > > Thanks for the work, > Adrian > > ==== > > Purpose and direction of the document.... > > It's all very interesting, but why are we publishing it? What is it > adding? What is the purpose? > > If this is intended to be simply a record of discussions: > 1. It should say so > 2. It should say that more work is needed to examine the mechanism > before any attempt is made to convert it to a protocol > 3. I don't need to review it for technical accuracy > 4. I don't understand why the working group wants to publish it > 5. I can't decide on the value of improving the document to make it more > easy to read. > > The document doesn't seem to have any *use*. > > What does WG consensus mean for this document? That there is consensus > to publish it, or that there is consensus behind the content? If the > former, why? If the latter, what does this mean? > > After discussion of this point with a WG chair and with one of the > authors, it seems that it would be reasonable to add a significant note > to the Abstract and the Introduction about the purpose. This would say > something along the lines of... > > The idea is to capture the current state of discussions in the WG so > that they are not lost, can be referenced, and might be picked up again > later. The WG currently has no interest in pursuing these ideas > further. > > --- > > Notwithstanding the discussion of scope in the point above, the Abstract > should state the scope and purpose of the document and the mechanism. If > this is a framework of a guidance for actual protocol mechanisms, it > should say that clearly and should indicate that: > - the mechanisms described need to be equally and conformantly > implemented by every node in the "network" (is that OSPF area or > IS-IS level?) > - this document only describes the principles, but does not specify the > protocol details for exchange of information and synchronization of > actions between routers in the network. > > --- > > I am a little bothered by the use of 2119 language in this document. Do > you believe you are using it to define a conformant implementation, and > how is conformance measured if the mechanism is not for implementation? > Or are you trying to use it to set requirements for the protocol > specification that might follow? Wouldn't normal English usage be just > as good? > > --- > > In email on the WG list you said: > > > The expected use of this technology in the failure case > > is in conjunction with IPFRR where following a protected > > failure, and in the absence of a convergence control > > technology, microloops may form and/or the repair > > may be staved. > > But this *really* is not apparent in this document until at the end of > Section 4.2 you have: > > The sudden failure of a link or a set of links that are not protected > using a FRR mechanism must be processed using the conventional mode > of operation. > > Thus, reading the document, very many questions arise and there is a lot > of confusion which has to be unpicked in the light of this fact. > > Indeed, the example in Figure 1 doesn't mention the FRR protection, and > the discussion seems to assume no such protection. > > Furthermore, in the Abstract it says: > This mechanism can be used in the case of non-urgent link or node > shutdowns and restarts or link metric changes. It can also be used > in conjunction with a fast re-route mechanism which converts a sudden > link or node failure into a non-urgent topology change. This is > possible where a complete repair path is provided for all affected > destinations. > implying that FRR is only one of the options. > > --- > > The fact that the oFIB process operates on a timer could possibly be > drawn out a little sooner. > > --- > > It is pretty well hidden that this mechanism only applies in a network > where all routers apply the mechanism. In fact, I suspect that that > limitation isn't quite true, and there are fringe conditions where > routers would not need to be upgraded. But, anyway, what you clearly > need to indicate is that the mechanism depends on a way to detect that > all routers operate the mechanism. And you should probably discuss a > little what happens if one or more routers in the network do not > participate. > > --- > > While I would agree that Section 8 describes a state machine that > produces the desired black-box behavior of an oFIB capable router, I > would suggest that it is not a requirement that oFIB capable routers > directly implement this state machine. > > You might change the section to say that the state machine describes the > behavior that an oFIB capable router must demonstrate. > > --- > > Section 8.4 suddenly introduces "LSP" and "AAH" > > AAH finally shows in Appendix A. > > --- > > Transitions to Abandoned and the text in Section 8.5 don't seem to > describe normal FIB updates (i.e. non-oFIB) but surely they have to be > done. Maybe that is what AAH stands for, but Appendix A seems to suggest > that AAH is an unknown (needing more research) and it is very unclear > what "Trigger AAH" actually means across the whole of Section 8. Yet > that line item appears a lot and is clearly an essential part of the > mechanism. > > --- > > Section 10 should at least point at B.4. > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From aretana@cisco.com Tue Nov 27 09:48:55 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBA221F8661 for ; Tue, 27 Nov 2012 09:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5eWfsM7KkiL for ; Tue, 27 Nov 2012 09:48:54 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 778B421F8641 for ; Tue, 27 Nov 2012 09:48:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=219; q=dns/txt; s=iport; t=1354038534; x=1355248134; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=CnJdMLf0oFunpJtpiGqkucGV2QhggUp21keL84NAQ/0=; b=W1KYJGsutU0XLW2+Tv5HCG1aN70dD9lXUoTrEbygvwLmNfoa47rFgWzp mR7X5FH1HvwgHzehJzZbiFdak3GIv/tZoitCYVGk5IKhEyH8ApwtgvfZs T9kwEcX22QT/vz8cBwDTOiQwEoYE41428Nlk35KMWBTtSF3IJKoyBorMT A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwKAP/7tFCtJXHA/2dsb2JhbABFhWK5LQQEgQcWc4IgAQQ6PxIBCCIUQiUBAQQBDQUIiAWwOZBJkBphA6ZFgnCCIA X-IronPort-AV: E=McAfee;i="5400,1158,6909"; a="143734390" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 27 Nov 2012 17:48:54 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qARHmsFY012819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Nov 2012 17:48:54 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.208]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 11:48:53 -0600 From: "Alvaro Retana (aretana)" To: "adrian@olddog.co.uk" , "draft-ietf-rtgwg-ordered-fib.all@tools.ietf.org" Subject: Re: AD review of draft-ietf-rtgwg-ordered-fib Thread-Topic: AD review of draft-ietf-rtgwg-ordered-fib Thread-Index: Ac2gHt23L7KiHt6bQxOcXBrENofYLgsxjlWA///VfwA= Date: Tue, 27 Nov 2012 17:48:52 +0000 Message-ID: In-Reply-To: <033c01cdccb2$cd479d40$67d6d7c0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.236.103] Content-Type: text/plain; charset="us-ascii" Content-ID: <2913AFB6AD04C4439592AECE7DABF62E@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, 27 Nov 2012 17:48:55 -0000 On 11/27/12 10:20 AM, "Adrian Farrel" wrote: >Are there any plans to move this document forward? Yes. Stewart and I talked a few weeks ago and he will produce an updated draft. Alvaro. From adrian@olddog.co.uk Tue Nov 27 15:32:27 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C0F21E8030 for ; Tue, 27 Nov 2012 15:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpaNxVGsBNDQ for ; Tue, 27 Nov 2012 15:32:23 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id D9EF221E8034 for ; Tue, 27 Nov 2012 15:32:22 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id qARNWK4B017235; Tue, 27 Nov 2012 23:32:20 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id qARNWJbf017220 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Nov 2012 23:32:20 GMT From: "Adrian Farrel" To: References: <05f201cdac19$72ac3260$58049720$@olddog.co.uk> In-Reply-To: <05f201cdac19$72ac3260$58049720$@olddog.co.uk> Subject: RE: AD review of draft-ietf-rtgwg-ipfrr-notvia-addresses Date: Tue, 27 Nov 2012 23:32:19 -0000 Message-ID: <047c01cdccf7$71eb5910$55c20b30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKMOahqsbpvmEHaRx2w74LqSAffqJaBeyDA Content-Language: en-gb Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 23:32:27 -0000 At the risk of being a pain... The working group asked for publication of this document and over 40 days ago I sent a review that asked for two relatively minor actions. Can I hope for these to be completed soon? Thanks, Adrian > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of > Adrian Farrel > Sent: 17 October 2012 04:43 > To: draft-ietf-rtgwg-ipfrr-notvia-addresses.all@tools.ietf.org > Cc: rtgwg@ietf.org > Subject: AD review of draft-ietf-rtgwg-ipfrr-notvia-addresses > > Hi, > > I've done my usual AD review of your draft prior to issuing IETF last > call and passing the I-D for IESG evaluation. The main purpose of the > review is to catch issues that might come up in later reviews and to > ensure that the document is ready for publication as and RFC. > > I only have a small point that needs to be resolved in a new revision of > the document, so I will put it into "Revised I-D Needed" state in the > data tracker and wait to hear from you. > > But I would also like the document shepherd to make an update to the > write-up as described below. > > As always, all my comments are up for discussion and negotiation. > > Thanks for the work, > Adrian > > === > > The Shepherd write-up says... > > > There is consensus in the WG to proceed with publication. > > Looking at the mailing list, I see no comments positive or negative > during WG last call. What is more, I see no discussion of the I-D > going back four years (at which point I lost the will to search > further). How do you justify there being WG consensus for this document? > > I think this issue can be resolved by a revision to the write-up with > some explanation of the justification for publishing this as a WG > document. I would also like the write-up to explain the purpose of the > document as discussed in the following point. > > --- > > I was also unclear why you want to publish the document at all. I see a > note from Alvaro (extending the WG last call for an extra week) that > says: > > > this document is being published as an Informational RFC for > > completeness purposes...as has been discussed in the mailing list and > > live meetings. > > So I think that gives me the intended purpose: completeness. But I don't > know what that means, and the document doesn't help me at all. > > Furthermore, I couldn't find the discussion of this intention to publish > on the mailing list. > > Based on some conversations with Stewart, I understand that the idea > here is to capture the current state of discussions in the WG so that > they are not lost. But I also assume that the WG has no interest in > pursuing these ideas further. So it would be reasonable to add a > significant note to the Abstract and the Introduction about the > purpose. This would say something along the lines of... > > The idea is to capture the current state of discussions in the WG so > that they are not lost, can be referenced, and might be picked up > again later. The WG currently has no interest in pursuing these ideas > further. It is not intended that this document as currently written > should form the basis of an implementation or deployment. > > With this in mind, my review is considerably lighter than it would be > for a standards track protocol specification, and I think the document > will be fine for advancement. > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg